Yes, it is now that legendary time, well loved by the hearts of men for millennia(*): Graphics Test Week! Tomorrow - 2009-09-09 - is ATI/AMD Radeon graphics card Test Day. Thursday - 2009-09-10 - is NVIDIA graphics card Test Day. And Friday - 2009-09-11 - is Intel graphics card Test Day. I am currently rolling up a pair of live CD images that will likely be used for all three days; they should be uploaded soon. Please, please grab the live CDs, do the testing, and come out to the Test Day(s) for the graphics hardware you own! As always, graphics are a critical piece of Fedora and we want to make sure Fedora 12 works on as wide a range of graphics hardware as possible. The testing's very easy to do and it shouldn't take more than an hour of your time to boot the live CD and run the tests. There's no need to install anything to hard disk. You don't even need to be a Fedora user to take part, and what's in Fedora's drivers today will be in everyone else's tomorrow, so helping us test this benefits all distributions down the road. The Test Day gatherings themselves are held in IRC, in channel #fedora-test-day on the Freenode network. Please do join in if you can - we can help advise you with any questions you have, and if you run into bugs, the developers can investigate them with you right away. See this page if you're not sure how to use IRC. If you can't make it out for the actual day, though, you can still do the testing, and your results are still useful! Just download the live image, do the tests, and fill in the results table as the page instructs. Many thanks to everyone who's able to make it out and do the testing. Remember - tomorrow ATI; Thursday NVIDIA; Friday Intel. * - well, okay. Not really millennia. More like...months.

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.

So a bit more tweaking later, I have improved my freevo setup EVEN MORE. For super-awesome NVIDIA love: Here's the sneakiness... in local_conf.py, you want to set up something like this: MPLAYER_ARGS = { 'mkv' : '-vo vdpau -sid 0', 'mp4' : '-vo vdpau -demuxer lavf -sid 0', 'default' : '-vo vdpau -cache 5000 -sid 0' } MPLAYER_VF_INTERLACED = '' MPLAYER_VF_PROGRESSIVE = '' and in ~/.mplayer/config - for whatever user you run freevo as - you want: vo=vdpau,xv, vc=ffh264vdpau,ffmpeg12vdpau,ffvc1vdpau,ffwmv3vdpau, the redundancy is because freevo likes to pass its own explicit -vo settings at the start of the mplayer command line, which overrides the preference you set in .mplayer/config. So you have to set freevo's config file to force it to pass -vo vdpau later in the mplayer command line. But I still set it in ~/.mplayer/config just for when I call mplayer manually for some reason. That will get you VDPAU output always and VDPAU-accelerated decoding whenever possible - the vc= line is the magic, it tells it to try each of the VDPAU decoders in turn and then fall back to whatever mplayer would otherwise use if none of them work. The MPLAYER_VF_* lines are very important, because if you don't override it this way, Freevo likes to try and do some post-processing on all video playback, and the post-processing settings it uses aren't compatible with VDPAU. Took me half an hour of wall/head interfacing to figure that out. This just disables all post-processing. If you watch a lot of interlaced video this might give you trouble (investigate a very recent SVN mplayer and vdpau's own deinterlacing options...), but I don't, so I don't care. Another line you can stick in ~/.mplayer/config if you have S/PDIF connection to a surround sound receiver: ac=hwac3,a52, that will do hardware AC-3 / Dolby Digital passthrough whenever it makes sense. If it doesn't make sense, it just does normal audio playback. I realize this is all a bit vague, but hopefully it makes sense to anyone else who's ever bloodied themselves on Freevo's configuration files, and may be of use to some of them :) So now my HTPC uses its video card to decode just about anything I throw at it, and that zonking great dual-core CPU I put it in feels a bit useless. Hmm. Oh well!

