View Single Post
Old 15th December 2018, 21:51   #17  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
It sounds like there's a video delay, given there's no such thing as negative delays for MKV. Does MTS allow negative delays?
The trouble is, if both the video and audio have delays, you need to know both values as the correct delay for remuxing the audio changes.

I made an MKV similar to the one you described, except in addition to specifying a video a delay of 855ms, I specified a delay of 55ms for the audio. MediaInfo reports an audio delay of -800ms.

gMKVExtractGUI shows the correct info in the GUI. At the end of the video stream it displays [855][855] and for the audio stream it displays [55][-800]. It writes -800ms to the extracted audio stream.

Audio_track2_[eng]_DELAY -800ms.ac3

MKVCleaver doesn't tell you anything in the GUI, but it can be configured to write either/both delays to the audio stream. I have it configured to do both. That way you can look at the extracted audio and know there's a video delay.

Audio 02 eng TDly 55ms Delay -800ms.ac3

It's configurable, so if you prefer you could change it to write something like this instead.

Audio 02 eng TDly -800ms Delay 55ms.ac3

My custom output configuration looks like this:
[Filename] [Track#] >[LNG3] TDly >[Delay] Delay >[aDelay]

What source filters do to compensate when decoding is a different matter, but the delay you'd use when remuxing the original audio depends on whether you're remuxing with the original video, where you should use 55ms, or with a re-encoded version, in which case the original video delay is usually lost, and the correct audio delay would be -800ms.

I downloaded your earlier sample (source.mkv). The audio sync isn't perfect anyway. To me, it seems to need an audio delay of around -250ms relative to the video to sync them up. That aside though.....
It has a video delay of 1249ms and no audio delay, so when remuxing the extracted audio with the original video you'd ignore the -1249ms delay written to the audio stream. Normally, after re-encoding the video, you'd apply the audio delay.

When I extracted the audio with MKVCleaver, the file name it created for the extracted stream was this:
source 02 TDly 0ms Delay -1249ms.aac

Or if you remux the original sample while applying a delay of -1249ms to both the audio and video streams, MKVToolNixGUI will remove the first 1280ms from the audio, and you'll be left with a "real" audio delay of 31ms and no video delay.

I almost never work with sources with orphaned B frames at the beginning so I'm not sure if MKVToolNix automatically drops them when remuxing. I suspect not because I think it'll split video with an open gop which can orphan B frames (I assume), but if those sources are easy to identify and don't have an open gop, the first thing I'd probably do is remux with MKVToolnix while splitting the video on the first keyframe. That should put the first keyframe at "0" and any audio delay shown by MediaInfo etc. should always be "real" or "correct". Are orphaned B frames at the beginning all that common?

Last edited by hello_hello; 16th December 2018 at 11:46.
hello_hello is offline   Reply With Quote