NVIDIA To Create Protocol For VDPAU

[_txf_]

I'm not sure I understand. Does VDPAU and XvBA actually render anything? If it's anything like DXVA, you still need a renderer. For example, DXVA does the decoding, OpenGL or DX7-Overlay shows you the actual picture. So you would use a renderer that supports vsync in this case (like gl).

Is that not the case with VDPAU/XvBA? If not, then whoever designed the thing wasn't thinking, I'd say.

Actually, DXVA acceleration is tied to the renderer (DX9). DXVA2 introduced in vista is not but AFAIK you can only use EVR to render (due to drm and stuff I guess).

For VDPAU the situation is the same as DXVA. You need to use the vdpau renderer to display video, this creates problems for things like subtitles (mplayer works beautifully tho). I'm not sure if the renderer is required for technical reasons but everything else has to be done in VDPAU else you loose things like bitstream decoding (plus video data has to be copied back and forward from cpu to gpu instead of remaining in the gpu).

VDPAU does use vsync and it works fine when not using compositing. As soon as you use compositing you either turn on vsync in the compositor which ruins smoothness or you suffer video tearing.

[bridgman]

All of the decode APIs offer separate functions for decode and render (aka presentation). Some APIs allow you to intercept the decoded result and feed to something like OpenGL, others do not.

[RealNC]

When XvBA suffers from the same problem (very bad quality because of missing vsync) as fglrx's xv then you can put it in the dustbin.

I'm not sure I understand. Does VDPAU and XvBA actually render anything? If it's anything like DXVA, you still need a renderer. For example, DXVA does the decoding, OpenGL or DX7-Overlay shows you the actual picture. So you would use a renderer that supports vsync in this case (like gl).

Is that not the case with VDPAU/XvBA? If not, then whoever designed the thing wasn't thinking, I'd say.

[greg]

Actually since both VDPAU and XvBA can work as VA API backends, all you'd in theory have to do is create appropriate wrappers (AMD would have to offer their own for their XvBA), add VA API support in video players (yes, you video player developers, stop caressing VDPAU and get to work to add the support for VA API ) and we're done. ^^

OTOH, why not implement XvBA and VA-API backends for VDPAU? VDPAU certainly has the best application support.

[Kano]

When XvBA suffers from the same problem (very bad quality because of missing vsync) as fglrx's xv then you can put it in the dustbin.

[nanonyme]

AMD is developing XvBA, but it is uninteresting because it is only for their fglrx drivers and I think closed??.. >please correct me if im wrong<

Actually since both VDPAU and XvBA can work as VA API backends, all you'd in theory have to do is create appropriate wrappers (AMD would have to offer their own for their XvBA), add VA API support in video players (yes, you video player developers, stop caressing VDPAU and get to work to add the support for VA API ) and we're done. ^^
After that it doesn't matter which video acceleration API drivers implement, it Just Works, given there's a wrapper from VA API to the API they use.

[Kjella]

how many video APIs do we actually have for Linux (Xorg to be more precise)?????

It's complicated because the graphics hardware *can* do many of the parts of a rendering process.

Resize, color conversion, frame flips, OSD, compositing and decoding. Decoding also depends on which codec, and it can be either with fixed function hardware or on shaders. It can be full decoding or just GPU-assisted decoding. Many options lead to many APIs, or one very big API.

Anything other than plain X/DirectFB, and trust me you don't want that, is using the graphics hardware in some way. It's just not on a linear path from little to more, it's branching out in different directions. For example XvMC only matters if you play MPEG2 video, nothing else.

[jscurtu]

how many video APIs do we actually have for Linux (Xorg to be more precise)?????

its this by NVIDIA, Xvsomething, Vaapi, i think AMD has its own that will (is??) ported to linux and probably some more

Sure there are a few, like Xv and others ... but there is nothing close to the acceleration and quality to nvidia's vpdau so that makes it for Linux very important..

AMD is developing XvBA, but it is uninteresting because it is only for their fglrx drivers and I think closed??.. >please correct me if im wrong<

[89c51]

Competition and different approaches are good for Linux and OSS in general. It's true that there are quite a good number of implementations around now that does the same thing.

i disagree

we dont need a billion APIs, libraries or apps that do the same thing bad

the user needs one that does what its supposed to do really well


this approach (multiple project aiming the same thing) is the Plague of
Open Source

[thefirstm]

Competition and different approaches are good for Linux and OSS in general. It's true that there are quite a good number of implementations around now that does the same thing. IMHO Nvidia has proven that VDPAU is rather mature and has proven this with so many projects adopting it. It would be interesting to see if this could become the OpenGL for video playback. Imagine if this could be ported/implemented on other platforms aswell.

I hope you are right about VDPAU becoming the OGL for video playback. I don't see any reason why it shouldn't be, since both ends of the standard are open and quite a few media players already support it.