Youtube 4K support

[KeithCu]

I wanted to download a 4k youtube video:
http://www.youtube.com/watch?v=hHKJ5eE7I1k

By default, youtube-dl only downloads the 1280x720 version:
youtube-dl -F http://www.youtube.com/watch?v=hHKJ5eE7I1k
[info] Available formats for hHKJ5eE7I1k:
format code extension resolution note
140 m4a audio only DASH audio , audio@128k (worst)
160 mp4 192p DASH video
133 mp4 240p DASH video
134 mp4 360p DASH video
135 mp4 480p DASH video
136 mp4 720p DASH video
137 mp4 1080p DASH video
264 mp4 1080p DASH video
138 mp4 >1080p DASH video
17 3gp 176x144
36 3gp 320x240
5 flv 400x240
43 webm 640x360
18 mp4 640x360
22 mp4 1280x720 (best)

I managed to get it to download the 4k version by doing this:
youtube-dl -f 138 http://www.youtube.com/watch?v=hHKJ5eE7I1k

But maybe it would be nice if you could find the 4k by default or have some easier command line prompt?

[HalosGhost]

Concisely: youtube-dl does not currently recognize 2K (format code 264) or 4K (format code 138) as what they are, and, perhaps as a result, 720p is selected as the default rather than the highest-quality format available).

It does, however, seem odd that the correctly identified 1080p (format code 137) is not considered higher-quality than 720p, by default. Related issue?

[AGSPhoenix]

I think youtube-dl chose the 720p because there is no single-file 1080p, only 1080p DASH, which would require muxing to produce a playable file. Since most users aren't likely to have a muxer on their systems, this seems like reasonable behavior, though automatically detecting a usable muxer and fetching the two DASH formats would be a nice feature.

I'll put in a pull request to get the format descriptions changed, though automatic handling of DASH formats having better quality will probably have to be tackled by someone a bit more familiar with the code.

[meteormatt]

👍

[HalosGhost]

AGSPhoenix, I'm confused about what you're saying. The file mentioned in the OP downloads as a single file, by default, for me when using -f138. If the muxing is required, it's not requiring me to do anything.

[AGSPhoenix]

All the DASH Video formats contain only video - no audio. The audio is in a separate file, specifically format 140. To use the DASH video formats, youtube-dl has to download both the video and audio files, then use a separate program (ffmpeg or avconv) to 'mux' the two files together into a single file that any video player can handle.

If you tell youtube-dl to download format 138, you'll get a complete file you can play, but there will be no audio.

[HalosGhost]

Oh, I see. It makes perfect sense then that it should not be the default. Thank you for explaining.

[Xender]

Actually supporting automation of downloading a&v separately and muxing them would be very nice.
Selecting whether go with muxing or single 720p download could be done either whether autodetection or config option.

https://gist.github.com/ckorn/7284075
This script looks relevant, but it's only half-automatic (and if it turns out than the video doesn't have versions >720p, user has to ^C it and go with regular youtube-dl invocation instead).

There actually is fork of this script with better ffmpeg compatibility: https://gist.github.com/lwr/7b1e57ea5540d8b1af55

What would be more optimal? Incorporating this feature into core youtube-dl or trying to fully automate what shell-script does by actually parsing youtube-dl -F's output (instead of showing it to user and asking what to do)?

[jaimeMF]

In the last versions of youtube-dl you can run youtube-dl 'http://www.youtube.com/watch?v=hHKJ5eE7I1k' -f bestvideo+bestaudio to download and mux the best quality dash formats (you need to have ffmpeg or avconv installed). You can replace bestvideo with other dash video itag.

[dandv]

Why isn't -f bestvideo+bestaudio done by default, at least for 4K videos?

Is there a shorter switch for this combo?

[AGSPhoenix]

It's something that has been on the list for a while, but requires a lot of
code changes under the hood to implement, namely automatically detecting
whether or not the user has ffmpeg or avconv installed.

As for a default, I suspect you could add that to your config file, though
I haven't been keeping up with the project for a while, so that may not be
the case. A second alternative might be writing a simple wrapper.
On Mar 4, 2015 2:08 AM, "Dan Dascalescu" notifications@github.com wrote:

Why isn't -f bestvideo+bestaudio done by default?

Is there a shorter switch for it?

Reply to this email directly or view it on GitHub
#2400 (comment).

[Xender]

@AGSPhoenix - I don't like the idea of automagically detecting things on user's system.
I feel, as a user, that it's better throw an error in user's face (even on default settings!), than silently fallbacking to worse quality.

When you get error thrown in your face, you either install ffmpeg or decide to use -f best.
When it silently fails (and fallbacks), you may not even notice.

