--max-quality not being honored

[VxJasonxV]

I don't care much for WebM. It doesn't work in my workflow, it doesn't work in my apps, I don't want it. So, I've tried using the --max-quality flag in order to only get the best possible mp4 file, or perhaps flv (which is terrible, but acceptible).

According to http://en.wikipedia.org/wiki/YouTube#Quality_and_codecs , I should define --max-quality at 38, in order to get the best possible MP4/h.264, but no-WebM.

Unfortunately, it doesn't seem to work. Consider the following output:

$ youtube-dl -t 'http://youtube.com/watch?v=cf5Ep75CHc4'
[youtube] Setting language
[youtube] cf5Ep75CHc4: Downloading video webpage
[youtube] cf5Ep75CHc4: Downloading video info webpage
[youtube] cf5Ep75CHc4: Extracting video information
[download] Destination: Grilling_foooood_at_Momo_s_house-cf5Ep75CHc4.webm
[download]  10.5% of 38.65M at  156.44k/s ETA 03:46^Z
[1]+  Stopped                 youtube-dl --max-quality=38 -t 'http://youtube.com/watch?v=cf5Ep75CHc4'

Note that I have aliased 'youtube-dl' to 'youtube-dl --max-quality=38' in my .bashrc

You can see that the alias is being automatically applied (last line), but you can also see that a webm file is being downloaded (5th line).

[phihag]

The video you linked to is only available in the formats 43 (webm, 640x360), 18 (mp4, 640x360) and 5 (flv, 400x240). Since 38 is the best possible possible format (mp4, 4096x3072), --max-quality 38 has no effect (the limit is by video quality, not by numeric value). --max-quality 18 works fine for me. The proper way to exclude webm is --format 38/37/22/35/34/18/6/5/17/13.

However, since multiple people seem to have problems with webm and there is no discernible difference between webm and the corresponding mp4 format, the just released version 2011.09.18c (youtube-dl --update to get it) reverts to prefer mp4 over webm.

Note that webm is still being actively developed, and is free - in the sense of free speech as well as free beer. If an open-source software does not support it, letting them now of the problem is a good idea.

[phihag]

@VxJasonxV reopen? Just comment here why you want it reopened, and I'll reopen it. Open/closed is just a marker ;)

[VxJasonxV]

Sorry about that. I thought that if I couldn't reopen it, I also couldn't comment. Then I tried anyways and saw that I could at least comment :P.

Here's what I was going to say originally:

Thanks Philipp, a few clarifying details;

1. "The limit is by video-quality, not by numeric value".

Considering the output of the youtube-dl -h, I would request that --max-quality SHOULD WORK as max format code, and not by actual video/audio quality.

Video Format Options:
-f FORMAT, --format=FORMAT
video format code
--all-formats download all available video formats
--max-quality=FORMAT
highest quality format to download

Considering that we can either pick a specific format, or just specify a max format, I feel that my original understanding is exactly how it should to work, with the fallback being your suggestion of multiple format codes.

1. I don't feel that your .18c commit was necessary, but regardless I thank you for making it. I have both updated my bash alias with your original suggestion, as well as updated youtube-dl. Thank you.

[phihag]

highest quality format to download means exactly that. The option is meant to limit bandwidth, not to exclude specific formats.

Note that you don't have to use format fallback now to avoid webm - with 2011.09.18c (and youtube always encoding both webm and mp4 if the quality is available), you'll always get mp4 over webm.

Since bug reports here are just the tip of the iceberg, and we've had two after switching to webm (which was a user suggestion from the debian project, by the way), I do think preferring mp4 is the right choice for now. With the recently introduced fallback option (which we might extend in the future), everyone can express their preferences anyways.

[rbrito]

Oh, darn... The webm format file reverted... :-(

It seems like VxJasonxV is a user of a Mac and, of course, Apple only sees what they want (H.264).

Anyway, thanks phihag for including that commit. I guess that I will still include that when I create the next package for Debian... :-(

[phihag]

@rbrito Sorry, while I see the merits of webm, it seems our users want mp4. Two bug reports in such a short period is definitely too many, so I'll have to be pragmatic.

Since one can assume the debian packages will only be used on debian (for debian = debian, Ubuntu, Knoppix, etc) where webm support should be at least as good as mp4 support, preferring webm is the best choice for debian. In the long term, we'll probably have configuration files, and maybe an option prefer-webm which you then could preconfigure to true in /etc/youtube-dl.conf. But in the short term, you'll need a patch. One more thing: I included the 44 format, so you need a new patch:

--- a/youtube-dl
+++ b/youtube-dl
@@ -1088,7 +1088,7 @@ class YoutubeIE(InfoExtractor):
        _AGE_URL = 'http://www.youtube.com/verify_age?next_url=/&gl=US&hl=en'
        _NETRC_MACHINE = 'youtube'
        # Listed in order of quality
-       _available_formats = ['38', '37', '22', '45', '35', '44', '34', '18', '43', '6', '5', '17', '13']
+       _available_formats = ['38', '37', '45', '22', '44', '35', '34', '43', '18', '6', '5', '17', '13']
        _video_extensions = {
                '13': '3gp',
                '17': 'mp4',

[rbrito]

@phihag Yes, yes. Whenever I upload a new version of youtube-dl, it does enter all those Debian-derivatives and having support for them will be nice for those that prefer something Free'er.

Until we have such preference system in place, I will keep my branch prefer-webm active, so that you can watch that if you want.

OK, I know that this is getting off-topic, but just so it gets registered, I am planning on improving that vimeo support and getting support for other (external) downloaders in place. My main interest is in getting aria2c as a downloader, as that gives me a lot of speed, especially in face of Youtube throttling the speed of downloads. This is in embrionic for in the use-other-downloaders branch of my tree.

Thanks.

[phihag]

@rbrito I'm sorry, but I don't watch all the forks of youtube-dl, but I'm looking forward to the pull request.