[Bug 755072] vaapi: expose memory:DMABuf capsfeature

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Mon Jun 26 11:05:14 UTC 2017


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

--- Comment #83 from Julien Isorce <julien.isorce at gmail.com> ---
(In reply to Víctor Manuel Jáquez Leal from comment #82)
> (In reply to Julien Isorce from comment #81)
> > 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.
> 

Ah ok I see but it still does not fit with: vaapih264dec ! capsfilter
caps="video/x-raw(memory:SystemMemory)" ! videoscale ! "video/x-raw, width=320,
height=240" ! glimagesink

In general, it should just not push any dmabuf as memory:SystemMemory if it is
not mappable.
Your last week set of patches does not break anything compared to the state
without them. It is just a note how it should be. Maybe we should add a TODO in
the code for now. We might need to wait for Scott's meta to address this TODO
properly.

> > 
> > 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.
> 

Let me clarify, with current upstream gstreamer-vaapi vaapih264dec ! capsfilter
caps="video/x-raw(memory:SystemMemory); video/x-raw(memory:DMABuf)" ! fakesink
chooses the caps feature directly despite system being first.
I think that one is a bug and should not be a TODO like the other problem
mentioned on top.

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


More information about the gstreamer-bugs mailing list