--prefer-free-formats does not prefer webm to mp4

[kparal]

$ youtube-dl 'https://www.youtube.com/watch?v=r9rGX91rq5I' -v -F
[debug] System config: [u'--prefer-free-formats']
[debug] User config: []
[debug] Command-line args: [u'https://www.youtube.com/watch?v=r9rGX91rq5I', u'-v', u'-F']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2015.06.04.1
[debug] Python version 2.7.10 - Linux-4.0.5-300.1.kparal.fc22.x86_64-x86_64-with-fedora-22-Twenty_Two
[debug] exe versions: ffmpeg 2.6.3, ffprobe 2.6.3
[debug] Proxy map: {}
[youtube] r9rGX91rq5I: Downloading webpage
[youtube] r9rGX91rq5I: Extracting video information
[youtube] r9rGX91rq5I: Downloading DASH manifest
[info] Available formats for r9rGX91rq5I:
format code  extension  resolution note
171          webm       audio only DASH audio  108k , audio@128k (44100Hz), 3.84MiB
140          m4a        audio only DASH audio  127k , m4a_dash container, aac  @128k (44100Hz), 4.76MiB
278          webm       256x144    DASH video   62k , webm container, VP9, 15fps, video only, 1.23MiB
242          webm       426x240    DASH video  112k , 30fps, video only, 1.88MiB
160          mp4        256x144    DASH video  122k , 15fps, video only, 3.37MiB
243          webm       640x360    DASH video  205k , 30fps, video only, 3.59MiB
244          webm       854x480    DASH video  281k , 30fps, video only, 6.15MiB
134          mp4        640x360    DASH video  297k , 30fps, video only, 3.44MiB
133          mp4        426x240    DASH video  307k , 30fps, video only, 7.54MiB
135          mp4        854x480    DASH video  626k , 30fps, video only, 7.05MiB
247          webm       1280x720   DASH video  645k , 30fps, video only, 14.85MiB
248          webm       1920x1080  DASH video 1204k , 30fps, video only, 27.42MiB
136          mp4        1280x720   DASH video 1286k , 30fps, video only, 14.79MiB
137          mp4        1920x1080  DASH video 2521k , 30fps, video only, 29.69MiB
271          webm       2560x1440  DASH video 3741k , 30fps, video only, 66.79MiB
264          mp4        2560x1440  DASH video 5990k , 30fps, video only, 96.12MiB
313          webm       3840x2160  DASH video 9743k , VP9, 30fps, video only, 157.88MiB
266          mp4        3840x2160  DASH video 10775k , h264, 30fps, video only, 152.25MiB
17           3gp        176x144    
36           3gp        320x240    
5            flv        400x240    
18           mp4        640x360    
43           webm       640x360    
22           mp4        1280x720   (best)

$ youtube-dl 'https://www.youtube.com/watch?v=r9rGX91rq5I' -v --get-format
[debug] System config: [u'--prefer-free-formats']
[debug] User config: []
[debug] Command-line args: [u'https://www.youtube.com/watch?v=r9rGX91rq5I', u'-v', u'--get-format']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2015.06.04.1
[debug] Python version 2.7.10 - Linux-4.0.5-300.1.kparal.fc22.x86_64-x86_64-with-fedora-22-Twenty_Two
[debug] exe versions: ffmpeg 2.6.3, ffprobe 2.6.3
[debug] Proxy map: {}
266 - 3840x2160 (DASH video)+140 - audio only (DASH audio)

Please note that [debug] System config: [u'--prefer-free-formats'] shows that I have preference to free formats enabled, but youtube-dl wants to download mp4 instead (266+140).

[dstftw]

This is expected behavior. --prefer-free-formats is only respected when non-free and free formats are of the same quality. 266 (mp4) has higher bitrate than 313 (webm) therefore is selected. You may want to use -f bestvideo[ext=webm]+bestaudio[ext=webm]/best[ext=webm].

[rg3]

I think the option documentation should mention that. Right now it reads:

Prefer free video formats unless a specific one is requested

[kparal]

The bitrate will never be exactly the same, it will always differ slightly. But higher bit rate doesn't imply higher quality, it depends on the codec. So that assumption is somewhat off.

But as @rg3 says, that option is not about quality, at least as it is currently documented. It says "pick the free format, if it is available". It does not speak about quality at all. So maybe the current implementation is expected by the developers, but certainly not by the users.

