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

[GStreamer (GNOME Bugzilla)]

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

Matt Fischer <mattfischer84 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #343748|0                           |1
        is obsolete|                            |

--- Comment #17 from Matt Fischer <mattfischer84 at gmail.com> ---
Created attachment 343926
  --> https://bugzilla.gnome.org/attachment.cgi?id=343926&action=edit
Patch to add dmabuf export to gldownload

Here's an updated patch that cleans up the implementation a bit.  It checks
whether the context is EGL before attempting an export.  If the context does
not possess the appropriate extensions, then the function will fail gracefully.

This works well for downloading an OpenGL buffer into a dmabuf, which is then
picked up by the vaapi plugins correctly.  However, on my system, the dmabuf is
not mappable, so any other use of gldownload (i.e. waylandsink) doesn't work,
because the buffer cannot be mapped into a regular CPU buffer.  So this
approach is definitely not sufficient by itself, because we don't know when to
export and when not to export.

One answer would be to negotiate the memory:DMABuf feature, and only attempt
the export when that feature was negotiated.  For that to work, the VAAPI
plugins would need to add memory:DMABuf as a possible input caps feature.  I
don't know enough about the history of memory:DMABuf to know whether or not
that will be an option.  Some of the discussion in
https://bugzilla.gnome.org/show_bug.cgi?id=755072 made it seem like something
that can't be used here.  Can you provide some context?

Another possible option would be to invent a new meta that we could attach to
the buffer.  So the main buffer would remain as it is, but dmabuf-aware
elements could grab the meta and use it to perform the export.  This would
require adding new code into vaapipluginbase to make use of it, though, and
would add more complication to what seems to already be a very complicated
issue, so maybe it's not a good option.

Do you have any suggestions on how I might proceed with this patch?  Thanks for
all of your help so far.

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