[YoutubeDL] Make bestvideo+bestaudio/best default format when merger is available

[dstftw]

Closes #5447.

Pros:

• Results in best overall quality.

Cons:

• Potential merge issues (-f bestvideo+bestaudio tries mixing codecs that don't match #5298).
• Unable to watch video while downloading (by piping to video player).

[jaimeMF]

In some issue report someone commented saying that for videos in low resolution it's more convenient to just get the normal formats, since they have the same or better quality. Checking these cases would probably complicate the code too much and I don't think it's worth the effort.

Potential merge issues

We should make sure that the default formats work (otherwise users would get confused), I propose two alternatives:

• If bestaudio and bestvideo are not compatible, we merge into a mkv file
• Use bestvideo[mp4]+bestaudio[m4a]/bestvideo[webm]+bestaudio[webm]/mp4 instead, with this option we may not get the best quality (I think in some cases there's either a webm or mp4 with better resolution, but I'm not really sure).

With this change the YoutubeIE test fails, we have to change the format field in test/parameters.json.

Apart from the previous comments, I like the change and agree that bestvideo+bestaudio/best should be the default

[dstftw]

I think merging in mkv sounds reasonable since theoretically there may be a situation when there are no video/audio of compatible formats available. Moreover, general video+audio format selection will benefit from it as well.

[jaimeMF]

I also prefer defaulting to mkv. Some players may not support it, I don't think it's a big problem (it happens the same if some website only gives flv files), but some users may not like it.

We could also merge into mkv and use bestvideo[mp4]+bestaudio[m4a]/bestvideo[webm]+bestaudio[webm]/bestvideo+bestaudio/mp4, but that's quite ugly, I'd prefer to keep it as simple as possible.

[jaimeMF]

Since bestvideo+bestaudio/best will be the default, maybe it's better to use to_screen.

[dstftw]

Why? Uncompatible formats scenario is still expected to happen less often that compatible and can be treated as reasonable-to-warn-about.

[jaimeMF]

You are right, it's fine.

[jaimeMF]

Before merging this I think we should detect if the video has already been downloaded and merged. Currently if you don't use --keep-video, the files are redownloaded and merged again (if you prefer, I can try to implement it myself).

One issue with merging is that for long videos (like fEAyDNWaCto from #5298), ffmpeg takes a relatively long time to merge them. I don't know if we can do something to fix it.

[dstftw]

I've added basic check for already merged file. Feel free to tweak it if that's not what you expected.

[jaimeMF]

I have written an alternative in #5469, we have to use a temporary file with ffmpeg, otherwise we can end with a partial video if we cancel the merging.
(If you like it we can merge it to master directly or you cherry pick it in your branch, as you prefer)

[dstftw]

Ok, lets just merge both to master.

2015-04-19 21:03 GMT+06:00 Jaime Marquínez Ferrándiz <
[email protected]>:

I have written an alternative in #5469
#5469, we have to use a temporary
file with ffmpeg, otherwise we can end with a partial video if we cancel
the merging.
(If you like it we can merge it to master directly or you cherry pick it
in your branch, as you prefer)

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

[jaimeMF]

Cherry picked everything except the last commit (feccf29, 81cd954 and 70947ea). Nice work!