Added "Delay Relative to Video" on outputs [HELP]

[SaizenXVII]

Ok, so everytime i encode videos, the output would always have a delay of around 10-12ms...
it is stated in the MeGUI Log Tab as well as in Mediainfo Text Mode

My previous encodes (which was last 2012) never had an added delay when i checked them in mediainfo.

I found this out when i decided to re-encode the same videos as they had low bitrates, then i noticed this "delay" which wasn't present
in my previous encodes.

Btw, i use "AutoEncode" feature for both my past and present encodes instead of manually merging the files with mmg....




Here's my avisynth script if it helps

[nic2k4]

Are you trimming anything before you encode? I usually get 16 ms whenever I trim a movie before I convert it, even when I check the delay beforehand with other programs and they say 0 ms. The thing is I've never been able to figure out which is right, I can't tell the difference in the output. The delay would have to be over 60 ms for it to become apparent.

[SaizenXVII]

Are you trimming anything before you encode?

nope, i didn't trim anything at all, both for my past and present encodes.



*added avisynth script screenshot

[Selur]

looks like the normal aac encoder delay which changes depending on the encoder, the audio type (he-aac, he-aacv2, aac), the sampling rate and the container, this delay might need to be compensated during muxing.

here's how Hybrid takes it:

if (heaac) { //HE-AAC
  if (nero) {
    encoderDelay = int(2336 * 2000 / audioOutputSampleRate.toDouble() + 0.5);
  } else if (qaac) {
    encoderDelay = int(2585 * 2000 / audioOutputSampleRate.toDouble() + 0.5);
    mkvDelayFix = encoderDelay;
    mkvDelayFix -= int(2112 * 1000 / audioOutputSampleRate.toDouble() + 0.5);
  } else if (fhg) {
    encoderDelay = int(794 * 2000 / audioOutputSampleRate.toDouble() + 0.5);
  }
} else if (heaacv2) { //HE-AAC V2
  if (nero) {
    encoderDelay = int(2808 * 2000 / audioOutputSampleRate.toDouble() + 0.5);
  } else if (qaac) {
    encoderDelay = int(2585 * 2000 / audioOutputSampleRate.toDouble() + 0.5);
    mkvDelayFix = encoderDelay;
    mkvDelayFix -= int(2112 * 1000 / audioOutputSampleRate.toDouble() + 0.5);
  } else if (fhg) {
    encoderDelay = int(794 * 2000 / audioOutputSampleRate.toDouble() + 0.5);
  } else { //faac/fdk/...
    encoderDelay = int(2048 * 1000 / audioOutputSampleRate.toDouble() + 0.5);
  }
} else {  //AAC LC
  if (nero) {
    encoderDelay = int(2624 * 1000 / audioOutputSampleRate.toDouble() + 0.5);
  } else if (qaac) {
    encoderDelay = int(2112 * 1000 / audioOutputSampleRate.toDouble() + 0.5);
  } else if (fhg) {
    encoderDelay = int(1600 * 1000 / audioOutputSampleRate.toDouble() + 0.5);
  } else {  //faac/fdk/..
    encoderDelay = int(2048 * 1000 / audioOutputSampleRate.toDouble() + 0.5);
  }
}
delay = QString::number(inputDelay - encoderDelay);

there should be something similar in MeGUIs source code.

Cu Selur

Ps.: there should be a few threads about it here and over at doom9s.

[hello_hello]

Lossy formats (ie AAC) use a type of frame (the audio is divided into segments). They also add "padding" to the beginning (and end) of the audio stream. The amount of "padding" should be written to the output container (MP4 or M4A). That's how gapless playback works for audio encoded using a lossy format. The player reads the info, skips the "padding" and only plays the original audio.

If the info is written to the output container, MKVMerge (which MeGUI uses for muxing MKVs) takes the "padding" into account. As an example.... and I'm just making up numbers.....

There's 60ms worth of "padding". The audio frames are 25ms. Ideally you'd compensate for the padding by using a delay of -60ms when muxing the audio, but MKV doesn't allow for negative audio delays, so MKVMerge removes the first three frames (75ms). To compensate for the 15ms difference, an audio delay of 15ms is used when muxing.
The same type of thing happens if you manually apply a negative audio delay when muxing. An appropriate amount will be trimmed from the beginning and you'll invariably end up with an MKV which has a small positive audio delay.

