[Bug 794817] msdk: Add Dmabuf Import support in encoder and vpp elements

[GStreamer (GNOME Bugzilla)]

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

--- Comment #16 from sreerenj <bsreerenj at gmail.com> ---
(In reply to Nicolas Dufresne (ndufresne) from comment #15)
> Just to recap our IRC discussion, V4L2 Kernel API does not any API that
> really match this. There is ways that user space could tell it's preferred
> stride, with guaranty it will be used. UVC driver does not implement that
> (even though it's doable). Downstream, in every cases, should be ready to
> copy (fallback path) if the incoming alignment or stride does not match it's
> own requirement.


Thank you for the details, it is unfortunate that we can't do the zero-copy
here.
But interestingly it is possible with v4l2+gstreamer-vaapi+intel-vaapi-driver
where gstreamer-vaapi + intel-vaapi-driver is happy to take whatever upstream
is providing. This is not the case with the new media-driver.:
Here is the bug: 
https://github.com/intel/media-driver/issues/169

What I can think of is a work-around:
1: By default msdk elements check for the padding/size restrictions of incoming
buffers from v4l2src and do the copy. The code is already there, needs to add
some sanity check.

2: We can still make media-driver work with this by fooling it, just tell it
that the size of memory is large enough :( This works in basic test cases, but
I don't know when it is going to fail. So maybe put this path under a property
which requires explicit enablement if the user really wants to experiment with
it. I believe it worth a shot since gstreamer-vaapi+ intel-vaapi-driver works
like this for a while by without checking the padding restrictions.

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