And, if only quality is concerned, what would be the point of such an option? If mp4 has slightly better bitrate, it is picked. If webm has slightly better bitrate, it is picked. Such option would have no effect at all, because it is already the default behavior!

So really, this option should mean "I always want free formats, if they are available, otherwise fall back to proprietary formats". That's how I want to configure youtube-dl. Please make it possible. Thank you.

[kparal]

You may want to use -f bestvideo[ext=webm]+bestaudio[ext=webm]/best[ext=webm].

I can use this, but I guess that will fail for videos which don't have a webm version. So I would have to do this: -f bestvideo[ext=webm]+bestaudio[ext=webm]/best[ext=webm]/bestvideo+bestaudio/best

However, when I download videos for my tablet (not PC), I want to avoid 4K videos. So I need height filters. And then the filter gets really complicated.

I would much rather have --prefer-free-formats work as documented, than very complicated command line arguments.

[yan12125]

Opening as I think --prefer-free-formats should behave as documented.

[dstftw]

@kparal --prefer-free-formats won't anyhow help you avoiding 4K, you'll need to use filters anyway. @yan12125 I don't think this behavior should be changed since it's an expected behavior from the beginning and changing it will break in general the main youtube-dl's purpose - downloading best available quality. Documentation however should be clarified, yes. What you suggest is an --require-free-formats option that was already rejected previousy.

[kparal]

