Mplayer (VA-API, VDPAU, ffmpeg-mt) experimental build repository for Fedora 11, Rawhide

UPDATE: I've been updating this repository ever since making this blog post. I update with the latest builds from upstream (Gwenole) every so often, and packages are currently in the repo for Fedora 13, Fedora 14, and Rawhide.

I spent today building a set of experimental mplayer packages for Fedora 11 and Rawhide. You can find them here:

http://www.happyassassin.net/video-experimental/

It's probably worth a quick legal notice, at this point. This is mplayer, based on an RPM Fusion build, which it is suggested infringes on several patents held in the United States. I haven't done any particularly detailed research into this, so if it worries you, ask a lawyer. However, I live in Canada, and so does my server - the server on which these packages are hosted. To my knowledge, no Canadian patents are infringed by this stuff, so I'm good. If you're in America (or any other jurisdiction which may have relevant patents), please be aware that it may be illegal for you to use these packages, and it's on your head to confirm whether it is or isn't. Not mine. And of course, these packages are my own personal work, built and hosted on my own personal systems, and have nothing whatsoever to do with my employer.

There are repos for Fedora 11 and Rawhide for ix86 and x86-64. In each repository are two mplayer builds, mplayer-accelerated and mplayer-mt, and support libraries for mplayer-accelerated. The mplayer packages install alongside the regular mplayer package, and contain only the mplayer executable, with a different name so it doesn't conflict with the original.

mplayer-accelerated is built with support for both VDPAU and VA-API video decoding and output acceleration. VDPAU support was written by NVIDIA and merged into mainline mplayer some time ago. VAAPI support comes from the patch written by Gwenole Beauchesne. This means you can get hardware accelerated video playback on various hardware, currently NVIDIA cards (GeForce 8xxx and later) using the proprietary driver, Intel Poulsbo (GMA 500) adapters using my driver packages for Fedora 13, S3 Chrome 530 GT and S3 Chrome 540 GTX adapters using S3's own driver, and Intel i965 and later adapters.

To use VDPAU acceleration (which is for NVIDIA and S3 adapters), you'll need to install mplayer-accelerated and libvdpau (which is now in Fedora proper). If you're using NVIDIA, disable compositing - add a line like this: Option "Composite" "Disable" to the Extensions section of /etc/X11/xorg.conf . If there's no Extensions section, create one. It goes right at the top, and should look like this: Section "Extensions" Option "Composite" "Disable" EndSection Then you call mplayer-accelerated something like this: mplayer-accelerated -vo vdpau -vc ffh264vdpau somevideo The vc parameter changes depending on the codec used by the file. ffh264vdpau is for h.264-encoded video. There's also ffmpeg12vdpau for MPEG-1 and MPEG-2 files, ffmpegvc1vdpau for VC-1 files, and ffmpegwmv3vdpau for WMV files. Once you've tested it and made sure it works, you can create a file ~/.mplayer/config which looks like this: vo=vdpau,xv, vc=ffh264vdpau,ffmpeg12vdpau,ffvc1vdpau,ffwmv3vdpau, and it should work 'automatically' on any file if you just call mplayer-accelerated.

To use VAAPI acceleration, for Intel adapters, you'll need to install mplayer-accelerated and libva. For Poulsbo you'll also need xpsb-glx, but that should be installed anyway if you have the driver working. Then call it like this: mplayer-accelerated -vo vaapi -va vaapi somevideo There's no codec-dependent parameters for VAAPI. A ~/.mplayer/config file like this should work: vo=vaapi,xv, va=vaapi though I haven't tested that. In a final wrinkle, you can actually use VDPAU through VAAPI, if you install the vdpau-video package that's also in the repository. So on an NVIDIA or S3 system, install the appropriate driver, mplayer-accelerated, libva, libvdpau, and vdpau-video. Then call mplayer-accelerated with the VAAPI parameters, and it ought to work. There's no particular benefit in practical terms to doing it this way rather than using VDPAU directly, really, but this is probably the direction things will develop in future for the sake of a coherent interface, so it's worth testing.

It's pretty easy to tell whether it's working. If it's really broken, mplayer just won't play. Feel free to drop a comment with whatever error message you got, and some details. If it does start playing back, to make sure the acceleration is actually being used, just open top (or htop - friends don't let friends use top when htop is available!) while the video's playing. If acceleration is in use you should see negligible usage on all your cores (unless something else CPU-intensive is running, of course). If it's not working, mplayer will be using an appreciable fraction of CPU time. Best to use a pretty high-resolution video to test, just so the difference is clear cut, especially on a fast system (my 3.36GHz Core 2 processors don't go above 30% even decoding h.264 at 1080p, so it may actually be quite hard to spot the difference with an SD MPEG video or something).

