Vaapi. The ability to add input types to the decoders plugin: GstVideoGLTextureMeta and DMABuf

[Alexander Yanin]

> Adding memory:DMABuf caps feature in vaapipostproc sink pad is not
> implemented. BUT, dmabuf-based buffers don't need to use that caps feature
> *if they are mappable to user-space*.

> gldownload can pass dmabuf-based buffers without memory:DMABuf caps feature, as
> far as I understand. And vaapipostproc can detect if that buffer is dmabuf-based
> and upload it onto a VA surface (no copy is involved).

> There is no need to duplicate the code in vaapipostroc in the encoders, when you
> can just prepend vaapiproc in the pipeline.

How could gldownload figure out to pass DMABuf instead of raw memory
if the elements negotiated video/x-raw caps? For example, I've tested
this pipeline:

gst-launch-1.0 gltestsrc is-live=true ! glvideomixer ! gldownload !
vaapipostproc ! vaapivp8enc ! webmmux ! filesink location=test.webm

SVG of this pipeline is attached.

It is doubtful that gldownload uses DMABuf in this case.
If I use caps filter with 'memory:DMABuf' specified, negotiation fails.

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.svg
Type: image/svg+xml
Size: 51697 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20180822/fb74e611/attachment-0001.svg>