Google's Linux Video Acceleration API: VAVDA

[ChrisXY]

VAVDA = V(a)A(pi)V(ideo)D(ecode)A(cceleration).

Video Acceleration API Video Decode Acceleration.

[Awesomeness]

The way I read it, this isn't a new API, it's just a wrapper to integrate hardware decoding into Chrome.

So what? The standard is still OpenMAX but somehow desktop-oriented vendors are unwilling to support it. (It is widely supported on other platforms such as smartphones and even the PS3.)
Neither VAAPI, nor VDPAU, nor the AMD one is an actual standard. Only OpenMAX is.

[FireBurn]

So what? The standard is still OpenMAX but somehow desktop-oriented vendors are unwilling to support it. (It is widely supported on other platforms such as smartphones and even the PS3.)
Neither VAAPI, nor VDPAU, nor the AMD one is an actual standard. Only OpenMAX is.

It depends on your definition of standard. Technically a standard is the one everyone uses. OpenMAX is advocated by Khronos but I think it came too late to the party (which is a shame)

[devguy]

Have any of you been able to get gasping acelleration using fglrx and the xvba wrapper on chrome 21 with pepperflash? Remember, you have to run with the --enable-vaapi flag.

[Gusar]

9J

So what? The standard is still OpenMAX

I can respond in the same way: So what? VDPAU and vaapi are here and they work. It makes much more sense for Google to support one of these instead of something that's not used by any X driver. Standard or not.

[Nasenbaer]

9JI can respond in the same way: So what? VDPAU and vaapi are here and they work. It makes much more sense for Google to support one of these instead of something that's not used by any X driver. Standard or not.

For Google this is true as VAVDA seems to be no new API.
But for the AMD, NVIDIA and Intel it is not true. An system independent API like OpenMAX would allow to use the same code for various platforms. Media-Software programmers could find this a nice thing. Nowadays your have to use the DXVA-API for Windows and VA-API + VDPAU for Linux and i.e. OpenMAX for a Smartphone. A portable solution like OpenGL ES would be much better.

[elmariachi]

anyone tried this? how can I be sure that I'm using vaapi after passing the --enable-vaapi flag to chromium?

[Awesomeness]

9JI can respond in the same way: So what? VDPAU and vaapi are here and they work.

VAAPI does not work on my NVidia system, just as VDPAU does not work on Intel systems. AMD's API works on neither of the first two, just as the first two do not work with AMD systems.
I'm aware of wrapper libraries but those never worked for me. So no video acceleration with VLC (only supporting VAAPI) on my NVidia system.

OpenMAX is far more widespread than any of those three proprietary APIs (I'm using the original meaning of “proprietary” here, not the FSF meaning of “proprietary” = “closed source”). Some Linux software (such as GStreamer) even support OpenMAX. The only major roadblock are the drivers because AMD, Intel, and NVidia all suffer from NIH syndrome in this case.

[Kano]

Your example is wrong. the vdpau-video wrapper works with vlc (and with mplayer vaapi) but crashes with xbmc (but there you can use vdpau natively). It is easy to verify that vaapi is used, the output is similar to that what you get when you execute vainfo (only the debug lines).

[Nasenbaer]

Additionally VA-API support is provided by Splitted Desktop's VA-API<-->XvBA wrapper library. But this solution doesn't always work flawlessly. And the native XvBA support came too late and has again its own API. But I agree that a common API (at least like DXVA under Windows) is required. Look at Adobe Flash - it does not support all APIs. And this applies to most other programs, too.