[Bug 792034] implement dmabuf-import negotiation with upstream

[GStreamer (GNOME Bugzilla)]

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

--- Comment #34 from Víctor Manuel Jáquez Leal <vjaquez at igalia.com> ---
(In reply to deshui from comment #31)
> i notice with all above patches, the sinkpad_allocator for plugin always be
> video memory, not dma-buf memory.
> to use the dma-buf import feature, icamsrc have to check the mem type, since
> the memory type is video memory, not dma-buf memory, icamsrc plugin can't
> work will.
> so, would you like to tell me how to make the sinkpad_allocator be dma-buf
> memory?


Since there must two pools, it doesn't matter if plugin->sinkpad_allocator is
vaapi memory based because:

Two pools are offered upstream in propose_allocation(): one produces buffers
with vaapi memory and another with dmabuf memory.

The first one, will set the sinkpad_allocator and sinkpad_buffer_pool in
gstvaapipluginbase.  But the second one is not hold by gstvaapipluginbase, it
is only offered and forgotten. Upstream element could hold it and use it,
otherwise it is unrrefed.

If the dmabuf-memory-based pool is held by upstream element (camerasrc should
be  do this in this case), the source element will use that pool to produce the
output buffers and later they will be imported by vaapi elements as they were
imported before.

Read the patches proposed for v4l2src in bug #793271 for how I proposed to
handle this. The logic, basically is, if the io-mode property in v4l2src in
dmabuf-import, then check for all the offered pool in the query and if it is
there one with DMABUF property, it is hold and use.

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