It's interesting what side alleys you wander into sometimes... I spent a few minutes updating Mandriva's moovida packages today (well, just backporting to 2009.0 and 2009.1, and re-adding a patch I'd disabled a while ago). I periodically check out moovida to see if it could replace freevo on my HTPC setup. It's always getting better, but always still missing one or two bits. Right now I'm down to what's really a pretty small gripe in any context but that of someone who _actually uses his HTPC a lot_ - there's only one speed for fast forward and rewind, it skips a minute at a time. That might not seem like a big deal, but around the twentieth time you just want to rewind ten seconds to catch that line you missed, it becomes one. Anyhoo, one of the nagging imperfections in my HTPC setup that triggers my tweaking muscles like this is the fact that I've always got moderate video tearing, of the kind where when the 'camera' (I put that in quotes because we mostly use the HTPC for anime...) is panning smoothly sideways, the picture gets sort of split in the middle horizontally. It's not deal breaking, just...always annoyed me a little. Several times I've vaguely looked into it, and come up with nothing. And every time I try moovida instead, it's always as bad or worse. This time my research eventually hit paydirt, and sent me off on some interesting side tracks. I've always tried different video output methods for mplayer (freevo) or gstreamer (moovida). It never really seemed to help much. I tried OpenGL instead of Xv output...it seemed to help a bit, but it took a lot of CPU time, maxing out my fairly beefy HTPC decoding a 1080p video, which it doesn't with Xv output. Then I got back into the hairy world of VDPAU (my HTPC has an NVIDIA card and uses the proprietary driver). I always figured VDPAU should give damn perfect output, but it seemed to tear more than anything. Finally, I hit paydirt on a solution to this: disabling compositing in X.org. With compositing disabled, VDPAU output is smooooooth as butter. I also realized you can just use VDPAU for rendering the video without actually using its hardware decoding acceleration abilities. This is good because mplayer doesn't yet seem to be able to auto-detect whether VDPAU can accelerate the decoding, and if so which -vc option to use; you have to know and do it manually for each video. Which makes it a bit of a non-starter through an HTPC interface. But you can just use -vo vdpau, and let the CPU do the decoding work, and it'll work for all videos. And still no tearing. Yay! This has made my HTPC much happier. So, the sidetracks: #1: gstreamer is, very quietly, developing VDPAU support. There's VDPAU output support and experimental MPEG decoding acceleration in gstreamer-plugins-ugly; they just don't talk about it much. Don't believe me? looky here. I didn't bother testing it much, though. It seems a little early, and hacking up moovida to use it could be...fun. #2: I downloaded mplayer SVN to see if they're improving the VDPAU support to do autodetection yet. Still looking at that. #3: While thinking about the 'high CPU use with OpenGL output' situation, I found there's an experimental branch of ffmpeg with multithreading support. So you can actually use all the cores of your modern multicore CPU for decoding. Probably interesting for low-end Pentium and Athlon dual-core systems, where one core might not have quite enough oomph for 1080p decoding, but two together almost certainly will. DEFINITELY interesting for the upcoming wave of dual-core Atom nettops. I'm looking into doing a build of current SVN mplayer with current git ffmpeg-mt, for Mandriva, for experimentation. (I do all this stuff on Mandriva because that's what my HTPC runs, and I gotta keep my hand in somehow :>) This is all making me think quite hard about my future HTPC hardware setup...the current system is a giant power-sucking Core 2 Duo in an Antec Overture case. Which is nice, but hardly small. Hmm...

Time for another Test Day update! Today is Sectool Test Day in Freenode #fedora-test-day. Sectool is an intrusion detection / security audit tool. Today's usually the Fit and Finish Test Day, but FnF have kindly donated their slot this week. It's easy to help out and test Sectool on any Fedora 11 or Rawhide system, so please come along and run a few tests! Thursday will be Sugar on a Stick Test Day. Sugar on a Stick is a Fedora-based live distribution designed to let you run the Sugar desktop environment on any system from a USB key. Sugar is the revolutionary desktop environment initially designed for the One Laptop Per Child project - if you've ever seen one of the cute little OLPC XO systems, that's the desktop it was running. This Test Day is being organized by the Sugar folks. Please come out on Thursday and help them test out the project! It will of course be very easy to test, since it's designed to be a live distribution: you just download the SoaS v2 Beta release and run the tests that will be listed on the Test Day page. No need to change your installed systems at all. Again, the Test Day runs in #fedora-test-day on Freenode IRC, all day long. It's also worth taking a sneak preview: next week will be Graphics Card Test Week. We'll be testing ATI cards on Wednesday 2009-09-09, NVIDIA cards on Thursday 2009-09-10, and Intel cards on Friday 2009-09-11. I don't have the Test Day pages up yet, but they will be soon. Mark it in your calendar! There's also an awesome new project I wanted to draw attention to: Boog, which has been kicked off by Kushal Das and Rahul Sundaram. It's a bug reporting client, intended to simplify the process of reporting bugs in Fedora. It will help to identify your Fedora release and the versions of any related packages, and also includes some types of commonly required information. It's great to see Kushal took advantage of the bug information pages we in QA have been working on lately for this. I didn't immediately see a link to where you can get a hold of Boog yet, but as soon as I do I'll definitely try it out and everyone else should too. For myself, I spent a bit of time yesterday updating my libva and mplayer-vaapi packages (in my poulsbo repository) with the latest changes from Gwenole. I briefly looked into building a VAAPI-enabled vlc package also, but it appears to be very full of pain, so I skipped out on that. If anyone else feels like doing it, please go ahead :)

Just a quick update on the Poulsbo stuff. It's in review for RPM Fusion, now - see here. The current packages in the repo should be pretty damn bulletproof, up to kernel 2.6.30. I'm running them on 2.6.30 on my Vaio P now and they're solid, it stays up forever and everything works. I starting fooling around trying to get something going on Fedora 12 (Rawhide) this morning, but no joy. I've patched the kernel module and X driver to build on 2.6.31 and X server 1.7 respectively (with a little help from Adam Jackson - thanks), but they don't actually work; hangs on X startup with a blank screen, at least for me. I've been testing on a live USB stick so no way to grab the X log and see what's going wrong, for now. I tried a different approach for a bit - building X server 1.6 for Rawhide - but it's too icky, there's too many changes to underlying libraries and I'm not sure I want to rebuild the entire X stack. I may wind up having to do that in the end, but I'm not going to spend the time yet. If anyone wants to take a look at the Rawhide builds, they're available: binaries here, sources here.

It's that time of the week again: test day time! There was no Fit and Finish test day this week, but tomorrow - 2009-08-27 - is Dracut test day. This is a very important test day, as Dracut is a vital new piece of infrastructure for Fedora 12. Dracut is intended to replace mkinitrd and nash for the purpose of generating the initrd. The initrd is a disk image which is loaded alongside the kernel, containing the necessary drivers for the initial boot process to proceed and access your real hard disk partitions where Fedora lives. Obviously, if there's a problem with the initrd - your system won't be able to boot. So it's vital for as many people as possible to test Dracut in as many situations as possible so we can be sure it's bulletproof. Dracut may well replace mkinitrd in other distributions in future too, so even if you don't use Fedora - hi, Mandriva readers! - it's probably in the best interests of you and your distribution to come out and help test at least the live CD (which obviously won't require you to install Fedora at all). We're happy to get testing from anyone! Involved testing will require some manual configuration and possibly an installed Rawhide system. However, basic testing can be carried out simply by booting a live CD image and reporting whether or not it works, so there's no excuses for not doing the basic test! The wiki page has comprehensive instructions on testing, so please come along to the test day tomorrow and let us know how it works for you. The test day will be held in the Freenode IRC #fedora-test-day channel all day tomorrow (please note the relatively new IRC channel, we're not doing them in #fedora-qa any more). If you need any help on using IRC, see this page.

