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

[Corey Hickey]

Michael Niedermayer wrote:
> Hi
> 
> On Wed, Feb 01, 2006 at 01:44:55PM -0800, Corey Hickey wrote:
> 
>>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
> 
> 
> well that makes absolutely no sense, there can be no -1 dts in AVI its not
> possible

I meant for other containers. Remuxing to avi should just copy the
original dwStart values into the new file, I think.

-Corey