Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Feature: Add ability to force remux to custom container even when not necessary #21343
Comments
|
Only now I noticed the --recode-video option, sorry about that. However it also has the context of "if necessary", so I guess that was close heh. That option is again heavily mislabeled IMO. When it comes to container formats the term "remux" is more appropriate, and secondly, the term "video" at the end is also confusing because when talking about "re->coding" video is usualy meant to be re-encoing it to a different codec, not just remuxing/repacking it into a different container, if it is about remuxing anyway, then the valid values would be mislabeled. |
The --recode-video option does in fact reencode the end file(audio+video), even if a remux would suffice (E.g. mp4 to mkv). Therefore i think that the name of the option "recode-video" is correctly labeled, but this also means youtube-dl is missing a proper remux option. I agree that a real remux option is needed, to give the user the possibility to force a certain container if he wants to. |
|
What about |
Does only work when audio and video files are downloaded separately and merged in the end. But if you use 22 as quality setting for example(to get a higher audio-bitrate), you endup with a mp4 instead of an mkv (even when |
|
Yeah I spoke a bit too soon, recode does indeed re-encode, it's nice to have capability in there but unless I can precisely control the encoding configuration then I rather to it separately, but it's getting complicated just maintaining an archive already a chore quite a bit more than I thought. What I meant to say is that the values are misleading then, it should be recode to X264 or HEVC or stuff like that, encoding is a bit more involved to fit into one simple command so that could be a bit though out and redesigned but I don't have strong opinions there as I want to preserve the video quality first and foremost (even tho I know youtube uses the worst chroma subsampling, but it's about archive integrity) |
|
@altimumdelta, Chroma subsampling doesn't affect the perceived visual-quality, "quantization" is what affects the visual quality in this context.
|
|
Reencoding currently has a problem in that it does not have a way to target video quality/bitrate (unlike audio), which can massively reduce bitrate even if you just want to place the video+audio in a different container (aka, if you simply prefer .mkv, or want subtitles to not convert to timed text when it had a perfectly good SSA at source just because it went to mp4 -- which, by the way, does also seem like something that should be a sufficient "requirement" for a different container as opposed to lossily throwing away good captioning information). |
Well sure in this case when we have a higher level of chroma subsampling, we won't be converting to a different one, but have you ever recorded a monitor's RGB output, like a 3D game, chroma subsampling has a huge effect and you can't see some things that you can with the raw video, because pixels simply disappear, so I don't think I can agree with that rule, perhaps it was made by some TV people 20 years ago who never looked at a computer monitor before I guess? Yeah I found the study, I don't agree with it, they tested some ordinary TV content with ordinary mom/pops untrained subjects, yeah it can be said for TV when people are watching it half-aleep after work from a larger distance, that's about it, beyond that the study does not apply, every time I look at chromad content I puke, the difference in colors, lighting, and detail is absolutely undeniable, horrible. But back to the main point, I think this request is reasonable, to have a way to remux the video to a container format, it's something that's really a low complex thing, whereas supporting re-encoding is a much larger thing so that's why I see no reason why this couldn't be a supported thing. |
|
Thank you for doing this PR. |
Checklist
Description
It may be handy to support remuxing the finished downloads with ffmpeg to a custom container format (eg. MKV) even when not necessary, for the purposes of having a backup archive filenames and formats consistent across the board (in case of a mix of MKVs, MP4, etc) as well as opening up possibilities for combinating with other features such as described here: #21344