an odyssey: mplayer, NVIDIA, VDPAU and video tearing

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...