How to Prevent MKVMerge adding a delay?

[VideoFanatic]

When I mux raw files with TS Muxer, medianinfo reports no delay in the resulting file. However muxing with MKVMerge reports a -80ms delay. How can I prevent MKVMerge adding a delay?

In the Options there's this option: "Set the delay input field from the file name". Do I untick that or not? Tried unticked and ticked and still got the delay.

I also tried this: In Format Specfic Options tab, I entered a delay of 0 for both the video and audio and I still got the -80ms delay.

[ndjamena]

https://sourceforge.net/p/mediainfo/discussion/297609/thread/9da3b411/

[VideoFanatic]

Thanks but that didn't solve my problem.

[hello_hello]

MKVMergeGUI is probably getting it right.

There's no such thing as negative delays in MKVs. If you mux audio using a negative delay, MKVMergeGUI actually removes an appropriate amount from the beginning instead (or as close as it can) which is fairly normal when muxing.

If MediaInfo is reporting a negative audio delay for an MKV it probably means the video has a positive delay. I don't why, maybe the first couple of frames aren't keyframes so MKVMergeGUI removes them, then applies a 80ms delay to the video to keep it in sync, which would seem pretty logical if the frame rate is 25fps (40ms frame durations).

If you open an MKV with gMKVExtractGUI it'll show you the delay for every track, not just the audio.

Rather than spend all day theorising, why not check if the audio sync is different for the TS and MKV versions? Rather than type out instructions again, you can find my method for doing so using MPC-HC towards the end of this post. 80ms mightn't necessarilly be enough to notice the audio is out of sync when watching a single video, but when playing two side by side it'll be obvious if they're not the same. If you think they're different, you might want to file an MKVToolNix bug report.

In the Options there's this option: "Set the delay input field from the file name". Do I untick that or not? Tried unticked and ticked and still got the delay.

When audio is extracted by some programs (DVD audio by DGIndex, or MKV audio extracted by MeGUI etc) the programs write any delay to the audio's file name. The format looks something like this:

"Extracted 5.1ch Audio Delay 80ms.ac3"

If you add that audio to MKVMergeGUI for muxing, it'll automatically place the appropriate delay value in the audio delay section. If there's no delay specified in the file name, ticking or unticking the option won't make a difference. It's best to let MKVMergeGUI apply any delay unless you're sure you know better.

[VideoFanatic]

There's no delay in the file names. I don't think any of that will make a difference unless I can prevent MKV Merge from adding a delay. The MKVMerge resulting file has an -80ms delay. It plays in sync. But the problem is when I go to re-encode that MKV with MeGUI. The resulting file then has a noticeable 1 second delay.

I guess I'll just have to use TSMuxer instead of MKV Merge. I wanted MKV files because TS file sizes can be several hundred MBs higher than MKV files which saves hard drive space. I can't mux to MP4 as VideoRedo crashes whenever I try to save an MP4 file so I don't think that format would be any good for me. Only thing left is TS.

[ndjamena]

THERE IS NO DELAY AT ALL. The MPEG2 codec provides for OUT OF ORDER decoding, meaning a frame can be decoded before the previous frame in the display order is decoded. The display order in the video stream is BBI, meaning you decode the I-Frame first, then you decode each of the b-frames, but you display the b-frames first. MKVs store frames in DECODING ORDER rather than DISPLAY ORDER so in the file they're ordered IBB. But the time-code of the I-frame is 00:00:00.080 and since MediaInfo only looks at the time-code of the first frame to determine stream "delay" it's incorrectly assuming there is an 80ms delay in the video stream. The audio stream delay is called "delay relative to video" and since MediaInfo thinks the video stream begins later than it actually does that delay information is completely wrong.

[VideoFanatic]

My files are h264 not MPEG2. Does what you said apply to h264 as well?

[ndjamena]

I have no idea, possibly not. Anyway, if there was already a delay in the m2ts then MKVMerge would have copied that delay over to the MKV. MKVMerges delay parameter alters relative delay rather than the absolute (oddly me asking for setting absolute delays is what got us track statistic tags in MKVs). So if you want to remove a delay, you need to set the delay parameter relative to what it already is.

Try this first MKVInfo -t -r "%~dpn1.txt" "%~f1" and check the timecode of the first video frame. If it's 80ms then leave it alone.