There's been an exciting development recently in Fedora QA land: thanks to the superhero Kevin Fenzi and friends, we're now doing an automated Rawhide build of each official live Fedora spin every night, and publishing them here. Yep - nightly Rawhide live CDs! (Or DVDs, when the generated images are too big for a CD. Which happens.) If you need to quickly test something in Rawhide but you're not in a safe position to install it - just grab the last nightly live CD and boot it up. Of course, Rawhide being what it is, sometimes the compose will fail and there won't be an image built that day, and occasionally the image might just not work at all, but it's still a great improvement. Hopefully this will greatly lower the bar for people getting involved with testing Rawhide.

Well, this has been an interesting weekend so far! Yesterday I decided it was past time for my partner to get a PC update (he was still using the Athlon 2400+-based system I built him over four years ago), so I headed off to Netlink armed with a list of parts and some price match sources, and returned home a few hours later the happy - ignorant, but happy - owner of (among other miscellaneous components) a Gigabyte GA-MA770-UD3 motherboard and a G.SKILL F2-8500CL5D-2GBPK RAM stick pair (2x1GB DDR-II sticks). Here is some advice, free at point of delivery, from one who has paid for it in full: do not become the owner of said combination of computing equipment. It will bring you only misery and pain. I, fr'instance, was - at 5 a.m., one hour before I had to wake up and play a tournament tennis match - still awake and trying approximately the night's seven bazillionth combination of BIOS tweaks, hardware swaps and livestock sacrifice in an attempt to make the damn thing run stably for more than fifteen minutes. Suffice to say, it was a losing battle. That motherboard and that memory just _really_ don't get along with each other. So today I returned to Netlink armed with a couple of different SKUs and a hastily-reboxed motherboard and pair of memory sticks, and after some wheedling and strategic pointing out of what a prolific customer I am to the service tech, managed to get a straight credit for the two offending components, even though I hadn't _technically_ ruled out the CPU or hard disk as the source of the trouble (I knew they weren't, but I hadn't proved it...) and they're usually quite strict about that sort of thing. I plumped for an MSI 770-C45 motherboard and a slightly different pair of G.SKILL memory sticks (these ones are the newfangled DDR-3). These have so far proved to make beautiful music together, thankfully - if that hadn't actually sorted the problem I'd probably have hauled off and killed someone by now. 30 hours of screwdriver hell (I switched out power supplies and graphics cards with other systems I had lying around to see if those bits were the trouble, and did the usual connecting / disconnecting hard disks and memory and other miscellaneous bits dances - if you don't maintain your own systems, trust me when I say that swapping PSUs between two fully-hooked-up systems is not a bundle of laughs) punctuated by a single hour of sleep and two tennis matches will do that to you. I am now going to have a beer. Possibly even two! Then clean up the mess... The system in question is running Windows 7 (he plays a few Windows games, obsessively, and they don't run too well in wine). It does seem like Microsoft have done a fairly decent job with it. It hums along quite quickly and seems surprisingly robust for a Microsoft operating system (watch out, that faint praise'll have someone's eye out!) - I was pleasantly surprised when it managed to run the Experience Index performance rating thingy, and consequently enable all the whizzy Aero effects, without clobbering the 3D game that was running in the background. The user access control compromise they've come up with just seems...odd - on a regular basis you get warned that doing something needs administrator privileges, and asked if you want to let it happen, and then you say yes, and it happens. You never actually enter a password at any point. Heck, I wasn't asked to _set_ an administrator password, nor did I have to grant my user administrative rights or anything. I'm not entirely clear on what the model is there, but at least there appears to be some kind of model, and it's not as eye-stabbingly annoying as Vista's was, by all accounts. Hey ho.

Time for a quick Test Day update! Today - right this very minute - is the Fit and Finish group's printing Test Day. If you have a few minutes to spare, hit up that Wiki page, do some testing, report your results and join #fedora-fit-and-finish on IRC to discuss the situation. Fit and Finish is a great initiative, so please do join in. Thursday - August 20th - is the next main track Test Day, on ABRT, the Automatic Bug Reporting Tool. This is an important component of Fedora 11 and 12 which pops up an offer to file a bug report when an application crashes. Its scope has been extended for Fedora 12, so please come along to the Test Day - in #fedora-qa - to help make sure it's ready for the release. As always, live CDs will be available to help make testing easier.