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

[mirv]

sorry...but what? when did people go on about giving the sdk only to oems?
You're twisting things a little. The target was embedded devices. They're not the same as a PC.
And I'm not saying that the oss drivers are superior - or even that they ever will be when compared to fglrx drivers when it comes to 3d (chances are, they won't be).
And if you've had that many dead cards, try treating your hardware better - my original radeon8500 is still running perfectly fine.

[Kano]

Well first gen bluray/hd players where stripped down pcs. If you call that embedded fine. Basically thats standard pc hardware - the lib we talk about is /usr/lib/libAMDXvBA.so.1.0 which appeared about 1 year ago in the official fglrx driver packages. That was the time it was introduced for the EMBEDDED systems you like to talk about. As the driver is available for x86 it could not be that much different than what you have got. Maybe not the full gfx card range, but as ATI has got shared code with Win drivers and Linux it is really hard to believe that this is so complicated. Basically it is just another abstraction level to that what they use for DXVA. The same you could say about VDPAU. You can be sure the code behind that is shared for the biggest part. What happend now is that they did not provide the xvba sdk (which is of course there for months/years, otherwise xvba-video would not exist) compared to the vdpau specification which are public. The xvba-wrapper only works with opengl output which does not allow osd. When you hear that the pcom variant which only works with the sdk would allow osd/subtitles then you got a completely crippeled video accelleration for free that can easyly lock up the pc. compared to vdpau thats EXTREMELY poor.

[mirv]

I can see you've never dealt with embedded stuff. If nothing else (and seeing as you love to describe bluray players as a stripped down pc, care to point to any sites that document the internals of one?) developers are aware of the hardware and software combo, which makes quite a difference.
An orange compared to vdpau is "extremely poor". An orange really can't play videos that well. But then, an orange isn't being given as direct competition to vdpau. Same for xvba - that's a community forced opinion on something amd never stated.
To be clear: I do think vdpau and nvidia drivers are better for video card accelerated playback under linux for home users at current. But let's turn that around a bit - how's nvidia shaping up against amd in the target audience for xvba?

[bridgman]

@droidhacker

are you a clone of bridgman who always wants to tell us how great the idea of oss drivers are which are way behind fglrx for 3d? if you want working video accelleration NOW you can not chose the card freely, the vendor is determined that it will not be ATI.

Clone ? Seems unlikely -- I'm probably old enough to be droidhacker's father

[jrch2k8]

I can see you've never dealt with embedded stuff. If nothing else (and seeing as you love to describe bluray players as a stripped down pc, care to point to any sites that document the internals of one?) developers are aware of the hardware and software combo, which makes quite a difference.
An orange compared to vdpau is "extremely poor". An orange really can't play videos that well. But then, an orange isn't being given as direct competition to vdpau. Same for xvba - that's a community forced opinion on something amd never stated.
To be clear: I do think vdpau and nvidia drivers are better for video card accelerated playback under linux for home users at current. But let's turn that around a bit - how's nvidia shaping up against amd in the target audience for xvba?

well someone can define the audience for xvba? cuz well vdpau is able to play bluray in very trashy hardware like netbooks or even atom system with really very very low end cards + is stable + is really well accepted in many project from mplayer to vlc + in my test with an 8800gt mobile is almost exactly as the windows performance with dxva + you even can use a nice set of filter accelerated (still some missing ofc).

i dont doubt that maybe is some very ultra extremely weird cases, using maybe some ultra specific test case, with heardware coming straigth from hell (like arm or cell processor) xvba wins (i assume, cuz xvba is almost like a myth for anyone using linux for now at least).

the truth is vdpau is here since long and is kicking asses, and well i lost any hope of seeing xvba working in my desktop, cuz i suspect that if ever get released officially it will require a bunch of releases to get something usable enough to compete with vdpau.

so the only way i see amd competing here is through opencl in the OSS driver when the tracker get functional enough, and based in the current state of the oss driver code quality i think opencl video accel is gonna be awesome too

[bridgman]

XvBA was developed for "sealed box" applications with proprietary player code, like DVD players, set top boxes, and digital TVs, where there might be a Linux system inside but no end-user access to that system. That's what we mean by "embedded".

We are also making efforts to provide decode acceleration support for "semi-embedded" products (a made-up term for "closed but not sealed" boxes using open source player apps where the decode API needs to be visible, eg the Splitted Desktop products), leveraging some of the same code but not all of it.

I don't believe we have actually released anything for consumer PC users at this point; the work-in-process code has merely been "discovered" as a consequence of public availability of Gwenole's excellent work on the VA-API-to-XvBA bridge, and some users are making use of it today.

[Kano]

@mirv

amd + embedded is most likely something x86 compatible. for nvidia embedded is partly ion maybe but more likely tegra - as used by zune hd. There are for example samsung tvs with rs690 which do not show a picture with oss nor fglrx 9-3 drivers and newer samsung tvs with hd3200 (which show something). Most likely this was the target plattform.

[droidhacker]

@droidhacker

are you a clone of bridgman who always wants to tell us how great the idea of oss drivers are which are way behind fglrx for 3d? if you want working video accelleration NOW you can not chose the card freely, the vendor is determined that it will not be ATI.

Clone?

I'll take this as your request to know where I'm coming from.... so I'll tell you. MOST of the time-consuming, hair-pulling, sticky, ugly problems I've had with anything in ANY operating system have been directly a result of black box things that nobody can understand (and probably not even fully the people who wrote it). Also to make matters worse, EVERY TIME I have ever faces one of these blobs, they have *always* given me a headache, and BAR NONE, these problems just magically go away when the box gets cracked open. I'll tell you this -- the FIRST OS install that went (for me) without a single hitch was F12, which also happened to be the very first OS I've EVER installed that didn't need SOME closed source black box ugly mess of a blob in order to attain *acceptable* function.

I'll tell you... right now I can live without video acceleration. It would be nice, but I'm definitely not willing to deal with the black boxed blobs in order to accomplish that - I'd rather max out all the cores on my CPU and end up with a bit of a choppiness. And based on the development to date and what everyone has said, I have a very nice picture in my mind about where things will be *very very soon*.

[droidhacker]

Clone ? Seems unlikely -- I'm probably old enough to be droidhacker's father

Hmm... so just how old ARE you then old man?

[bridgman]

Well... let's just say that I had been programming for a while when the Intel 8080 came out...

... but then again I started pretty young. I do remember trading in the teletype for a DecWriter and being able to program a lot faster