Ending segment ends up corrupt when just merging
IAmEmphy opened this issue · 5 comments
Hi!
I have a bunch of files where opening\ending is segmented, and it's mostly been working great.
But I've hit a tiny issue that I can't seem to figure out\work around on my own.
I would like to just do a merge and not -fv due to time, number of files and that I would like to keep the bit depth instead of down-converting to 8bit.
My ending segment turns out like this:
But only on this specific ending segment, all files using other ending segments seem fine.
Tracelog (Lines 3239-3250 might be interesting, but I'm not entirely sure what they mean) here:
TRACE.txt
The command I run is:
unlinkmkv.exe -ll TRACE --outdir C:\unlinkmkv\output\YYH YYH\ > C:\unlinkmkv\output\YYH\TRACE.txt
My suspicion is that something is wrong with the ED2 file so it breaks when handled by mkvmerge.
I'm not sure if this is something you can work out, or if I'm stuck until I fix the file somehow. (Any advice on how, should that be the case, would be much appreciated.)
If you need any more information, I will provide that as quickly as possible. :)
Thank you for making this amazing software!
Unfortunately that issue is a telltale sign/normal behavior when two segments are incompatible with each other. Re-encoding is really the only thing you can do, which is what fixvideo does. By no means do you have to use the default encoding options (look at the ini file for an example), but you will lose quality and it will be lengthy as these things go.
Okay, thanks for the swift reply!
I'm a bit confused about the difference between the linux and windows version. If it's okay that I ask that question in this issue?
Do I just drop this onto a new line in the ini file?
fixvideotemplate = -c:v libx264 -b:v {var_minrate}k -minrate {var_minrate}k -maxrate {var_maxrate}k -bufsize 1835k -max_muxing_queue_size 4000
Just with modified parameters ofcourse. I'll have to do some research on exactly what those parameters would be.
And alternatively, is there any way to make the last segment compatible? Then I could just re-transcode part of the episodes and manually change the segment ID.
I'm not entirely sure how to tell exactly what makes them incompatible, or what to google for more info. Can you tell that from the logs? (Or if I send you the files. But I don't want to be too much of a bother.)
Right on the parameters. Generally the windows version lags a little behind since I have to build it in a VM (I don't personally use windows on my workstation), and that one comes with the dependencies to ease set up.
As far as making it compatible, that'd be tricky. Essentially what you'd need to do is learn how the other segments were encoded, and use the same/similar settings -- if you're able to ask the original encoder, that'd be by far the easiest way to determine this. Sometimes it's straight up not possible, though I've only ran into this with ogg vorbis audio, those aren't able to be appended at all.
In case someone else comes by, here's how I seemingly solved it:
I acquired a 10bit version of the ffmpeg binary since they apparently can only be either 8 or 10. (Got mine from ffmpegyag, but a binary can be compiled manually with the parameter --bit-depth=10)
So I simply swapped that in place with the other one, ran with -fv and it seems fine from initial viewings. (I also added high10 in the ffmpeg parameters, but not sure if that's actually needed considering the binary should only output 10bit either way.)
Would it be difficult to put in a 10bit ffmpeg binary in the repo that gets triggered by something like -fv10. Would you consider that?
I'm not a developer, and what little I know is not Perl, so I'm not sure how much work would be involved.
Beyond that, I've solved my problem and this can probably be marked as closed. Thanks for all the help. :)
I just wanted to ask, is this related to the problem cited above?
It depends on the episode, but I end up with something similar on one, if not all, the segments after muxing.
The first 14 episodes were alright since they used the first set of OP/ED, but once I started providing the second set everything went wrong.
Here is the tracelog for that episode: trace.txt.
Thanks