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

[Nicolas Dufresne]

Le mer. 22 août 2018 08:57, Víctor Jáquez <vjaquez at igalia.com> a écrit :

> On Wed, 22 Aug 2018 at 15:12, Alexander Yanin wrote:
> > > 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:
>
> Indeed, there's now a code path in gldownload to verify if the generated
> buffers
> are mappable.
>
> I just quick hacked gldownload
>
> diff --git a/ext/gl/gstgldownloadelement.c b/ext/gl/gstgldownloadelement.c
> index aefc289ee..429bcb4d2 100644
> --- a/ext/gl/gstgldownloadelement.c
> +++ b/ext/gl/gstgldownloadelement.c
> @@ -137,14 +137,14 @@ gst_gl_download_element_set_caps (GstBaseTransform *
> bt, GstCaps * in_caps,
>    if (gst_caps_features_contains (features,
> GST_CAPS_FEATURE_MEMORY_GL_MEMORY)) {
>      /* do nothing with the buffer */
>  #if GST_GL_HAVE_PLATFORM_EGL && GST_GL_HAVE_DMABUF
> -  } else if (gst_caps_features_contains (features,
> -          GST_CAPS_FEATURE_MEMORY_DMABUF)) {
> +  } else {
>      dl->dmabuf_allocator = gst_dmabuf_allocator_new ();
> -#endif
> -  } else if (gst_caps_features_contains (features,
> -          GST_CAPS_FEATURE_MEMORY_SYSTEM_MEMORY)) {
> +  }
> +#else
> +  } else {
>      dl->do_pbo_transfers = TRUE;
>    }
> +#endif
>
>    return TRUE;
>  }
>
>
> And it seems to work.


VAAPI implements implicit modifiers, pass the same dmabuf to kmssink or
waylandsink, you'll see that it breaks. Implicit modifiers are terrible
idea which breaks so many use case. The dmabuf currently produced by vaapi
Intel driver are only going to render correctly on an Intel GPU, it won't
event work on Intel display because the display requires explicit
modifiers. VAAPI needs to pass or negotiate the modifiers, meanwhile, we
should be really careful with the vaapi dmabufs.


> The other option is to implement in vaapipostproc the negotiation of
> memory:DMABuf caps feature.
>
> vmjl
>
> >
> > 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
>
>
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20180822/509e991a/attachment.html>