Help with mkv extract and remux

[bigtoedsloth]

I have a mkv containing mpeg2 video, ac3 audio, chapters and vob subs that was created with makemkv (v1.6.7 linux) from a DVD.

I'd like to replace the video with an x264 compressed version, but I'm having a/v sync problems after I extract the tracks and remux them. I'm using mkvtoolnix v4.6.0.

This works OK
mkvmerge input.mkv --output output.mkv

This works OK (note that I'm not transcoding the video, just remuxing)
mkvextract input.mkv --raw -f 1:video.m2v --raw -f 2:audio.ac3
mkvmerge video.m2v audio.ac3 --output output.mkv

But this doesn't
mkvextract input.mkv --raw -f 1:video.m2v
mkvmerge video.m2v --no-video input.mkv --output output.mkv

Obviously I want to use something like the last example (which doesn't work), since the chapters and subs are retained.

Can someone please help me with what I'm doing wrong?

[sneaker_ger]

It could be that there is an audio delay which mkvmerge will copy from the source mkv. It cannot do that for raw ac3 data, as this information will get lost on extraction.

Try setting a default duration of 32ms for the ac3 track.
Another way: also extract video timecodes and mux them back in later. This is probably easier/smarter.

/edit3:
As mkvextract's mpeg2 part is kinda broken, how about you encode directly from the mkv? x264 supports that and can take care of the timings:
x264 -o intermediate.mkv input.mkv
mkvmerge intermediate.mkv --no-video input.mkv --output output.mkv

[bigtoedsloth]

I don't think that its a problem with broken extraction in this case. I'm not finding any sync issues if I extract both tracks and then remux. Also, its not a constant offset. The sync starts OK, then gets progessively worse.

Just to confirm, I tried your suggestion of transcoding with x264 then remuxing, but there is still the same sync issue.

[sneaker_ger]

I just did a test to see it for myself and it did indeed not work for me either, which is IMHO an incorrect behavior of x264. I'll look further into it, consult the devs if I conclude it's an error and then report back here.

[bigtoedsloth]

That's great. Thanks for investigating.

Independent of x264, though, I'd still like to know why mkvmerge behaves differently when applied on two raw tracks (extracted using the same toolset) compared to one raw and the original file. Why is it that the a/v sync is OK for one and not the other?

[sneaker_ger]

In matroska every frame of every track (not only video, but also audio and subtitles) has a timestamp. When you feed mvkmerge a mkv file it will copy all those timestamps to the new file. If you feed it the raw files it has to create new timestamps from scratch. In your case the video track has lost all timestamps by extracting and is not sync anymore with the timestamped audio track. To prevent that you could copy the timestamps from the source to the destination:

mkvextract timecodes_v2 input.mkv 1:video_timestamps.txt
x264 input.mkv -o intermediate.mkv
mkvmerge -o output.mkv --timecodes 1:video_timestamps.txt intermediate.mkv --no-video input.mkv

That your raw video is in sync with the raw audio is probably a coincidence. Another possibility would be, that your track got somehow broken and maybe some frames are skipped. You are not doing any kind of IVTV, are you?

I haven't done all tests on x264 yet, but it seems that it drops any delay, so that the first timestamp is always 0.

[sneaker_ger]

It's an x264 feature, not a bug, but that doesn't explain progressive async. Please try the suggestion in my last post. If it still doesn't work, it's either:
1.) a bug in x264, ffms or mkvmerge
2.) a broken stream
3.) you are doing some kind of framerate conversion (--fps, --vf, some AviSynth stuff...)

If that doesn't help, it's beyond me.

[bigtoedsloth]

Brilliant!

Thanks for your help. I wasn't aware of the timecode output option from mkvextract. I haven't tried transcoding yet, but extracting the timecodes, video and then remuxing with the timecodes worked perfectly.

My problem is solved!

[bigtoedsloth]

If I do this, as you were suggesting

x264 -o intermediate.264 input.mkv
mkvmerge --timecodes 0:video_timestamps.txt intermediate.264 --no-video input.mkv --output output.mkv

then I still have problems, unless I pass the timestamps to x264 (using the --tcfile-in option), i.e.

x264 -o intermediate.264 --tcfile-in video_timestamps.txt input.mkv

From what you (sneaker_ger) mentioned before, x264 is supposed to take care of timings ... so what's going on?

edit: actually it just occured to me that you output to .mkv rather than .264. Does that make a difference to the timings?

[sneaker_ger]

From what you (sneaker_ger) mentioned before, x264 is supposed to take care of timings ... so what's going on?

Only if it doesn't have any initial delay and if you output to mkv or mp4. Post the first number of "video_timestamps.txt".

actually it just occured to me that you output to .mkv rather than .264. Does that make a difference to the timings?

Not if we feed mkvmerge with the timestamps.

Make sure that the "video_timestamps.txt" is from your original input.mkv and actually from the video track (look at the track order), not from any intermediate file. And it shouldn't matter for the sync whether you output to raw h264 or mkv nor whether you use --tcfile-in or not, as long as we feed mkvmerge with the video_timestamps.txt file for the final mux.

Otherwise:
If it still doesn't work, it's either:
1.) a bug in x264, ffms or mkvmerge
2.) a broken stream
3.) you are doing some kind of framerate conversion (--fps, --vf, some AviSynth stuff...)

If that doesn't help, it's beyond me.

[bigtoedsloth]

The initial timestamp is zero. I had a look through the first few thousand stamps and the differences are all 40ms (i.e. 25Hz) except for one which was 200ms.

Obviously I need to do a few more experiments and post back.

I can't vouch for 1 or 2 in your list, but its definitely not 3. You've definitely been helpful. Thank you.

[sneaker_ger]

Can you upload the complete timecodes of both the video and audio tracks of the input.mkv?

[bigtoedsloth]

I've attached the timecodes, but it turns out I've been a fool. I have always been using x264 to output a raw stream rather than muxing into a container. It turns out that in this case (corresponding to the attached timecodes) if x264 outputs to mkv then the remux with mkvmerge and the audio from the original file works fine.

[sneaker_ger]

Glad you got it solved, I didn't find the time to look at it over easter.
I highly doubt mkv vs. es output makes a difference in the case that you apply the timecodes back through mkvmerge.
I think the root of the problem might actually be mkvmerge not copying timecodes for audio tracks and instead creating new ones. I didn't know that - my assumption was that mkvmerge will copy the timecodes 1:1 for all kind of tracks, including audio. The reason I suspect that as the source of the problem is that the audio timecodes of your source show 80 gaps.
It doesn't matter because you solved your problem, but I thought I'd take a look at it anyways.