When I re-encode audio using Nero AAC, if I open the output MP4/M4A with MediaInfo, there's a single chapter within. It's usually at around the 53ms mark. I think it also represents the padding value. After MKVMergeGUI has done it's thing, I usually have an output MKV with an audio delay of 9ms.

If I'm correct regarding what's happening, it means your current encodes have slightly more accurate audio/video sync than your old ones. If memory serves me correctly, MKVMerge only started compensating for padding when muxing within the last year or two. And to the best of my knowledge it only does so when muxing AAC audio. All lossy formats use padding, and different encoders add different amounts (NeroAAC and QAAC would probably be slightly different) but for other formats such as MP3 or AC3 I don't think the padding is taken into account. Maybe there's a reason for that. MP3 doesn't officially support gapless playback (although the LAME encoder writes the info and lots of players can use it). I don't know whether AC3 supports it.

[jagabo]

I don't know if this has anything to do with your issues, but high compression audio codecs typically add a short bit of silence when encoding:



The top waveform is the original. The middle is ac3, the bottom aac.

[hello_hello]

looks like the normal aac encoder delay which changes depending on the encoder, the audio type (he-aac, he-aacv2, aac), the sampling rate and the container, this delay might need to be compensated during muxing.....

Ps.: there should be a few threads about it here and over at doom9s.

I'm pretty sure I even posted in one at the time, but I can't find it. I did find this in the MKVMergeGUI changelog though.

2012-02-06 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: new feature: mkvmerge will parse and apply the audio
encoder delay in MP4 files that contain said information in the
format that iTunes writes it. Fix for bug 715.

I can't quite get my head around what Hybrid does. Is it pretty much doing what mkvmerge does?

[SaizenXVII]

thank you everyone for your replies

If I'm correct regarding what's happening, it means your current encodes have slightly more accurate audio/video sync than your old ones. If memory serves me correctly, MKVMerge only started compensating for padding when muxing within the last year or two. And to the best of my knowledge it only does so when muxing AAC audio. All lossy formats use padding, and different encoders add different amounts (NeroAAC and QAAC would probably be slightly different) but for other formats such as MP3 or AC3 I don't think the padding is taken into account. Maybe there's a reason for that. MP3 doesn't officially support gapless playback (although the LAME encoder writes the info and lots of players can use it). I don't know whether AC3 supports it.

so is it a good thing and leave it as it is?

[jagabo]

As was noted earlier, you generally can't tell a difference with an audio delay or advance under 50ms.

[hello_hello]

so is it a good thing and leave it as it is?

Yes.

[SaizenXVII]

thanks....
i have another thing to ask though

what if the original source had an added delay to it (-83ms)(checked it through mediainfo under "delay relative to video")
will getting a 11ms delay in the output still okay? also, i was wondering why the delay in outputs are all fixed with 11ms

-not really an expert sorry

[hello_hello]

If they're all fixed at 11ms it'd seem a little odd. Maybe it's just co-incidence.

If the audio has no delay and the muxing program is simply compensating for padding, and you're using the same encoder each time, I'd imagine the resulting delay after remuxing would always be the same. For me it's always 9ms (NeroAAC) and for you it seems it's always 11ms (QAAC).

When it comes to also applying an additional negative delay it's possible to still end up with the same 11ms delay after muxing, but probably a lot less likely. I think the muxing program should effectively remove the appropriate amount from the beginning of the audio stream to compensate for the padding, plus an appropriate amount to compensate for the specified negative delay, then apply a positive delay if need be to make up for any difference. It could end up being 11ms again but it's more likely to be something else.

If you took the audio in question and muxed it into an MKV while applying a -83ms delay and it resulted in a 11ms delay after muxing, then muxed the same audio again while applying a slightly different delay the resulting audio delay should change. If it doesn't there's probably something odd happening.
Using your example (-83ms delay resulting in 11ms delay after muxing) if you applied a -94ms delay instead you might end up with an MKV with no audio delay at all. There's no guarantee though, because the beginning of the audio can only be removed in certain size "segments". If changing the delay to -94ms required an additional segment be removed from the beginning of the audio you could end up with a whole new positive delay value in order to make up the difference. Hopefully that makes sense.....

