Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
yt-dl does not always pull the 'best' version by default, or even when commanded. #18203
It appears that yt-dl is not always pulling the 'best' version by default, or even when commanded.
For the longest time, I fully assumed that a command for a merged version of the 'best mp4' and 'best m4a' would produce an absolute 'best video possible' end result, but that's not the case here (or with many other videos).
According to the -F readout, .f136 is the 'best' separate video, not .f135. So why didn't it grab .f136 instead? Additionally, .f22 appears to have the best video and audio already in single-file form.
So I tested the defaults to see what it would grab:
Same deal. It tries to grab the apparent 'second best' of the individual, separate components, fully ignoring the higher quality 'single-file' option that's available (.f22).
The only way to get the truly 'best' version of this, and many others, is to specifically call for it:
The problem here is that automating the task (where there can be no review of the
Is there a way to instruct yt-dl to make a determination of 'true best' by comparing the best complete video with the best individual components (i.e. make it a little smarter)?
It appears to me that .f22 has the highest bitrate (mp4a.40.2@192k) compared to either of the audio-only options (mp4a.40.5@ 48k or mp4a.40.2@128k), while it's video component is HD720, as opposed to .f135's lesser 480 format. yt-dl also has .f22 marked as (best), but then ignores that when using the defaults.
Which is why I'm still asking: