Announcement

Collapse
No announcement yet.

AMD Opens Up XvBA! Their Catalyst Linux Video API

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

  • #31
    The headline was so chipper but the contents dump all over AMD. What the hell, Phoronix? Is it really so necessary to spin news reporting like that?

    PS: "The server is too busy at the moment. Please try again later."? How much load can a forum make?

    Comment


    • #32
      Wyatt, I am absolutely pro-AMD, but regarding video decoding support for Linux through UVD, they totally messed up by now.
      Starting to open up now, very very late after anybody else has done so already, is only a spark of hope that things might some day get better.

      Not more. Unfortunately.

      Comment


      • #33
        I wonder how feasible it would be to make XvBA independent of the rest of the driver, i.e. make it work with both radeon and fglrx. That could act as a stop-gap measure until proper OSS video decoding can be implemented.

        Comment


        • #34
          Kudos to AMD for finally opening up the API. Though it's of little use to me now, as I'm not using fglrx due to the many bugs it contains that make the driver not a viable option for me at the moment.

          But anyway opening things up is always good in my book. And I'm sure it would make the life of anyone interested in reverse engineering UVD a lot easier

          Comment


          • #35
            Very nice, looking forward to a Brazos-powered HTPC

            Comment


            • #36
              Interesting. Looks like the API does use the interesting convention of one data structure for the input arguments and one for the output arguments that I thought it did. Really weird API...

              Comment


              • #37
                Originally posted by popper View Post
                ooh WOW, that's insane today , totally agree , and we dont need any more drama on the ffmpeg mailing list

                scratches head trying to think of a way to solve or at least get around it.....

                nope nothing coming to mind here , i guess we have to give XvBA yet another strike for fail, so back to VA-API and the OpenCL decode as the only option If They Ever get around to making it available to Linux OC
                What the BEEP are you talking about.. No way around it. pfff ever heard of interfaces? You can abstract it all away with a few interfaces which means that it doesn't need X11 or OpenGL to compile, but does require them to run the api functions.

                Besides that. This API sadly is C and is sadly using GTK in the examples.. I'd rather see a C++ API using Qt but that might be personal preference as well

                Comment


                • #38
                  Originally posted by makomk View Post
                  Interesting. Looks like the API does use the interesting convention of one data structure for the input arguments and one for the output arguments that I thought it did. Really weird API...
                  It could be useful if you want to maintain binary compatibility at any case. Though, in practise, this won't change and complicates things to users since they will have to write their own bindings.

                  Comment


                  • #39
                    Originally posted by markg85 View Post
                    What the BEEP are you talking about.. No way around it. pfff ever heard of interfaces? You can abstract it all away with a few interfaces which means that it doesn't need X11 or OpenGL to compile, but does require them to run the api functions.
                    Yes, you can stick to VA-API for example. No need to write yet another interface then.

                    Besides that. This API sadly is C and is sadly using GTK in the examples.. I'd rather see a C++ API using Qt but that might be personal preference as well
                    I think you are confusing the XvBA SDK with XvBA Tools. The XvBA SDK is plain C. The internal driver API is C++. XvBA Tools contain... tools to demonstrate the API, and this is written in C with Gtk for the UI.

                    Comment


                    • #40
                      Originally posted by markg85 View Post
                      What the BEEP are you talking about.. No way around it. pfff ever heard of interfaces? You can abstract it all away with a few interfaces which means that it doesn't need X11 or OpenGL to compile, but does require them to run the api functions.
                      That's all very well, but if it has a dependency on X11 and OpenGL, it still needs X11 and OpenGL HEADERS to compile, and X11 and OpenGL LIBRARIES to link.
                      So that means for source distributions you need both the above to build avcodec, and for binary distributions that the package would have a dependency on X11 and OpenGL.

                      The distinction you make is quite academic, it doesn't make any difference in practice.

                      Comment


                      • #41
                        Originally posted by popper View Post
                        it's more than just 'This feels like', it probably is a key part of 'the man with the plan' ,
                        however in this case it doesn't seem to be bridgman , rather Tim Writer ECSD Liaison Engineer at AMD, Owner at SaaS 44 Inc. whoever he is ?
                        That's me. I finally registered here and will answer questions about the XvBA SDK and XvBA Tools as best as I can and as time permits. I would prefer that technical discussions about usage of the SDK and Tools take place on the xvba-devel mailing list at SourceForge. So please join that list if you're using XvBA.

                        Tim

                        Comment


                        • #42
                          As a xvba-video already exists it would be much more interesting to know when

                          a) the headers are in the ati installer

                          b) when h264 l5.1 will work - without it is completely pointless

                          Comment


                          • #43
                            Originally posted by gbeauche View Post
                            I have no intention to package XvBA Tools.
                            The primary purpose of XvBA Tools is to be sample code illustrating how to use XvBA so it really doesn't make sense to package it at this stage.

                            Tim

                            Comment


                            • #44
                              Originally posted by markg85 View Post
                              This API sadly is C and is sadly using GTK in the examples.. I'd rather see a C++ API using Qt but that might be personal preference as well
                              I chose C for XvBA Tools for maximum compatibility. I've compiled it with g++ from time to time but some incompatibilities may have snuck in. If you find any, please report them on xvbat-devel at SourceForge.

                              I chose GTK+ because I didn't want to use C++ and because I think its use is more widespread on the platforms that AMD supports. This is sample code and the GUI is minimal so the choice of toolkit is not important.

                              Tim

                              Comment


                              • #45
                                twriter: Hello, please can you tell me if/when will H.264 L5.1 videos work over XvBA? This is really important to me.

                                Comment

                                Working...
                                X