add support for automatically merging encode segments via helper script #219
Conversation
|
If some of those segments have different resolutions or framerates, what happens? |
|
I'm not sure, but I suspect in that case it might be necessary to re-encode manually to stick them together. IIRC the concat demuxer normally requires the videos to be uniform in those respects, so it might fail in cases like that. Still, right now the worst-case scenario is that the concatenation fails and the segment files are still there. So in its current state, it should still be safe to enable, even in situations where it wouldn't work. You do have a good point; I guess if the script was going to be altered to automatically delete the segments after merging them, there should be a check in place to make sure it only did that if the merge was successful. I assume ffmpeg would have a nonzero exit code if there was an issue, so in Bash that would be a simple if statement. I haven't tested that yet though. |
Instead of just leaving the copy-pasted one intact 🤦♂️
No need to pipe `yes` to overwrite without prompting.
|
I just tested what actually happens when you try to merge files with differing framerates and resolutions. Surprisingly, it actually merges them without error, at least if the video bitstreams are h264. I'm not sure if that's good or bad, though, since the merged file may have very poor compatibility. Mpv handles the framerate and resolution transitions seamlessly, but I don't think most other players are so robust against something so unusual. Even VLC stuttered a bit from the resolution shift, in my testing. A lesser player may just decide to crap out entirely... I can't figure out how to make ffmpeg simply quit with an error if there's a mismatch, which means it can't be used for the basis of an if block. So if another option were added to delete the segments after merging, it would be unsafe in cases where there's a resolution or framerate mismatch. Though as it stands now, it's still safe because the segments are unconditionally retained, so if the automerged video is broken/weird it can't just ruin an entire encode. |
|
That's what I expected the least! |
|
I looked up the in-depth documentation for the concat demuxer. It had an option called Apparently the "conversion" referred to is not a re-encoding, but just messes with the metadata in the bitstream packets or something like that, for h264 (and does nothing for other formats). Apparently this option was enabled by default. I tried disabling it manually with " ...After that test, I even tried mismatching the codec, and still it chose to produce an invalid file rather than exiting with an error. It seems the concat demuxer is determined to produce some sort of output file and exit "successfully", come hell or high water. |
|
Just add an explicit check then, it has to have a way to tell if the video parameters are different. Lack of proper error seems to be their bug, you decide if you feel like reporting it to them. |
|
Mkvmerge, unlike ffmpeg, does seem to care if the inputs match. If adding it as a dependency were no obstacle, that would be the simplest option. Otherwise, an explicit check would likely require parsing the output of |
|
I just figured out that it might be easier to embed the script than have it as a separate file. I was initially afraid a solution like that might end up as a escape-sequence riddled mess (insert dumb joke about Shulk spamming Backslashes here). But it turns out C++ supports "raw string" syntax since 2011, so it actually can integrate pretty seamlessly without making a mess of the script and resulting in "write-only code". That being the case, I don't actually see a downside to moving the script inside a string constant in a header. |
…e project is supposed to have a copy of this at the top.
It worked even though I forgot this, so I assume it was already getting included by one of the other headers. Still, I think it's good practice to explicitly include the correct headers.
|
The downside is probably not being able to tweak the "script" that's being run? |
|
Well, it might be worthwhile to specifically support running user-provided scripts instead of just the one. As I mentioned, the raw string means the script is still reasonably maintainable as a header file, but it might be interesting to support tweaking/replacing it at run-time without recompiling. 🤔 In that case, the new feature would probably be defined less as the ability to merge segments, and more as the ability to run a user-provided script after finishing an encode, with my merge script just being an example. It might be good in that case to have the user provide a script path in the encode settings window instead of just looking for |
|
Is this pr gonna get merged or just closed and forgotten? I think its pretty handy. |
|
Would like to see this. Constantly getting PCem encodes with 8 different segments during boot. |
|
I've had a thought. Even if I tell ffmpeg to output segments of the same resolution and framerate, they are still split. Maybe that part needs to be fixed on the libtas end first? However how would it know ffmpeg outputs at the same res? libtas is using nut so it doesn't know what the user told ffmpeg to do. Or maybe we just a setting in the encode config that tells it not to split? |
|
Yes, we could have a setting that prevent the encoder from restart on window resize. It would probably break the encode if the resolution changed. Or, we could link to |
|
If done automatically, it'd make sense to also control resize filter and target res, but on the other hand if the user already handles resizing manually why would it ever change the end resolution? |
|
The split is done because nut format does not allow changing the resolution inside a single stream. So whatever was passed to ffmpeg does not indeed matter. Resizing must be performed by libtas, or it must be done after ffmpeg pass. Or maybe there's an option to tell ffmpeg to append multiple consecutive streams? |
@nattthebear do you happen to know? |
|
I don't remember anything special offhand, no. |
|
I got this suggestion from Spike:
|
|
|
This is in response to #243.
It adds a checkbox to the encode settings window and a boolean to the config structure, and connects them together. When this new setting is enabled, a helper script written in Bash is called to merge all the segments automatically.
For now, the segments are still left intact and not deleted. However, if it's desired to automatically clean up the segments and free up space after writing the merged file, this could be changed just by adding an extra line or two to the Bash script.
It should be noted that the script heavily uses "Bashisms" and won't run on just any generic POSIX shell. You very seldom see a Linux system without Bash installed though, since it's part of the GNU base system, so I don't think of this as introducing a new dependency.