Video Codec "Private Data" Does Not Match During Join

[Shoal]

Hi all!

I've been trying to merge two MKV videos in mkvmerge but keep getting the following error:

"The track number 0 from the file '[file1]' can probably not be appended correctly to the track number 0 from the file '[file2]': The codec's private data does not match (lengths: 42 and 42). Please make sure that the resulting file plays correctly the whole time. The author of this program will probably not give support for playback issues with the resulting file."

I don't understand how this error is happening. Both videos use the h264/AVC-x264 codec and encoding settings, both have the same framerate and resolution, both have WAV audio (stereo, 16-bit, 48kHz), and both were created using the same version of mkvmerge. Their video was created using the same version of x264, and their audio the same version of SoX.

Furthermore, both files were encoded from a HuffyUV-WAV lossless source. The same version of HuffyUV and Audacity were used to make them. I made those source videos myself (from another even earlier source).

Every time I re-encode the "broken" video the same error happens; every time the video turns out "different" from the others. This happens even if I re-create the original Huff-WAV source and re-encode from there.

The audio, note, must be WAV since the content is meant for blu-ray. I have no choice but to use MKV. MP4 doesn't allow for WAV audio.

Any help would be greatly appreciated, thank you.

[sneaker]

The H.264 parameters differ, for an in-depth analysis you may require something like CodecVisa. (Sometimes this is not relevant, sometimes it is.)

[Shoal]

What would I be looking for?

[sneaker]

Open each video, click first frame. In bottom-left part of the CodecVisa window you will find info about headers (SPS, PPS). Look for any differences.

[Shoal]

Is there no free way to do this?

[badyu17]

Since you are making this for blu-ray, is the frame rate 23.976? I remember I once had same error when the frame rate was different. Maybe something like 24000/1001 for first video and 23976/1000 for second video which is different. Either that or you forgot to change one of the x264 settings. Check it again.

[Shoal]

badyu17 -
All framerates are exactly the same. MediaInfo reports "Constant" framerate at 23.976 for all videos.

[badyu17]

Can you upload short sample of the files?

[Shoal]

badyu17 - I'll have to see if the error holds on a sample edit. That would be an interesting test. But I'm doing a different test right now to try and solve the problem though, so I'll get to that afterward.

[Shoal]

I can say, however, that I discovered something interesting: if I attempt to join video only, excluding audio, I don't get the error message. Weird. Somehow the audio track must be screwing it up.

[badyu17]

Weird... is the version of mkvmerge recent?

[Shoal]

badyu17 - Latest, yeah.

[jagabo]

All framerates are exactly the same. MediaInfo reports "Constant" framerate at 23.976 for all videos.

That may not mean anything because 23.976 is only an approximation. The true value is 24000/1001 or 23.976023976023976... So if one program flags the frame rate as 24000/1001 and another as 23976/1000 or 2157842/90000 (a time base of 90000 is often used in MP4 files) all will show up as 23.976 in MediaInfo and most other programs. But they are not exactly the same. And some joiner/muxer programs will call that a frame rate mismatch.

[Shoal]

jagabo - How would I look that closely at the framerate? Does the aforementioned CodecVista do it? EDIT: Also note what I said earlier about the videos joining fine if I remove the audio.

[Shoal]

Another update:
If I combine all the video files with no audio, the length comes out to 5:24:16.354. But the all the audio combined without video produces 5:31:46.561! I know the audio is correct. Something is REALLY screwy. When I playback the video it seems(?) to be running faster than it should. I didn't leave out any videos. But it still says "Constant 23.976" for the video as a whole.

[Cornucopia]

All framerates are exactly the same. MediaInfo reports "Constant" framerate at 23.976 for all videos.

That may not mean anything because 23.976 is only an approximation. The true value is 24/1001 or 23.976023976023976... So if one program flags the frame rate as 24/1001 and another as 23976/1000 or 2157842/90000 (a time base of 90000 is often used in MP4 files) all will show up as 23.976 in MediaInfo and most other programs. But they are not exactly the same. And some joiner/muxer programs will call that a frame rate mismatch.

I think you mean 24000/1001, not 24/1001.

Scott

[jagabo]

I think you mean 24000/1001, not 24/1001.

Yes, of course. Fixed the original post so as not to confuse future readers.

[sneaker]

Is there no free way to do this?

CodecVisa free trial version never expires, just limited to first 2 frames. That's sufficient for this purpose. (There may be other free softwares as well.)

I can say, however, that I discovered something interesting: if I attempt to join video only, excluding audio, I don't get the error message. Weird. Somehow the audio track must be screwing it up.

"video only" as in "h.264-in-mkv" or as in "raw H.264"? Mkvmerge will never show the discussed warning in case of the latter but that does not mean the problem isn't there.

But it still says "Constant 23.976" for the video as a whole.

MediaInfo will typically not analyze the video as a whole and the framerate information is not always reliable.

I suggest you go back to start to find your error. Anyways, it is recommended to cat in a program like AviSynth and then encode video and audio as a single, continous entity from that, not encode single parts and cat them afterwards. That will avoid a number of possible problems.

[Shoal]

