[Bug 794946] msdk: vpp: Add dmabuf-export support

[GStreamer (GNOME Bugzilla)]

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

--- Comment #4 from sreerenj <bsreerenj at gmail.com> ---
(In reply to Víctor Manuel Jáquez Leal from comment #3)
> Review of attachment 371145 [details] [review]:
> 
> Hi Sree,
> 
> The problem with this patch is that it is only enabled with the dmabuf caps
> feature, and that caps feature shall be only enabled by upstream if it
> generates dmabuf-based buffers which cannot be mapped onto the userspace.



Upstream usage:
A)
The msdk element negotiates a DMABufCapsFeatures only if upstream supports
it(DMABufcapsfeature in srcpad). Otherwise always negotiate the raw caps.
So v4l2src always use the raw caps for negotiation and we haven't implemented
the supported for this in msdk; should be fixed based on this #794817

B) If the upstream source element supports explicit "DMABufCapsfeatures", let's
force the usage from msdk element by negotiating the capsfeature for this.
Non-mappable, but still better. isn't it?

> For example a sink can efficiently import a dmabuf without negotiating the
> caps feature because it wouldn't support non-user-space-mappable buffers. A
> simple approach would be export dmabuf-based buffers if downstream
> negotiates raw buffers or dmabuf caps feature.


Downstream usage:
Same as upstream usage: msdk element always creates and use its own pool.
Force negotiation of DMABufCapsfeatuers only if downstream supports this
capsfeature since the fds are non-mappable in msdk.

The third patch (to disable passthrough if capsfeature changes), will provide a
way to negotiate pipelines if downstream can't support DMABufCapsfeatures.

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