[Bug 743345] glimagesink: Add support for dmabuf

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=743345
  GStreamer | gst-plugins-bad | unspecified

--- Comment #10 from Matthew Waters <ystreet00 at gmail.com> 2015-02-08 04:13:35 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > Same reasons you add any caps feature.
> > 
> > 1. Simplicity - you know exactly what you're getting.
> 
> There is real use case where we can't guaranty that all buffers will be DMABUF.
> A copied buffer to system memory might sneek in (it's a known way to speed up
> reclaim when it's strictly required). If it's in the caps, that would be
> illegal. So far, my take on supporting DMABUF is that it should first be
> considered system memory, and the rest is optimization on top.

This is very much like GstGLMemory.  It can also be considered system memory
with optimization on top for GL specific handling.

The check for GL will also allow dmabuf/sysmem features in the dmabuf uploader.
 But if you provide a non-dmabuf memory.  glupload will fallback to raw upload
and stay there for subsequent buffers until new caps are set.  If you can't
guarantee dmabuf for every buffer, then you should not export dmabuf caps
features.

> > 3. Selection - You may want to select a specific memory type to connect to
> > appsink for example.
> 
> There is no cost of exporting DMABUF. Neither upstream (downstream pool) or
> dowstream (upstream pool) really need to be aware.

Uh, bufferpools need to allocate dmabuf which means they definitely need to be
aware of it.  Also, how does one select between GLMemory/EGLImage/dmabuf/upload
meta without caps features for element links that provide multiple ways of
producing GL data along with multiple ways one can map the memory as sysmem
(GLMemory/dmabuf)?  And what if the app wants too choose?

> The case where DMABUF is strictly required is extremely rare.

But it still exists.

> > 5. Mapping - the feature might not support mapping to sysmem (doesn't seem to
> > apply here)
> 
> Indeed.
> 
> The only case where this caps feature is needed, is when you have a disjoint
> set of color formats to support system memory and dmabuf. And for this is
> reason, I think the caps feature will be required. But I don't think it should
> make any difference for GL. There is no documented way (without having a DMABUF
> in hand) to trial and error and figure-out if a format is supported or not.
> Also, failing importation does not mean the format isn't supported. So in
> general, if the buffer is a dmabuf we should try something, hence the dynamic
> check.

For GL, if the resolved video format from the dmabuf is a different format to
the guessed output caps (from the dmabuf uploader), then the glupload element
will reconfigure with the new output caps and we go from there.

Also, it is possible for GL to export dma-bufs
http://airlied.livejournal.com/78704.html

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.