mplayer-mt is built against ffmpeg-mt, rather than the main branch ffmpeg which mplayer usually ships with. The experimental ffmpeg-mt branch adds support for multi-threading. That means it can split the work of video decoding across multiple cores on a dual-core, triple-core or more-core (:>) system (well, on any system really, but it wouldn't make an awful lot of sense to do it on a uniprocessor system). Frankly, most systems that are dual-core or higher in the first place can handle 1080p decoding for just about any codec on one of their cores, but there are a few systems where this may not be the case - especially the upcoming dual-core Atoms - and it's always nice to spread the load even if one core could just about handle it.

Using it is rather easier than the acceleration stuff. Just install mplayer-mt - none of the other packages are needed, for multi-threading - and call it like this: mplayer-mt -lavdopts threads=N somevideo where N is the number of threads you want to use (so, usually, set it to the number of cores you have). This will work for any video which would use an ffmpeg codec (and that's most of them). You can check that it's working, again, with top or htop. Without multi-thread support, you'll only see one mplayer process, chewing up X% of CPU time on one core, while your other cores sit idle. With it, you should see N mplayer processes - where N, again, is the number of threads you specified - each chewing up X/N% of CPU time, more or less. It's a pretty obvious difference. Again, if it doesn't work, please do drop me a line and complain. I love complaints!

In case you're wondering, I did try doing an uber-awesome build with both acceleration and multi-threading support. Unfortunately, it seems the VAAPI patch doesn't get along with ffmpeg-mt; if you build with both VAAPI and ffmpeg-mt, then try playing something back using VAAPI, mplayer just crashes. So it has to be two separate builds, for now. I've reported this to Gwenole - he may be able to do something about it. Or not! We'll see.

Comments

[...] updated my video acceleration repository again yesterday. The update to libva in the last repository update was broken – even though [...]
[...] have also done an update to my accelerated mplayer repository for Fedora. New versions of mplayer-accelerated and vdpau-video. I’m not entirely sure [...]
[...] good news – I’ve updated the video-experimental repo with the latest builds of libva, vdpau-video and mplayer-accelerated. I’ve also added the [...]
[...] Then just reboot, and usually it should work. Remember, you can get an mplayer build with video playback acceleration support which will let you play HD videos smoothly from my video-experimental repo: details in this post. [...]
Simply Gades wrote on 2010-07-24 16:52:
Hello, well done on the GMA 500 driver, works great! As I am new to fedora, I would like to know whether there is a way to add your video-experimental repo and install mplayer with vaapi support, or should I manually download the packages? Thank you!
Ilkka wrote on 2010-08-21 10:13:
I think you might need to update the repodata in your F13 repository for mplayer-accelerated... yum tries in vain to install an older libva than is available.
MossySF wrote on 2010-09-12 21:56:
On my config (Core i5 integrated video + Fedora 13 + RPMfusion libva-freeworld), mplayer-accelerated does not work with divx or xvid. Most h.264 videos work but a few do crash. The console errors I get are: divx [vo_vaapi] vaPutImage(): operation failed xvid MPlayer interrupted by signal 11 in module: filter_video - MPlayer crashed by bad usage of CPU/FPU/RAM. h264 Too many buffered pts Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] The selected video_out device is incompatible with this codec.
matteo wrote on 2010-09-16 11:50:
I have installed mplayer-accelerated and all packages related to vaapi on my system but when I run "vainfo" I have the following error message [root@bigmatteo matteo]# vainfo libva: libva version 0.31.1-sds1 Xlib: extension "XFree86-DRI" missing on display ":0.0". libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib64/va/drivers/fglrx_drv_video.so libva: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit [root@bigmatteo matteo]# I'm on a Fedora13 64bit system with an ATI RADEON HD4550 video card... please help
adamw wrote on 2010-09-16 22:47:
with that graphics card, you need to be running the fglrx (ATI proprietary) graphics driver and have xvba-video installed, which I don't package because I can't test it and really can't be bothered with it. Otherwise, libva won't work.
[...] celebrate the new year (and because someone poked me about it on IRC), I updated my video-experimental repo. F12 is out, F14 and Rawhide are in, and there are updated versions of mplayer-accelerated and [...]
[...] to build recent vdpau-video code, so the latest vdpau-video is now up for F13, F14 and Rawhide in my video-experimental repo (yes, I’ll note the irony before anyone else does: said repo is unsigned, if anyone pwns my [...]