[FFmpeg-devel] RV30/40 decoder seek reset

[Kostya]

On Fri, Feb 06, 2009 at 11:39:10PM +0200, Uoti Urpala wrote:
> On Fri, 2009-02-06 at 23:46 +0200, Kostya wrote:
> > On Fri, Feb 06, 2009 at 05:05:55PM +0200, Uoti Urpala wrote:
> > > On Fri, 2009-02-06 at 09:45 +0200, Kostya wrote:
> > > > On Fri, Feb 06, 2009 at 05:20:08AM +0200, Uoti Urpala wrote:
> > > > > Currently the decoders do not have a .flush() function and produce
> > > > > incorrect output after a seek. Is this just an oversight or would there
> > > > > be something nontrivial to implement?
> > > >  
> > > > Why should they need flush() ? They operate on whole frames and the problem
> > > > is in demuxer (and RM format itself).
> > > 
> > > I'm not sure which "the problem" you're talking about. You mean getting
> > > completely correct RV30/40 frames after a seek is nontrivial?
> > 
> > For lavf demuxer it may be so.
> > 
> > > Now the
> > > RV40 decoder seems to show a complete frame from before the seek. At
> > > least that should be avoidable - there's no reason it would have to
> > > produce frames with zero actual content from after the seek.
> > 
> > Any error messages?
> 
> No. After a seek there just always seems to be one more buffered frame
> from the previous position before the picture shows anything from the
> new location.

Ah, of course - decoding delay caused by B-frame presence. Will try to implement
flush() for that case then.
 
> > > When testing the rmvb samples from mplayerhq the lavf demuxer also
> > > showed a timestamp problem. Video looked visibly jerky, timestamps
> > > sometimes jumped over some tenths of a second or went backwards.
> > 
> > Video decoder does not set them, demuxer does.
> 
> Yes this is a separate problem in the lavf demuxer; I didn't mean the
> decoder would cause it.