After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794946 - msdk: vpp: Add dmabuf-export support
msdk: vpp: Add dmabuf-export support
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal enhancement
: 1.15.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 789886
 
 
Reported: 2018-04-03 18:36 UTC by sreerenj
Modified: 2018-04-30 19:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add dmabuf-export support using CapsFeatures (8.67 KB, patch)
2018-04-19 22:57 UTC, sreerenj
rejected Details | Review
msdkvpp: Disable passthrough if memory capsfeature changes (2.22 KB, patch)
2018-04-24 00:22 UTC, sreerenj
rejected Details | Review

Description sreerenj 2018-04-03 18:36:52 UTC
MSDK decoders are supporting dmabuf, but no support in vpp element.
Add dmabuf support in msdkvpp element too.
Comment 1 sreerenj 2018-04-19 22:57:02 UTC
Created attachment 371145 [details] [review]
Add dmabuf-export support using CapsFeatures
Comment 2 sreerenj 2018-04-24 00:22:04 UTC
Created attachment 371306 [details] [review]
msdkvpp: Disable passthrough if memory capsfeature changes
Comment 3 Víctor Manuel Jáquez Leal 2018-04-24 09:56:20 UTC
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.

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.
Comment 4 sreerenj 2018-04-24 19:23:14 UTC
(In reply to Víctor Manuel Jáquez Leal from comment #3)
> Review of attachment 371145 [details] [review] [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.
Comment 5 sreerenj 2018-04-30 19:41:23 UTC
Review of attachment 371145 [details] [review]:

I will push a rebased version. But again only supports dmabuf through capsfeatures for now.
Comment 6 sreerenj 2018-04-30 19:42:13 UTC
Review of attachment 371306 [details] [review]:

Rejecting, A rebased version has been pushed.
Comment 7 sreerenj 2018-04-30 19:43:14 UTC
Pushed: 
Commit1: ef6e186801fe664e5c22281f0a5d6f98176b3607
Commit2: e1a90f1ec998619e1b5321112e95e0d9593ab1a7