[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