If it's 0ms then set the MKVMerge delay on the audio to 80ms and it should remove the -80ms delay. But it will make it all out of sync. AC3 has 32 ms frames, DTS is about 10ms you may have to remove some frames from the audio to get everything to sync properly. I don't think MKVMerge will do that for you.

[hello_hello]

There's no delay in the file names. I don't think any of that will make a difference unless I can prevent MKV Merge from adding a delay. The MKVMerge resulting file has an -80ms delay. It plays in sync. But the problem is when I go to re-encode that MKV with MeGUI. The resulting file then has a noticeable 1 second delay.

Ahhh..... more info........ "the resulting file"...... that sounds like it might be an MP4Box bug.
It's the only reason I know of for a small delay causing that sort of problem, but that doesn't mean it can't be something else.
There was a discussion in this thread which resulted in MP4Box being fixed (I don't think MeGUI has been updated yet) and a fix for MKVMergeGUI's handling of MP4 delays was mentioned.
http://forum.doom9.org/showthread.php?t=105920&page=386

I guess I'll just have to use TSMuxer instead of MKV Merge. I wanted MKV files because TS file sizes can be several hundred MBs higher than MKV files which saves hard drive space. I can't mux to MP4 as VideoRedo crashes whenever I try to save an MP4 file so I don't think that format would be any good for me. Only thing left is TS.

VideoRedo??? Where does muxing raw files come into it?
It seems like there's a delay involved which isn't being handled correctly at some stage, but not knowing your actual workflow it's hard to know where. You could always open an MKV with a negative audio delay, manually apply an appropriate delay to cancel it out (+80ms), remux as a new MKV, then encode that one...... but you might have to apply the opposite delay to the final output file (-80ms) to fix the audio sync again. Of it's consistant (always -80ms) add a +80ms delay when muxing in the first place so you at least have a 0ms audio delay MKV to work with.

[hello_hello]

Have you tried opening an MKV with gMKVExtractGUI and checking for actual delays for each stream rather than relying on MediaInfo?

There's two delay values. The first is the actual delay. The second is the "effective" delay. The author explains the effective delays this way:

The "Delay" field is the actual track delay as defined in the mkv header.
The "EffectiveDelay" is the actual delay that players use while playing the file. It is actually different only for the audio tracks, in cases that there is a delay defined for the video track. This is the value that is used for generating the output file name when extracting the track.


[Attachment 27750 - Click to enlarge]

If you had an MKV with a 50ms video delay and a 10 ms audio delay, the effective video delay is shown as 50ms and the effective video delay is -40ms. If you extract the audio and video streams, the audio will have a -40ms delay written to the file name.
MediaInfo should report the audio delay as -40ms.

[VideoFanatic]

I dragged the video into that program (is that all I have to do to use it?) and it says the video has 80ms delay and the audio has -80ms delay. But how does that info help me prevent MKVMerge from adding a delay in the first place?

I never said anything about using an MP4 in MKVMerge so I don't know what you're talking about. I said I could try muxing to MP4 (I assume MKVMerge doesn't make MP4's so it would be another program that would mux to mp4 and hopefully it won't add a delay) but if I wanted to edit the file in future then MP4 is of no use to me because saving to MP4 (with AC3) in VideoRedo causes VideoRedo to crash before it finishes saving to MP4.

Sources I'm working with are Elgato Game Capture HD MP4 files with AAC. They have no delay to begin with. I edit in VideoRedo (MP4 with AAC don't crash VideoRedo) and the file then has a -80ms delay reported by MediaInfo. It's somewhat random if you get a delay or not. I then demux, convert AAC to AC3 and remux with MKV Merge. Still have the delay. I then re-encode with MeGUI and the audio is noticeably out of sync by 1 second. If I demuxed and MKV with the delay and remuxed with TSMuxer then MediaINfo reports no delay and when re-encoded using MeGUI I don't get any delay.

I use a batch script to do the demuxing and conversion in MKVMerge so I don't really want to have to mess about setting different delays to cancel the delay out (it would also be easy to enter a wrong delay by mistake). I just want to run the script which will do the conversion automatically without adding a delay. It seems that's not possible with MKVMerge so it looks like I'm going to have to mux to TS with TSMuxer instead which is a bummer as those files are several hundred MBs larger than MKVs.

[ndjamena]

Are you sure it's one second? I know a 60ms out of sync audio would be completely noticeable to most people.

[VideoFanatic]

See for yourself at 2 mins 20 secs: https://www.dropbox.com/s/1elfl33jla1gca3/Raw%202014%20Sep%2022%20clip%20after%20MeGUI.m2ts?dl=0

[ndjamena]

Wait are you saying Video Redo adds the delay?

Like I said, I asked Mosu about letting MKVMerge set absolute delay and he said "No". Apparently it's far too difficult because of how each of the containers creates their delays. (Apparently AVI fills the empty space with crap). We did get track tags out of it though, which no one will appreciate until certain key programs are updated to make proper use of them, and no one will appreciate then anyway, since they'll just take it for granted.

[VideoFanatic]

Seems like it. The MP4 source had no delay. If I save that to TS or MKV with VideoRedo I get a delay. If I save to MP4 instead it mentions no delay but says "Duration_LastFrame: -21ms". If I then save that MP4 to MKV I get the -80ms delay again!

Is Mosu the author of MKVMerge? I did create a ticket about it but his reply was a bit cryptic but I assume it was to say that you can't set an absolute delay.

[ndjamena]

Mosu is saying pretty much the same things I am. Have you tried MKVInfo on the files yet?

[VideoFanatic]

What's that?

[ndjamena]

If you look in your start menu there's a shortcut to MKVInfo GUI. Open it, click Options | Show All Elements, then File | Open and select your file. Go down and expand the first "Cluster" you find and find the first few time-codes in either the "Blocks" or "Simple Blocks" elements. Track 1 should be the video.

[VideoFanatic]

I don't have MKV Toolnix installed. I use a portable version. I can't see MKInfo GUI in the MKVToolnix folder, I only see the exe file.

[ndjamena]

mkvinfo -g

The command line and GUI versions run from the same .exe.

[VideoFanatic]

No idea what you're talking about. What file to I open to open the GUI?

[hello_hello]

I dragged the video into that program (is that all I have to do to use it?) and it says the video has 80ms delay and the audio has -80ms delay.

The delay or the effective delay? My crystal ball seems a little foggy. I'd guess the video track has an 80ms delay. The audio doesn't so the audio delay is effectively -80ms.

But how does that info help me prevent MKVMerge from adding a delay in the first place?

The same way you not explaining your workflow properly in the first place doesn't.

I never said anything about using an MP4 in MKVMerge so I don't know what you're talking about.

I took a guess at MP4 being your MeGUI output given MP4Box had a similar audio delay problem and the closest you came to describing MeGUI's output was "the resulting file" and I had no idea what that meant.

Sources I'm working with are Elgato Game Capture HD MP4 files with AAC. They have no delay to begin with. I edit in VideoRedo (MP4 with AAC don't crash VideoRedo) and the file then has a -80ms delay reported by MediaInfo. It's somewhat random if you get a delay or not. I then demux, convert AAC to AC3 and remux with MKV Merge. Still have the delay. I then re-encode with MeGUI and the audio is noticeably out of sync by 1 second. If I demuxed and MKV with the delay and remuxed with TSMuxer then MediaINfo reports no delay and when re-encoded using MeGUI I don't get any delay.

And the MeGUI output..... will still don't know what container it is. Back to the MP4Box problem with audio delays being a possible cause of the audio going out of sync by a second....
Does MeGUI extract the audio which you just remuxed, and if so, why do you bother remuxing it anyway, but if it does, does it write a delay to the audio file name?

Seems like it. The MP4 source had no delay. If I save that to TS or MKV with VideoRedo I get a delay. If I save to MP4 instead it mentions no delay but says "Duration_LastFrame: -21ms". If I then save that MP4 to MKV I get the -80ms delay again!

The MP4 source has no delay according to what? MediaInfo? I've rarely seen it display MP4 delays correctly, if at all. If you remux the MP4 as an MKV and MediaInfo reports a delay it's probably because MKVMergeGUI got it right. And given you said saving the output directly to TS or MKV results in the same delay, it's probably reasonable to ignore what MediaInfo reports regarding the MP4.

When I mux raw files with TS Muxer, medianinfo reports no delay in the resulting file. However muxing with MKVMerge reports a -80ms delay. How can I prevent MKVMerge adding a delay?

If I save that to TS or MKV with VideoRedo I get a delay.

My motivation for trying to extract the correct information is a little on the low side today. I think I'll leave you to it. Good luck.

[VideoFanatic]

But why does demuxing an MKV with a delay then remuxing to TS with TS Muxer NOT give a delay but remuxing to MKV with MKVMerge does add the delay?

