[MPlayer-users] Slow seeking in incomplete files

[RVM]

El Jueves, 5 de Febrero de 2009 09:40, Reimar Döffinger escribió:
> On Thu, Feb 05, 2009 at 01:23:27AM +0100, RVM wrote:
> > Something I noticed is that seeking in incomplete files (and I actually
> > mean files still downloading in mldonkey) is much faster in mplayer
> > 1.0rc1 than in recent versions (1.0rc2 and svn). In 1.0rc1 when I press
> > cursor up or pgup it almost immediately finds something to play, while in
> > recent versions it takes a lot of time.
> >
> > Why?
> > Is there an option to return to the behavior of 1.0rc1?
>
> That certainly is not true in general (e.g. AVI file seek behaviour is
> definitely unchanged and playback of damaged files is much improved), you
> will have to be more specific which kind of files you mean.

I think this problem happens with avi files. At least I've just tested with a 
mpg and a wmv and seeking with mplayer SVN-r28450 and mplayer 1.0rc1 seems to 
work the same (it's pretty fast).

The problem of newer versions when seeking in avi files, is that when trying 
to seek to a part which hasn't been downloaded yet, the image freezes while 
mplayer outputs a lot of error messages, like these:

[mpeg4 @ 0x879cd60]header damaged  0.484 4841/4841  0%  0%  1.0% 0 0
Error while decoding frame!
[mpeg4 @ 0x879cd60]header damaged  0.488 4842/4842  0%  0%  1.0% 0 0
Error while decoding frame!
[mpeg4 @ 0x879cd60]header damaged  0.492 4843/4843  0%  0%  1.0% 0 0
Error while decoding frame!

With mplayer 1.0rc1, that doesn't happen. It just displays something like this

[mpeg4 @ 0x8660db8]warning: first frame is no keyframe

but it immediately finds something to play.

If I use -demuxer lavf with mplayer SVN-r28450 then it seems seeking is a 
little bit faster, but not as much as mplayer 1.0rc1.

> You could try -demuxer mov, but if that helps you should also try a
> newer MPlayer version, that might be fixed.

It seems -demuxer mov doesn't work with avi files.

-- 
RVM