What I'm saying is that there's no easy way to prefer free formats (regardless of quality, literally prefer) without writing an explosive set of command line arguments. That's also the case of aforementioned #2196 - it gives a workaround, but it's neither simple nor clean, if you want to cover all the cases. (And I don't think anything was rejected - "you are welcome to contribute a patch that adds one").

@dstftw Can you please clarify what is the purpose of --prefer-free-formats as you see it? I still don't understand it. Does it work only for formats with exactly the same resolution/fps/bitrate? Doesn't that have like 0.00001% chance of occurring? Does it make sense to have an option that almost never applies, because bitrate is never exactly the same? What is the logic when that option is not given - a random format is picked, or always a proprietary one?

In my understanding "require" has different meaning than "prefer". When you require a free format, you pick the best free format, and if it is not available, you fail with an error ("free format required, but none available"). When you prefer a free format, you pick the best free format, and if it is not available, you pick the best non-free format.

[kparal]

One further argument - some Linux distributions like Fedora add --prefer-free-formats to the default configuration file, see here: http://pkgs.fedoraproject.org/cgit/youtube-dl.git/tree/youtube-dl.conf

The reason is that h264/aac/other codecs are neither installed by default nor offered in the repositories, because of patent issues. So the wish of the package maintainers of youtube-dl is to allow all Fedora/other distro users to make as many videos playable by default as possible - that means they want to configure youtube-dl to download free formats every time it is possible to do so. So that it is really useful for all users, and not just for those who live outside of USA + other countries where software patents apply and installed proprietary codecs. They don't want to require it, because downloading something is better than downloading nothing, but they want to prefer it as much as possible.

[jaimeMF]

I agree with @kparal, I think that with --prefer-free-formats if the formats have the same resolution it should choose the webm. I don't think that giving higher priority to the filesize and bitrate is the best solution, I don't really know how useful is comparing them for diferent containers.

[dstftw]

@kparal I've already stated the purpose of it - downloading free format when both formats are equal according to metadata describing quality. youtube-dl supports not only YouTube so the probability is much higher especially if some metadata is not available.

What is the logic when that option is not given - a random format is picked, or always a proprietary one?

Huh? Not a random but best quality format according to metadata. @jaimeMF for YouTube giving less priority to filesize and bitrate is likely to be reasonable, but in general probably not.

[rg3]

I believe (so basically I'm inventing stuff as I write, haha) people using this option are probably interested in downloading free formats if available, just like the current option documentation suggests.

So if a given website (YouTube or other) offers videos in either MP4 or Webm, using --prefer-free-formats should pick a Webm one, and should only download MP4 if no free formats are available.

Once that "format filter" has been applied, it should choose the highest quality one, or obey other format restrictions the user may have specified.

But then we can raise other questions. For example, someone may want to have --prefer-free-formats in the config file, but in a specific case (s)he may want to specify a format filter that wouldn't work with that, so they need a second option to override the config file setting in a given program call (as in --no-prefer-free-format).

Just my two cents. You know I don't want to have any voting weight in the development process and I don't even use that option, so it's irrelevant to me. :P

[kparal]

I've already stated the purpose of it - downloading free format when both formats are equal according to metadata describing quality. youtube-dl supports not only YouTube so the probability is much higher especially if some metadata is not available.

So IIUIC --prefer-free-formats has no effect on YouTube videos, because full metadata is available, and the videos are always at least slightly different (the bitrate is never the same), so it never happens that this option is taken into account. It can happen on other video sites, which don't provide full metadata, but not on YouTube. That's... suboptimal.

And it doesn't help at all to those users who don't have proprietary codecs installed, and want to download free fomats without hand-picking them every time.

@dstftw For you, quality might be the most important factor. But this belief is not universal and other groups of users might have different priorities. Like open formats. I'm one of them, I believe that patented formats need to be purged from this world and I'll gladly sacrifice some quality because of it. It would be great to have an option which would allow such groups of users to use youtube-dl easily. It can be a new option, if needed (even though in my personal opinion it would make most sense to just use the current one, especially since it currently doesn't seem to have any effect on the largest and most widely used video site).

[jaimeMF]

--prefer-free-formats is expected to pick free formats only if they have the same quality, which is the tricky point, and I think that's the correct behaviour. If someone wants to really prefer the free formats (even if webm is only 1080 and mp4 is 4k) they can use a custom -f or we could add an additional flag.

@dstftw I think we should only take into account the resolution for --prefer-free-formats, in the case that two formats with the same extension exist we would still use the bitrate and other fields to sort them, I don't think it would be a big problem.

[dstftw]

@jaimeMF if some hoster serves formats of the same resolution but really bad bitrate for free format it will end up selecting free format for --prefer-free-formats that is obviously wrong since they are not the same quality and it violates

--prefer-free-formats is expected to pick free formats only if they have the same quality

So, with your suggestion the general semantics of --prefer-free-formats changes to: select free formats when resolutions are equal and not formats of the same quality. In this situation (if we change the semantics of the option) I guess it's indeed more reasonable to change it to what @kparal suggested: select best free format if available otherwise fallback to any best.

[jaimeMF]

@jaimeMF if some hoster serves formats of the same resolution but really bad bitrate for free format it will end up selecting free format for --prefer-free-formats that is obviously wrong since they are not the same quality and it violates

Yes, that's true, but my point is that deciding if two formats have the same quality (for --prefer-free-formats) is complicated and I would choose to use the resolution. For example, from the output posted by @kparal:

248          webm       1920x1080  DASH video 1204k , 30fps, video only, 27.42MiB
136          mp4        1280x720   DASH video 1286k , 30fps, video only, 14.79MiB
137          mp4        1920x1080  DASH video 2521k , 30fps, video only, 29.69MiB

It prefers 720 mp4 over 1080 webm based just on the bitrate, for me it's more sensible to prefer resolution. But I understand it's not so simple (and my knowledge is quite limited, so I may be completely wrong).

So, with your suggestion the general semantics of --prefer-free-formats changes to: select free formats when resolutions are equal and not formats of the same quality. In this situation (if we change the semantics of the option) I guess it's indeed more reasonable to change it to what @kparal suggested: select best free format if available otherwise fallback to any best.

I wouldn't say it changes, it would "fix" it, since that's how it was supposed to work (at least that's my impression when looking into the original implementation, it seem that it picked the mp4 file if it was the one with the highest resolution). Additionally with that behaviour you could use formats filters like best[height<720] and you would get the format with the height closest to the requested and it would try to pick the free version. With the proposed behaviour it would pick the closest free format, which may not be the one with the highest height.

Anyways, since this is probably a bit subjective and I don't use that option, I don't really mind what it does as long as we clearly document what it does and add tests to verify we don't break it.

[yan12125]

Thanks @jaimeMF my interpretation of --prefer-free-formats is the same. However, I can't speak for others because I don't use it.

Prioritizing resolutions than bitrates is reasonable. Technically free formats often have lower bitrates than non-free formats. Take VP9 for example, it aims to "Reduce video bitrate by 50% with image quality comparable to VP" ( VP9 requirements ). In other words, bitrates is not a synonym of quality. In real cases, it's uncommon for VP9 to have higher bitrates than H264. As a result, relying on bitrates is problematic.

[haasn]

I always thought that --prefer-free-formats would prefer free formats over proprietary formats at all costs. It is in this issue that I learned it does not. (Not the documentation!).

If I'm specifying this option, odds are that I either:

1. Want to use a free format for ideological reasons
2. Don't have proprietary codecs supported on my system

So I think it's fair to choose a lower-quality free format over a higher-quality fair proprietary format when this option is specified.

[ghost]

That should probably be a separate flag, such as "--only-free-formats".

The main issue was that while getting only free formats was relatively easy ("-f bestvideo[ext=webm]+bestaudio[ext=webm]/best[ext=webm]"), it got really complicated if you wanted to get the highest resolution video, and then prefer the free format if it had one which would lead to such horrors as: -f bestvideo[ext=webm,height=1080]+bestaudio[ext=webm]/bestvideo[ext=webm,height=720]+bestaudio[ext=webm]/bestvideo[ext=webm,height=640]+bestaudio[ext=webm]/bestvideo[ext=webm,height=480]+bestaudio[ext=webm]/bestvideo[ext=webm,height=240]+bestaudio[ext=webm/best[ext=webm]

with entries for every possible video size you could expect. This was further complicated by the fact that youtube periodically introduces higher resolutions (such as 1440), and things like 3D videos, which mean you have to continually retune the script to add new resolutions to a massive list. (Edit: Or by making a custom script that runs -F and parses the text looking for the highest res free format, which is another undertaking that's much more effort than most people can or should be bothered with.)

[haasn]

This seems like a conflict of interests. If you make this behavior a separate flag, then --prefer-free-formats no longer has a solid reason to exist.

There's no inherent reason to prefer free formats over proprietary formats other than ideological ones.

The way I see it, the gigantic format string you are describing is born from a need to work-around a different youtube-dl limitation: The fact that it doesn't understand that VP9 is higher quality than AVC even at lower bitrates.

But why are we spending so much time focusing on a work-around instead of improving the core problem here?

Note: I use a similar such work-around, namely:

(bestvideo[vcodec=vp9]/bestvideo[height>720]/bestvideo[fps>30])[tbr<13000]+(bestaudio[acodec=opus]/bestaudio)/best

But I consider this a pure work-around simply because I really don't care if my video stream is VP9 or AVC. I'm just special-casing VP9 because of aforementioned youtube-dl bug.

[ghost]

This seems like a conflict of interests. If you make this behavior a separate flag, then --prefer-free-formats no longer has a solid reason to exist.

Yes it does. Some videos have mp4 formats in better resolution (and/or audio quality) than in webm, --prefer-free-formats now values resolution, and then format, in that order.

One such video off the top of my head is: https://www.youtube.com/watch?v=9n7viZaniTU Which has 720p video and 255k audio in mp4, but the webm is only available as 360p video with combined audio of unspecified bitrate.

Sure, this is not a super common scenario, especially with newer videos, but it does happen.

There's no inherent reason to prefer free formats over proprietary formats other than ideological ones.

Sure, but there's also a reason to prefer higher resolution videos over lower resolution videos: quality.

People often have lots of different ideological preferences, and they can intersect in different ways for different people.

If we're going to go the full ideological purist route, then we shouldn't even be using youtube, since it defaults to a restrictive license, and often treats content creators like crap.

[jaimeMF]

I'm with @AliceTheGorgon, --only-free-formats would please those who only want free formats (the name looks clearer) while the fixed --prefer-free-formats would be for those who prefer a higher resolution over the format used (as I pointed in https://github.com/rg3/youtube-dl/issues/6018#issuecomment-113958960, that seems to be how the original implementation worked).

[haasn]

Yes it does. Some videos have mp4 formats in better resolution (and/or audio quality) than in webm, --prefer-free-formats now values resolution, and then format, in that order.

This argument makes no inherent sense. If you care about quality over the format, then why are you specifying --prefer-free-formats at all? Just leave away the flag and you will get the best quality stream.(*)

(*) Except for the part where youtube-dl is currently bugged and prefers AVC over VP9 even when the latter would be higher quality, of course.

Which has 720p video and 255k audio in mp4, but the webm is only available as 360p video with combined audio of unspecified bitrate.

In this case I would expect --prefer-free-formats to pick the 360p WebM stream. After all, the 1080p MP4 version is clearly proprietary.

If we're going to go the full ideological purist route, then we shouldn't even be using youtube, since it defaults to a restrictive license, and often treats content creators like crap.

This is not a decision that concerns youtube-dl so I don't understand why you mention it.

[Hrxn]

--prefer-free-formats just specifies a precedence, not necessarily an exclusion. So, given a video with a 720p stream AVC and 360p WebM, I would assume to get the 720p version, because resolution/quality takes priority over format here, and only if both streams have the same (or let's say similar) resolution, the free format would have precedence.

That's how I understand it, so --prefer-free-formats and --only-free-formats both make sense. I don't know how often this option is used in the wild, so this maybe an issue with barely any relevance, but that's another topic.

I'm a bit confused about the quality discussion, on the other hand, because MP4 is either a) the name of the standard or b) the name of the container format, which is part of this standard, uses the .mp4 file extension, has two different versions, and if that would be not enough confusion, MP4/MPEG-4 is divided into different parts which specify quite different things.

So, my point is, MP4 itself does not say anything about the video quality. MP4 Part 10 (also known as ITU-T H.264) specifies the AVC compression, and you can compare AVC against VP9, true. But an MP4 container can also contain a stream using MPEG-H (MPEG-H is basically the successor, the next MPEG in the line, so to speak) Part 2 (also known as H.265/HEVC), and that codec is vastly more efficient than AVC, and thus changing the quality game in comparison to VP9.

I'm not in the video encoding business anymore (okay, was just a hobbyist), but back then x264 was considered the best implementation of AVC, and even better than VP9, but they might caught up to 264 in the meantime..

[kparal]

--prefer-free-formats just specifies a precedence, not necessarily an exclusion. So, given a video with a 720p stream AVC and 360p WebM, I would assume to get the 720p version, because resolution/quality takes priority over format here, and only if both streams have the same (or let's say similar) resolution, the free format would have precedence.

What people argue here is that if you use such an option, the format itself should be the first criterion, not resolution, bitrate, codec or anything else. I'd also expect that when I use --prefer-free-formats, I receive the highest quality free format available (in this case it would mean 360p webm), and only if there's no free format available, then I receive highest non-free format available (720p avc). With --only-free-formats, I'd expect the same thing, just receiving an error in case there's no free format available, instead of a non-free format.

There's no inherent reason to prefer free formats over proprietary formats other than ideological ones.

I'd like to say that this is mostly true, but not always. This can be easily an economic reason. There are countries in which it is illegal for you to obtain a proprietary format decoder (even an open source one) without paying royalties to the patent holders, because of software patentability. The most obvious example here is USA. So if your operating system doesn't come with such codecs preinstalled, you don't want to purchase them separately, and don't want to break the law, you'll want --prefer-free-formats to actually prefer free formats as the first criterion, because those are the only ones that you can play.

[cloph]

for what it's worth: I expect --prefer-free-formats to only prefer free formats when there's actual choice for ytdl to make. In other words: I fall into "if same resolution available, prefer free format". If however I did specify "bestvideo" selector, it should pick highest resolution available, no matter what format, free or not.

so for

--prefer-free-formats
-f bestvideo[height<=?1080]+bestaudio

it should pick webm variant if available in 1080, even if that has lower bitrate than mp4 (as stated bitrate is bad indicator between codecs). if webm is only available in 360p, but proprietary is available in higher solution, I expect the "bestvideo" statement to override the mere preference for free formats and result in the 1080p mp4 variant instead.

And option that would hand out 360p webm version instead of 1080p mp4 would need to be "--force-free-formats" or "--only-free-formats", but that can also be more easily selected using the extension filter, without duplicating each statement. (so far less need for such an "enforce" option)

[haasn]

^ That behavior might be more intuitive naming-wise, but at the same time occam's razor tells me it's not a possibility that should be under consideration.

When you think about it, the current --prefer-free-formats exists only to serve the needs of somebody who “cares” about freedom, except when it inconveniences them :p

[ghost]

When you think about it, the current --prefer-free-formats exists only to serve the needs of somebody who “cares” about freedom, except when it inconveniences them :p

Your definition is no better. You just draw the "inconvenience" line at "I still want the video even if there's no free version". Everyone else draws it at "I want the highest resolution video, and hopefully there's a free format at that resolution."

[haasn]

Your definition is no better. You just draw the "inconvenience" line at "I still want the video even if there's no free version". Everyone else draws it at "I want the highest resolution video, and hopefully there's a free format at that resolution."

Which is why the only sane thing to do (IMO) is remove this flag entirely and provide an --only-free-formats flag.

[ghost]

Which is why the only sane thing to do (IMO) is remove this flag entirely and provide an --only-free-formats flag.

No, and you are an asshole. You know that a bunch of people want to be able to have the highest quality video, and have the free format of that quality, and that this flag is very useful to them. There is no way to replace this tag without a massively convoluted set of preferences, whereas it's trivial to only select the free formats with a comparatively simple "f=bestaudio[ext=webm]+bestvideo[ext=webm]/best[ext=webm]".

You are purposefully ignoring that people actually exist who want this flag, and belittling their preferences in favor of your own, simply because you think your preferences are magically better because you have them.

I am done wasting my time on you, because you adamantly refuse to accept that anyone else has legitimate preferences of their own.

[Hrxn]

What is going on here? Taking this to a personal level does not make a compelling argument..

It's not that this specific option enables a functionality of the program that isn't achievable otherwise.

Why are we even talking about weird definitions, that don't make any sense and are contradictory? If you think that a specific option should result in not getting any video at all in the end, then please explicitly say so. Kinda defeats the whole purpose of the program, but whatever..

I have an even better idea: Get rid of any *-free-format option altogether.

[davidhedlund]

@AliceTheGorgon @cloph @jaimeMF Please participate to help solve this issue: Add --require-free-formats

[cloph]

I see no point in having a force/require-free-formats option. As mentioned in this issue multiple times such a strict filter can be added with a quite short extension filter (e.g. bestvideo[ext=webm])

What however is not easy without creating a long filter list is a prefer-free-formats option that behaves as the name suggests. So I see no point in reopening #2196.

I want to get rid of a (youtube) filter string like 248+251/248+bestaudio/137+251/137+bestaudio/247+251/247+bestaudio/136+251/136+bestaudio/bestvideo+bestaudio/best

and replace that with a simple [height <= 1080p] and --prefer-free-formats

[davidhedlund]

@cloph Thank you.

[fireattack]

After reading all these old issues I assume this is right place to discuss the "bitrate vs resolution" debate.

My take on this, at least for YouTube, is that resolution is a better indicator, because:

1)) the bit rate reported by YouTube is very unreliable and often quite off. So we shouldn't rely on it no matter what.

One example is what I reported in #12198. Video https://www.youtube.com/watch?v=iMhwshjSauo (warning: video is not available in the US and other 4 countries) reports:

135          mp4        720x480    DASH video  198k , avc1.4d401e, 30fps, video only
133          mp4        360x240    DASH video  242k , avc1.4d400c, 30fps, video only

However, the actual bitrate is 112 kbps (480p) and 32.2 kbps (240p), respectively. As you can see, not only the numbers are off, the order bwtween formats are dramatically changed.

Another example is in #11451.

2)) since from my experience YouTube never upscale videos (correct me if I'm wrong), higher resolution one should always have better quality (if the encoding didn't go wrong), since it literally has more raw information.

[aufkrawall]

Could someone please provide me with a hint how to always play VP9 and Opus/Vorbis in mpv when they are available? I don't get prefer-free-formats to work in mpv's config. There are some videos where H.264 is chosen over VP9, which imho is simply wrong (VP9 also looks better than H.264 at lower bitrate). Example: https://www.youtube.com/watch?v=o_24LPjOIHI

I tried ytdl-format=bestvideo[vcodec=vp9]+bestaudio[acodec=opus]/bestvideo+bestaudio/best which works for this video, but not for the following: https://www.youtube.com/watch?v=TexBjznr4yM

[utack]

This should work: ytdl-format="((bestvideo[vcodec^=vp9]/bestvideo)+(bestaudio[acodec=opus]/bestaudio))/best"

[aufkrawall]

Thanks a lot! Is there a chance to also make it use Vorbis instead of AAC when it is available?

[utack]

In the case I posted above it will only select opus when a video is found I should mention, for pure audio streaming sites it falls back to "best" But you can add more and more terms any time (bestaudio[acodec=opus]/bestaudio[acodec=whateverelse]/bestaudio[acodec=yetanothercodec]/bestaudio)

[aufkrawall]

Thanks again, got it working. :)

[davidhedlund]

@utack How is it going to look for WebM container with Vorbis video and Opus audio?

[ghost]

To those who suggest that it's simple to replicate the preference / requirement for free formats with -f, it's not entirely true. As you can see from the discussion above, there are multiple free formats, and the format string can get messy.

To make everyone happy, perhaps we could keep --prefer-free-formats as-is (prefer highest resolution/quality and then free format if available), and add --prefer-free-formats=always to prefer free formats even at the expense of quality. And perhaps a --require-free-formats could be added, which will obviously always either download the highest quality free format available, or if there is none, error.

And while it's not entirely on-topic here, I have also noticed that youtube-dl incorrectly prefers H.264 over VP9 due to the slightly higher bitrate. I don't know what's the best solution to that problem though, as you can't necessarily just say VP9 is always better than AAC, because there's a possibility a site will make a worse-quality VP9 encode than H.264 for the same resolution.

[haasn]

And while it's not entirely on-topic here, I have also noticed that youtube-dl incorrectly prefers H.264 over VP9 due to the slightly higher bitrate. I don't know what's the best solution to that problem though, as you can't necessarily just say VP9 is always better than AAC, because there's a possibility a site will make a worse-quality VP9 encode than H.264 for the same resolution.

The approach that always pops in my head is introducing “bitrate coefficients”, perhaps based on some commonly available codec benchmark. (Basically, the idea is that if VP9 encodes ~20% smaller files than H.264 at the same visual quality, as assessed by an objective quality metric such as MS-SSIM, then you can multiply 1.2 into the VP9 bitrate)

[utack]

@haasn Has anyone found a VP9 with same resolution and FPS that looked worse than the H264 counterpart yet?
Does not seem to happen generally with the settings they use

[haasn]

@utack I remember seeing some pathological VP9 encodes of video game streams a year or two ago, specifically Dwarf Fortress. May have changed in the meantime, and I may be misremembering, but afaik you'll still find weird clips like that where x264 is still hard to beat, in some of the areas it's specifically tuned for.

[Hrxn]

Has anyone found a VP9 with same resolution and FPS that looked worse than the H264 counterpart yet? Does not seem to happen generally with the settings they use.

Well, at least not on YouTube. But haasn is right, some bitrate reference value for comparison would be a good idea. Another thing I noticed, YouTube specific: Some newer videos, on official channels, music videos etc. had VP9 and H.264 with more or less the same bitrate, thus eliminating the potential file size benefit of VP9 for the sake of better visual quality. I don't know any YouTube Insider, but maybe that is their current strategy, adapting for higher availability of broadband Internet access across the user's population.

[haasn]

But haasn is right, some bitrate reference value for comparison would be a good idea.

For lack of anything better, we could use netflix's results (which are normalized to the VMAF metric).

This seems to suggest that e.g. at 1080p, a coefficient of “1.4 bitrate” for VP9 and “1.5 bitrate” for HEVC would be good candidates. (This scale would presumably normalized such that x264 represents the reference)

[fireattack]

Even if we decided the "coefficient" for each format, how we're going to deal with the fact that YouTube sometimes straightly reports wrong bit-rate?

[haasn]

Probably by ignoring the “bitrate” and using the filesize, or something. Actually, looking at e.g. youtube-dl -F https://www.youtube.com/watch\?v\=KQs0Gj7bXYY:

...
247          webm       960x720    720p 2092k , vp9, 30fps, video only, 319.30MiB
136          mp4        960x720    720p 2249k , avc1.4d401f, 30fps, video only, 437.94MiB
298          mp4        960x720    DASH video 3348k , avc1.4d4020, 60fps, video only, 683.20MiB
302          webm       960x720    720p60 3891k , vp9, 60fps, video only, 591.97MiB
...

Comparing formats 298 and 302 specifically, if we assume 3348k is the true bitrate for the 683.20MiB H.264 stream, then the VP9 stream's reported bitrate of 3891k is roughly “1.34x” higher than what it should be going by the filesizes. So maybe youtube already internally gives VP9 a format-specific “bitrate” boost?

[fireattack]

Well it doesn't always return file-size.

[davidhedlund]

@nyuszika7h

And perhaps a --require-free-formats could be added

Add --require-free-formats was declined but with your vote on the issue they might change their mind.