[FFmpeg-devel] [PATCH] Add wayland support for VAAPI

Mark Thompson sw at jkqxz.net
Tue Jun 27 19:08:59 EEST 2017


On 27/06/17 13:13, Hardening wrote:
> Le 27/06/2017 à 09:54, Mark Thompson a écrit :
>> On 27/06/17 07:38, David Fort wrote:
>>> Wayland environment became quite popular with gnome 3. This patch adds the ability to
>>> initialize the VAAPI accelerator from a wayland display.
>>
>> Is there some specific use-case which needs this?  The X11 support mainly exists because of old systems (*cough* Intel Media SDK *cough*) which don't support render nodes, and therefore have to connect to a DRM master device - if X11 is running then it has to use the DRI2 authentication ritual to do that.
>>
>> Anything recent should be connecting via the render node, which allows it to be used independently of any other system and has clear control over what hardware you are using on systems with multiple possibilities.
>>
> 
> Hi,
> 
> my final goal is to have a h264 video rendered directly in a surface
> (using ffmpeg as a library).

Note that the hardware decoders are not in general able to render to a surface which can go directly to scanout.  You'll always want some intermediate here - typically this is done with OpenGL (see video players, e.g. mpv), though you can also do it inside VAAPI by using the VPP mechanism.

With ffmpeg + Wayland only, it should be doable by using the decoder along with the scale_vaapi filter (really doing format conversion, though as the name suggests it can scale as well) - allow the decoder to allocate its frames internally, but supply your own VAAPI surfaces as the output of the filter made from the Wayland surfaces using DRM PRIME sharing.

>                              If render nodes surfaces can be displayed
> on the screen then I'm fine with it and forget about that patch.

Yes - surfaces are not distinguished by the context they come from, only by the actual underlying hardware device they exist on and what format they are.

> I did some tests and I had the impression that when the rendering was
> done with a DRI render node, it was slower than when the VADisplay was
> grabbeb from wayland (F25 with gnome3). But it may be just an impression
> or a test bias.

That should be identical.  The mechanism used by Wayland (and X11 DRI2) is to ask the server which DRM device node it should open, receiving a string path and a cookie it return.  It opens the node and authenticates with the cookie if necessary (i.e. if anything more than rendering is required, which it isn't for codec stuff).  (X11 DRI3 is different - that actually gives you a file descriptor to the DRM device directly.)

I'm not really against the patch, but it adds a new Wayland dependency to libavutil which is probably undesirable in general.

Thanks,

- Mark



More information about the ffmpeg-devel mailing list