Announcement

Collapse
No announcement yet.

Will AMD's XvBA Beat Out NVIDIA's VDPAU?

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

  • #61
    Well usable is hard to say. It seems only embedded device manufacturers got the needed headers to write apps which support xvba - and the funny one who made those benchmark tests to annoy people because HE can use it but nobody else. If you would get a precompiled binary you could use it, but how to get it?

    Comment


    • #62
      Finally though it looks like AMD may be prepared to launch XvBA formally this summer. - Michael Larabel
      US definition of Summer: Begins June 21, summer solstice, and ends with the autumnal equinox on September 22.

      Time left in Summer -- 73 days (inl. weekends)

      Comment


      • #63
        The boy the cried wolf?

        Hi all and Monkey King,

        I really do hope that ATI/AMD do finally enable ther world klass video decodes on the HD4xxx cards. Getting what one paid for is always a good thang! :-)

        By the end of the USA summer, would be a year later, but better later than never.

        To many of these "coming up real soon now," articles, followed by the big nada, does tend to reinforce the notion, that we are all listening to, "the boy who cried wolf...." I do hope that is not the case. But I have been wrong b4.

        Crossez fingerz. :-)

        GreekGeek.

        Comment


        • #64
          hmm did this news go over everyones heads then?, wasnt the real news here that
          there is apparently now a working "UVD" ASIC hardware codebase in the hands of (i assume thats you gbeauche ?) Gwenol? Beauchesne that previously wrote the VA-API support for MPlayer / FFmpeg and even a VDPAU back-end for VA-API. (along with SheepShaver, and adapted many just-in-time (JIT) translation techniques lets not forget ) we may get to use the ATI "UVD" hardware decoding and frame accurate editing in some form if it makes it to the likes of FFMPEG patchs and at some point soon, FINALLY ?

          why are you already arguing the API points when you cant even currently use or code for the "UVD" hardware right now without Bridgman's help and Gwenol?'s currently usable codebases....

          rememeber way back in january 8th 2009 Bridgmen said:

          Quote:
          Bridgmen said:"we are going to look into opening up UVD, I just can't make any commitments until we have actually gone through the investigation and it won't be quick. We have 6xx/7xx 3d code out now, so IMO the next priority should be basic power management. "


          popper said:thats a shame, we are looking at months at the very least then!


          Quote:
          Bridgeman said:For open source, yes, but I expect fglrx will have it sooner.
          Last edited by popper; 17 July 2009, 08:42 PM.

          Comment


          • #65
            You didn't miss anything. We didn't make a public announcement because the current implementation is not something we can make available other than in embedded applications under NDA. When we have an implementation which can be made publicly available, trust me you'll know about it
            Test signature

            Comment


            • #66
              Originally posted by mukiex View Post
              All things considered, however, I wonder if we're better off putting VA-API on top of VDPAU instead of the other way around. VDPAU already works on Mplayer, FFMPEG, VLC, and XBMC patch-free, and it's somewhat of an open standard. Making Ati's, Intel's, and S3's chips play along means we won't have to wait for patch updates for all the major video playback programs.
              Supporting both would be awesome!

              VAAPI on top of VDPAU, and VDPAU on top of VAAPI would both show which API has the least overhead and could in the long term help improve both these APIs, ...while short term it would allow all software that support VDPAU today use VAAPI through VDPAU, and the all software that support VAAPI today use VDPAU through VAAPI.

              Best for the media player software developers however would be if we someday get an API that not only word on Linux/UNIX or Windows, but an API that would also work on Windows and Mac OS X, ...kind of like the concept behind the Gallium 3D device driver framework.

              If I have to pick today though I choose VDPAU because its closest to DXVA (Microsoft's DirectX Video Acceleration API for Windows) so its more 'portable' for the media player software developers than VAAPI.

              PS! In any case, I too hope to see publicly released ATI/AMD GPU acceleration library/drivers for video decoding on Linux soon and XBMC Media Center implementation for it.
              Kodi is a free media player that is designed to look great on your big screen TV but is just as at home on a small screen.


              Comment


              • #67
                Originally posted by Gamester17 View Post
                Supporting both would be awesome!
                Yes.

                VAAPI on top of VDPAU, and VDPAU on top of VAAPI would both show which API has the least overhead and could in the long term help improve both these APIs, ...while short term it would allow all software that support VDPAU today use VAAPI through VDPAU, and the all software that support VAAPI today use VDPAU through VAAPI.
                No. That is just more overhead and more silliness.

                Best for the media player software developers however would be if we someday get an API that not only word on Linux/UNIX or Windows, but an API that would also work on Windows and Mac OS X, ...kind of like the concept behind the Gallium 3D device driver framework.
                The entire point of Gallium is to not need to have universal APIs. Instead, you have frontends for each OS and windowing system, and a single driver in the backend.

                Additionally, the media player guys don't get any breaks if the video decoding API is universal; they still have to have GUI stuff broken out. (Well, except for VLC because they use Wx, but you're not talking about VLC.)

                If I have to pick today though I choose VDPAU because its closest to DXVA (Microsoft's DirectX Video Acceleration API for Windows) so its more 'portable' for the media player software developers than VAAPI.
                VDPAU is for Unix-likes only.

                PS! In any case, I too hope to see publicly released ATI/AMD GPU acceleration library/drivers for video decoding on Linux soon and XBMC Media Center implementation for it.
                http://xbmc.org
                Meh. They still don't understand how to write proper GL/GLX code; I'm not optimistic about their Radeon compatibility...


                Kodi is a free media player that is designed to look great on your big screen TV but is just as at home on a small screen.

                Comment


                • #68
                  Originally posted by MostAwesomeDude View Post
                  (Well, except for VLC because they use Wx, but you're not talking about VLC.)
                  http://xbmc.org/trac/ticket/6382
                  VLC uses Qt4. wxWidgets GUI was deprecated circa 0.9.0.

                  Comment


                  • #69
                    Originally posted by MostAwesomeDude View Post
                    VDPAU is for Unix-likes only.
                    I know, I was refering to that NVIDIA basically got the idea for VDPAU by reverse-engineering the concept behind the DXVA design

                    Originally posted by MostAwesomeDude View Post
                    Meh. They still don't understand how to write proper GL/GLX code; I'm not optimistic about their Radeon compatibility...
                    Watch out, even though I coded none of XBMC GL/GLX code myself I might still take that as an personal insult,

                    ...just kidding, but I am the one who has been on Team-XBMC the longest, hehe http://xbmc.org/about/team/

                    This is totally off-topic but know that it not really a bug in XBMC. You see XBMC GUI rendering engine requires proper OpenGL 3D with GLSL and ARB shaders support, something that the any (open source drivers other than Intel) does not provide as of yet, and it should be noted that this minimum requirement is for the GUI and not for the video playback renderer, ...later we might even raise this minimum requirement for XBMC from OpenGL version 1.3 (as today) to OpenGL version 2.1 in order to support even more eye candy with GUI skinning.

                    http://xbmc.org/about/vision/
                    Last but not least, be beautiful to look at, after all, we hope you will be using it a lot!

                    Comment


                    • #70
                      Originally posted by Gamester17 View Post
                      Watch out, even though I coded none of XBMC GL/GLX code myself I might still take that as an personal insult,

                      ...just kidding, but I am the one who has been on Team-XBMC the longest, hehe http://xbmc.org/about/team/

                      This is totally off-topic but know that it not really a bug in XBMC. You see XBMC GUI rendering engine requires proper OpenGL 3D with GLSL and ARB shaders support, something that the any (open source drivers other than Intel) does not provide as of yet, and it should be noted that this minimum requirement is for the GUI and not for the video playback renderer, ...later we might even raise this minimum requirement for XBMC from OpenGL version 1.3 (as today) to OpenGL version 2.1 in order to support even more eye candy with GUI skinning.

                      http://xbmc.org/about/vision/
                      No slight meant.

                      The bug's in XBMC's GLX setup, and it could be fixed with a bit of code inspection. Maybe I'll fix it someday. Has nothing to do with shaders.

                      Actually, somebody should really change the GL setup too so that it falls back to ARB programs if available (which do work in current Mesa) and to properly detect GL extensions. Unless I'm out-of-date and somebody's already done it, of course.

                      Comment

                      Working...
                      X