Different response to --output, in two different situations

[krasnh]

Different response to --output, in two different situations

[pukkandan]

I swear there is an open issue for this, but I can't find it

[Grub4K]

You always should append .%(ext)s to the output template, otherwise it might cause even more problems (Like when the name contains a .).

• In the first case, yt-dlp implicitly appends an extension for processing so ffmpeg can merge the files
• In the second case, it will download straight to the file, so it can use the filename as given

Why do you want to download without the extension in the first place?

[dirkf]

Presumably the merge process is applying the extension even though it wasn't specified in the output template.

Actually, as the first log shows, yt-dlp is forcing the {format_id}.webm extension to avoid having one format overwrite the other (function correct_ext(), I think), the merge command is using a temp.webm extension for the output, and that is being renamed by just removing the temp. part (because dl_filename passed to the post_process() is that temp filename when no file has been downloaded).

Would the answer to this be a documentation note that an output template with no %(ext)s is likely to cause unexpected behaviour except in very simple cases, like downloading one combined format video with a specific filename?

[krasnh]

but I can't find it

And I was looking for it. I was also surprised that for the entire existence of "yt-dlp", I was the first one who encountered this problem. :)

upd. If this is not a problem but a feature, it is advisable to mention it in the readme.

[dirkf]

This old upstream issue, with its relatives, is somewhat similar: user who specified a fixed --output value (in particular, without %(ext)s) was surprised when the final file had a .webm or .mkv extension as a side-effect of merging.