Why the offset?

[Ranguvar]

Just wondering why DGIndex so whole-heartedly enjoys applying an offset to the audio when demuxing it... what purpose does that serve?

[Guest]

The design is inherited from DVD2AVI. Revising that is highly non-trivial. The source code is available if you wish to implement it and contribute your work to the community.

[Ranguvar]

So it serves no purpose whatsoever? Just checking.

My high school only offers JAVA, and at an annoyingly slow+easy pace. But once I can do more than the simple C++ I do now, helping with open source projects is something I guarantee you I'll be doing.

[Guest]

So it serves no purpose whatsoever? The offset is a consequence of the simple demuxing design. At some point in the stream you start outputting the video and audio into separate streams and lose the timestamps. But the audio and video are not necessarily aligned in the source stream (that's why you need timestamps!). Printing the offset that is seen when starting the demuxing allows for correcting it in the following application. So there is a purpose for detecting and displaying the offset.

There are more complicated demuxing approaches that could be tried, and I am experimenting with them for DGAVCDec. The goal is to generate demuxed streams with an offset as close to zero as possible. My design goal is +/-24ms.

[Ranguvar]

Okay, that makes sense. So although it isn't as nice, just using say, DirectShowSource() to grab the audio from the source. Would that be sidestepping the problem (although it isn't as good as a demux+NicXXXSource) or would I just be ignoring the problem?

[Guest]

By asking that you show that you don't really understand what I told you.

If you do that you will get a random alignment because the demuxing of the video and audio are decoupled. Worse still, you won't know what the delay is and will have to use a manual correction process.

[Ranguvar]

No... you just answered me. I would be ignoring the problem. Which obviously doesn't help anything.

Thanks for the info.