Fine-tuning 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...
Um
try xine instead of using the commandline MPlayer
Er... 'gmplayer' anyone. It comes with the basic mplayer install iirc.
Re: Um
> try xine instead of using the
> commandline MPlayer
>
> Er... 'gmplayer' anyone. It comes with
> the basic mplayer install iirc.
If you would care to read the article, you would see that he talks about MPlayer having a fine GUI now, and you ought to have the whole sentence as a quote as he states it was a while ago. :)
My pet peeve about MPlayer
Sometimes I might be doing other things while using MPlayer. Browsing the web for example.
When I run mozilla, MPlayer drops some frames. That's fine, and not unexpected since mozilla is taking up most of my CPU time when it starts up.
But every time MPlayer drops a couple of frames, the annoying "Your system is too SLOW to play this!" message box comes up. Usually it comes up right over the video, so I have to stop what I'm doing and click "OK" so I can continue to watch the movie.
Is there any way to get rid of this messagebox?
Crappy opinion!
The commercial OSS are $#17
The days i were using them were the most frustrating days in my life with
linux
They DO WORK, but living without them was better for me till i've got a new
soundcard that works with ALSA 0.9 REALLY COOL!
with the commercial OSS, I had to restart esd often because the sound begin to
be bad, Playing with the mixer values affects the sound playback, I didn't
find a way to store/restore the mixer values.
Finally, Yes i don't like them and they were about to let me hate our Great
OS, But they deserve a thanks for their work too ;)
A strange thing:
# echo 1024 > /proc/sys/dev/rtc/max-user-freq
bash: /proc/sys/dev/rtc/max-user-freq: No such file or directory
I even failed to create the file
# lsmod | grep rtc
rtc 5528 0 (autoclean)
Can anyone please point me to the problem here ??
Re: My pet peeve about MPlayer
-framedrop enable frame-dropping (for slow machines)
Re: My pet peeve about MPlayer
That doesn't work. I still get that messagebox if I'm doing another CPU-intensive operation like starting mozilla or bunziping a large archive, even with the -framedrop switch.
I realize that MPlayer isn't getting enough CPU power during that time, but it only takes a few seconds to start mozilla, and I can deal with MPlayer dropping a few frames.
But that messagebox is damn annoying. MPlayer shouldn't presume it is the only (or even the most important) application running. I think there should be a config option to disable that messagebox.
Re: Crappy opinion!
>
> # lsmod | grep rtc
> rtc 5528 0
> (autoclean)
>
>
If you're running 2.5.59, like me, the file seems to have disappeared. I hope it will return soon...
Re: Crappy opinion!
>
>
>
> If you're running 2.5.59, like me, the
> file seems to have disappeared. I hope
> it will return soon...
>
No, 2.4.18
i'm sure i'm missing something here, Anyway i'll recompile it as soon as i finish the Xfree 4.3 stuff
Re: Crappy opinion!
> No, 2.4.18
> i'm sure i'm missing something here,
> Anyway i'll recompile it as soon as i
> finish the Xfree 4.3 stuff
Quoted directly from the article:
"With 2.4.19pre8 and above, you can enable it for normal users as well:
echo 1024 > /proc/sys/dev/rtc/max-user-freq"
;-)
Re: Crappy opinion!
>
> % No, 2.4.18
> % i'm sure i'm missing something here,
> % Anyway i'll recompile it as soon as i
> % finish the Xfree 4.3 stuff
>
>
> Quoted directly from the article:
>
> "With 2.4.19pre8 and above, you can
> enable it for normal users as well:
> echo 1024 >
> /proc/sys/dev/rtc/max-user-freq"
>
> ;-)
The rtc enrtry in /proc won't appear until the rtc module is loaded - run "modprobe rtc". That's for non-root users anyway, if autoloading of modules works on your configuration it will be loaded as soon as Mplayer tries to access it.
changing timeslices?
I've run mplayer on a variety of machines and I've never had to alter kernel settings to get smooth playback on any system that had the cpu power to decode the files i was using. Maybe you need to look and see if you have other processes running at a higher priority than mplayer is, lots of distros like to run X at a high priority.
Also not getting too in depth on the alsa api and the oss api, sufice it to say that if you plan on having times of interrupting high cpu processes during playback of a movie, running oss emu on top of alsa and using the oss output for mplayer is a much better choice than to tune your kernel specifically for mplayer (unless that's all you run). So if you are having problems with sound latency try doing that before anything else.
Also not really mentioned. If your video card is sucking it up in X because X doesn't have very good drivers for you, the vesa output plugin for mplayer may be lacking some of the functions of the X drivers but even non-fb driver equipped systems can run movies in vesa console mode.
And as a general rule for post processing, dont use post processing at all unless the movie is really bad. Mpeg1, use it. Divx really low quality use it. But Divx 800kbit+ will only look worse with post processing enabled. Deblocking will make still pieces of an image look like it's moving. Other post processing features shouldn't need to be used unless you're using either of the first two (vb or hb). I strongly suggest not using autoq features as a config option because most videos you'll make and watch wont need it. the post processing algorithms just aren't good enough so that you can use them on high quality video. This makes things a bit annoying since you cant be completly lazy and set up preferences for all video files in your config file and be done with it.
As a general rule. I do not run post processing on divx5/odivx files and I do run it on div3/wmv/asf/mpeg1/xvid/qt/rm and only hb and vb without the luminance filter. -vop pp=hb:y/vb:y .
And also, if you're unfortunate enough to need to use the swscaler instead of hardware accelerated, always set either your width or height to 0 so you preserve aspect ratio.
Set your vfm to ffmpeg because 9 out of 10 times if you're not already forced to use it, it's better than any other decoder/encoder for that codec. Compile that yourself with whatever your favorite gcc opts are.
Do not use ffmpeg's audio decoder for mp3 though, you will most likely get ringing as a result. mp3lib is your friend there.
it's hard to find stuff not covered on mplayer's website and manual file.
Re: changing timeslices?
I realize the timeslice thing may be mistaken for what was said in the article about the realtime clock stuff, it was meant as a reference to some xmms related posts on lkml. but it has bearing with mplayer as well.
a really nice and cheap soundcard with excellent drivers is the emu10k1 driven sb live. I get annoyed with desyncs of a tenth of a second or more and despite some really bad encodes or experimental codecs, and i've been happy with mplayer and how it handles skips and such.
Re: My pet peeve about MPlayer
Obviously, you're using gmplayer.
MPlayer is definitely the best movie player out there, but at this point in time, it's gui is pretty pathetic, with stupid behaviour like the one you describe. It also seems to be somewhat slower.
My tip: Don't use gmplayer. Use the command-line player - it's much more configurable, anyway.
Re: Crappy opinion!
>
>
> The rtc enrtry in /proc won't appear
> until the rtc module is loaded - run
> "modprobe rtc". That's for non-root
> users anyway, if autoloading of modules
> works on your configuration it will be
> loaded as soon as Mplayer tries to
> access it.
>
It's not even there, though the module is loaded. I remember selecting "enhanced RTC deiver"
i'll try recompiling to see
scalable ?
> Player is a very scalable player. From low-end P1 systems to N GHz CPUs, you can get the best out of your machine.
What about SMP ?
for a single-threaded player I find it quite difficult to scale on SMP :P
FWIW vlc does it very well, using even more threads than native players in BeOS (the multi-threading heaven) :))) (vlc indeed integrates very well in BeOS, for a ported player... I just hope mplayer can get along as nicely one day :)
Re: scalable ?
Oh, and btw, mplayer does work in BeOS... just need to get my hands on the diffs and clean them up to be included in the cvs (I heard the patch is quite ugly as is).
mplayerplug-in
After installing mplayer - be SURE to install mplayerplug-in
Lets you watch movies embedded in your browser - like the QuickTime plugin in Apple Macintosh does.
rpm based distro's can make an rpm for mplayerplug-in by typing:
rpmbuild -tb source.tar.gz
Re: My pet peeve about MPlayer
-quiet or --really-quiet will stop messages in console while a file is playing, also good for files with errors in them as mplayer reports these errors to console as well.
> That doesn't work. I still get that
> messagebox if I'm doing another
> CPU-intensive operation like starting
> mozilla or bunziping a large archive,
> even with the -framedrop switch.
>
> I realize that MPlayer isn't getting
> enough CPU power during that time, but
> it only takes a few seconds to start
> mozilla, and I can deal with MPlayer
> dropping a few frames.
>
> But that messagebox is damn annoying.
> MPlayer shouldn't presume it is the only
> (or even the most important) application
> running. I think there should be a
> config option to disable that
> messagebox.
>
Re: Um
> If you would care to read the article,
> you would see that he talks about
> MPlayer having a fine GUI now, and you
> ought to have the whole sentence as a
> quote as he states it was a while ago.
> :)
Another nifty program is KMplayer. I like it
mainly
because it doesn't allow you to distort proportions
when resizing, the 'recently watched' list (handy to
keep your place when watching an anime series) and
the KDE file open dialog box, much better then what
gmplayer has. The only problem is that the window
can have focus, but somehow mplayer itself cannot,
so you have to click the movie to be able to give it
keyboard commands. And there is no video progress
bar (outside of the OSD). But its only version 0.7.2.
You can get it at
www.xs4all.nl/~jjvriez...
or just
emerge it if you use Gentoo 1.4.
I've had zero problems with mplayer
I think it's best player for any system.
But like anything else you have to learn to use it.
Re: My pet peeve about MPlayer
> That doesn't work. I still get that
> messagebox if I'm doing another
> CPU-intensive operation like starting
> mozilla or bunziping a large archive,
> even with the -framedrop switch.
>
> I realize that MPlayer isn't getting
> enough CPU power during that time, but
> it only takes a few seconds to start
> mozilla, and I can deal with MPlayer
> dropping a few frames.
1) had the same problem when copying something via Samba and a RTL8139 NIC.
2) i think a renice for Mplayer would work. Or run it as root and run Mozilla as user.
Re: Um
KMPlayer is really slow compared with GMPlayer... (btw, KDE is a really slowwwwwwwww desktop!)...
But when you emerge your mplayer in Gentoo it automatically installs the gmplayer frontend...
>
> % If you would care to read the article,
>
> % you would see that he talks about
>
> % MPlayer having a fine GUI now, and you
>
> % ought to have the whole sentence as a
>
> % quote as he states it was a while ago.
>
> % :)
>
>
> Another nifty program is KMplayer. I
> like it
> mainly
> because it doesn't allow you to distort
> proportions
> when resizing, the 'recently watched'
> list (handy to
> keep your place when watching an anime
> series) and
> the KDE file open dialog box, much
> better then what
> gmplayer has. The only problem is that
> the window
> can have focus, but somehow mplayer
> itself cannot,
> so you have to click the movie to be
> able to give it
> keyboard commands. And there is no video
> progress
> bar (outside of the OSD). But its only
> version 0.7.2.
> You can get it at
> www.xs4all.nl/~jjvriez...
>
> or just
> emerge it if you use Gentoo 1.4.
>
>
Mplayer rules but....
About KDE being slow, I have to agree, personally I prefer gnome for speed, but use KDE more as its more, erm, user friendly (I'm a seasoned Win user.....)
Back to Mplayer, well, when I got my hands on Mandrake 9.0, first thing I did was uninstall Xine and d/l Mplayer ! Good thing, Mandrake 9.2 came pre packed with Mplayer ! :))
Still, I'm keeping Xine for now, as it offer better UI. I'm still too lazy to memorize Mplayers lists of functions , and the GUI still suk, :(
Still, Mplayer is the best movie player out there. With -vo sdl watching fullscreen movies are very smooth, even with xv.
Mplayer and Debian
I've had to read quite a bit to be able to use mplayer the way I need it (form the man pages and online documentation to forums and IRC). However, I have noticed that the following link
deb marillat.free.fr/ unstable main
brings a lot of packages that help the configuration of this great movie player. I have downloaded the fonts, plugins (all sorts) and even the program itself. It works like a charm, and you can just dpkg-reconfigure whatever you wish.
Re: Mplayer rules but....
> About KDE being slow, I have to agree,
> personally I prefer gnome for speed, but
> use KDE more as its more, erm, user
> friendly (I'm a seasoned Win user.....)
>
> Back to Mplayer, well, when I got my
> hands on Mandrake 9.0, first thing I did
> was uninstall Xine and d/l Mplayer !
> Good thing, Mandrake 9.2 came pre packed
> with Mplayer ! :))
>
> Still, I'm keeping Xine for now, as it
> offer better UI. I'm still too lazy to
> memorize Mplayers lists of functions ,
> and the GUI still suk, :(
>
> Still, Mplayer is the best movie player
> out there. With -vo sdl watching
> fullscreen movies are very smooth, even
> with xv.
>
>
I have to agree with you about KDE being slow (Just like Win) but the main reason for that is its becuase its like (Win) hehee.
Debian packages
The new sources.list line for Marillat packages is
deb ftp://ftp.nerim.net/debian-marillat/ unstable main
And if you run KDE, the same repository also contains a package for kplayer, which is of course mplayer-based.
Re: Crappy opinion!
>
> %
> %
> % The rtc enrtry in /proc won't appear
> % until the rtc module is loaded - run
> % "modprobe rtc". That's for non-root
> % users anyway, if autoloading of
> modules
> % works on your configuration it will
> be
> % loaded as soon as Mplayer tries to
> % access it.
> %
>
>
> It's not even there, though the module
> is loaded. I remember selecting
> "enhanced RTC deiver"
> i'll try recompiling to see
I've found the best thing to do is to add the line
"sys/dev/rtc/max-user-freq=1024"
to /etc/sysctl.conf
Generally works for my Debian system, and apparently is the way you are supposed to be manually setting these things.