[FFmpeg-devel] RV30/40 decoder seek reset

Kostya kostya.shishkov
Fri Feb 6 22:46:39 CET 2009

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?

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

> For
> example with crash.rmvb the first video timestamps show up as follows in
> mplayer -demuxer lavf (with MPlayer's native demuxer the video at least
> looks smooth):
> 0.0
> 0.1 x4
> 0.3 x6
> 0.4 x4
> 0.5 x2
> 0.6 x4
If the problem manifests with one demuxer and does not with the other one,
perhaps that's not the decoder problem?

P.S. Current lavf RM demuxer is in grave need of rewriting. Patch may be

More information about the ffmpeg-devel mailing list