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

[Corey Hickey]

Michael Niedermayer wrote:
> Hi
> 
> On Tue, Jan 31, 2006 at 12:51:49AM -0800, Corey Hickey wrote:
> 
>>Michael Niedermayer wrote:
>>
>>>>>>I _think_ mplayer doesn't properly use the dwStart field in the stream
>>>>>>header of AVI files. To reproduce, create a file with 10-second audio delay:
>>>>>>
>>>>>>mencoder file.avi -ovc copy -oac copy -audio-delay 10 -o delay10.avi
>>>>>>
>>>>>>MEncoder writes the audio delay in the dwStart field of the audio
>>>>>>stream. You can check it with a hex editor or with 'mplayer -v delay10.avi'.
>>>>>
>>>>>
>>>>>MEncoder supports -delay now anyway, you should use that... -audio-delay is 
>>>>>a hack..
>>>>
>>>>Are you sure? That seems to be the intended purpose of dwStart,
>>>>especially considering that Microsoft's player appears to use it that
>>>>way and -audio-delay is the documented way to adjust A-V sync with
>>>>mencoder.
>>>>
>>>>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
> 
> 
> wrong!
> {A|V}<id><PTS><DTS>
> original: (lets say its raw)
> A000 A111 A222 A333
> V000 V111 V222 V333
> 
> decoding delay: (this cannot be stored without either skiping a frame or 
>                  dwStart in AVI due to the -1 DTS)
> A000  A111 A222 A333
> V00-1 V110 V221 V332
> 
> decoding delay + skip frame: (stored in AVI)
> A000 A111 A222 A333
> V110 V221 V332
> 
> ignoring decoding delay: (stored in AVI, 1 frame delay wrong)
> A000 A111 A222 A333
> V010 V121 V232 V343
> 
> dwStart style:
> A011 A122 A233 A344
> V010 V121 V232 V343
> 
> all of these remuxed: they stay the same, why in hell should anything change?
> you find the pts from the dts by using a AVParser and the dts are known from
> avi

I guess I was assuming that the remuxing program wouldn't know about the
decoding delay and would assign video PTS starting at 0 rather than at 1.
dwStart style, remuxed (incorrect; how I thought it was):
A011  A122 A233 A344
V00-1 V110 V221 V332

...or maybe I'm way off-base again and don't even understand how I'm
wrong. I don't know -- I'm still fumbling through all this, without
knowing anything beforehand.

-Corey