Comment 33 for bug 1424201

(In reply to Jean-Yves Avenard [:jya] from comment #14)
> (In reply to martin from comment #13)
> VAAPI has an API to map a VAAPI surface to an OpenGL surface, it could then
> be drawn without having to first copy it to software.
> Though, IIRC, Intel was talking about deprecating that API so that you must
> go through the VAAPI framework to draw the surface. If they did that, we
> would have to do the same work as we need for VDPAU

> So for VDPAU, we need a VDPAU compositor. Something that would allow us to
> draw a VDPAU surface into the screen.
> The way VDPAU works typically is that you create an OpenGL surface, assign
> it a colorkey and then tell VDPAU to draw on that color key. That allows to
> draw the VDPAU surface into the OpenGL surface and then render that surface
> on the screen using OpenGL.
> It's similar to your blue screen stuff used on TV and movies.

Ok, thank you for explaining.
So, if I understood correctly, the blocker now is the OpenGL compositor, which is now disabled by default on linux. I guess there are some reasons for that, some issues?
When OpenGL compositor will be working fine, then it could be possible to use VAAPI (using that - maybe in future deprecated - API to map VAAPI surface to OpenGL surface) - that would be the (relatively) easy way, right?

In fact I'm not sure, what VDPAU/VAAPI compositor means - does it mean entire new compositor (like the OpenGL one, which probably still has some issues (guessing from it's not enabled by default)), or is it some "overlay" on OpenGL compositor?
The "entirely new" option would be bad, I'm afraid it would take very long time... It's really a problem on linux, I also experienced lags and dropped frames in some HD videos, so I hope it wouldn't take years to support video HW acceleration.