Nifty tidbits and random thoughts on technology and anything else that catches my fancy
Monthly Archives: April 2012
So this is a continuation to my last post on my effort to upgrade the media center at home. While I wait for hardware to come, I’ve been reading up through forums and blogs online and am finding it real hard to get some good advice. So, thought it might help to list down concisely the situation as it stands currently, in the hope that it will server other folks who’re trying to find similar answers.
So what’s the fuss all about?
Getting XBMC on Linux with AMD fusion APUs to work nicely and render hardware accelerated video. Also, while we’re at it, also do it by booting off a pendrive (ie hdd less system)
To get hardware accelerated video on ATI/AMD hardware on Linux, currently, there are two choices
- XvBA – this is AMD’s graphic APIs (similar to VDPAU on nVidia). Not very well supported.
- VAAPI – this is intels APIs. XBMC Eden is said to work well with VAAPI.
- Open source Linux drivers for ATI chips lag behind the closed source ATI proprietary drivers. For HD video, you’re pretty much limited to using ATI’s proprietary drivers. So, let’s emphasize – from now on, driver means ATI Catalyst for Linux
OpenElec is covered in the earlier post – but essentially you have a Fusion optimized micro builds that can run off an SD card/flash drive. From a video perspective, this should be identical to XBMCBuntu. The upside is that everything is pre-configured while the downside is that it’s pretty limited.
Also covered in my previous post – lightweight Ubuntu based distro/LiveCD. XBMC Eden implements VAAPI and Catalyst Fusion APUs drivers can be used asa backend with these and provide hardware accelerated video. There are some cases where this bridging doesn’t/may not work well. On the other hand, since this is the officially supported method, its going to be around and improved upon, and likely to have more info available in public domain etc.
XBMC-XvBA PVR builds
So this is an unofficial build by the community. THe promise is that instead of going the VAAPI route, this has direct support for XvBA api so, offes better performance. The forum thread tracking this is available here. While the build is supposed to be quite usable, from the thread activity, it seems its also heavily under development.The goal is to merge this back to the mainline once it stabilizes.
I plan to go the path of least resistance – OpenElec, then XBMC-XvBA and finally settle on XBMCBuntu – but things might change once I actually get down to it.
Time for the big fat disclaimer – Nothing in this post is guaranteed to be correct. this is my read of stuff on the net and it could be wrong. You’re welcome to correct it in the comments and I’d be more than happy to fix the post.
Vim installed by Cygwin’s setup project does not have Ruby/Python/Perl support enabled by default. As my list of must have vim plugins has a few which use Ruby and Python, thought that it might be good to build my own Cygwin build of Vim. Turned out a little more work than I thought – but that’s more due to the misleading (at least for me ) Make file in the vim source tree called Make_cyg.mak.
Here’s how to compile:
- Make sure you have python (and ruby, perl and whatever other interpreters you need vim built with) installed.
- Do not install vim through cygwin (or uninstall it if you have it)
- Download vim source tarball, untar it and go into the
./configure --enable-pythoninterp --enable-perlinterp --enable-rubyinterp --enable-gui=no --without-x --enable-multibyte --prefix=/usr make && make install
- You’re off to the races!