MKVmerge video delay not working

[CyberTootie]

Hello, trying to finish a music video remux with MKVmerge that I've "spent way too much time on" and I'm not getting expected behavior with the delay setting for the video stream. It's not taking it into account at all.

Previously, when delaying the video stream, the videos would display the first frame of the video upon starting and then begin playing upon reaching the delay point.

Putting a negative value in the audio stream is working and getting the audio in sync, but then I lose all the audio at the beginning.

[poisondeathray]

Did you try another mkvmerge version?

Maybe another approach would be to append blank video , or video of 1 frame, or something similar to the beginning of the video

[CyberTootie]

I have so many calculators open, and so many markers in Audition, I just had to step away... now I'm not exactly sure where I am, if you know what I mean, except that I'm in perfect position if I could get expected behavior.

[poisondeathray]

IMO, zero delay is best (Perfectly aligned audio and video), because not all players act as expected with either +/- audio or video delays (video delays can be especially problematic, it might work on some players, some software but not others)

If you said a negative audio delay worked, then use that value to figure out how long blank video you need to append (you need to know what framerate, duration in ms of the negative audio delay to figure out the # frames required)

Another way you could do this is with timecodes and VFR - again that can be problematic for some situations and hardware players - so the "best" solution IMO is still zero delay, CFR.

If you need to take a break, go for nap and revisit this when you're more fresh

[manono]

I didn't understand all that, but for many kinds of audio DelayCut can remove the delay entirely. All kinds of WAV and AC3 and MP2 audio. Then you can mux without having to worry about a delay.

Putting a negative value in the audio stream is working and getting the audio in sync, but then I lose all the audio at the beginning.

That's what a negative delay does. If there's necessary audio getting removed then pdr's solution is the right one - add video frames.

[hello_hello]

The problem with using DelayCut, or a negative audio delay, is that sometimes you don't want to remove any of the audio from the beginning. 99.999999% of the time it doesn't matter, but sometimes it does.

CyberTootie,
It seems like it might be a player issue. I just tried setting a video delay using MKVToolnix 7.6.0 and 7.8.0 and each time it worked fine. You can check if the delay is being set correctly using MediaInfo. You can't have negative delays for tracks in MKVs, but MediaInfo displays a negative audio delay instead of a positive video delay, so you can check for that.

A one second positive video delay looks like this to MediaInfo, but don't forget if the audio also has a delay they can effectively cancel each other out.

[CyberTootie]

The delay is the result of a desire to intentionally modify the beginning of a video. When direct-stream remuxing you are limited to cutting in with I-frames. In this case, a black frame is available as an I-frame, which could be repeated during the onset as desired, but then I would have a lot of math to re-do in order to maintain sync because I'd have to factor in a modified frame rate, and as I've previously stated I'm not sure what is what in that regard.

Here's a screencap of what I'm doing and the info MKVinfo shows me that the video stream is not being delayed as intended.
https://forum.videohelp.com/images/imgfiles/eL1j3To.png

I've applied this concept/procedure to numerous other videos without problem before.

[manono]

I've applied this concept/procedure to numerous other videos without problem before.

To videos with a 24.928 framerate? Did you happen to begin with a variable framerate video?

[CyberTootie]

That specific framerate? Probably not, but yes for other unusual framerates brought about by syncing various music videos to alternative audio sources. Now I'm basing the fact that I have solely on the number of videos I've worked on overall... I've remuxed hundreds, but I can't recall a specific instance. But what does the framerate have to do with the delay, anyways? Is there some undocumented limitation where if you use X, Y is ignored?

To the best of my knowledge, it was not a variable framerate. But in my processing chain any variable timing discrepancies are discarded. Doing this became a sync issue with another newer music video... in that case I had to take steps to leave the timing information in-tact, and in doing so I was unable to do certain things I normally would have.

I was able to successfully finalize a "zero delayed" version of the project which initially triggered this post, but my curiousness of the source of the delay issue still stands.

[hello_hello]

It seems to be a bug in MKVMergeGUI. Unless it intentionally works this way, but I doubt it as the command line includes the specified video delay. It won't change the frame rate and set the video delay at the same time. At least not when it's a positive video delay. It seems to work okay when the video delay is negative. I've tested versions 7.6.0 and 7.8.0 so it may be a bug that's been around for a while. The only way to do it at the moment seems to be to mux the video/audio twice. Once to change the frame rate and then by opening the MKV with the new frame rate and setting the video delay.

As I'm already logged into doom9 and I've stuck my nose in there already, I'll report the problem in the MKVToolNix thread for you. If nothing else, it might get you a quicker reply.

[CyberTootie]

Ah, well thank you. Now that you mention it, I think I have run into this problem before but just figured I was doing something wrong. And this would've been almost a year ago. Well I'm glad to have been part of a bugfix if that's what the issue is.

[hello_hello]

I thought I'd post the findings here CyberTootie, although you've probably read the posts at doom9. For others reading the thread here......

When you apply a video delay it changes the duration of the first frame. This effectively gives you a variable frame rate output, even though it's possibly only the first frame that has a different duration to the rest.
When you specify a frame rate each frame is given the same duration, so the frame rate becomes constant. Effectively what's happening is you're specifying a video delay that makes the frame rate variable, then specifying a frame rate that makes it constant again. Well..... it's MKVMerge's fault for doing it in that order.

Mosu said he'll fix MKVMerge so it's clever enough to change the frame rate first and apply the video delay second. That should solve the problem.

[CyberTootie]

It's coming back to me. For what it's worth, now I remember why this wasn't an issue before a year ago. It was because I was changing the video framerate during the editing phase while using Avidemux. Later versions of Avidemux required the use of a filter to change the framerate, thus disallowing for direct stream copies with different framerates, thus I had to start using the framerate setting of mkvmerge for the same functionality.