I thought Raw files don't contain delay info so where's MKVMerge getting the -80ms delay from that it's adding to the MKV?

I could encode to any container with MeGUI and I always get the same delay.

[ndjamena]

No idea what you're talking about. What file to I open to open the GUI?

mkvinfo.exe -g

Does that make more sense? I generally skip the .exe part because it's unnecessary.

[VideoFanatic]

Mkvinfo.exe just opens then closes a command prompt. If you're referring to the command line, I don't know how to use the command line. None of this matters as there's no way to prevent MKVMerge adding a delay. Thank you to everyone who posted though.

[ndjamena]

sigh

mkvinfo -g

but really, at this point I'd rather you didn't bother.

[hello_hello]

Mkvinfo.exe just opens then closes a command prompt. If you're referring to the command line, I don't know how to use the command line. None of this matters as there's no way to prevent MKVMerge adding a delay. Thank you to everyone who posted though.

You just need to create a shortcut and edit it.

But why does demuxing an MKV with a delay then remuxing to TS with TS Muxer NOT give a delay but remuxing to MKV with MKVMerge does add the delay?

I thought Raw files don't contain delay info so where's MKVMerge getting the -80ms delay from that it's adding to the MKV?

There's no such thing as negative delays in MKVs....
If MediaInfo is reporting a negative audio delay for an MKV it probably means the video has a positive delay.

Assuming that's the reason, I don't know why it's deciding it needs a positive video delay. Or how the video delay is being retained, but that seems to be what's happening. Maybe the video stream contains a couple of "null frames" at the beginning and that's how MKVMergeGUI handles them..... I'm just guessing.

What sort of editing are you doing? Just simple cutting etc? I ask, because that's easy enough to do with MeGUI in which case you can bypass VideoRedo.
Open a capture for conversion with MeGUI and create a script for encoding. Open the script with the AVS Cutter under the Tools menu. Add your "cuts" to the script using a preview. You can add multiple start and end frames to a script. Save a "cuts file" for loading into the audio section so the audio will be re-encoded to match. Or use the Audio Cutter under the Tools menu if you don't want to re-encode it.

[ndjamena]

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L3.1
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 10 frames
Codec ID                                 : V_MPEG4/ISO/AVC
Width                                    : 768 pixels
Height                                   : 576 pixels
Display aspect ratio                     : 4:3
Frame rate mode                          : Constant
Frame rate                               : 25.000 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Writing library                          : x264 core 142 r2409 d6b4e63
Encoding settings                        : cabac=1 / ref=10 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=250 / rc=crf / mbtree=1 / crf=22.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=2:1.10

| + SimpleBlock (key, track number 1, 1 frame(s), timecode 0.000s = 00:00:00.000)
|  + Frame with size 1346
| + SimpleBlock (track number 1, 1 frame(s), timecode 0.360s = 00:00:00.360)
|  + Frame with size 27
| + SimpleBlock (discardable, track number 1, 1 frame(s), timecode 0.200s = 00:00:00.200)
|  + Frame with size 24
| + SimpleBlock (discardable, track number 1, 1 frame(s), timecode 0.040s = 00:00:00.040)
|  + Frame with size 24
| + SimpleBlock (track number 1, 1 frame(s), timecode 0.080s = 00:00:00.080)
|  + Frame with size 24
| + SimpleBlock (track number 1, 1 frame(s), timecode 0.120s = 00:00:00.120)
|  + Frame with size 24
| + SimpleBlock (track number 1, 1 frame(s), timecode 0.160s = 00:00:00.160)
|  + Frame with size 24
| + SimpleBlock (track number 1, 1 frame(s), timecode 0.240s = 00:00:00.240)
|  + Frame with size 23
| + SimpleBlock (track number 1, 1 frame(s), timecode 0.280s = 00:00:00.280)
|  + Frame with size 23
| + SimpleBlock (track number 1, 1 frame(s), timecode 0.320s = 00:00:00.320)
|  + Frame with size 23

So yes, h.264 has out of order decoding as well, it's comes from necessity with the idea of the B-frame (bi-directional referencing). I haven't found one that starts with a B-frame as yet, but I don't see anything stopping it from happening.