[Bug 755072] vaapi: expose memory:DMABuf capsfeature

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=755072

--- Comment #15 from Julien Isorce <julien.isorce at gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #14)
> maybe memory:DMABuf is only needed when downstream can import
> DMABuf and upstream produce non-mappable DMABuf ?(for DRM purpose
> apparently).
> 

* fail to map:

This case part of 1- in https://bugzilla.gnome.org/show_bug.cgi?id=759358#c7
"If producer fails to map then it adds the caps feature"

Indeed that could be the case for secure dmabuf, i.e. when using
"smaf_set_secure" see:
https://git.linaro.org/people/benjamin.gaignard/libsmaf.git/blob/HEAD:/lib/libsmaf.h#l35
. Which could be used in conjunction to a TEE (Trusted Execution Environment
(Also see
https://www.phoronix.com/scan.php?page=news_item&px=SMAF-v5-DMA-BUF-SPD and
https://wiki.linaro.org/WorkingGroups/Security/OP-TEE)

In gstreamer-vaapi one would need to add VA_SURFACE_EXTBUF_DESC_PROTECTED when
creating the surface that is going to be exported as dmabuf. This would tell
the vaapi backend to call "smaf_set_secure".


* choice between pushing buffers with meta:GstVideoGLTextureUploadMeta and
pushing dmabuf:

In gst_vaapi_plugin_base_decide_allocation, if has_texture_upload_meta is true
(i.e. downstream supports meta:GstVideoGLTextureUploadMeta) then you would
decide to go for dmabuf if the gstglcontext is of type GST_GL_CONTEXT_TYPE_EGL
and gst_gl_check_extension ("EGL_EXT_image_dma_buf_import", ctx_egl->egl_exts)
returns true; (then try to map is through vaMapBuffer, if it fails add DMABuf
caps feature is supported by downstream)
In short, if egl then prefer dmabuf over meta. The reason is because the later
requires to keep a handle on the downstrean GstGLContext which is more error
prone (see gst_vaapi_display_egl_set_gl_context (GstGLContext...); ).
Other reason is that dmabuf allows to be transfered to another process
(decoding in on process and rendering in another process like it is done in
ChromiumGStreamerBackend).

That would make pushing dmabuf only a very particular case but as Nicolas said:
"As of now, only glupload implements DMABuf in a usable way".

Also between 2 vaapi gst elements I would always do memory:VASurface so no
dmabuf at all.

Actually I can try to add that logic in my branch
https://github.com/CapOM/gstreamer-vaapi/commits/dmabuf_caps_feature which
currently does not supports to pushing dmabuf whithout caps feature.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.