[Bug 776927] vaapi: plugins: accept GLMemory buffers from upstream

[GStreamer (GNOME Bugzilla)]

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

Víctor Manuel Jáquez Leal <vjaquez at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ystreet00 at gmail.com

--- Comment #8 from Víctor Manuel Jáquez Leal <vjaquez at igalia.com> ---
(In reply to Matt Fischer from comment #7)
> Certainly the best case would be if we can export a GLMemory on all
> platforms, so that the functionality can always be depended on.  I imagine
> there is probably some way to do this with GLX, I just don't know GLX well
> enough to know for sure.  If somebody who understood it better could comment
> on whether there's a way to do it, that would be very helpful.

In deed. In the case of GLX, (again) IIUC, it would need to dump the texture's
pixels into a pixmap and then copy it into a system's memory GstMemory. It
won't be zero-copy.

Which brings me to another approach to this functionality: the element
gldownload.

That element downloads a GstGLMemory into a system's memory based GstMemory.
Which is normally the case without zero-copy.

We could extend this functionality to the case where the GstGLImage is EGL, and
EGL_MESA_image_dma_buf_export is available, to generate a GstDmaBufMemory,
which could be imported by gstreamer-vaapi as is.

What do you think Matthew??

> 
> For the EGL case, the path that's available is to wrap the texture in an
> EGLImage.  That image can then be exported either to a DRM buffer using the
> MESA_drm_image extension, or to a dmabuf using the MESA_image_dma_buf_export
> extension.  Either of these can then be imported to a VASurface by making a
> buffer proxy out of them.  I chose to do it via the DRM buffer route because
> that's the method used by the gst_vaapi_surface_new_with_egl_image()
> function which has already been implemented.  In principle I think that
> could just as easily be done using dmabuf instead, but I didn't see any
> reason to change what had already been written since it seems to work.  How
> would you like to see this patch proceed?
> 
> Also, do you have any comments on the chroma_type issue I mentioned above? 
> That would still need to be resolved regardless of what technique is used to
> do the actual buffer importing.

IIUC, with the approach above this wouldn't be necessary, since this
information is provided by EGL_MESA_image_dma_buf_export.

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