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

[Baptiste Coudurier]

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,
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 ?

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312