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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #36 from Benjamin Gaignard <benjamin.gaignard at gmail.com> ---
(In reply to George Kiagiadakis from comment #35)
> 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.
>

This is false, elements doesn't need to know the allocator type to get access
to the buffer, a call to gst_buffer_map() is working well.
For example a software element like videoconvert is able to use a dmabuf buffer
without knowing that it is a dmabuf memory type. 
If you introduce dmabuf in caps you will split gstreamer elements in two
categories: those who can use dmabuf and the others.

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

That is exactly the slip between elements that I want to avoid, we have to be
able to mix SW and HW elements either we loose all gstreamer flexibility.

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