Silent fails are bad. Just compare what PHP does when something goes wrong to what Python does.

But! This can be done better.
First of all, -f bestvideo+bestaudio is not always better then -f best (unless DASH 720p is better than "normal" 720p), and AFAIK it can even sometimes be worse (best DASH quality being 240p when 360p "normal" is available or sth like that).

So what I always do is:

• youtube-dl -F some_url
• (manually check, what is really best quality - -f best (default) of -f bestvideo+bestaudio)
• youtube-dl some_url or youtube-dl -f bestvideo+bestaudio some_url depending on that.

It would be nice, if youtube-dl could do that algorithm internally.
Algorithm decided that -f bestvideo+bestaudio is better, but user has no ffmpeg? Please, just throw the error in the user's face, with some informative message. I like to know what is going on.

For people who like silent fails and fallbacks, made a commandline option to do that. Just not make it default, please.

[AGSPhoenix]

@Xender, it's just not reasonable to fail out and make the user specifically allow the downloading of low er quality content just because they don't have a very niche tool installed.

If you personally prefer this behavior, you can add the equivalent of -f bestaudio+bestvideo,best to your config file.

More gracefully handling the availability of higher quality formats is something that has been planned for a while, and implementing a warning message when the user isn't getting the highest quality is something we've idly considered, but no one has expressed an interest in it, so it hasn't been done. If you think that would be a step in the right direction, I might take a crack at it, as I've been looking for an excuse to get back into coding in my spare time.

[Xender]

@AGSPhoenix - How is FFmpeg more niche than youtube-dl?
Also, isn't ffmepg/libav a dependency installed for like every wideo player on Linux?

Also, maybe silent-fallbacking on Windows makes sense, but if I don't have ffmpeg installed on my Linux station, I just type one command, go for tea, and bam, it's installed.
Far less damaging than noticing that half of my downloaded videos are lower quality because of the silent fail.

[AGSPhoenix]

ffmpeg is probably less niche than youtube-dl, but the overlap isn't necessarily that large. I'd be shocked if more than half of the youtube-dl userbase had it installed. Outright breaking downloads for the rest of them would crush our support resources. There are already issues on the tracker that go weeks without a response, and even with well worded and clear instructions on how to proceed, we'd still be flooded with people who can't be bothered to read.

Again, we have a configuration file for users who prefer to change the default behavior, and I'd encourage you to use it.

Also, if you think about the bare command you run (youtube-dl <URL>), it roughly translates to "download this video". If you think about it in terms of which failure condition is least surprising to the user, "it downloads in a lower quality than is possible" is better than "it doesn't download at all".

If you still think the majority of the userbase would be benefited by this change, hop on IRC and discuss it with the project runners, and if they're willing to try it, do up a pull request.

[Xender]

@AGSPhoenix - If you are bothered with users of CLI program who cannot read, then making it a warning is acceptable minimum.

And again, how can ffmpeg/libav be niche, when it's a required dependency for Linux video players?
Are there distros packaging the library and the CLI tools separately?

[AGSPhoenix]

@Xender, I didn't have much time to double check, but based on a cursory examination of Ubuntu's package repository (which unfortunately only has avconv), it doesn't seem like there are many packages that actually depend on libav-tools (the package that contains avconv). Though the same might not be true for other distros, I would assume any reasonable media player would depend on the actual software libraries and not a command line transcoder to do their work.

Keep in mind that I don't have much of a final say in the matter. If you really want this, open a new issue or bug one of the real devs and see what they think about it.

[vjk2005]

+1 for 4K default. I’m having to do the -f bestvideo+bestaudio thingy almost every other video I download these days. If it’s not possible to bring ffmpeg's av muxer in-house, perhaps youtube-dl can download and install ffmpeg during install time to ensure 4K is supported on that system.

[jaimeMF]

@vjk2005 note that you can add -f bestvideo+bestaudio/best to your configuration file to make it the default.

[vjk2005]

@jaimeMF that’s a nifty trick, will try it out. Thanks.

[jleaders]

I'll just say this, from the user perspective, you should automatically:

• Detect if a muxer is installed -- this isn't hard to do, just "ffmpeg -h" and if it fails "avconv -h". On success, do best quality.
• If a muxer is not installed, go ahead and drop down to 720p, but throw a warning that is user-friendly explaining they need ffmpeg or avconv installed to get a highest quailty.
  Adding
  -f bestvideo+bestaudio/best
  to a config file just sounds like you're making the user fix the program, instead of the developer fixing it. It is reasonable for a user to assume they are going to get the highest quality clip downloaded, and most programs handle dependencies internally in 2017

Thanks for your great work

[dstftw]

@jleaders this is already there for more than 2 years. Bother to read FAQ before posting.