[Bug 755072] vaapi: expose memory:DMABuf capsfeature

[GStreamer (GNOME Bugzilla)]

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

--- Comment #47 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
(In reply to Julien Isorce from comment #46)
> 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.

This is intentional in GstGL. Drivers must support DMABuf with offsets.

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

The problem is that the cache would keep growing even if the dmabuf are
released. Worst, the FD might get reused and then the cache becomes incoherent.

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