Merging two MKV files (x264 10bit same settings)?

[Flux]

I tried to merge two MKV files which both have been encoded with same x264 10-bit command line settings, but when I play the video with MPCHC madVR LAV, the video is green, purple garbage when second part is playing.

Because encoding takes so long, I have splitted one video file to multiple parts, encode each part and merge them later. You can't do that?

mkvmerge says:

track number 0 from the file 'test.mkv': The codec's private data does not match. Both have the same length (46) but different content. 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.

[Atak_Snajpera]

1) demux video stream to .264
2) copy /b part1.264+part2.264 joined.264
3) mux joined.264 back to mkv

this is exactly what i do in distributed encoding mode in ripbot264.

[Flux]

Now It seems that the second part works, if I don't jump there, but let the player to reach the breakpoint of the joined parts by playing it normally. After that the first part is garbage, if I jump back there.

Used MeGUI's muxer. Same result with mkvmerge. Muxed joined .264 file in both cases.

[Flux]

I have probably kept the different version of the part1 video, so I joined two parts of different encoding settings. One was CRF 18 and other CRF 16. Tuning was different too. This might be the problem? Altough other splitted parts of the video seems to work correctly together, there is still those big gray block artifacts which are present in one or two frames when player has reached the seam of two video files. However, it doesn't happen in all seams.

Opened these parts separately in virtualdub and seems that some parts have first two frames filled with dark gray and gray blocks. Why that happens?

EDIT

Gray blocks are present in original splitted files too. So mkvtoolnix fcked up the splitting for most files. I used split every X seconds method. How I can avoid this happening again? What is the safe method to split mkv files for re-encoding and then merge them back for seamless playback?

Because only first two frames are ruined in multiple video files, how I should proceed to re-encode those frames from clean source and then merge them? Not going to re-encoding the whole video again because it takes forever.

[Atak_Snajpera]

Have you tried Distributed Encoding mode in Ripbot? Go to C:\temp\Ripbot264temp\job1\Chunks folder. Then you will see how I do it exactly in AViSynth with FFVideoSource.

Not going to re-encoding the whole video again because it takes forever.
Let me guess. You have Atom CPU and you used Placebo preset ;)

[Flux]

I'm using veryslow preset and overclocked Q6600 3.2 GHz. 10-bit x264 takes its toll too. :scared:

[Atak_Snajpera]

Why don't you use Default medium preset then?

On my Q6600@3Ghz i get about 8 fps with 1920x1080 source. With another Q8200@2.8Ghz I'm able to achieve even 16fps.

[Flux]

Because veryslow seems to give best results for 10-bit encode. Only few parts left anyway. I'm not actually whining about time consumption, it is just annoying when something is fcked up and re-encoding the whole crap is easiest but very time consuming option.

Why don't you use Default medium preset then?

On my Q6600@3Ghz i get about 8 fps with 1920x1080 source. With another Q8200@2.8Ghz I'm able to achieve even 16fps.
I get like 2-3 fps with veryslow preset.

[Atak_Snajpera]

I get like 2-3 fps with veryslow preset.
LOL. 3-4 times slower than on default profile. For me it is just a waste of time. I'm glad that I'm not so obsessed with quality ;)

[Flux]

This is really weird now. I merged two original splitted files together and MPCHC doesn't show any artifacts when going through the seam. Virtualdub shows gray block artifacts in first two frames for both parts. Only when I re-encode those parts, then merge them, those artifacts what virtualdub shows, are visible in MPCHC too.

[mgh]

You need to split on I Frames, if you are going to transcode the parts separately. If you are going to split and then just rejoin, it is not necessary.

[Flux]

How I can split mkv files on I-frames? Can mkvmerge do that? Shouldn't these things be automatic in first place?

[zetsu_shoren]

Bumping to ask something.

What about merging an 8bit with 10bit? Say I have an episode in 8bit, and the same episode by another sub group in 10bit, and I want to replace the next episode preview part of the 8bit video with the 10bit's next episode preview. I want to do this because the next ep preview of the 8bit file is corrupted. The video stops playing, the subs don't show when the video stops playing, but the worst is the green boxes on the video when it stops playing. The audio continues to play. If you skip ahead, the video turns black. Sometimes, going back would show other messed up garbage.

I wanted to ask if there's anything wrong about merging these 2 files of different colour bit depths together into 1 file.

[sneaker_ger]

It is not allowed to do that in Matroska.

[zetsu_shoren]

How is it not allowed? I was able to do it, and it works fine. I put the 8bit into mkvmerge GUI, clicked on the Global tab, and under splitting, I inputted the time just before the corrupt next episode preview part and separated into two parts after said time. I did the same thing for the 10bit file. I dragged the 8bit into mkvmerge GUI again, fresh, clicked on Append which is in the Input tab, chose the second part of the 10bit file I split (since I did the same thing as with the 8bit, it should be understood that there too are two 10bit files), muxed, and voilà.

A whole new file that makes use of the 8bit up to the point before the next episode preview, and the 10bit next episode preview.

It works well. There's nothing wrong with the new file whatsoever. Everything's in sync. I basically replaced a part of the video with another part of a video from a different source. I don't know the consequences for this, what it may do to my system, but for now, I would like to say that merging 8bit and 10bit videos work. This "merge" I refer to is NOT the chapter linking. I think THAT'S the one that's NOT ALLOWED. As for joining two videos of different colour bit depths into one, it works fine.

Just wanted to ask about the consequences for this, if any, and I wanted to share my discovery, if not yet discovered.

[sneaker_ger]

I didn't say it wouldn't work, I said it's not allowed. An H.264 stream's headers are stored in the "CodecPrivate" mkv element. The problem is that headers differ between 8 bit and 10 bit so you would need more than one such element per stream. The element is however global for the entire stream length, i.e. more than one and in turn mixing 8 bit and 10 bit is implicitly forbidden by the specs.

It may nonetheless be played back successfully if the player reads headers from the stream itself instead of only from the mkv container. If the headers are not present (or not in every GOP) playback can and will break. It will also break for players that rely on the mkv spec being followed instead of reacting to header changes within the H.264 bitstream.