Correct Delay relative to video in MKV with mkvpropedit or ffmpeg?

[mrwhitethc]

I have an MKV it shows -21ms for "Delay relative to video" on a single audio track. If I load the same MKV up into gmkvextractgui it shows

video [21ms][21ms]
audio [0ms][-21ms]
audio [0ms][-21ms]
audio [21ms][0ms]
audio [21ms][0ms]
audio [21ms][0ms]

What is the way to change the delay with either mkvpropedit or ffmpeg? and/or how to set them all to zero in one shot? I did try using ffmpeg and something simple like:

ffmpeg -itsoffset 0 -i $mkvfile -itsoffset 0 -i $mkvfile -map 0:0 -map 1:1 -c copy test.mkv

and it did not change the "Delay relative to video" field. I also tried using mkvtoolnix gui and setting all the deley (in ms) fields to 0 and it also didn't change it. I also don't like to use mkverge because for whatever reason it often changes the md5hash of the video if I check it with ffmpeg.

[johns0]

Mkvmerge doesn't change any settings or alter the file structure,the only reason you see any hash difference is due to files being removed or added to the mkv.Just keep the delay as it is since its done to keep the file in sync.

[mrwhitethc]

Mkvmerge doesn't change any settings or alter the file structure,the only reason you see any hash difference is due to files being removed or added to the mkv.Just keep the delay as it is since its done to keep the file in sync.

The delay is actually wrong since I'm added a new track to the file and replacing a previous track in it's place and the delay information is being copied over incorrectly. I also tried stripping out the audio then adding in a new track and the [21 ms][21 ms] delay listed in the video track still remains. It might seem silly but I would like to know how to fix this in the event where I would like to set or correct that field myself.

*EDIT* I inadvertently thought it was copying over the metadata delay to the audio track I'm trying to add. Since the video track is set to 21ms any track added with a 0 delay is being set to -21ms.

[hello_hello]

For the record, MKV streams can't have a negative delay. As you surmised, in your case the audio has a -21ms delay relative to the video, which has a 21ms delay.

Applying a -21ms delay to just the video stream doesn't prevent the other streams from having a -21ms applied to them, as that's not what's happening. If the streams should be in sync as they are, then a -21ms delay should be applied to every stream while muxing.

Keep in mind that MKVToolnix can trim the required amount from the beginning of the audio instead of applying a negative delay, because it can't do that. It can't always trim the exact amount specified, in which case it'll trim a fraction more and then apply a delay to the audio to make up for the extra bit trimmed.

[mrwhitethc]

For the record, MKV streams can't have a negative delay. As you surmised, in your case the audio has a -21ms delay relative to the video, which has a 21ms delay.

Applying a -21ms delay to just the video stream doesn't prevent the other streams from having a -21ms applied to them, as that's not what's happening. If the streams should be in sync as they are, then a -21ms delay should be applied to every stream while muxing.

Keep in mind that MKVToolnix can trim the required amount from the beginning of the audio instead of applying a negative delay, because it can't do that. It can't always trim the exact amount specified, in which case it'll trim a fraction more and then apply a delay to the audio to make up for the extra bit trimmed.

So I figured out it was because I was including an AAC track when I encoded the whole thing with handbrake. I was checking to see if I wanted to keep encode the PCM track to AAC, AC3 or FLAC. I don't need that AAC track any more, I'm keeping the FLAC track and the rest of the tracks are just AC3 and DTS. I do need to bring over another track from a different release with a 0ms delay which is why I started to look into this after seeing it show up with a -21ms Delay relative to video when muxing it in.

[hello_hello]

Most MKVs don't have a video delay, but I've bumped into enough of them to always check for one and adjust all the streams by the amount required to have a video delay of 0dB before re-encoding. That way there's no ambiguity for my poor little brain to cope with.

I'm not sure about Handbrake, but programs often assume there's no video delay when re-encoding a video stream, so the delay is lost. If that happens applying a -21ms audio delay is the correct thing to do when muxing it with the encoded video. If you were to extract the audio from the MKV and then remux it with the original video again, a -21ms audio delay would probably be incorrect because MKVToolNixGUI at least, retains any existing video delay by default. I assume ffmpeg does too.

