Closed AlexBlandin closed 4 years ago
dstftw
commented
4 years ago You not allowed to hardcode the ext in output template in the first place. Putting .mkv in output template will not produce mkv but just the original media file named with mkv extension.
AlexBlandin
commented
4 years ago Still a valid problem with --merge-output-format not respecting subtitles and the listed problems with lossy embedding, so closing and marking this as invalid is disingenuous. The listed problem is that it goes to mov_text, when it shouldn't. Granted, the exception is due to ytdl not noting the intended container by hardcoding, which you say is not allowed, though that seems a little bizarre to me.
Calling with --merge-output-format mkv, it still goes to .mp4 and does not merge into .mkv, despite the problems with lossy subtitle embedding as I described.
For the sake of testing, simply replacing "-c:s" mov_text with "-c:s" copy in the ffmpeg command works, even given an mp4 hardcoded to mkv, as below:
ffmpeg -y -loglevel "repeat+info" -i "file:C:\Users\alex\Videos\Keep Your Hands Off Eizouken! Episode 3 – Let's Accomplish Something!.mkv" -i "file:C:\Users\alex\Videos\Keep Your Hands Off Eizouken! Episode 3 – Let's Accomplish Something!.mkv.enUS.ass" -map 0 -c copy -map "-0:s" -map "-0:d" "-c:s" copy -map "1:0" "-metadata:s:s:0" "language=eng" "file:C:\Users\alex\Videos\Keep Your Hands Off Eizouken! Episode 3 – Let's Accomplish Something!.temp.mkv"This was sufficient as ffmpeg simply encodes the merged output correctly. So regardless of how (as I said, I support using --merge-output-format mkv) ytdl needs to recognise it should be losslessly merging the video and subtitle files into an .mkv, which to me seems like the exact thing --merge-output-format exists for.
AlexBlandin
commented
4 years ago In addition, going over https://github.com/ytdl-org/youtube-dl/blob/51c7f40c83a12f9dc0fce0b9e5102a0c13467b6a/README.md there does not appear to be anything that says you should not hardcode the extension in the output template.
gw711
commented
4 years ago DId anyone ever figure out how to use youtube-dl to get an mkv file that maintains the ass subtitle format when downloading CR? I've had a nightmare attempting to workaround this limitation
AlexBlandin
commented
4 years ago Currently your only robust option is to keep the files with -k or do a "subtitle run", then merge into an .mkv.
Using switches like the above are viable for individual videos and their subtitles, but you'd probably want something a little extra for, say, doing an entire series at once. Using the built in switch --exec to run a script that does this might be easiest, allowing you to bake in the subtitles.
An alternative as a user, though your milage may vary, is to not embed the subtitles. Some players (or configurations/options) will load local subtitles properly, but this is dependent on your setup, and adds extra hassle/clutter to your filesystem.
gw711
commented
4 years ago Yeah what's I've settled on is youtube-dl downloading the video and subtitle files, and using --exec to run a powershell script to ffmpeg the video and subtitles into a single file, and also delete the inputs.
Checklist
Verbose log
Description
I was doing some testing and noticed the above error (in particular, the testing was all
-qso I had to recreate it for the log and as described below).I had been wanting to weigh in on how to force to a specific container when
--merge-output-format(incorrectly, imho) decides not to merge, such as when subtitles are lossily converted. Personally, I think that when ytdl embeds subtitles it should do it losslessly, and so elevating to a.mkvwhen given--merge-output-format mkvis reasonable, especially given how .mp4 currently only converts to timed text -- which has serious accessibility problems, especially given content with multiple subtitles in different places on screen at once. At the very least, testing different ways of doing this would allow me to figure out how I should do such a thing should I ever need it myself (given how recoding the entire video is recommended by some, but is entirely unnecessary and can drop the bitrate, I felt I needed to find at least one good way to do this without problem).In principle, simply setting the extension with
-oallows you to at least always have it as, say, an.mkv, but that also means you can waste time if it does not need merging, which is why I support the above interpretation of--merge-output-formatas including subtitle conversion as part of how it chooses whether it should merge to the given format, presuming the user has specified it all correctly lest face errors.A simpler log (
-q -v) should suffice for much of the explanation here:Though we do need to include this from the verbose log:
So, given a resonably typical setup (the user config simply deals with good YT & Twitch handling), the command lines are what we would expect for one hoping to embed subtitles. The simpler log is useful since the CR extractor is very noisy, but we do need some of the full verbosity (a quiet mode to deal with the fallback downloader as used on CR would be useful, but that's neither here nor there) as before.
The specific switches with this also overwrite the
-oto always have the extension.mkv, meant to demonstrate one way of forcing a container. In theory, this should not be a problem, and we would expect the subtitles to simply be copied in (given they are in a supported format), however the most important detail to note is that the subtitles are merged with:Which, given that they are
.asssubtitles merging into an.mkv, means something is clearly wrong. Fortunately, as ffmpeg errors out, ytdl exits early, and so never cleans the files up, meaning we can in principle recover from this and embed, but that also means that there are.tempfiles strewn around the directory, and have to use more effort in performing both the embedding and the cleanup externally to ytdl, which we would obviously rather avoid.It would be natural to think that, given how no subtitle conversion was specified, by default it would simply embed the given format -- particularly when it fits in a possible container (if it were to either merge with
--merge-output-formator is supported by the original container).If we are able to preserve the subtitle file whilst still being able to clean up (ie, without a full
-k, or without doing it twice, once as--write-suband the other just the video), that would at least allow a relatively simple--execto embed it, which may need to be included in the documentation.Of course, improving the subtitle embedding is obviously much more user-friendly. If the source provides
.assor some other format, then most users would probably prefer it over something on the level of srt.Hopefully this discussion can help bring attention to (and resolve some of) the problems in other issues, like #17968, #21343, and #21344. In particular, beyond pushing for improved subtitle embedding, this should highlight that we can change container through
-o, but that we may want to have some other mechanic for dealing with containers (especially in the context of correct subtitle embedding).Ideally, we would not want to lead to conflicts with existing configs or scripts, so I am a proponent for extending
--merge-output-formatand having it consider subtitle embedding in the choice of whether to merge or not. Alternatively, one option is specifying a preferred container, or allowing it to fall back to a more compatible container if something would be incompatible or require lossy conversion, perhaps defaulting to.mkvbut allowing the user to override on its own, akin to a second level of--merge-output-formatthat the existing option could itself fall back upon.Hopefully, updating ytdl to not simply use
-c:s mov_textby default will help with embedding multiple subtitles of varying formats into a given container.Also, subtitle embedding needs to be noted in the docs as forcibly converting to
mov_text/ "timed text" by default until this is resolved.Subtitles are easily neglected, but are important to many users for many different reasons. Thankfully, a lot of the heavy lifting can be done by ffmpeg, especially when using containers such as
.mkv. Given how many have problems with the default setup of subtitle embedding in ytdl (given it repeatedly appearing in the issues) it seems worthy of calling the defaults at least somewhat flawed, and the attempt to forcibly convert tomov_textbeing a clear bug (since it can lead to ytdl crashing), especially as the lossy conversion would likely not be what the user wanted unless they specifically said so with--convert-subs.