Fine-tuning MPlayer for Linux, OSX, QNX, and even Windows

MPlayer is a movie player. It's written mainly for Linux, but it works on most Unices and even on other architectures like OSX, QNX, and (somehow) even Windows. Although it's a desktop/end-user application, it is not as user-friendly as it should be. Some time ago, I even told newbies (coming from Windows) to try xine instead of using the commandline MPlayer.

It has improved a lot. The new MPlayer 0.90 RC series comes with a very nice, skinnable, handy GUI with the usual GUI functions and some hidden (undocumented) features and easter eggs. For example, the very new playbar function is unique; move the mouse to the middle bottom of the screen while playing in fullscreen mode, and you'll see a mini-GUI rolling in with the most important control functions. (Note: It's available only with the "default" skin at the moment.)

So usage is easier now, but configuring your environment for MPlayer is sometimes not trivial. This short article tries to summarize the usual steps of setting up and configuring MPlayer on Linux to get the best performance and/or quality. Note that most of the information below can be found in more detail in the documentation.

Sound drivers

You're probably curious why I start with this. It's because it's the most common cause of performance problems. The reason is not obvious. Playing only audio (for example, .mp3 files) differs greatly from playing movies. In the latter case, the player has to synchronize audio and video. Since all sound cards/drivers have some kind of buffering, this delay has to be compensated. It's not a big issue at first look; both the ALSA and OSS APIs have functions to query the buffer status, the current audio delay. Unfortunately, many of the sound drivers (mainly the OSS drivers included in the kernel) don't implement these extra (driver authors seem to take everything not needed for .mp3 playback as extra...) functions or, even worse, implement them in broken/buggy ways, reporting false values. I've even heard some drivers crash the kernel when one queries the delay!

So, as you can see, I (sadly) take up the sound drivers as the No. 1 issue on Linux. It is not only MPlayer's problem; it effects most players and games (!). MPlayer may be more sensitive, since it synchronizes everything to the audio, so broken sound drivers may cause jerky playback, hangs, or even crashes. Jerky playback (caused by inaccurate buffer delay reporting in the driver) can be worked around with the new -autosync option of MPlayer, but for more seriously broken drivers, you have to fix the driver itself. I strongly recommend using ALSA 0.9; it has turned out to be much more reliable than the in-kernel OSS drivers, even with their OSS emulation layer. If your card is not supported by ALSA, try the commercial OSS drivers from 4Front Technologies. They cost a few $, but it is worth it; they implement the whole OSS API correctly and provide extra features (and support) over the free drivers.

VGA cards

Most recent cards (manufactured in the past few years) have some kind of support for hardware scaling and direct support for the YUV colorspace. They are very important features if you want high-quality (perfect, smooth colors) and fast (hardware accelerated) fullscreen playback. Note that it's not enough for the card (hardware) to support these features. You need stable, fast Linux drivers supporting them. The latter prerequisite has turned out to be more important; only a few cards have perfect support and only a few have imperfect, but at least stable, working drivers. For Matrox and ATI cards, you can use our VIDIX drivers. For the rest, you can hope that the card is supported in XFree 4.x and the driver supports the Xvideo extension (run "xvinfo" to check). The S3 Savage, Trident, and Neomagic chips are known to have serious Xv problems, while some others (like nVidia and 3dfx) work most of the time, sometimes with small issues or limitations. Selecting the video output mode in MPlayer is done with the -vo switch; see -vo help for the available drivers. Try each, and find the best (quality/speed).

CPU speed

Is your CPU fast enough for DivX playback? It depends on the VGA support. Why? Let's have a look at two corner cases. I have a PII 250MHz for testing, equipped with a Matrox G200 AGP card. It's able to play DVDs in fullscreen and even 720x576 DivX files. A friend of mine has a 1GHz PIII with an S3 Trio3D. He is unable to play DVD fullscreen, since his card has no native drivers -- not even Xv support, even DGA is broken, just pure X11 works. He has to use software scaling, which means a lot more data to transfer over the slow AGP bus and more work for the CPU. He can watch DVDs under Windows with <50% CPU usage, thanks to the better Windows VGA drivers.

So, if you have a sufficiently good VGA card with sufficiently good Linux support, any CPU can do the job, assuming it's at least a 250-300 MHz one. However, you can watch smaller (like 512x384) DivX files even on a P1 166 with MMX! The only case in which your CPU really matters is when you start using filters (-vop) like postprocess, deinterlace, blur/sharpen, denoise, etc. They can eat huge amounts of CPU time to do the image processing.

Direct Rendering

No, this is not related to XFree 4.x's DRI.

