[Bug 755072] vaapi: expose memory:DMABuf capsfeature

[GStreamer (GNOME Bugzilla)]

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

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

No deadlock here and I am trying with intel vaapi driver. If you use
vaapipostproc in pipeline above it will make videoscale to switch to
passthrough mode so you need this change:

vaapih264dec ! vaapipostproc ! capsfilter
caps="video/x-raw(memory:SystemMemory), width=640, height=480" ! videoscale !
"video/x-raw, width=320, height=240" ! glimagesink

Sorry my bad all good, indeed it is not RW mappable but it is RO mappable so
the videoscale succeeds to map and do its job. But since it is tiled, the
output frames are wrong. Indeed GST_VAAPI_SURFACE_ALLOC_FLAG_LINEAR_STORAGE is
not set. If I set it then output is correct.
So no bug here. And again it will be improved with Scott's meta.

> 
> > > > 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 :(

Ack. Will also depends on Nicolas's replies. The current behavior might be
alread y ok in fact. Depends on what we want. I was just confused with what
commits messages say as opposed to what is effectively implemented.

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