Announcement

Collapse
No announcement yet.

XBMC's Thoughts On XvBA: AMD Catalyst Has Problems

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by popper View Post
    well Knuckles, you can always buy a cheap Raspberry Pi and get full Hardware decode with that as all the ARM devices today will probably play all 1080P video using full Hardware decode unlike AMD and their non functional UVD decode block
    http://forum.xbmc.org/showthread.php?tid=113824
    Threw ICS on my HP TouchPad... that little Snapdragon processor can curb-stomp just about anything I throw at it (except 10-bit [High 10 Profile] H.264 content).

    Amazing what you can get out of hardware when you're working with good drivers.

    Thank you, Qualcomm, for not mailing it in.

    Comment


    • #17
      http://www.j1nx.nl/multimedia/xbmc/x...vice-openelec/
      especially update2

      Allwinner A10 Features list;


      1.2ghz Cortex A8 ARM Core
      MALI400MP OpenGL ES 2.0 GPU
      DDR3 Controller 800MHz 1GB max
      2160p Hardware-accelerated Video playback (4x the resolution of 1080p)
      NAND Flash Controller that is capable of 8-way concurrent DMA (8 NAND ICs)
      4 SDIO interfaces (SD 3.0, UHI class)
      USB 2.0 Host as well as a 2nd USB-OTG Interface (USB-OTG can be reconfigured as USB 2.0 Host, automatically)
      24-pin RGB/TTL as well as simultaneous HDMI out
      SATA-II 3gb/sec
      10/100 Ethernet (MII compatible)
      A 2nd 24-pin RGB/TTL interface that is multiplexed (shared) on the same pins for a standard IDE (PATA) interface.
      GPIO, I2C, PWM, Keyboard Matrix (88), built-in Resistive Touchscreen Controller, and much more.
      Last edited by popper; 06-21-2012, 11:05 PM.

      Comment


      • #18
        I didn't bought any ATI/AMD hardware since I moved over to Linux about 5 years ago. Every once in a while I look out for new AMD products, just to find out that they still didn't made there homework.
        No really, I'd love to build a new HTPC and I'd love to use AMD hardware for that, but I simply cant because not every feature I want is supported.

        Comment


        • #19
          Originally posted by popper View Post
          well Knuckles, you can always buy a cheap Raspberry Pi and get full Hardware decode with that as all the ARM devices today will probably play all 1080P video using full Hardware decode/encode unlike AMD and their non functional UVD decode block while you wait for the sandy bridge SOC to appear.
          http://forum.xbmc.org/showthread.php?tid=113824 or perhaps you prefer an allwinner 10 instead http://wiki.xbmc.org/index.php?title=Allwinner_A10
          Thanks, but I want a laptop, not just a static sit-on-the-shelf media player. For that, I have a desktop box with an nvidia graphics card.

          Comment


          • #20
            Hm...

            I've been using the XVBA branch for a while now... not that my 3Ghz Quadcore needs it, but it's still nice to see "no" CPU load, even with high bitrate h264. No sure why there's so much arguing about High Profile 5.1 though. I've yet to encounter them in a massive scale. PS3 doesn't support it either (just flat out denies playback), but works, if you rewrite the header. Didn't have to do that with any of my current media, though. All my video is encoded to BDROM spec, and thus works like a charm. MPEG2 isn't as CPU intensive and can easily be decoded without the GPU helping, even on low end CPUs. Not sure of 1080P MPEG2, though, as none of my BDROMs use it, and none are made today using it, either. HD TV in Germany uses h264 only, and that works too, for me. Though I don't watch a lot of TV, so it's not something I really need.

            For me, it's much more problematic to get stable digital audio passthrough working with SPDIF. With the old Audio Engine, it worked sometimes, but now with AE, it always says "device busy", although mplayer and others happily pass the audio to my receiver.

            Comment


            • #21
              @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, 06:38 AM.

              Comment


              • #22
                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).

                Comment


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

                  Comment


                  • #24
                    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.

                    Comment


                    • #25
                      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.

                      Comment


                      • #26
                        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.

                        Comment


                        • #27
                          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.

                          Comment


                          • #28
                            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.

                            Comment


                            • #29
                              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.

                              Comment

                              Working...
                              X