--stitchable & variable frame rate encoding

[hello_hello]

Is there a reason why the stitchable option rarely seems to work when using variable frame rate encoding (giving x264 a --tcfile-in file)? At least when the encoder is writing directly to an MKV, even when it's using the same timebase for each segment.
MKVToolNix always seems to complain about the codec's private data not matching, although the appended files seem to play okay, so maybe it's not x264's fault.

The last attempt resulted in "The codec's private data does not match (lengths: 45 and 46)"

For some reason the workaround seems to be to extract the avc stream and timecodes from the MKVs, use them to mux new MKVs, then append the new MKVs together. I don't understand why that works, but it stops MKVToolNix from complaining.

Thanks.

[sneaker_ger]

Field rate (timescale and num_units_in_tick) is part of the H.264 headers. So probably x264 choose at least a different num_units_in_tick for different timecode file. But it should not be a problem for playback. Identical header data means there should be no problem but non-identical header data does not necessarily mean there are problems.

For some reason the workaround seems to be to extract the avc stream and timecodes from the MKVs, use them to mux new MKVs, then append the new MKVs together. I don't understand why that works, but it stops MKVToolNix from complaining.
When input is not mkv there is no "CodecPrivate" element (it's specific to mkv container) so Mkvtoolnix doesn't warn. Does not mean the same "problem" isn't there.

[hello_hello]

When input is not mkv there is no "CodecPrivate" element (it's specific to mkv container) so Mkvtoolnix doesn't warn. Does not mean the same "problem" isn't there.

I see..... (although I don't really understand what "num_units_in_tick" means). Is that the same as the timebase?

I wonder if maybe the --stitchable option isn't working when VFR encoding is used. I checked MeGUI's log file, and both times x264 said "automatic timebase generation 1/199900" and I definitely used the same encoder settings each time, aside from the --tcfile-in file.

Is there a way to investigate what's different about the "codec private data"? I know nothing about it.

I'll check the appended video in a couple of stand-alone players, although normally if MKVToolNix complains and there's a problem, it shows up when playing the appended files with MPC-HC, but you never know.

It's just that it was such a long encode, and for the first time in a long time encoding slowed and slowed until it eventually stopped, hence re-commencing from the middle, so even though I've noticed appending VFR files has been a problem in the past, in this case I'd prefer to avoid doing it all over again unless it's necessary.

Cheers.

[sneaker_ger]

With --fps 24000/1001 x264 will set:
num_units_in_tick 1001
time_scale 48000

So it's basically like fps value in H.264 bitstream. It's what e.g. mkvmerge uses to guess the framerate of raw H.264 input.


I wonder if maybe the --stitchable option isn't working when VFR encoding is used.
--stitchable is working as intended.

Is there a way to investigate what's different about the "codec private data"? I know nothing about it.
It's basically just H.264 header data. Use H.264 analyzer.

in this case I'd prefer to avoid doing it all over again unless it's necessary.Cheers.
It's not necessary to re-encode.

[hello_hello]

Thanks. I'll check out h264 analyzer.