Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 45

Thread: AMD Opens Up XvBA! Their Catalyst Linux Video API

  1. #31
    Join Date
    Jan 2009
    Location
    Columbus, OH, USA
    Posts
    323

    Default

    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?

  2. #32
    Join Date
    Mar 2008
    Posts
    63

    Default

    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.

  3. #33
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,099

    Default

    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.

  4. #34
    Join Date
    Dec 2008
    Posts
    980

    Default

    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

  5. #35
    Join Date
    Feb 2010
    Posts
    519

    Default

    Very nice, looking forward to a Brazos-powered HTPC

  6. #36
    Join Date
    Aug 2008
    Posts
    83

    Default

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

  7. #37
    Join Date
    Oct 2007
    Posts
    279

    Default

    Quote 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

  8. #38
    Join Date
    Jun 2009
    Location
    Paris
    Posts
    428

    Default

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

  9. #39
    Join Date
    Jun 2009
    Location
    Paris
    Posts
    428

    Default

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

  10. #40
    Join Date
    Nov 2009
    Posts
    101

    Default

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

Tags for this Thread

Posting Permissions

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