Page 3 of 3 FirstFirst 123
Results 21 to 29 of 29

Thread: XBMC's Thoughts On XvBA: AMD Catalyst Has Problems

  1. #21
    Join Date
    Feb 2011
    Posts
    163

    Default

    @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.
    Last edited by fritsch; 06-22-2012 at 07:38 AM.

  2. #22
    Join Date
    Mar 2010
    Posts
    27

    Default

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

  3. #23
    Join Date
    Feb 2011
    Posts
    163

    Default

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

  4. #24
    Join Date
    Mar 2010
    Posts
    27

    Default

    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.

  5. #25
    Join Date
    Oct 2007
    Posts
    297

    Default

    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.

  6. #26
    Join Date
    Jul 2009
    Location
    Maryland
    Posts
    4

    Default

    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.

  7. #27
    Join Date
    Oct 2007
    Posts
    1,323

    Default

    Quote Originally Posted by oliver View Post
    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.

  8. #28
    Join Date
    May 2010
    Posts
    684

    Default

    Quote Originally Posted by Teho View Post
    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.

  9. #29
    Join Date
    Oct 2008
    Posts
    3,244

    Default

    Quote Originally Posted by markg85 View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •