XBMC's Thoughts On XvBA: AMD Catalyst Has Problems

[fritsch]

@TheWretched:

1080i mpeg-2 is a big problem. Doable of course - but with cpu load at very high value at least on Fusion Hardware. These high values increase temperature a lot. So noise is another factor one has to think of when running htpcs small in size. As written in the article, these interlaced mpeg-2 streams are used within DVB-S, so watching TV for hours is a scenario we have to focus when creating htpc software.

[TheWretched]

Yeah well... too bad^^ My next HTPC will get a good CPU anyways, as I plan on using it for MAME and other stuff, too. I have ordered a Raspberry Pi, too, which will probably only act as a simple client for my bedroom, if anything.

My audio problem is much more aggravating to me, though. Finally got it working in 11 and now with the 12 alphas, it's broken again... though I must say it's a big change and I will probably buy an HDMI capable receiver soon (my current one only allows HDMI passthrough which is kind of pointless).

[fritsch]

You can join #xbmc-xvba we get your audio fixed. I am sure :-)

[TheWretched]

I am currenctly playing around with Gentoo anyways... that way Pulseaudio won't get in the way anymore (current system uses Ubuntu with updated Pulseaudio to 2.0). My current system is rather improvised...

Still, I have less problems with XVBA though^^ I can't complain, other than the reoccuring problems with garbage displayed when Gnome insists on opening a window in the background (like the update manager), as I use Gnome and not the "main" XBMC manager.

[markg85]

I asked this a couple years ago (iirc back when the splitted-desktop-systems released the XvBA to VA-API wrapper) and i will ask it again since matters didn't really improve all that much over time. If any!

If we go back to the core XvBA is implemented on top of UVD right. Why don't the capable people "simply" reverse engineer UVD? I mean, linux has a fairly well working reverse engineered Windows api in Wine, we have a fairly well working Nouveau driver that's also fully reverse engineered. Surely those people are more then capable in reverse engineering a darn chip with probably just a dozen functions or so.

It must be possible and easier then ever. We even have the XvBA api description now, we can trace the function calls and see what the expected output should be. Surely it's easier then ever to reverse engineer it, right? We can even fill the missing pieces from the windows side since there "XvBA" (called differently) is better implemented then on the Linux side.

More importantly, i'm having high hopes that the UVD chip is a physically separated chip which doesn't require the fglrx driver to work. If that is really the case it means we can have hardware accelerated decoding with the UVD chip on the OSS gallium drivers (r600g for example). Or even on VESA Anyway, that's all if i'm right and if someone can actually reverse engineer UVD.

[ChamPro]

I have an ASRock ION 3D that works great with XBMC. It work super running over HDMI in 1080p in the old XBMClive (based on Ubuntu 10.04 32-bit with XBMC Dharma) and the new XBMC Eden on Ubuntu 12.04 64-bit. I'm having small issues with some DVDs playing with skippy video, but I don't think that's related to the video drivers.

[DanL]

Both these companies however, do actually care about open source, or see that it's far more beneficial to just pretend to care, and at least release their stuff in an open source manner... nVidia may seem like this awesome Linux friendly company, that has like the best video driver. The truth however, is that nVidia simply doesn't really care about opensource. They realize there's some extra sales to be made by having and releasing a Linux driver, but that's it. "Open source is a wrong business model" or something the like (I really have to find that interview again).

I would rather have a company that openly admits they don't care about open-source (but puts out a damn good blob driver) rather than a company that just pretends to care. In terms of video acceleration, vdpau is as good as it gets, though intel has narrowed the gap on sandy/ivybridge.

[bwat47]

If you don't need powerful graphics I would go with Intel APUs without a question. Their work on open source drivers and the rest of the stack is phenomenal.

Yeah, I've been loving the intel drivers, very few issues. Granted vaapi doesn't actually work too well on my older intel ironlake card, but I've heard it works much better on their newer hardware. For my purposes my i5 is more than adequate for video decoding anyway.

[smitty3268]

If we go back to the core XvBA is implemented on top of UVD right. Why don't the capable people "simply" reverse engineer UVD? I mean, linux has a fairly well working reverse engineered Windows api in Wine, we have a fairly well working Nouveau driver that's also fully reverse engineered. Surely those people are more then capable in reverse engineering a darn chip with probably just a dozen functions or so.

It's certainly possible. I think it comes down to 3 things:

1. Most of the people with reverse engineering experience are working on nouveau instead, and don't have too much interest in radeon.
2. The people who are getting paid to work on radeon are either under NDA or not allowed to do something like that which could jeapordize their company relations with AMD.
3. The unpaid devs are probably waiting for Mesa's video statetracker code to stabilize before jumping into anything.

Building a whole video pipeline from start to finish is a pretty big job, even without reverse engineering a driver. It probably makes sense to wait for that to get up and fully running before attempting to get into UVD support.