[Bug 755072] vaapi: expose memory:DMABuf capsfeature

[GStreamer (GNOME Bugzilla)]

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

--- Comment #82 from Víctor Manuel Jáquez Leal <vjaquez at igalia.com> ---
(In reply to Julien Isorce from comment #81)
> Sure, it is great anyway!
> 
> So I tried and I have a few remarks. For the caps feature did you try with
> glimagesink patch from https://bugzilla.gnome.org/show_bug.cgi?id=774649 ?

No. I did not :S

> 
> Because if I apply that patch, it seems that vaapi does not respect the
> gstglupload caps order/prefs. Indeed vaapih264dec ! glimagesink will
> negotiate the DMABuf caps feature, whereas being ordered after the
> SystemMemory.
> 
> Can also be tested with:
> 
> vaapih264dec ! capsfilter caps="video/x-raw(memory:SystemMemory);
> video/x-raw(memory:DMABuf)" ! glimagesink
> 
> Second remark, here
> https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/tree/gst/vaapi/
> gstvaapipluginbase.c#n611 I would expect to be plugin->srcpad_can_dmabuf
> instead of the !plugin->srcpad_can_dmabuf but actually shouldn't be passing
> TRUE always ? In order to match the commit message
> https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/commit/
> ?id=f578515988ecf6c0ebaf920a94ea43b3fcf5c2a6


IIUC, the issue here is how do we understand plugin->srcpad_can_dmabuf

As I understand it, it means that downstream can "import" dmabuf, so there is
no  need to map them.

As a matter of fact, I'm planning to add a similar mechanism to kmssink to let
know upstream that it can "import" dmabuf.

We should rename that variable to make it clearer.

With these patches, the logic is to try to use dmabuf as a SytemMemory if it is
mappable, because it will be "more standard" rather than the vaapi
mapping/unmapping. 

And yeah, I didn't review the commit log for that commit. My mistake.

> 
> Can be tested with:
> 
> vaapih264dec ! capsfilter caps="video/x-raw(memory:SystemMemory)" !
> glimagesink
> 
> Currently the decoder pushes dmabuf buffers despite being not mappable.

If your are under EGL, yes, it will. But if you are under GLX it won't, because
dmabuf cannot be imported.

> 
> ---- 
> 
> So without caps renegotiation support, which I am fine with it for now
> (again what you did is already a great step further and might be enough
> after all), I would expect that the pipeline:
> 
> vaapih264dec ! capsfilter caps="video/x-raw(memory:SystemMemory);
> video/x-raw(memory:DMABuf)" ! glimagesink 
> 
> would just does not do any dmabuf at all. Because it will try dmabuf without
> caps feature first and map will fail. But since it will not try to
> renegotiate, it will not try to negotiate with the caps feature. So no
> dmabuf which is what I would expect with current commits upstream
> (+gstglupload patch that adds the caps feature)

IMHO that's the correct approach, since memory:SystemMemory works and it is
preferred by the user.

> 
> The only way to do dmabuf with current upstream (+ gstglupload patch that
> adds the caps feature) would be to add a capsfilter:
> 
> vaapih264dec ! capsfilter caps="video/x-raw(memory:DMABuf)" ! glimagesink
> or
> vaapih264dec ! capsfilter caps="video/x-raw(memory:DMABuf);
> video/x-raw(memory:SystemMemory)" ! glimagesink (i.e. changing the order by
> using a caps filter for custom usage for example)
> 
> Which would match what the commit message
> https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/commit/
> ?id=b6863e64b550af8b472eeb35520071ab7cc0d6eb says :)
> 
> Thx !

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