Direct rendering means accessing the video card's RAM directly, bypassing all the "useless" things in the middle, XFree and/or the drivers. From a more general perspective, DR means bypassing image copies (i.e., the codec won't allocate its own memory buffers, but decodes directly into the video card's (hard DR) or the video driver's (soft DR) memory). Bypassing a RAM-to-RAM copy is not a big improvement; RAM chips are fast enough to do it using only a few percentages of CPU. The real advantage comes from the fact that less than the whole image changes between 2 frames (only the parts in which some objects move), on average only 20-40% of it (the exception is a panning/zooming camera). This means it's enough to transfer only 20-40% of the image to the slow video RAM through the even slower PCI/AGP bus. This gives a huge performance boost on slower systems (like old AMD K6 systems). You can activate DR with the -dr switch in MPlayer; it's disabled by default. Note that even if you enable it, it may be ignored, as it requires a big chain of conditions to match, which includes codecs, filters, colorspaces, and video driver features. Run MPlayer with the -v switch to see if it allocates buffers or uses DR.

Disadvantages of DR:

It requires a VGA driver supporting "hard DR" (VIDIX, mga_vid, DGA, VESA, or fbdev).
It doesn't work with double buffering (it may result in a tearing effect).
It sometimes doesn't work with OSD/Subtitle rendering.

Smooth playback

The defaults of MPlayer's A-V sync parameters aren't fine-tuned for perfect files. They are set to match most (average) files. If you have high-quality videos, you may want to limit A-V sync correction in order to get smoother playback. The most important A-V sync parameter is "-mc". It means "max A-V time correction per frame", and defaults to 0.01. For good input, you can go down even to 0.0001, but 0.001 is enough for most cases. Note that smaller values make playback smoother but slow reaction time to fix A-V desynchronization (broken/skipped frames, etc.).

When looking at timing in such detail, you should take care of video timers, too. Be sure that the hardware RTC timer is used (check MPlayer's output). Note that it requires "root" access with older kernels. With 2.4.19pre8 and above, you can enable it for normal users as well:

echo 1024 > /proc/sys/dev/rtc/max-user-freq

(Also note that it has to be enabled in your kernel configuration.)

If your sound card/driver is not perfect (I haven't seen a perfect one yet...), you should also smooth its timer a bit; try -autosync 30 for a start. Higher values mean more smoothing, but avoid using numbers too high, as they will cause independent timing from the sound card and may result in an A-V desync.

Video quality/Filtering

If your video source is imperfect (noisy, interlaced, blocky artifacts...) and you have a few percentages of idle CPU, try some of MPlayer's filters.

For interlaced video (when there are fast movements, you can see every second line of the image displaced, creating a comb effect), you should try -vop pp=0x20000. If that's not satisfactory, try 0x10000, 0x40000, and 0x80000. For badly-converted NTSC movies, try -vop dint or FFmpeg's adaptive filter, -vop pp=fd:c or -vop lavcdeint. If you're lacking CPU time (deinterlacing is a CPU-consuming process), try one of the "cheap" deinterlacers, -vop halfpack or -vop field.

For blocky video (most common with low-bitrate DivX/WMV or poor-quality (S)VCD), enable the deblocking and (optionally) deringing postprocess filters. For deblocking only, use -vop pp=0x33; for deblock+dering, try -vop pp=0x77. Note that you can combine flags for deblocking and deinterlacing (-vop pp=0x20077, useful for some SVCDs) and get both filters at the same time. If you don't like binary arithmetic, you can use more human-readable flags for -vop pp; see "mplayer -pphelp" for details.

For noisy video (even some older DVD releases are very noisy), try -vop denoise3d. The defaults (4:3:6) aren't the best for every kind of video; you'll probably want to increase/decrease the spatial and temporal amounts, depending on the noise level. The first parameter is the luma spatial coefficient (higher means a smoother but blurry image; it's comparable to the smartblur filter); the second is the same for chroma. I recommend using half of luma for the chroma for MPEG video. The last number is the temporal filtering. It's more efficient on noisy video without blurring/smoothing the image, but values too high (>15) make fast movements jerky and sometimes cause a motion blur effect. If you still have idle CPU time, try -vop hqdn3d, the high-precision version of this filter. (Available only in the "main" CVS version.)

Regarding software scaling: Even if your VGA card and driver support hardware scaling, you may want to try SwScaler, for better quality (at the cost of high CPU usage). Note that SwScaler can do some kinds of filtering (blur/sharpen, chroma shifting), too; see the -ssf option. You can select the scaling method with the -sws option, from nearest-neighbor (pixelized) to bicubic spline (very nice).

Summary

MPlayer is a very scalable player. From low-end P1 systems to N GHz CPUs, you can get the best out of your machine. It just requires lots of RTFM and experimentation...