[FFmpeg-devel] [PATCH] fix speex sample
Fri Apr 10 08:33:11 CEST 2009
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.
>>>> 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
>> 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
> 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
> 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
More information about the ffmpeg-devel