AMD Opens Up XvBA! Their Catalyst Linux Video API

[Wyatt]

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?

[edgar_wibeau]

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.

[BlackStar]

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.

[monraaf]

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

[PsynoKhi0]

Very nice, looking forward to a Brazos-powered HTPC

[makomk]

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

[markg85]

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

[gbeauche]

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.

[gbeauche]

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.

[barkas]

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.