Announcement

Collapse
No announcement yet.

AMD's UVD2-based XvBA Finally Does Something On Linux

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

  • Originally posted by Kano View Post
    @gbeauche

    Could you define which debian system you tested and what was working on ubuntu which did not work on debian? I can not see those differences - only broken code sometime...
    The supported platforms are defined here:
    http://www.splitted-desktop.com/~gbe...ne/xvba-video/

    The Debian platforms that did not work for me were Debian etch and lenny. I haven't tried recently and I don't care, there are already too many bugs and those have to be reported against an AMD officially supported distribution anyway... So, if you match what AMD recommends you have better chances to get it run, though that doesn't mean this will always work either.

    Comment


    • So you only refer to xvba-video, well i test of course vdpau-video too as you know. However U users have got the strange color problem with h264 too and VC1 seems to work on D lenny too, so what exactly was better on U?

      Comment


      • Originally posted by Kano View Post
        So you only refer to xvba-video, well i test of course vdpau-video too as you know. However U users have got the strange color problem with h264 too and VC1 seems to work on D lenny too, so what exactly was better on U?
        Do you know if Canonical ever addressed the strange color space problem on U 9.10? The last time I checked their forums, many users were having the same color problem, and fixes were not common to everyone.
        For example, some users here on this thread reported weird blue patters while viewing 720p and 1080p h.264 videos.

        Comment


        • When you use vaapi+xvba then it is a pure ATI problem. Buy nv and it works

          Comment


          • Originally posted by Kano View Post
            So you only refer to xvba-video
            Yes, this topic concerns UVD and there is no problem with NVIDIA HW.

            However U users have got the strange color problem with h264 too
            This is fixed for a future Catalyst driver.

            so what exactly was better on U?
            Official support from AMD... It's better to deviate as little as possible from their recommendations.

            Comment


            • Originally posted by gbeauche View Post
              This is fixed for a future Catalyst driver.
              Tell me the version please...

              Comment


              • Sign the NDA please

                Comment


                • $%#&^$%*&%!!! edit...

                  The last post was obviously intended for Kano, not for gbeauche.

                  Comment


                  • @bridgman

                    That info is absolutely nothing for NDA because everybody who has got the hardware or intends to buy should know that!

                    Comment


                    • Yes and no. It's obviously speculative information until we have the fix in a release that passes QA testing -- and once that happens the release gets into users hands quickly anyways. I would like to see us release more of that speculative info, but as long as it keeps getting twisted into "AMD promises..." and used to beat us with it's going to be a pretty tough sell.

                      For now, you know it's being worked on, and any additional info isn't really going to make much difference until the work gets out the door in a release.

                      Comment


                      • Yes, QA is important because a feature may be working for some time but this can get horribly undermined by a regression in another part of the driver thus rendering the whole pretty useless or unusable. So, even if there is a target release, nothing is sure until you get the final release of the driver out. However, there are strong constraints to get this out at a specific time.

                        That info is absolutely nothing for NDA because everybody who has got the hardware or intends to buy should know that!
                        This won't change much. Any normal and sane person willing to buy X or Y will check if this meets his requirements right now. Otherwise, he would never buy anything. And, at this time, the best working solutions for H.264 decoding available to Linux are Broadcom, Intel and NVIDIA. Needless to say, this is in lexicographical order.

                        Comment


                        • So, what's new in xvba-video-0.6.10 and libva_0.31.0-1+sds11? I just noticed that they were added to the download pages on March 18..

                          Comment


                          • From the changelogs:

                            libva (0.31.0-1+sds11) hardy; urgency=low

                            * G45 updates:
                            - Add vaDeriveImage().
                            - Fix YV12 image format.
                            * OpenGL extensions updates:
                            - Dynamically allocate VA/GLX vtable.
                            - Fix display context destruction chain.
                            * Upgrade to GIT snapshot 2010/03/08:
                            - Merge SDS patches 010, 320.
                            - Fix test/encode/h264encode.c issue.

                            -- Gwenole Beauchesne <gbeauchesne@splitted-desktop.com> Fri, 26 Feb 2010 10:26:13 +0000
                            The funny thing is the date

                            Version 0.6.10 - 18.Mar.2010
                            * Add I420 image format
                            * Add support for VA-API 0.31.0-sds6
                            * Fix destruction of child windows used by vaPutSurface()

                            Comment


                            • Hello all,

                              I am really excited about all of this. While I fully appreciate bridgman's comments that AMD/ATi didn't promise much, I bought my 780G over a year ago and expected the UVD on it to work in the near future. I also mistakenly believed that all information about the cards had been publically released (including the UVD parts) and that Free drivers would be able to support this feature. Needless to say I was a bit disappointed when I found out the truth, especially as an nVidia alternative would have allowed VDPAU from the time that I bought it. I'm happy to see AMD/ATi using VA-API for its acceleration instead of creating yet another API.

                              Since AMD/ATi "opened up", I have been an avid supporter and bought only AMD/ATi cards. In New Zealand, however, our digital TV uses HD H.264 and practically needs acceleration to play properly. I have been stuck on analogue for my MythTV HTPC and have been trying to buy a cheap nVidia 8600GT to put in my 780G for VDPAU. I'm now hopeful that these recent changes may stop this being necessary. I was reading this:
                              http://www.mythtv.org/wiki/Release_Notes_-_0.23
                              I believe that 0.23 will include VA-API:
                              http://svn.mythtv.org/trac/browser/t...64.c?rev=23525
                              http://svn.mythtv.org/trac/browser/t...pi.c?rev=23525

                              On that note, I would really appreciate it if somebody who has the UVD/VA-API setup working could test that the samples on the following page are being properly accelerated:
                              http://www.geekzone.co.nz/Fossie/4877

                              Thank you to everybody who is working on this.

                              Bridgman: I follow your posts avidly. They are very informative and helpful. I understand that AMD has not yet decided whether or not it will release the UVD specs to those developing Free drivers. This is really important to me if I wanted to be stuck with non-free drivers, I would be using nVidia. The best result would be if the Free drivers could utilise the UVD hardware. If this isn't possible with the current architecture for DRM reasons, please put pressure on AMD/ATi to resolve this in future UVD versions so that these two things can be separated. I realise this thread is about the proprietary AMD/ATi drivers, but I want to flag that I only consider the non-Free drivers a stop-gap until the Free drivers accelerate video enough (whether through UVD, Gallium3D shaders etc.) to allow my CPU to decode 1080i in real time.

                              Regards,

                              Aaron

                              Comment


                              • Basically vaapi is only "working" when you want so when you use mplayer, vlc works from time to time too, currently it is broken with xvba, but mostly working with nvidia. Wrappers seem to be always problematic, the many issues i had with vdpau-video too. I can no say something about psb, that would have got native vaapi (g45 too, but currently only mpeg2, thats boring).

                                Comment

                                Working...
                                X