wayland: Add VA-API support

[giselher]

This issues is for tracking the problems and current state of vaapi support in the wayland backend.

Different ways to add vaapi support are:

• OpenGL Interop support in gl_wayland
• Using vaapi in vo_wayland
• Adding a wayland backend to vo_vaapi

To avoid problems with the OSD wight might have to use the wl_subsurface extension.

Opinions and Ideas are welcome.

Resources

• va_wayland.h
• va_egl.h
• eglCreatePbufferFromClientBuffer
• EGL_KHR_image_base
• wl_subcompositor & wl_subsurface specs

[giselher]

Here is how gstreamer uses vaapi under wayland: https://gitorious.org/vaapi/gstreamer-vaapi/source/4a650e8e624a87c5808462d34d18f741eea1a5f9:gst-libs/gst/vaapi/gstvaapiwindow_wayland.c They don't use OpenGL interop.

It is a bit complicated how they do it, but I get the basic idea.

[axeldavy]

Unless you really want to use an OpenGL specific functionality, I don't advise to use it here. It could induce a copy, and would prevent you to use in the future the wl_buffer_queue extension (not designed yet), which like the X present extension would allow to target a specific frame at the screen (to synchronize audio/video better).

One of the major goal of wl_subsurface was to enable having a YUV surface with non-YUV surfaces around for window decorations, buttons, etc. It looks like vaapi can put the OSD directly in the frame, but I expect it to be less efficient (I imagine YUV would be less performant for storing the OSD). Moreover the OSD will likely need to be updated at a much slower rate than the video, and wl_subsurface mechanism allows you to avoid unneccesary redrawing of the OSD.

I think the best GPU/CPU usage can be found with using vaapi in vo_wayland and handling the OSD with wl_subsurface: there would be no useless redrawing/copy. The only copy being the compositing done at the end by the compositor. Much less than the copies done with the glx backend for example: copy of the vaapi buffer to GLX, GLX/DRI2 copying to the front buffer, and an additional copy if there is an X compositor.

[ghost]

Unless you really want to use an OpenGL specific functionality, I don't advise to use it here. It could induce a copy,

Gwenole told me that supposedly the EGL interop does not require a copy.

and would prevent you to use in the future the wl_buffer_queue extension (not designed yet), which like the X present extension would allow to target a specific frame at the screen (to synchronize audio/video better).

Why not allow this with OpenGL? It would be much more useful.

One of the major goal of wl_subsurface was to enable having a YUV surface with non-YUV surfaces around for window decorations, buttons, etc.

Frankly, I don't know why they even bother with YUV surfaces. It likely will make it harder to display video correctly (such as getting control over the YUV color conversion matrix, certain post processing, etc.).

Moreover the OSD will likely need to be updated at a much slower rate than the video

It can potentially change every frame, such as when displaying the OSC (on screen controller, which renders something GUI-like using the OSD mechanism, and updates every frame because the position bar can or does change every frame), or when displaying typical insane .ass subtitles.

Anyway, I agree that it might be worth improving vo_wayland, however VAAPI is completely Intel specific and does not work anywhere else, so I have my doubts. With EGL interop, it might at least help on X too (as opposed to using GLX interop), and the GL interop mechanism is already relatively isolated code-wise.

[giselher]

Anyway, I agree that it might be worth improving vo_wayland, however VAAPI is completely Intel specific and does not work anywhere else, so I have my doubts. With EGL interop, it might at least help on X too (as opposed to using GLX interop), and the GL interop mechanism is already relatively isolated code-wise.

I like to keep vo_wayland as platform-independent as possible. Also the EGL Interop seems to be the easiest to accomplish short time. In the far future we could split the x11 specific parts out of vo_vaapi and add a wayland backend.

After that we would end up with 3 different video outputs for wayland:

• vo_wayland: Shared Memory
• vo_opengl: EGL/OpenGL + optional vaapi decoding
• vo_vaapi: With a wayland Backend

I was thinking about adding wl_subsurface support quite some time ago. I actually had a test-implementation which was not working very well. But it is still on my list of things to add.

[axeldavy]

I think you'll meet issues with trying to use vaapi with EGL. . vaapi has an EGL backend, but it's not implemented. . getting to use the wl_buffer in EGL might be buggy, since it's code that's not widely tested yet (with YUV).

[giselher]

I think you'll meet issues with trying to use vaapi with EGL. . vaapi has an EGL backend, but it's not implemented. . getting to use the wl_buffer in EGL might be buggy, since it's code that's not widely tested yet (with YUV).

If the EGL backend is not implement than there is nothing we can do here, except wait for them to implement it.

I will add wayland support to vo_vaapi which then will use the normal wl_buffer stuff, but It might take some time.

[giselher]

@axeldavy I have created two new branches • wayland_subsurface where I use subsurfaces for the subtiles and OSC • wayland_viewport where I use wl_viewport for scaling the window

