Appending x264 encoded video

[hello_hello]

I'd assume if I encode the same video twice using the same encoder settings I should be able to append the two encoded videos without any problem?
Would it be safe to assume if I encode the same video twice while only using a different CRF value each time, or using CRF for one encode and 2 pass for the second, I should still be able to append the encodes?

Logically to me the answer would be yes each time, however it seems while at one stage the answer might have been yes, at some point that changed.
The end of a previous discussion on the topic of appending encodes. (http://forum.doom9.org/showthread.php?p=1619425#post1619425)

Generally the error offered by MKVMergeGUI is something like this:
"Warning: The track number 0 from the file 'D:\video1.mkv' can probably not be appended correctly to the track number 0 from the file 'D:\video2.mkv': The codec's private data does not match (lengths: 42 and 42)."

Aside from the fact the warning seems to indicate the codec's private data does match, the problem seems to relate to the MKV container but I'm not sure it's an MKVMerge problem.

If I encode the videos as per the examples at the beginning of this post, the only way all of those encodes would append correctly would be if the encoder output was rawavc each time. If the encoder output is MKV, they won't. One exception would be two encodes using the same settings and CRF value. They'll still append correctly if the encoder output is MKV. If the CRF value is different, they won't.

What I don't understand is if the encoder output is MKV and I extract the video from it as a raw stream, the raw streams can be appended, but while inside an MKV, MKVMergeGUI produces the above error.
Likewise I can take 2 raw streams which append together fine, mux them into individual MKVs, then try to append those MKVs with MKVMergeGUI to find they'll no longer append.

Does anyone know what it is about x264 video inside an MKV which effects it's ability to be appended when as a raw stream it'd append fine?
I'd have assumed this is a MKVMerge problem except for the fact the same applies to the x264 encoder's direct MKV output. That and the fact the poster in the thread I linked to tested older versions of the x264 encoder and found the problem hasn't always existed.

Anyone know what's going on? And can offer a not too technical explanation? :)

[sneaker_ger]

It is not an mkvmerge problem. The private data has to match in mkv (no changes during the course of a track allowed) - just having the same length does not equal being identical. The header data can vary for different input files even when using identical settings. Use the --stitchable option if you plan to cat several encodes together later on.

[hello_hello]

Wow, that was a quick reply! :)

The --stitchable option, is that an x264 option or a MKVMerge one? I'm not familiar with it.

What I don't understand is the inconsistency. Working with rawavc there's no problem if the encoder settings are the same (from the testing I've done). I can append CRF encodes using different CRF values and CRF encodes to 2 pass encodes etc. When the video's inside an MKV it's a different story. Extract it from the MKV and the problem goes away again. How does the MKV container effect the private data?

Thanks.

[sneaker_ger]

x264 option, needs revision 2342 or newer.

What I don't understand is the inconsistency. Working with rawavc there's no problem if the encoder settings are the same (from the testing I've done). I can append CRF encodes using different CRF values and CRF encodes to 2 pass encodes etc. When the video's inside an MKV it's a different story. Extract it from the MKV and the problem goes away again. How does the MKV container effect the private data?

I think mkvmerge simply does not check for ES input and will just create the PrivateData with the first headers it finds. When appending mkv files these already have PrivateData fields and then it does check whether they match or not.

[hello_hello]

I think mkvmerge simply does not check for ES input and will just create the PrivateData with the first headers it finds. When appending mkv files these already have PrivateData fields and then it does check whether they match or not.

That would be a quite satisfactory explanation except for what happens when you try to play the appended files. Maybe there's an explanation for that too.......

When I append two MKVs (same encoder settings) and MKVMerge spits out the private data warning, those files never play correctly (MPC-HC). They play to the point where the second video was appended to the first and from that point on playback is generally gibberish.

Same two encodes..... only appending rawavc instead of MKV. No warning from MKVMergeGUI and the appended video plays perfectly from beginning to end.

At least that's what's happened when I've run test encodes so far.

[hello_hello]

Well you're right. I still don't quite understand the rawavc vs mkv differences when it comes to appending, but --stitchable certainly seems to fix the problem. Cheers.

[sneaker_ger]

I don't know 100% but I think it may come down to the muxer that created the two separate mkvs in the first place. Basically the mkv PrivateData can replace the headers (sps/pps) in the H.264 bitstream. You could in theory drop all those headers when muxing to mkv and simply rely on the PrivateData for playback. Each encode has its own PrivateData that it needs for playback. Now if you created the two separate mkvs with a muxer that drops all headers when muxing you will lose the headers of the second part when combining them with mkvmerge, because those headers only existed in the mkv PrivateData of the second part and mkvmerge only keeps the PrivateData of the first part (keeping multiple PrivateData fields is not possible in Matroska). When decoding reaches the second part of the appended file the PrivateData does not mach the bitstream anymore and the decoding becomes b0rked.

Now when you encode to raw ES and let mkvmerge append those, mkvmerge will not delete the various headers. When playing that file in a linear fashion the decoder can actually read those new headers once the second part starts and now decoding will not become b0rked. There can still be problems though if you try to seek because the header may only be at the very beginning of the second part. If you didn't play the beginning first the decoder does not know that it should have switched to new headers along the way.

Which muxer did you use to create the separate mkv source files? I guess the one from Haali included in x264?

[hello_hello]

I tried it both ways. First the x264 Haali muxer, then remuxing the ES straight from the encoder with MKVMerge. Either way the ability to append changed the same way when the video was inside an MKV.

And yes.... it only happened once, but I appended two ES at one stage and playback was a little odd. It wouldn't display correctly if the player opened the video and attempted to begin playback from somewhere other than the beginning. If I started playing the video from the beginning it was okay. Or if I stopped it and started playback from just before the point where the video was appended, playback returned to normal after it played through the "join" point.

--stitchable does seem to be the solution.

[Stereodude]

I haven't had any issues joining more than one h.264 files that were encoded with identical x264 command lines in a mkv container. They play fine. I found that newer versions of MKVtoolnix require you to not set a FPS for any of the clips (let it detect it from the files) or the resulting file won't play past the first segment.

[hello_hello]

If you're joining raw AVC and outputting MKV, MKVMergeGUI doesn't complain, and with the same encoder settings the joined video seems to play okay. I did find one exception though (joining 2 pass encodes which then didn't play properly).

With the same video inside an MKV I could only get appending to work if CRF encoding was used along with the same CRF value each time. Until sneaker_ger suggested using --stitchable, that is.

[sneaker_ger]

I haven't had any issues joining more than one h.264 files that were encoded with identical x264 command lines in a mkv container. They play fine. I found that newer versions of MKVtoolnix require you to not set a FPS for any of the clips (let it detect it from the files) or the resulting file won't play past the first segment.

There was a fix related to that in 6.3.0 (#889 (https://trac.bunkus.org/ticket/889)). If it's still broken you should upload a sample for Mosu.