Edit: The original -83ms delay you referred to..... MeGUI should be applying it automatically. If you don't think it is when using AutoEncode post back and I'll have a play with it as I use MeGUI quite a bit myself. Although thinking about it, how are you re-encoding the audio? Did you extract it and re-encode the extracted audio or is it being re-encoded via a script? If it's the latter MeGUI might skip the first 83ms when re-encoding, so the encoded version would no longer require the -83ms delay. Then it'd be just the usual 11ms after the encoder padding is removed. I'd need to check that theory. I generally extract the audio and re-encode it use foobar2000, let MeGUI do the video, them mux the two myself using MKVMergeGUI, so I'm not always 100% sure what MeGUI does, or what it should do.

MeGUI can only extract the audio from MKVs for re-encoding. For everything else, it re-encodes it via a script. If you'd prefer to keep the original audio and not re-encode it at all (which I often do) you can remux any AVI's/MP4s etc as MKVs first using MKVMergeGUI, then open the MKV for re-encoding instead. AutoEncode will let you add the original audio instead of (or as well as) an encoded version. Just in case you weren't aware of all that....

[SaizenXVII]

Although thinking about it, how are you re-encoding the audio? Did you extract it and re-encode the extracted audio or is it being re-encoded via a script?

what i do is just make an avisynth script and do this:

FFMpegSource2("video", atrack = -1).AssumeFPS(24000,1001)
DirectShowSource("video", audio=true, convertfps=true).AssumeFPS(24000,1001)

that way the audio would be loaded automatically, then use autoencode to set the bitrates.

actually i do ALL (video and audio) encoding processes in MeGUI... then click autoencode to set the bitrate

btw, my encoder setting under the audio tab in MeGUI is "Nero AAC: NDAAC-HEPS-32Kbps

[Selur]

@hello_hello:

I can't quite get my head around what Hybrid does. Is it pretty much doing what mkvmerge does?

the posted part is simply about calculating the delay that occurs.
Since mkvmerge does sometimes only fix a part of the delay some rest still needs fixing (mkvDelayFix).
Mainly posted the code to demonstrate, that the delay depends o different factors.

@SaizenXVII: Independent from what you configure in MeGUI.
Is the output async ? If it isn't stay with your settings and be happy that MeGUI properly handles the delay.
If it is async you might want to fill a bug report so that the MeGui developer(s) is aware of the problem.

Like mentioned, the simply occurrence of another delay, when encoding to aac is normal and no reason for concern since the NeroAacEnc creates a delay due to the nature of aac and the way how NeroAacEnc handles it.

[SaizenXVII]

okay, thanks

[hello_hello]

what i do is just make an avisynth script and do this:

FFMpegSource2("video", atrack = -1).AssumeFPS(24000,1001)
DirectShowSource("video", audio=true, convertfps=true).AssumeFPS(24000,1001)

that way the audio would be loaded automatically, then use autoencode to set the bitrates.

When you decode audio via DirectShow it's decoded as it would be on playback, so I'm pretty sure any negative delay used for the audio in the original file wouldn't need to be taken into consideration when muxing. That way the delay after muxing would just be the delay required to remove the encoder padding. I can't say I've thought about it much before and I'd need to find a file with a substantial negative audio delay to check, but I'm pretty sure that's what'd happen. When re-encoding the audio the first (using your example) 83ms of audio wouldn't be encoded so you'd not need to apply the original -83ms audio delay.

That'd be my guess but even when re-encoding audio via DirectShow I've never done it the way you're doing it. At least not using MeGUI.

[SaizenXVII]

what i do is just make an avisynth script and do this:

FFMpegSource2("video", atrack = -1).AssumeFPS(24000,1001)
DirectShowSource("video", audio=true, convertfps=true).AssumeFPS(24000,1001)

that way the audio would be loaded automatically, then use autoencode to set the bitrates.

When you decode audio via DirectShow it's decoded as it would be on playback, so I'm pretty sure any negative delay used for the audio in the original file wouldn't need to be taken into consideration when muxing. That way the delay after muxing would just be the delay required to remove the encoder padding. I can't say I've thought about it much before and I'd need to find a file with a substantial negative audio delay to check, but I'm pretty sure that's what'd happen. When re-encoding the audio the first (using your example) 83ms of audio wouldn't be encoded so you'd not need to apply the original -83ms audio delay.

That'd be my guess but even when re-encoding audio via DirectShow I've never done it the way you're doing it. At least not using MeGUI.

btw, there are times when the output has less duration than the source... like 6seconds was removed from the clip, the audio is a bit out of sync but not really noticeable unless when you look closer to their mouth and the audio, its a bit off... so any idea why this is happening?

[Selur]

so any idea why this is happening?

