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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #32 from Benjamin Gaignard <benjamin.gaignard at gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #31)
> (In reply to Benjamin Gaignard from comment #29)
> > I don't think that having a specific sink for dmabuf protocol could work
> > because dmabuf usage is negotiated in the pool not in the caps so you won't
> > be able to select the good sink.
> > Else I don't understand the need to introduced a bin with videoconvert,
> > wl_dmabuf will not expose unsupported formats and I don't believe that
> > drivers will support a format in shm and not in dmabuf (or reverse).
> 
> I have been asked to explicitly negotiated dmabuf memory type through caps
> features, see:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=745459
> 
> When that is fixed, V4L2 element that can export or import DMABUF will be
> able to consider downstream capabilities and configure the queue accordingly.

I have answer in this thread why I believe that putting dmabuf in cap is a bad
idea.
The way of how use dmabuf allocator has been discuss while introduce it
mainline: https://bugzilla.gnome.org/show_bug.cgi?id=703659

> 
> Caps features are often used to accept different sets of color formats
> depending of the memory type. At the moment, there is cases I've seen where
> the list of formats do vary. Though, right now it will only vary because
> there is no method to retrieve this list (yet).

If you look at v4l2 or drm frameworks the list of formats should not vary
depending of memory format. In the both frameworks it is only a flag
(VB2_DMABUF or DRIVER_PRIME) that is set to indicate dmabuf usage but without
any impact on supported formats.

> 
> My biggest need for the split is what Daniel said. I do start to agree that
> considering the dumb/drm allocator would make that specialised sink more
> useful, potentially allowing a SW decoder to be used and upstream
> importation assuming we can fulfill any kind of alignment. Though, on
> platform where SW decoder can be considered, it is likely that glimagesink
> (and widget specific friends) will perform better. We need not to forget the
> waylanddmabufsink is not the only upcoming way to render DMABUF with
> acceleration. It's a way that allow the compositor to make smarter decisions
> (e.g. choosing between GL and HW layer is an example).
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=743345
If the shm allocator remain the first in pool's allocator list it will be
selected by default so SW decoder will continue to work as usual. If you want
that your SW decoder use dmabuf you will modify it to select dmabuf allocation
at pool negotiation time and take care of alignment.
It works very well since a while for us like this.

Selecting the better sink (wayland or gl) for your platform is not link dmabuf
but to the compositor you want to use.

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