[Ffmpeg-cvslog] r8424 - trunk/libavformat/utils.c

[Michael Niedermayer]

Hi

On Tue, Mar 20, 2007 at 03:29:32PM +0100, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> > Hi
> > 
> > On Tue, Mar 20, 2007 at 01:38:27PM +0100, Baptiste Coudurier wrote:
> >> Michael Niedermayer wrote:
> >>> Hi
> >>>
> >>> On Tue, Mar 20, 2007 at 12:46:05PM +0100, Baptiste Coudurier wrote:
> >>>> Michael Niedermayer wrote:
> >>>>> Hi
> >>>>>
> >>>>> On Tue, Mar 20, 2007 at 11:06:34AM +0100, Baptiste Coudurier wrote:
> >>>>>> Baptiste Coudurier wrote:
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> michael wrote:
> >>>>>>>> Author: michael
> >>>>>>>> Date: Fri Mar 16 23:59:45 2007
> >>>>>>>> New Revision: 8424
> >>>>>>>>
> >>>>>>>> Modified:
> >>>>>>>>    trunk/libavformat/utils.c
> >>>>>>>>
> >>>>>>>> Log:
> >>>>>>>> add a delay variable to hold the timestamp buffer size
> >>>>>>>> set cur_dts correctly for delay>1
> >>>>>>>>
> >>>>>>>> [...]
> >>>>>>>> @@ -611,8 +612,7 @@ static void compute_pkt_fields(AVFormatC
> >>>>>>>>      }
> >>>>>>>>  
> >>>>>>>>      if(st->cur_dts == AV_NOPTS_VALUE){
> >>>>>>>> -        if(presentation_delayed) st->cur_dts = -pkt->duration;
> >>>>>>>> -        else                     st->cur_dts = 0;
> >>>>>>>> +        st->cur_dts = -delay * pkt->duration;
> >>>>>>>>      }
> >>>>>>>>  
> >>>>>>> Would adding a check for pkt->duration != AV_NOPTS_VALUE hurt here ?
> >>>>>> err read != 0, Im not yet awake.
> >>>>> yes it would hurt, all code afterwards assumes cur_dts != AV_NOPTS_VALUE
> >>>> So, what the code should do ?
> >>> what it does probably
> >>>
> >>>
> >>>> Lavf behaviour changed, old code returned pts to AV_NOPTS_VALUE,
> >>>> which is obviously more correct than always 0.
> >>> always returning AV_NOPTS_VALUE is hardly more correct, also the change
> >>> you quote does not cause this
> >> IMHO AV_NOPTS_VALUE at least indicate that value is not
> >> set/present/valid, 0 means a valid timestamp of 0.
> >>
> >> After checking it seems to be r8428, it seems at least one of
> >> dts/pts/duration
> >> needs to be available to compute pts/dts.
> >>
> >>> you will have to send a proper bugreport or debug it yourself like everyone
> >>> else too i cant guess which codecs and containers you used ...
> >> Right, sure, SWF/zeldaADPCM2bit.swf, should I use another thread ?
> >> Audio has no timestamps and frame size for adpcm is not computed,
> >> situation is a bit special.
> > 
> > the swf demuxer is broken it doesnt set timestamps, see the flash file
> > format spec (Frame Subdivision for Streaming Sound) this describes how
> > to mux audio with proper AV sync, just do the inverse in the demuxer and
> > you have exact timestamps
> 
> Not setting timestamps does not make it broken, though considering lavf
> design it might be true, and I agree that a decent container should
> provide timestamps, now I did not design swf.
> You can use time base (audio sample rate, video frame rate) and duration.
> 
> "If this results in a non-integer number, write an occasional
> SoundStreamBlock with one more or one fewer samples, so that the average
> number of samples per frame remains as close as possible to the ideal
> number."
> 
> "For uncompressed audio, it is possible to include an arbitrary number
> of samples in a SoundStreamBlock, so an ideal number of samples can be
> included in each SWF frame."
> 
> So sample number by frame in streamhead is not always exact and
> audio frames (soundstreamblock) does not have timestamps, though only
> one sound stream block is allowed per swf frame.
> 
> Those words looks like a "best effort" framing and not a "mandatory"
> framing,

well there will be av sync and latency issues if its not done ...


> though it seems always to be the case, mp3 framing is different than ad/pcm,
> and parser computes duration so it works fine if you set timebase to
> sample rate.
> 
> Now to fix swf demuxer, what would be best choice ? Computing pkt
> duration ? Setting it to avg sample per frame ? Infering duration from
> frame size ?

neither will work correctly, correct is to convert the video frame number
to the audio sample number add SeekSamples to it then use this as timestamp
for audio

all pure duration based variants fail as soon as you seek

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20070320/9dd2a0d7/attachment.pgp>