[MPlayer-users] Seeking in MPEG2/MPEG4 streams

[Uoti Urpala]

On Tue, 2010-01-05 at 06:50 +0100, Reimar Döffinger wrote:
> On Tue, Jan 05, 2010 at 12:34:49AM +0100, Barnabas Hajas wrote:
> > My computer is a 800MHz Celeron and yes I did test it and the
> > performance loss is noticeable. Monitor's refresh rate is not my
> > limiting factor at all. It runs at 60Hz and if I play a double (or
> > triple) speed video it looks a lot smoother when seeking forward.
> > MPlayer was always very famous of being efficient on hardwares very
> > different from each other. This is the number one property I really
> > like it for. I don't use FFMpeg, but libmpeg2, never used FFMpeg for
> > MPEG-2 decoding because it's slow as hell for this purpose including
> > seeking as well. So I was talking about libmpeg2 producing "incorrect
> > frames like that".
> 
> I think the issue really isn't that ffmpeg is slow.
> I do not know if the git version maybe has some of the issues I just
> fixed or some similar ones, so if you don't mind, could you also try the

Git has had fixes (and better ones) for those problems for a long time
already.

> latest SVN version?
> It still does not give back the "blocks" behaviour, but it plays very
> smoothly during seeking for me now (actually a bit too fast IMO).

His description looks unclear to me - what does "double (or triple)
speed video" mean in this context (playback speed should be irrelevant)?
Can you really talk about "smooth" when doing seeks, when most of the
frames should jump to significantly different content unless the video
is exceptionally static (does "not smooth" just mean there are long
pauses between updates)? And could this be a case where the demuxer
doesn't properly go to keyframes? If the computer is fast enough to
decode the video during playback then I think it should normally switch
the frame during seeking quickly enough (and even if it for some reason
switched between the essentially "random" frames at say only 20 FPS
instead of 60 that doesn't sound like a real problem that would hurt any
practical use case).

What SVN did - not updating frames at all when doing seeks in a rapid
succession - was a real problem, but there hasn't been any proper
description of a performance-related issue, and I at least don't feel
like trying to get the original poster to provide one.