[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 #9 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> 2015-02-08 03:09:57 UTC ---
(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.

> 2. Extensibility - possiblity to add extra required fields to the caps.

Not sure what use with DMABUF, but fair. The only extra I'm thinking of would
be if the kernel ever expose the allocated memory type. But meanwhile, we
should assume not being able to import DMABUF is expected, and fallback to
using DMABUF as if it was normal memory.

> 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. The case where DMABUF is
strictly required is extremely rare. The fact is that the main exporter for
DMABUF (v4l2 drivers) will always produce DMABUF in a very near feature.
Because there is not cost, and allow nice optimization in many elements (like
inter process elements). They don't need to know in advenced that the buffers
will have FD to share with another process. In fact, I think it's a important
feature if FD and non FD base buffer can be aliased (e.g. payloading). But that
falls outside of GL I can agree.

> 4. Negotiation - element can limit pools, allocators and meta to those that
> support the specific caps feature.  Can also prioritise element links with caps
> features in decodebin/playbin.

Not sure about this one.

> 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.

-- 
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.