starred/youtube-dl-ytdl-org

Fork 0

mirror of https://github.com/ytdl-org/youtube-dl.git synced 2026-03-02 19:17:00 -05:00

--max-quality not being honored #115

New issue

Closed

opened 2026-02-20 22:25:48 -05:00 by deekerman · 8 comments

deekerman commented

2026-02-20 22:25:48 -05:00

Owner

Originally created by @VxJasonxV on GitHub (Sep 16, 2011).

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).

Originally created by @VxJasonxV on GitHub (Sep 16, 2011). 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).

deekerman closed this issue

2026-02-20 22:25:50 -05:00

deekerman commented

2026-02-20 22:25:51 -05:00

Author

Owner

@phihag commented on GitHub (Sep 16, 2011):

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 commented on GitHub (Sep 16, 2011): 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.

deekerman commented

2026-02-20 22:25:52 -05:00

Author

Owner

@phihag commented on GitHub (Sep 16, 2011):

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

@phihag commented on GitHub (Sep 16, 2011): @VxJasonxV reopen? Just comment here _why_ you want it reopened, and I'll reopen it. Open/closed is just a marker ;)

deekerman commented

2026-02-20 22:25:52 -05:00

Author

Owner

@VxJasonxV commented on GitHub (Sep 16, 2011):

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;

"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.

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.

@VxJasonxV commented on GitHub (Sep 16, 2011): 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.

deekerman commented

2026-02-20 22:25:52 -05:00

Author

Owner

@phihag commented on GitHub (Sep 16, 2011):

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.

@phihag commented on GitHub (Sep 16, 2011): 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.

deekerman commented

2026-02-20 22:25:52 -05:00

Author

Owner

@rbrito commented on GitHub (Sep 17, 2011):

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... :-(

@rbrito commented on GitHub (Sep 17, 2011): 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... :-(

deekerman commented

2026-02-20 22:25:52 -05:00

Author

Owner

@phihag commented on GitHub (Sep 17, 2011):

@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',

@phihag commented on GitHub (Sep 17, 2011): @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', ```

deekerman commented

2026-02-20 22:25:52 -05:00

Author

Owner

@rbrito commented on GitHub (Sep 18, 2011):

@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.

@rbrito commented on GitHub (Sep 18, 2011): @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.

deekerman commented

2026-02-20 22:25:52 -05:00

Author

Owner

@phihag commented on GitHub (Sep 18, 2011):

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

@phihag commented on GitHub (Sep 18, 2011): @rbrito I'm sorry, but I don't watch all the forks of youtube-dl, but I'm looking forward to the pull request.

deekerman referenced this issue

2026-02-21 00:00:44 -05:00

2013.12.23.4 Redownloads Some Part and Completed Downloads #1584

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/youtube-dl-ytdl-org#115

No description provided.

Rows
Columns