Sneaker -
I think I did combine them as raw in mkvmerge. But, honestly, I don't remember. I may have done it both ways in my experiments.

It's been a loooooong time since I used AviSynth. XD I'll have to look into it again.

Update:
Re-encoding the original HUF-WAV videos in CRF rather than 2-pass seems to get rid of the error. Annoying, but it means I can at least move forward with the project!

I might try the AviSynth thing though. How does AviSynth access the command lines for x264, SoX, and mkvmerge?

[sneaker]

Update:
Re-encoding the original HUF-WAV videos in CRF rather than 2-pass seems to get rid of the error. Annoying, but it means I can at least move forward with the project!

Did you use varying --bitrate values when you used 2-pass mode? If you want to have varying --crf/--bitrate values between segments you need to activate the --stitchable option.

I might try the AviSynth thing though. How does AviSynth access the command lines for x264, SoX, and mkvmerge?

AviSynth is used via a scripting language. You would need to write a script that loads and appends all source files. Then you can feed the AviSynth script into x264 and SoX (or other encoders of your choice). To the encoders the AviSynth script is like a long, single file.

[Shoal]

Sneaker -
I was just planning on re-encoding all 14 of the videos with the same CRF value, just to be safe and visually uniform. Also, I used the same bitrate for all the videos in 2-pass mode.

As for AviSynth... I used to use it in VirtualDub for this or that, but not since probably 2007. I remember very little about it. As for today, I have it installed now (the latest version), but I fear using it x264 alone or SoX alone. I fear, in other words, separating the video and audio for separating encoding. Read above what happened when I tried this.

[Shoal]

Update:
I think these videos are reporting a constant framerate of 23.976 but, in actuality, have a variable framerate. Not only does joining the raw video streams without audio produce a much different length than all the audio joined together alone, but VLC doesn't even report the framerate of these videos. It's not listed in the codec information.

Is there a way using CodecVista to determine what's going on with the framerate? Or is there a way to read one of the original source videos and extract something that will allow me to preserve the variable framerate even when the videos are joined without audio?

[poisondeathray]

Update:
I think these videos are reporting a constant framerate of 23.976 but, in actuality, have a variable framerate. Not only does joining the raw video streams without audio produce a much different length than all the audio joined together alone, but VLC doesn't even report the framerate of these videos. It's not listed in the codec information.

Is there a way using CodecVista to determine what's going on with the framerate? Or is there a way to read one of the original source videos and extract something that will allow me to preserve the variable framerate even when the videos are joined without audio?

Furthermore, both files were encoded from a HuffyUV-WAV lossless source. The same version of HuffyUV and Audacity were used to make them. I made those source videos myself (from another even earlier source).

Huffyuv in AVI doesn't support VFR (AVI container is CFR only). So was it in sync at that part of your workflow ? or were there already problems then ? Check the A/V durations there

But yes , you can extract timecodes from a video that is VFR. There are many threads and differnent methods on how to do this

(It doesn't really help you in the end if your end goal was BD, because BD doesn't support VFR; it's CFR only.)



But what was the original, original source ?

It's more likely you just goofed up somewhere, maybe with the settings. 2pass vs. CRF shouldn't produce any differences in terms of appending

Doing it all at once is the much smarter way to do it. Audio & video are almost always done separately. You can check for sync by playing back the avs script (you can include audio in the script with audiodub() )

If you insist on doing it in parts, you should be using --stitchable for x264, it will improve your chances of appending (at least the video portion)

[Shoal]

poisondeathray -
The original HUFF-WAV files had no problems.

The original-original files are MP4s produced by Noteburner stripping iTunes videos of their DRM. I wanted to convert all my 1080p iTunes Star Wars: Rebels episodes into blu-ray. And because I don't know how to put different blu-ray videos on the same blu-ray, I knew I had to just turn them all into one big movie.

However, these MP4's had a big problem. That is, when I tried to join them together in mkvmerge the following error was reported:

"The AVC video track is missing the 'CTTS' atom for frame timecode offsets. However, AVC/h.264 allows frames to have more than the traditional one (for P frames) or two (for B frames) references to other frames. The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to."

Okay, so I'm going to have to re-encode the videos to fix them, right? This is where the HuffyUV versions came in. (I don't recall exactly why I decided to HUFF the episodes instead of just re-encoding them straight. But I must have had a reason. The whole story isn't in this text, and I don't even remember it.)

As for me "goofing up" somewhere, I honestly see no chance of that. I did exactly the same thing for those episodes as I did for all others, altering between them only the x264 command line from --pass "1" to --pass "2", and then back again for the next episode. Episodes 0-5 and 10-12 had no issues, but 6-9 and 13 had issues and would not join in mkvmerge without warnings. So I re-encoded them, and they STILL had problems. Then I re-encoded the HuffyUV versions and re-encoded those, and STILL had problems.

I was pulling my hair out by the time I started this thread. I cannot for the life of me figure out how these episodes, even after being HUFF'ed twice, produce warnings. It's like they're cursed!

But I did discover, as stated above, that joining the videos without audio didn't produce any warnings, and no warnings are produced if CRF encoding is used instead of 2-pass. (Even with audio present.)