[MPlayer-dev-eng] dwStart (stream delay in AVI files)

Corey Hickey bugfood-ml at fatooh.org
Wed Feb 1 04:05:10 CET 2006


Corey Hickey wrote:
>>>Up to this moment I was thinking of using dwStart to compensate for
>>>video decoding delay (with B-frames), but then I realized it could be
>>>detrimental to remuxing to other containers.
>>
>>
>>which? avi supports dwStart, nut can start at any timestamp too, mpeg-ps/ts
>>is fine too, basically a container which requires that the first packet of
>>every stream has the absolutly identical pts is quite limited
> 
> 
> Right, but the approach I was considering was to use dwStart to make a
> video player play the audio stream with a slight delay, thus matching it
> up to the slightly-delayed video frames. Remuxing to a container that
> uses pts would result in the video frames being played back without
> delay and the dwStart-induced audio delay would be erroneous.
> 
> Here are simplified playback timing tables of what I'm thinking will
> happen from using dwStart like that. The numbers
> 
> original   decoding   dwStart-   remuxed
> file       delay      adjusted   with PTS
> -----------------------------------------
> A1  V1     A1                        V1
> A2  V2     A2  V1     A1  V1     A1  V2
> A3  V3     A3  V2     A2  V2     A2  V3
> A4  V4     A4  V3     A3  V3     A3  V4
>                V4     A4  V4     A4

...and then, now that I think about it, skipping video frames to
compensate for the decoding delay isn't a remuxing-friendly option
either. That would end up like this:

skip a     decoding   remuxed
frame      delay      with PTS
------------------------------
A1  V2     A1         A1  V2
A2  V3     A2  V2     A2  V3
A3  V4     A3  V3     A3  V4
A4         A4  V4     A4

Heck, I don't know. Taking that into consideration, I'm inclined to
think using dwStart for decoding-delay correction is a better idea
simply because it doesn't skip any frames.

-Corey




More information about the MPlayer-dev-eng mailing list