[MPlayer-users] How to choose fastest drivers
Nix
niks1024 at gmail.com
Sun Oct 31 21:45:36 CET 2010
On 2010.10.31. 01:42, JD wrote:
> Dear all,
> I tried to play a test video (.mkv) format.
> I am having a terrible time to sync audio with video
> during playback. I keep getting
> Your system is too SLOW to play this!
I beg your pardon but that already implies that it's not a problem with
codecs or video/audio output drivers per se. Instead your current setup
simply can't handle the sheer load of having to decode 560p H.264 video
though I wouldn't be surprised if your CPU could be able to handle 720p
but only if you:
1) update your MPlayer to current because, if I recall correctly, just
recently there was a notable decoding efficiency increase for ffh264.
2) consider going 64 bit as your CPU supposedly supports that (though I
sort of recall Athlon64 being somewhat different from modern x86_64).
Why? Because that will give FFmpeg twice as many usable registers which
should help greatly with decoding H.264. The downside is that if you
already are low on memory it will only get worse as 64 bit binaries can
and generally are more memory expensive.
3) as you were already told, do not use x11 output driver, instead try
offloading some of CPU load to your GPU via xv or gl driver (xv is
probably a better option as, if I'm not mistaken, your only choice for a
video card driver is the open source radeon that has good if not great
XVideo but terrible OpenGL support (also ATI cards have problems with
OpenGL itself)).
4) use stuff like -lavdopts fast (maybe used by default now, not sure)
and if that doesn't help then -lavdopts
fast:ec=0:er=0:skiploopfilter=all and if that turns out to be not enough
either, try -lavdopts fast:ec=0:er=0:skiploopfilter=all:skipframe=nonref
but be warned that it can look very bad at times; -framedrop and -sync
30 or so can help to avoid lag buildup too but only if you're missing a
little bit of CPU cycles for smooth playback not a lot.
5) if you tend to have problems with slow drives, big cache is a good
thing as well.
> The highest cpu usage by any process is 1% or less.
> There are only 5 processes at 1% and the rest are
> below .2%.
And overall usage? If you have, say, 250 of such .2% processes it would
still equal to 50% as well as extra overhead switching between them.
Also do check I/O wait which generally isn't counted as real CPU usage
and therefore might not be shown.
Cheers,
nix
More information about the MPlayer-users
mailing list