Sounds like either:
a. your input is broken one way or the other
b. your input is vfr

[hello_hello]

It's not unusual for the audio and video to be different lengths, ie the audio finishes a little earlier than the video. If the sync is out by the same amount all the way through then it's probably easiest just to remux it with the correct delay. I've had that happen on the odd occasion without being able to work out why so rather than stress about it I just fix it.
There's probably no direct relationship to the audio being slightly out of sync and having a different duration to the video. The durations can be different when the audio is in sync.

If the audio sync changes as the video progresses it might be due the the video being variable frame rate. I've had video that's constant frame rate but it has the odd "missing" frame, or the odd frame with twice the usual duration (depending how you look at it) effectively making it variable. You can convert it to a constant frame rate. In fact if you open an MKV with MeGUI and let it index it, these days MeGUI automatically adds frame rate conversion to the script it creates when using ffms2 for indexing. It does the same for DirectShowSource.

I (and MeGUI) usually use FFVideoSource for the video, but I'm pretty sure the same applies to FFMpegSource2. For 23.976fps video, you could add something like this:

FFmpegSource2("E:\video.mkv", fpsnum=24000, fpsden=1001)

That'll force FFmpegSource2 to output a constant 23.976fps even if the input frame rate varies. It does so by duplicating/dropping frames where necessary. It mightn't be the best way to convert truly VFR video to a constant frame rate, but if the issue is simply "missing" frames it works well. You can tell if the video isn't purely constant frame rate by opening a script with MeGUI and making note of the frame count in the preview window. Add the frame rate conversion stuff to the script and open it again. If the frame count changes then the frame rate of the original video is very likely variable. If it doesn't it's most likely constant.

https://ffmpegsource.googlecode.com/svn/trunk/doc/ffms2-avisynth.html
int fpsnum = -1, int fpsden = 1
Controls the framerate of the output; used for VFR to CFR conversions. If fpsnum is less than or equal to zero (the default), the output will contain the same frames that the input did, and the frame rate reported to Avisynth will be set based on the input clip's average frame duration. If fpsnum is greater than zero, FFVideoSource will force a constant frame rate, expressed as a rational number where fpsnum is the numerator and fpsden is the denominator. This may naturally cause FFVideoSource to drop or duplicate frames to achieve the desired frame rate, and the output is not guaranteed to have the same number of frames that the input did.

DirectShow does it differently. I'm not sure there's any point in using "convertfps=true" unless you specify a frame rate. For DirectShow it's done this way:

DirectShowSource("E:\video.mkv", fps=23.976, convertfps=true)

Rather than just drop and duplicated frames, I think DirectShow will also blend frames to output a constant frame rate if need be. The same thing applies to checking the frame count with and without "convertfps=true" included using MeGUI's preview. If the frame count changes the source is very, very likely to be variable.

For "AssumeFPS(24000,1001)"......

If the video has a variable frame rate and you use it with FFMpegSource2, then FFMpegSource2 will output the average frame rate as a constant frame rate and "AssumeFPS(24000,1001)" will speed it up or slow it down, so the frame count will be the same as the original but the duration will be wrong. If you use fpsnum=24000 and fpsden=1001 with FFMpegSource2 then "AssumeFPS(24000,1001)" is probably redundant.

DirectShowSource would also output the average frame rate for VFR video (I'm pretty sure) without "convertfps" included. However DirectShowSource uses 23.976 as the frame rate and there's a very slight difference between 23.976 and 24000/1001. The difference is so small it's pretty much non-existent but following DirectShowSource's 23.976fps with "AssumeFPS(24000,1001)" probably can't hurt.

The other common frame rate numerator/denominator values are.....
30000/1001 for 29.970fps and 25/1 for 25fps

There's another way to handle VFR rate video. Remux it as an MKV and extract the video timecodes with a program such as MKVCleaver. Re-encode the video as-is (no frame rate conversion). That'll output a video with the same number of frames but the audio sync will probably vary. Open the encoded video with MKVMergeGUI, with the video stream selected add the extracted timecodes, remux as a new MKV and it'll have the same variable frame rate as the original. Personally though, if a video is VFR I prefer to convert it to CFR when encoding..... one way or another.....

[ConverterCrazy]

Urgent
-------

I have a video.mkv with 01:40:13 duration. It stops at 71% after playing for 01:10:27.
I have tried Metiorite, MMG & MKclean to repair the video. but failed.

Is it possible to repair the video?

Thanks.