[Bug 755072] vaapi: expose memory:DMABuf capsfeature

[GStreamer (GNOME Bugzilla)]

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

--- Comment #46 from Julien Isorce <julien.isorce at gmail.com> ---
For the rendering problem: I was surprised to see that it uses the same dmabuf
for the 2 distinct EGLImage, so it could have been an issue. Having a second
thought I guess it should not matter and should just work. So probably a bug in
GstGL (or in mesa). I will have a closer look.

But I am also concerned about the fact that GstGL fails to cache the EGLImages
because it uses the GstMemory pointer as a key for the qdata based cache, not
the dma buf number. Indeed with your new approach, gstvaapipluginbase creates a
new GstMemory each time.

1: We could either make the GstGL_cache uses dma buffer numbers as key instead
of the GstMemory pointer. 

2: We could cache these GstMemories somewhere in gstreamer-vaapi, for example
as a qdata of GstVaapiSurface. Or re-using the member "extbuf_proxy" of
GstVaapiSurface, plus having that GstMemory a member of GstVaapiBufferProxy. So
that from the surface we can get always the same proxy and from the proxy
always the same GstMemory.

With option 1 we still do not avoid the "ioctl" call that exports the surface
as a dmabuf (even if it returns the same value each time).
So I will experiment option 2 I think.

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