Save bandwidth ideas: Support for resolution limits in config file and more

[Fijxu]

Should be easy. I have no problem in implementing it myself.

https://git.nadeko.net/Fijxu/invidious/commit/8f46bd57519c08f18f09166fe0c062921853099c

[unixfox]

In my opinion I would prefer to artifically limit the max resolution in video.js: https://github.com/videojs/http-streaming#vhsrepresentations

This way anyone can still select 1080p but by default for example only up to 720p will automatically be tested by video.js. This should greatly reduce the strain of the bandwidth used.

What do you think?

[Fijxu]

Good idea, but that would only limit the resolution on the Invidious front-end, not for every third party program that uses Invidious to fetch the videos (e.g: FreeTube, Clipious, yt-dlp for downloads). What I'm looking for with this pull request is a hard resolution limit, for everyone. IMO this is useful for public instance maintainers that have fixed bandwidth limits and low link speeds

[unixfox]

Good idea, but that would only limit the resolution on the Invidious front-end, not for every third party program that uses Invidious to fetch the videos (e.g: FreeTube, Clipious, yt-dlp for downloads). What I'm looking for with this pull request is a hard resolution limit, for everyone. IMO this is useful for public instance maintainers that have fixed bandwidth limits and low link speeds

All the 3rd parties does not use the dash manifest API. They use the invidious API.

This means that we have to do some filtering on the video data given back to invidious. Once the API will be supported because right now it is not: #22

In my opinion, for a public instance 95% of the bandwidth is going to be consumed by people using the invidious frontend, not the 3rd party clients. So artificially limiting on the invidious frontend will already help a lot.

PS: yt-dlp does not download from the invidious server, the tool just detects invidious and assume it's a youtube link then download from youtube servers directly.

[Fijxu]

This means that we have to do some filtering on the video data given back to invidious. Once the API will be supported because right now it is not: #22

I see

PS: yt-dlp does not download from the invidious server, the tool just detects invidious and assume it's a youtube link then download from youtube servers directly.

I have seen people trying to use Invidious with yt-dlp to download videos since they can't download videos directly from youtube.
Reference: https://github.com/grqz/yt-dlp-invidious

[unixfox]

While looking at the video.js specification, I found something interesting to reduce the bandwidth used: https://github.com/videojs/http-streaming/blob/main/docs/bitrate-switching.md

---

PS: yt-dlp does not download from the invidious server, the tool just detects invidious and assume it's a youtube link then download from youtube servers directly.

I have seen people trying to use Invidious with yt-dlp to download videos since they can't download videos directly from youtube. Reference: grqz/yt-dlp-invidious

IMO if it's an issue for you, you should:

• turn on "verify_requests": https://github.com/iv-org/invidious-companion/blob/master/config/default.toml. Any endpoints like latest_version and dash manifest won't work without a check ID generated through the frontend
• block the API requests