There is still 1 Problem: The results of wl_viewport are atrocious at best. Horrible scaling. I don't know if this my fault, but this not how I imagined it to look like.

EDIT: What I actually wanted to say was that I am halfway done with a working vaapi backend in wayland.

[ghost]

Does it use nearest neightbour scaling?

[giselher]

It doesn't say which algorithm they use for scaling in the documentation, but it looks like nearest neighbor scaling.

[ppaalanen]

I am reluctant to define any specific scaling methods in the protocol. At most we might define general hints like "high-quality" and "fast"... but would you ever pick "fast"? The idea is that the compositor does its best with the resources it has, with the compositor user preferences it has. If it looks crap, blame the compositor.

The point is that we want to allow all hardware overlay scalers, and their scaling algorithms might be secret and patented. Or maybe they are crap, but also the only way to have performant scaling on a platform.

In Weston's case, I assume down-scaling a lot will look bad, because the GL-renderer does not use mipmapping or any fancy scaling techniques (yet?). You should be getting GL_LINEAR. If you get GL_NEAREST instead, that could be filed as a bug.

[giselher]

Hi @ppaalanen

If it looks crap, blame the compositor.

I didn't want to sound rude, I was just surprised at the scaling quality, especially for a protocol which purpose is to scale.

I really like to use it, but if we can't influence the quality of scaling then it can only be optional for user who rather have fast scaling. Hopefully there is a (easy) way to scale the image via vaapi post processing (I am no vaapi expert).

[ppaalanen]

@giselher no offence taken :-)

I don't think it would be feasible to have a way to affect the compositor's scaling from a random client, that would be the job for the compositor preferences. But what we could do is to help you decide whether you want to use wl_viewport or not. Can you think of anything that we could write in the protocol that would help you make the decision? I still think compositor's scaling should be adequate always, so it should be a case of improving the compositor instead.

Of course the obvious thing is that if the compositor does not advertise wl_scaler, it cannot scale. I'm not sure it would make sense to say that if the compositor cannot scale with high quality, it should not expose wl_scaler at all. Where to draw the line?

Should a player simply have a checkbox for "use system scaling"? shrug

Or would you perhaps like to help Weston and implement some better GLSL scaling algorithm? ;-)

If you have good suggestions here, send them to the Wayland mailing list, please. I don't think the wl_scaler proposal got too much feedback when it was a RFC. Personally I cannot come up with anything more useful.

[ghost]

Or would you perhaps like to help Weston and implement some better GLSL scaling algorithm? ;-)

We have our own OpenGL scaler in this player, but for some mindbending reason we can't use it.

[ghost]

PS: the reason being the hw decoding clusterfuck. I'd very much prefer if we could just use vdpau with OpenGL interop, instead of half-baken Intel-only crap with nearest neighbour scaling (wow).

[giselher]

Or would you perhaps like to help Weston and implement some better GLSL scaling algorithm? ;-)

We have our own OpenGL scaler in this player, but for some mindbending reason we can't use it.

PS: the reason being the hw decoding clusterfuck. I'd very much prefer if we could just use vdpau with OpenGL interop, instead of half-baken Intel-only crap with nearest neighbour scaling (wow).

If the EGL Interop stuff was actually implemented we could use mpv own OpenGL scaler, but at the moment I only get NOT_IMPLEMENTED messages when using vaGetEGLClientBufferFromSurface

[giselher]

Also I just checked again and It actually is not nearest neighbor scaling, but still looks not good compared to lanczos3 (which I use for watching videos) or mitchell in my opinion.

[giselher]

@giselher no offence taken :-)

I don't think it would be feasible to have a way to affect the compositor's scaling from a random client, that would be the job for the compositor preferences. But what we could do is to help you decide whether you want to use wl_viewport or not. Can you think of anything that we could write in the protocol that would help you make the decision? I still think compositor's scaling should be adequate always, so it should be a case of improving the compositor instead.

Of course the obvious thing is that if the compositor does not advertise wl_scaler, it cannot scale. I'm not sure it would make sense to say that if the compositor cannot scale with high quality, it should not expose wl_scaler at all. Where to draw the line?

Should a player simply have a checkbox for "use system scaling"? shrug

It would be very easy to just have a user option for system scaling. Which is what I will do once wl_scaler is in the standard wayland protocol.

Or would you perhaps like to help Weston and implement some better GLSL scaling algorithm? ;-)

I am quite the OpenGL noob and just knew enough to provide the EGL stuff for the opengl backend, but I always wanted to get into OpenGL and GLSL more. Maybe I can find some time to look into it. But I can't promise anything.

If you have good suggestions here, send them to the Wayland mailing list, please. I don't think the wl_scaler proposal got too much feedback when it was a RFC. Personally I cannot come up with anything more useful.

I think the protocol in itself looks quite good and I hope that It will soon be part of the wayland protocol. Personally I can't think of much how to improve the protocol [except for scaling].

[ghost]

Maybe someone could check whether this lib contains useful code: https://github.com/01org/libyami