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.