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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #39 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
(In reply to Benjamin Gaignard from comment #36)
> 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.

For existing V4L2 driver I agree. On the graphic side, I have been told that
there is low interest in adding mmap support to their DMABUF implementation
(dumb buffer are the exception) and the memory itself may be on slow-path for
read operations. Also, I believe if you add this idea of protected memory to
V4L2, you will no longer be able to map the DMABUF no ?

Obviously, if dumb buffers are opt-in, it should work just fine in with
memory:SystemMemory. The idea of memory:dmabuf is to ensure that we can
negotiate a pipeline where the memory will always be DMABUF, preventing element
that would cause a transition to memory:SystemMemory from being used. We
basically want a way to have no surprises, hence no compromise.

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

For that, I believe it's good habit to opt-in DMABUF by looking at incoming
memory type rather then caps (and implement fallbacks) if possible. That's what
the suggested wayland sink wrapper bin would implement (wrapper which is
*suggested*, not mandatory for merging dmabuf work). When the fallback back is
trivial, it would make sense to avoid this split, but at least right now, the
fallback is quite complicated in Wayland protocol. Note that for most decoder
(and that's a bug in GST) the output buffers of the decoder need to be
read-only as otherwise you endup messing the decoder observation. That means,
if you do something in SW you need to copy, and you may not have DMABUF in the
end.

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