[Bug 711155] wayland: add wl_drm support to wayland sink

[GStreamer (GNOME Bugzilla)]

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

--- Comment #35 from George Kiagiadakis <george.kiagiadakis at collabora.com> ---
I will agree with Nicolas on this one. We should not advertise the dmabuf
allocator, since it will not work with elements that don't know how to use it.

However, what we *can* advertise, is a subclass of the GstDmabufAllocator that
implements the alloc() vfunc in a certain way. For example, assuming we want to
use those "dumb buffers" to let the software decoder render into them, we could
implement a GstDmabufAllocator subclass that allocates those. This can and
should be advertised *without* the memory:dmabuf caps feature. Afterwards, if
the sink detects that the buffers come from this allocator, it can import them
as dmabuf, otherwise it will fall back to some other method (perhaps copy the
contents into such buffers)

But in the v4l2dec ! somedmabufcapablesink case, the caps should have the
memory:dmabuf feature if dmabuf is in use, because:

1) there is special allocation and handling involved that the elements must
know about (it's a requirement, not optional!)
2) the buffers should not be mmap()-ed and processed, as this is going to slow
down the hardware pipeline (and it is not guaranteed to work anyway). So by
using the special caps features we ensure that no generic software transform
element is going to sit in the middle and ruin everything.



Btw, I have started working towards this split as an experiment:
https://git.collabora.com/cgit/user/gkiagia/gst-plugins-bad.git/log/?h=waylandsink-1.7

My aim is to include dmabuf support in 1.7 if we are all happy with all the
details.

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