Thumbnail process loads high res streams

[christoph-heinrich]

Turns out the problem was introduced in acc092d, see comments.

It seems like the subprocess doesn't use some of the passed arguments, but from looking at the code that doesn't make sense 😕.

I was curious about how fast it would get thumbnails if I use a format that has video and audio, because those don't get throttled by YouTube (or at least far less).
So I replaced the line
"--ytdl-format=worst", "--demuxer-readahead-secs=0", "--demuxer-max-bytes=128KiB", with
"--ytdl-format=18", "--demuxer-max-bytes=1GiB",, but based on bandwidth usage, it doesn't use the right format. If i use the same options on the main mpv instance, it buffers the whole video very quickly and uses a lot more bandwidth, so the options should work.
I also tried other format options like --ytdl-format=313, which has a resolution of 3840x1920, but based on the bandwidth usage there is no way it actually loads a video with that resolution.

Also with the default --ytdl-format=worst it should use format 17, which has a resolution of 176x144, but the resulting thumbnail certainly isn't from that format (that format has a different aspect ratio, so the thumbnail should either have a different aspect ratio, or be distorted).

I'm certain that I'm editing the correct file, because I've put a print statement in the spawn function, and that shows up in the console (two times actually).

[christoph-heinrich]

So, had a feeling that network streams used to have a black border and bad image quality before i actually cloned the repo. So I made the thumbnail really big and bisected it. From acc092d onward it loads way too big thumbnails. Setting a max size of 1000x1000 still looks sharp.

[christoph-heinrich]

Oh I know, stream-open-filename contains the url that mpv streams, so if mpv loads a 4k video, then that is the direct url to that 4k video. No wonder that the ytdl-format option doesn't do anything.

Edit: Replacing "--ytdl-format=worst", "--demuxer-readahead-secs=0", "--demuxer-max-bytes=128KiB", with "--ytdl-format=18", "--demuxer-max-bytes=1GiB", makes the thumbnailing much more usable on long videos (otherwise it'is practically unusable on 2+ hour videos). Of course the cache doesn't have to be that big, but maybe it makes sense to introduce a cache size option, with e.g. 2/3 of that size being used for forward caching and 1/3 for backward caching.

[po5]

Yeah this is a temporary change until I implement proper YouTube thumbnails.
Ideally I do not want to download the video all over again to generate thumbs.
I know how to do it without having to reorder a lot of code, it's just a time investment I haven't made yet.

[christoph-heinrich]

Alright, looking forward to it 😉

[po5]

I started to work on yt-dlp storyboard support, fetching and cutting into individual thumbnails is done.
Currently missing the display logic, hope to have a branch with fast yt support this week (:

[rotorotoroto]

Any progress on this? Started working on a yt-dlp storyboard thumbnail addon before bumping into this thread.

Another option once storyboard thumbnail support is added is to allow the storyboard thumbnails to be used at first but use the current method after the thumbnail video is downloaded. This allows quick thumbnails while "upgrading" the quality later on.

Yeah this is a temporary change until I implement proper YouTube thumbnails. Ideally I do not want to download the video all over again to generate thumbs. I know how to do it without having to reorder a lot of code, it's just a time investment I haven't made yet.

This should be removed. It causes the network option to be unusable if you're watching high definition videos as the thumbnails never really end up showing and wastes A LOT of bandwidth. I didn't realize that I was downloading the 4k videos I was watching twice. All negatives really.