How can I mux a DVD compliant file with a 0ms audio delay?

[seanmcnally]

Current workflow is to export an non-multiplexed MPEG-2 file from Adobe Premiere Pro, then use this command with FFMpeg

ffmpeg -i movie.m2v -i movie.wav -vcodec copy -acodec ac3 -f dvd movie.mpg

Using this, then importing to AVStoDVD gives me this error:

Audio Track #1 is DVD compliant but has a delay of -37ms. Resulting DVD will be very likely out-of-sync, unless audio will be re-encoded.

How can I, using FFMpeg or something else, mux a file that doesn't have this delay? I've noticed that files ripped from commercial DVDs do not throw this error. Thanks.

PS - for my specific use case, simply letting AVStoDVD re-encode the audio is not an option.

[jagabo]

Try adding "-itsoffset 0.037" after importing the video but before importing the audio.

[seanmcnally]

Well, I tried this code:

ffmpeg -i movie.m2v -itsoffset 0.038 -i movie.wav -vcodec copy -acodec ac3 -f dvd movie3.mpg

And it worked! AVStoDVD is now reporting a 0ms delay.

...but, I still have some questions. Why did this delay exist in the first place? I just tried exporting a different clip and muxing without the -itsoffset flag, and the delay reported by AVStoDVD was -5ms. Is there a way to check this beforehand, so I don't have to do trial and error? Where does the delay itself come from?

[jagabo]

I believe it has to do with the audio having to be pre-loaded when muxing. But I don't know the exact details.

[Skiller]

https://forum.videohelp.com/threads/302180-Audio-to-video-delay-value-on-a-DVD#post2125315

In a nutshell: there won't be any delay during playback, even if there is a delay reported.
That's because the delay is taken into consideration upon playback.

[seanmcnally]

https://forum.videohelp.com/threads/302180-Audio-to-video-delay-value-on-a-DVD#post2125315

There won't be any delay during playback, even if there is a delay reported.
That's because the delay is taken into consideration upon playback.

So, then why is AVStoDVD warning me about it? Is it possible that software can't handle the delay?

[Skiller]

AVStoDVD uses DVDAuthor for muxing, so yeah I'm not surprised.

I also sometimes had issues with DVDAuthor that wouldn't occur with Muxman so I stopped using it for muxing entirely. Muxman's multiplexing is on par with commercial DVD authoring softwares and it does support audio delays.

[usually_quiet]

AVStoDVD uses Muxman now. I can't recall when the change occurred but it wasn't recent.

[Skiller]

That's great.
Maybe the description of AVStoDVD here on videohelp should be updated then because that's what I was relying on when I was researching what muxing engine it uses.


Edit: Here is an idea @seanmcnally, use standalone Muxman to multiplex the m2v and ac3 files and post the log file.

[seanmcnally]

I'm not sure that would help, but in my testing, the sync was actually different. Meaning, playback was different when I stacked the originals and AVStoDVD processed ones on a Premiere Pro timeline and played them back. So, the method I described above, using -itsoffset, is the best solution.

[Skiller]

I'm still interested in finding out what's really the issue here.
The Muxman log file of that m2v and ac3 might give some hints (using stand alone Muxman, not AVStoDVD).
You could also check if there is a delay reported if you run the new VOB through DGIndex.

[pandy]

So, then why is AVStoDVD warning me about it? Is it possible that software can't handle the delay?

As DVD is limited bandwidth, muxer need to prepare bitstream in such way that first time slots video data are transmitted and after some time first audio data are inserted (obvious as video require more bandwidth than audio) - because audio data are physically delayed when compared to video data there is added negative offset to compensate such delay, demuxer split audio and video so audio and video decoder receive own data however audio decoder is aware that is should present decoded audio data with negative offset i.e. inline when video starts...