-
Notifications
You must be signed in to change notification settings - Fork 10.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add muxing option; allow --embed-subs to automatically remux if needed #6996
Comments
There is already an option for recode: |
To clarify, I’m not trying to re-encode. MKV/MP4 muxing is a lossless action; it keeps the original video and audio streams, does not involve re-encoding and takes much less time than the recode command. In Verbose log follows. Not shown is the long wait during the encoding stage before subtitles are embedded.
|
Yeah, this would be nice. Whatever subtitle format is picked (either by default or manually with |
Just want to add my support to this issue. I was unaware that --embed-subs would fail if the format wasn't already in a compatible format for other reasons. I may delay my archiving tasks until this is fixed because I don't want to have to figure out down the line which ones need to have subtitles redownloaded. It would be great if the solution allows forcing remux to mkv, because for archiving tasks, I want all of the content to have uniform filenames / container formats. |
same here, I thought I am doing something wrong. |
another +1 from me on this old issue! Right now there seems to be no good solution if the source video's format doesn't support embedding subtitles. The only thing that works is a very slow and unnecessary "recoding" is so slow because youtube-dl calls ffmpeg without any codec information, so ffmpeg just uses sensible defaults based on the output file's container format. For example, here's what youtube-dl calls: after turning up ffmpeg's verbosity you can see it's made these re-encoding choices
In the meantime, I've hacked up my copy of youtube-dl to always pass Here's a tiny diff in case others might find this useful:
|
This please. I want to download CR shows, which come in as MP4, but to use the .ass subtitles I need MKV format. I thought --merge-output-format was what I needed, but it only takes effect if it thinks merge is required, which it apparently doesn't. Instead, it simply downloads MP4, converts the .ass file to a different format, and merged. Not good |
Fixes ytdl-org#6996 - Supported formats declared: mp4, mkv - Added FFmpegVideoRemuxerPP as postprocessor - Added option to README and shell-completion scripts
Fixes #6996 - Supported formats declared: mp4, mkv - Added FFmpegVideoRemuxerPP as postprocessor - Added option to README and shell-completion scripts Co-authored-by: Felix Stupp <felix.stupp@outlook.com>
Problem
A video from Crunchyroll is downloaded with
--write-sub
,--embed-subs
and--merge-output-format mkv
enabled. The expected outcome is that the downloaded FLV file will be losslessly muxed with the subtitles into an MKV file. What actually happens is that the two files are downloaded as normal without merging; the message[ffmpeg] Subtitles can only be embedded in mp4 or mkv files
is returned.Possible Solution 1
Add an option to remux the video to a given container format without re-encoding. (i.e.
--mux mkv
,--mux mp4
etc.)Possible Solution 2
Change the behaviour of
--embed-subs
so that it automatically remuxes if the file format doesn’t allow embedded subtitles. Allow the container format (MKV, MP4) to be specified if possible.Possible Solution 3
Change the behaviour of
--merge-output-format
to always remux regardless of whether or not a merge is required.Verbose output follows.
The text was updated successfully, but these errors were encountered: