Adobe's Flash Video Acceleration On Linux Uses VDPAU

[deanjo]

Or other vendors getting their stuff together. I'd much rather the latter actually. Not too keen on the one-size-fits-all approach.

The last thing needed is a different API for every vender. It serves no purpose.

[Kano]

Well i see no huge problem to use nvidia accelleration via vdpau-video wrapper - just the apps need to be fine tuned ab bit like xbmc. vlc has got only problems with vc1 and ion - but there even on win...

[mlau]

Or other vendors getting their stuff together. I'd much rather the latter actually. Not too keen on the one-size-fits-all approach.

This is why Windows is so much better: Microsoft provides ONE interface spec (DxVA) and driver and player software writers only have to worry about ONE interface (nevermind that DxVA isn't the perfect system).

The current VDPAU/VAAPI/XvBA situation in the linux world is ridiculous: Just pick one and fix it up so that all parties are satisfied instead of having every vendor invent their own.

Personally, I favor VDPAU: a lot of thought has been put into the overall
design, and the developers are responsive to inquiries and suggestions.

[evolution]

Agree and disagree...

This is why Windows is so much better: Microsoft provides ONE interface spec (DxVA) and driver and player software writers only have to worry about ONE interface (nevermind that DxVA isn't the perfect system).

The current VDPAU/VAAPI/XvBA situation in the linux world is ridiculous: Just pick one and fix it up so that all parties are satisfied instead of having every vendor invent their own.

Personally, I favor VDPAU: a lot of thought has been put into the overall
design, and the developers are responsive to inquiries and suggestions.

Yes, I also think the way MS handles driver's APIs is much better.
You just have a single API (DirectX), and if your drivers need to work with Windows, you just need to be complaint with MS API(s) (DirectDraw, Direct3D, DxVA, for instance). In another words, you don't need to create your own APIs, like it happens a lot on Linux (unfortunately).

Personally, I'd prefer an OpenGL-based shader solution to decode videos in HW. OpenGL is a proven technology, and is supported by almost all modern linux drivers. By another side, rival nVidia companies might not like to use rival technologies (VDPAU), so, here I disagree with your PoV. Futhermore, there are also some video decoding features in VDPAU that need PureVideo, and to make VDPAU work in another drivers, it might be needed to reverse-engineer some PureVideo features... (which could lead (although improbable) to lawsuits).

My 2c, cheers!

[deanjo]

Personally, I'd prefer an OpenGL-based shader solution to decode videos in HW. OpenGL is a proven technology, and is supported by almost all modern linux drivers.

Nothing prevents utilizing libvdpau on shader based decoding. There is however potential legal issues by using open shader base decoding for patent laden codecs like h264. A dedicated hardware decoder is licensed with the MPEG-LA , an open software based solution would almost certainly not be licensed. This is why distros can include vdpau decoding but not any open software based h264 decoding libraries.

. Futhermore, there are also some video decoding features in VDPAU that need PureVideo, and to make VDPAU work in another drivers, it might be needed to reverse-engineer some PureVideo features... (which could lead (although improbable) to lawsuits).

Not true. libvdpau is vendor agnostic. What libvdpau, the API is extremely open as to what functions it calls for. It would be on the driver end that one would have to determine how to handle it on their hardware. If they have a hardware solution for that function then they can utilize that otherwise they can use a software solution for it. S3's implementation of vdpau shows this. It doesn not have the same hardware decoding engine as nvidia but it can still use vdpau.

[bwat47]

This is why Windows is so much better: Microsoft provides ONE interface spec (DxVA) and driver and player software writers only have to worry about ONE interface (nevermind that DxVA isn't the perfect system).

The current VDPAU/VAAPI/XvBA situation in the linux world is ridiculous: Just pick one and fix it up so that all parties are satisfied instead of having every vendor invent their own.

Personally, I favor VDPAU: a lot of thought has been put into the overall
design, and the developers are responsive to inquiries and suggestions.

Quote for truth. Fragmentation of important API's like this are really harming linux when it comes to 3rd party software/driver support.

[bwat47]

Quote for truth. Fragmentation of important API's like this are really harming linux when it comes to 3rd party software/driver support.

GOD I HATE THE 1 MINUTE EDIT LIMIT, anyway continues from my last post

Flash really needs to have video accel support on cards outside of nvidia as well, compared to windows the performance is just abysmal to say the least. For example my laptop: 2ghz core2 duo, 4gb ram, 512mb hd2600. Flash absolutely rapes my cpu in linux, 480p youtube video eats ~50% cpu, in windows it uses like 10%. Also playing flash eats so much cpu my entire browser becomes less responsive.

[evolution]

To deanjo:

Adding to my last post, I also prefer to have OpenGL shader HW acceleration instead of libvdpau because these reasons:

1- It'd be easier to allow direct HW decoding of some codecs which (currently) don't have support with libvdpau (such as VP8 or VP3 (for instance, lots of anime movies you watch use it )) using shaders... If you already know OpenGL (shading programming), it's easier to make it work.

2- This is my major reason why I prefer to use OpenGL rather than libvdpau/libva. Both of them are libraries, so they also have the disadvantage of some overhead comparing to use OpenGL shaders directly on hardware... (For me, it's something like the case of using PulseAudio, when we just need for most cases the ALSA library to use our sound HW directly).

That's my personal opinion, OC.
Cheers!

[deanjo]

To deanjo:

Adding to my last post, I also prefer to have OpenGL shader HW acceleration instead of libvdpau because these reasons:

1- It'd be easier to allow direct HW decoding of some codecs which (currently) don't have support with libvdpau (such as VP8 or VP3 (for instance, lots of anime movies you watch use it )) using shaders... If you already know OpenGL (shading programming), it's easier to make it work.

You still can use shaders with vdpau. Nothing is impeding that. VC-1 support for older nvidia cards that did not have 100% VC-1 decoding ability already shows that despite not having a 100% hardware solution playback is still accelerated.

2- This is my major reason why I prefer to use OpenGL rather than libvdpau/libva. Both of them are libraries, so they also have the disadvantage of some overhead comparing to use OpenGL shaders directly on hardware... (For me, it's something like the case of using PulseAudio, when we just need for most cases the ALSA library to use our sound HW directly).

vdpau and Pulse have nothing in common. One is a api the other is a sound server. The "overhead" is next to non-existant in vdpau. You would have near identical load utilizing a pure shaderbase over a vdpau-shaderbase decode.

[deanjo]

Just a couple of graphs here with Shaderbased playback vs vdpau. Test file was a 13.5 Mbit/s h.264 @ 720p on a 1090T based system. Keep in mind that one core @ 100% would show as 16.6% CPU usage on the graph.