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

Nicolas Dufresne nicolas at
Wed Aug 22 12:52:38 UTC 2018

Le mer. 22 août 2018 07:26, Víctor Jáquez <vjaquez at> a écrit :

> On Wed, 22 Aug 2018 at 14:03, Alexander Yanin wrote:
> > > I guess you could use glsrcbin or gldownload to convert a GLMemory
> based buffer
> > > (with a texture inside) into a dmabuf-based buffer and vaapipostproc
> would
> > > upload it into a VA surface and then encoding it.
> >
> > In 1.14 vaapipostproc only has 'video/x-raw(memory:VASurface)' and
> > 'video/x-raw' sink pads, so there is no DMAbuf. Was it added in later
> > versions of gstreamer?
> > In case of DMAbuf input, does DMAbuf -> vaapi conversion implies copy
> operation?
> > Is there any sense in adding DMAbuf sink pad directly to vaapi encoder
> > base class?
> 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).

Sorry, atm it requires the caps feature and we have issues there since the
dmabuf are tiled, event though the modifiers aren't set by mesa. The mesa
dmabuf exporter is massively broken, so we'll have to disable this really
soon in libgstgl. It work till around Mesa 1.17, when the tiling and
compression got activated by default for all internal texture backend.

> There is no need to duplicate the code in vaapipostroc in the encoders,
> when you
> can just prepend vaapiproc in the pipeline.
> vmjl
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gstreamer-devel mailing list