[Bug 755072] vaapi: expose memory:DMABuf capsfeature

[GStreamer (GNOME Bugzilla)]

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

--- Comment #85 from Víctor Manuel Jáquez Leal <vjaquez at igalia.com> ---
(In reply to Julien Isorce from comment #83)

> 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

This is another bug: glimagesink requests more buffers than those that
vaapidecode can output, so you're facing a deadlock.

If you add a vaapipostproc after the decoder, it works.

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

We have to re-think how gst_vaapi_find_preferred_caps_feature() .. also, that's
another bug :(

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