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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #48 from Julien Isorce <julien.isorce at gmail.com> ---
(In reply to Benjamin Gaignard from comment #46)
> That is exactly what we do when adding the allocator in pool with
> gst_query_add_allocation_param() function.

Ah right, I also missed Sebastian's first review.

Could you attach the patches for other elements. I guess in their
decide_allocation you check for the existence of the proposed allocator
attached to the query. So that they know if they can produce/handle dmabuf
flow.
Because in the end I think these other patches are the main concern, especially
if it is for gstv4l2 elements.

Just to understand, are in the case dec/import -> export/sink or dec/export ->
import/sink ? (It seems to be the first case)

> 
> That definitively what I expected to have: caps without memory type and
> allocator selection while negotiate buffer pool

Right, I think there are 2 cases about dmabuf buffers: SW+HW buffers in the
same flow and HW buffers. I think the caps feature memory:dmabuf only applies
to the second case. In other words this caps feature does not apply to your
case. So we should not expect you to use memory:dmabuf caps feature in your
patch.

Here is what I suggest to handle the 2 cases:

If we expect the decoder to produce both system and dmabuf memories then the
downstream element only notify dmabuf during propose/decide query sequence
using gst_query_add_allocation_param.
But if you expect you decoder to produce dmabuf only then you additionally set
the caps feature memory:dmabuf in the caps of that query. (And add it to
template caps as well)
If in any case the decoder can only produce exclusively SW or HW buffers then
only the caps feature is needed to deduce what to produce.

All of these to say that we should agree to have memory:dmabuf as a caps
feature defined in gst-plugins-base. And patch gstv4l2 as an example for this
logic described above.

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