[Bug 743345] glimagesink: Add support for dmabuf

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=743345
  GStreamer | gst-plugins-bad | unspecified

--- Comment #5 from Daniel Stone <daniel at fooishbar.org> 2015-01-29 14:39:48 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > Finally about the multiple plane case, even if the driver supports it, maybe
> > you need to create one eglimage per plane as done here:
> > https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/raspicam/RaspiTex.h#L162
> > (or here
> > http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/gl/egl/gsteglimagememory.c#n480
> > but not yet tested) . In your code I can see only one call to eglcreateimage,
> > but again I may have missed something.
> 
> This has been discussed as an intermediate. The design of DMABUF import is that
> you can have up to 3 planes attached to a single EGLImage. In this case, the
> texture target is TEXTURE_OES, and color conversion is taken care by the
> driver.

This particular case can be seen in the Mali driver, where importing a YUV
dmabuf and binding it to a textureExternalOES() sampler results in RGB values
being returned.

> Daniel explained all the cases. The intermediate (when multiple planes
> does not work) would be to bind each dmabuf plane to an EGLImage. The unknown
> so far is if the set of DRM format will be sufficient to represent 8 bits/1
> component and 16bits / 2 components formats, or at least if there is a way
> around so the sampler can behave in a way that works with our shaders. This
> will need research, and is mostly an optimization for driver that only do
> single plane per EGLImage.

DRM formats are perfectly fine for that. The format specifies all the planes
(e.g. NV12 is one single-byte component in plane 0 and two one-byte components
at half-width/half-height in plane 1), and each plane has its own stride and
offset specifier. This bit is totally fine.

What's missing though is decent EGLImage API for the multi-plane case. Creating
multiple EGLImages is effectively lying by the formats (e.g. picking R or RG),
and might hit various limitations within the driver. But it's the best choice,
given that if we create a composite EGLImage representing all planes, we don't
have a good way to bind that to multiple samplers and do our own colour
conversion. Wayland currently implements this by the EGL_WAYLAND_PLANE_WL
attrib to eglCreateImageKHR, which lets you specify the full image information
up-front, but also specify which plane you'd like to be sampling from when
bound to a texture unit.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.