[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