[FFmpeg-devel] [PATCH] fix speex sample

[Michael Niedermayer]

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


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


> 
> Does the current code really do this ? It seems anyway current PS
> demuxers use dts.

current seeking code is broken in several ways ...


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


> 
> >>> [...]
> >>>>> Also if someone considers this feature to be so critical to him, he
> >>>>> can implement it, its simple "patch welcome"
> >>>> Well, I'm not disagreeing here, I tried to fix it myself and submitted a
> >>>> patch. I'm not sure to understand everything though.
> >>>> Like I don't clearly understand why closed_gop and broken_link would
> >>>> matter if we get error-concealment in this case.
> >>>> Like you said these flags might be wrongly set.
> >>> am i the only one that thinks that duplicating frames randomly through
> >>> error concealment on every seek is a poor idea?
> >>>
> >>>
> >>>> Do you mean that If broken_link is set, then these 2 frames cannot be
> >>>> decoded and should be discarded ?
> >>> no closed_gop must be set to 1 for the frames to be decodeable
> >> Ok, what if it is wrongly set to 1 ? You must have concealment right ?
> >> Isn't allocating last_picture_ptr enough ?
> > 
> > for functioning concealment? certainly not, it may be enough for avoiding
> > a crash but it will not look pretty,
> > best concealment strategy is likely to drop the frames if they access
> > a non existent reference because they are not used as reference themselfs
> > droping has very little vissible effect, a single wrong MV is very vissible
> > (think of a green block in someones face)
> 
> Interesting, I don't get this: it is not ok to drop a partial packet but
> it is ok to drop an entire frame which might be decoded correctly.
> Anything obvious I miss ?

you can decode the frames just fine by starting on the previous key frame


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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
-------------- 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/3dcba3de/attachment.pgp>