[FFmpeg-devel] [PATCH] fix speex sample

[Michael Niedermayer]

On Thu, Apr 09, 2009 at 11:33:11PM -0700, Baptiste Coudurier wrote:
> 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 :)

it should not be hard to change this but its not clear to me what the point
would be ...


> 
> >>>> 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.

no, what iam saying is that if you want to seek to time=500 so that you
will have a correctly decoded frame at time=500
and you have a key frame at pts=505 and one at pts=0 with some b frames
in between then you dont know to which of the 2 you should seek

if closed_gop=1 AND there are _only_ B frames covering the timespan
from 500 to 505 then you can seek to pts=505 otherwise you must seek
to pts=0
What iam saying is that we should always seek to pts=0 in this case and
avoid the complexity.



> 
> >> 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 :)

i hope it will


> 
> >>> 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.

ill remember in case someone ever asks me which are the most broken encoders
;)


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090410/e662259c/attachment.pgp>