I'm not sure if gMKVExtract does the same these days because I'm using an old version, but MKVCleaver can write both delays to an audio stream (actual and relative). It still hurts my brain, but the following extracts an audio stream named this way

My Video 02 eng TDly 52ms Delay -48ms.ac3

[Filename] [Track#] >[LNG3] TDly >[Delay] Delay >[aDelay]

[aDelay] is the "relative to the video" delay.
[Delay] is the actual audio stream delay.
For the MKV above the video stream had a 100ms delay and the audio stream had a 52ms delay.

gMKVExtract extracted the audio this way

My Video track2_[eng]_DELAY -48ms.ac3

[ProWo]

Use clever FFmpeg-GUI.

Load your video, click main, click multiplex, you'll see all streams and the actual delays of the audio- and substitle streams, if any.
Put in the stream delay field the value you want (in milliseconds) and click multiplex.
Done.


[Attachment 70004 - Click to enlarge]

[mrwhitethc]

Most MKVs don't have a video delay, but I've bumped into enough of them to always check for one and adjust all the streams by the amount required to have a video delay of 0dB before re-encoding. That way there's no ambiguity for my poor little brain to cope with.

I'm not sure about Handbrake, but programs often assume there's no video delay when re-encoding a video stream, so the delay is lost. If that happens applying a -21ms audio delay is the correct thing to do when muxing it with the encoded video. If you were to extract the audio from the MKV and then remux it with the original video again, a -21ms audio delay would probably be incorrect because MKVToolNixGUI at least, retains any existing video delay by default. I assume ffmpeg does too.

I'm not sure if gMKVExtract does the same these days because I'm using an old version, but MKVCleaver can write both delays to an audio stream (actual and relative). It still hurts my brain, but the following extracts an audio stream named this way

My Video 02 eng TDly 52ms Delay -48ms.ac3

[Filename] [Track#] >[LNG3] TDly >[Delay] Delay >[aDelay]

[aDelay] is the "relative to the video" delay.
[Delay] is the actual audio stream delay.
For the MKV above the video stream had a 100ms delay and the audio stream had a 52ms delay.

gMKVExtract extracted the audio this way

My Video track2_[eng]_DELAY -48ms.ac3

Yeah, the whole actual / relative delay makes my brain hurt as well.

I did find 2 workarounds, I did a quick encode of the 2nd file with the audio track I needed and had handbrake create an extra AAC track. Then I muxed the audio streams into the original file with FFMPEG and sure enough it does not show the Delay relative to video in mediainfo but if you open it in gmkvextractgui you'll see the 21ms listed for all streams.

I still would really love to know how to change the metadata if it's even possible.

The alternate approach I took is to extract all the streams with gmkvextractgui then merge all the streams back again. The only thing I don't like about this approach is the hash of the streams change. So running something like:

ffmpeg -i $mkvfile -map 0 -c copy -f streamhash -hash md5 -v warning -

on both files, the audio streams have the same hash, the video streams do not. But running something like:

 $ffmpeg -i $mkvfile -map 0:0 -f framemd5 mkvmerge.md5

once you line up the hashes they do match, the only oddity I found is that the file with the 21ms delay on the video starts at 1 instead of 0:

Original File
#stream#, dts,        pts, duration,     size, hash
0,          1,          1,        1,  5967360, b7217618431b198c7808f9cad9b62480

mkvmerge file
#stream#, dts,        pts, duration,     size, hash
0,          0,          0,        1,  5967360, b7217618431b198c7808f9cad9b62480

It also takes a lot longer running a framemd5 vs a streamhash.

[mrwhitethc]

Use clever FFmpeg-GUI.

Load your video, click main, click multiplex, you'll see all streams and the actual delays of the audio- and substitle streams, if any.
Put in the stream delay field the value you want (in milliseconds) and click multiplex.
Done.


[Attachment 70004 - Click to enlarge]

Interesting utility, so this did work. Either removing the delay from the AAC or just unchecking those tracks did leave the final file with [0 ms][0 ms] listed in gMKVExtractGUI and no Delay relative to video and the streamhashes even stay the same.

ffmpeg -i $mkvfile -map 0 -c copy -f streamhash -hash md5 -v warning -

Thanks. Though I am curious what command it's actually running in the background.