[MPlayer-users] Strange behaviour of latest mplayer when seeking

Reimar Döffinger Reimar.Doeffinger at gmx.de
Fri Apr 8 00:52:53 CEST 2011


On Tue, Apr 05, 2011 at 02:50:47AM +0400, Vladimir Mosgalin wrote:
> I updated mplayer to one of later builds, r33183. It has two strange
> strange things about it. First is, spitting
> [VD_FFMPEG] DRI failure.

Hm, I suspect you have enabled multi-threaded decoding.
That is a side-effect, we probably should just disable DR from the
start in those cases.

> Another, more serious problem is that it doesn't allow to seek in file
> properly. Say, I start video and press "right arrow" to seek forward,
> 10 seconds seek is bound to that key. Mplayer seeks for 2-3 minutes then
> stops. No errors or strange messages even with -v when it stops. Now I
> depress button, press it again, and it seeks again for a minute or few -
> and stops again.

I changed a few things, hopefully for the better.
I currently can see this behaviour only with larger -key-fifo-size values
(though I do not really understand why).

> Another way to increase chance of this happening is using big cache and
> big cache-min. With my default, -cache 65536 and -cache-min 5 it happens
> often. With -cache-min 5 -cache 4096 it seems to never happen. With
> -cache-min 50 -cache 8192, it happens. It also happens with -nocache,
> btw.
> 
> At times - really rare - this stop is accompanied by
> Cache not filling, consider increasing -cache and/or -cache-min!
> message. But most stops give no message.

I think that was just by chance that there was any relation. More or
less: the cache process would steal CPU from the playback process
which in turn caused the key fifo to fill up which then caused the
effect. Your cache settings just "by chance" changed the probability
of this happening.


More information about the MPlayer-users mailing list