[FFmpeg-devel] [PATCH] fix speex sample

[Baptiste Coudurier]

On 4/9/2009 3:33 PM, Michael Niedermayer wrote:
> On Thu, Apr 09, 2009 at 02:32:49PM -0700, Baptiste Coudurier wrote:
>> On 4/9/2009 2:14 PM, Michael Niedermayer wrote:
>>> On Thu, Apr 09, 2009 at 01:12:40PM -0700, Baptiste Coudurier wrote:
>>>> On 4/9/2009 12:37 PM, Michael Niedermayer wrote:
>>>>> On Thu, Apr 09, 2009 at 10:24:27AM -0700, Baptiste Coudurier wrote:
>>>>>> On 4/9/2009 7:06 AM, Michael Niedermayer wrote:
>>>>>>> On Thu, Apr 09, 2009 at 09:39:24AM +0200, Diego Biurrun wrote:
>>>>>>>> On Thu, Apr 09, 2009 at 04:46:34AM +0200, Michael Niedermayer wrote:
> [...]
>> FFmpeg encoder outputs 10 frames for the first gop when specifying gop 12.
> 
> ffmpeg will by default adapt gop sizes based on detected scene changes

Yes. It will still output 10 frames for the first gop when no scene
change appear :)

>>>> And if you don't duplicate frames you just loose 2 frames.
>>>>
>>>> You will seek based on pts. If you seek to 3 you will seek to the I
>>>> frame, if you seek to 1 you will seek to the I frame also since it is
>>>> before in coded order.
>>>>
>>> [...]
>>>> Basically:
>>>>
>>>> I pts 3
>>>> B pts 1
>>>> B PTS 2
>>> if you seek to pts=1 in this case you will end up at the I frame of the
>>> previous GOP (which is not shown) or if such does not exist seeking will
>>> fail
>> It's not shown because it does not exist, this is the beginning of the
>> stream and closed_gop is set to 1.
>>
>> Code should not seek to previous I frame is gop is closed in this case
>> anyway.
> 
> thats what i said below
> you must seek approximately, parse frames and extract closed_gop flags
> add their duration keep track of reordering and then you can decide if this
> or the previous I frame is correct and do the final seek.
> Or what iam suggesting all along, just dont support it which cuts the
> complexity down alot.

Ok I think I get it, you mean that even in this case, adding the code
will try to decode the 2 b frames and will result in failing ? In this
case decoder could skip the B frames according to closed gop. If flag is
wrongly set then we need concealment, however it is ok to fail in this
case, the stream is clearly faulty.

>> Does the current code really do this ? It seems anyway current PS
>> demuxers use dts.
> 
> current seeking code is broken in several ways ...

True, maybe gsoc will fix this :)

>>> it is possible to fix this by using convergence duration based on the
>>> count of b frames, their duration and the closed_gop flag but i pitty
>>> the one who would try to implement this because it wont be fun.
>>>
>>>
>>>> Considering delay you almost have to double check the pts of the decoded
>>>> frame in any case IMHO.
>>>>
>>>>> how that improves accuracy relative to not receiving frames prior to
>>>>> the timestamp to which you seek, i dont understand.
>>>> If you don't duplicate frames, you get 2 frames less than the source file.
>>> no, encoders should start with I frames not B frames
>> Yes, you get 2 frames less than the source file.
>>
>> Encoders _can_ start with B frames according to specs. I agree they
>> shouldn't.
> 
> It might be legal, this though does not mean it is done in reality nor
> it is more than rare.

It is done in reality my sample proves it, and I have many samples like
this one. Only one encoder doing it is sufficient. Final Cut Pro XDCAM
Encoder does it for example.

[...]

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org