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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #50 from Benjamin Gaignard <benjamin.gaignard at gmail.com> ---
(In reply to Julien Isorce from comment #48)
> (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.
> 
v4l2 decoder/encoder/transform code is here:
https://git.linaro.org/people/benjamin.gaignard/gst-plugins-v4l2.git

and you are right decide_allocation function check and select the allocator
attached to the query like this for example:
https://git.linaro.org/people/benjamin.gaignard/gst-plugins-v4l2.git/blob/HEAD:/gst/v4l2dec/gstv4l2dec.c#l469

> Just to understand, are in the case dec/import -> export/sink or dec/export
> -> import/sink ? (It seems to be the first case)
> 
yes it is the first case but the second could works also.

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

Yes selecting the allocator need to be done in propose/decide query sequence.

> 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 one element can only deal with dmabuf memory type and if this allocator
isn't available in decide_allocation function it should just failed.
If you add it into the caps you duplicate them for each allocator type.

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

As you have said before you can deduce what type of memory to use in
propose/decide allocation no need of caps here. 

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