gstreamer: v4l2videodec plugin

[Stanimir Varbanov]

Hi Nicolas,

On 04/11/2016 07:25 PM, Nicolas Dufresne wrote:
> Le lundi 11 avril 2016 à 15:11 +0300, Stanimir Varbanov a écrit :
>> adding gstreamer-devel
>>
>> On 04/11/2016 03:03 PM, Stanimir Varbanov wrote:
>>>
>>> Hi,
>>>
>>> I'm working on QCOM v4l2 video decoder/encoder driver and in order
>>> to
>>> test its functionalities I'm using gstreamer v4l2videodec plugin. I
>>> am
>>> able to use the v4l2videodec plugin with MMAP, now I want to try
>>> the
>>> dmabuf export from v4l2 and import dmabuf buffers to glimagesink. I
>>> upgraded gst to 1.7.91 so that I have the dmabuf support in
>>> glimagesink.
>>> Mesa version is 11.1.2.
> 
> I'm very happy to see this report. So far, we only had report that this
> element works on Freescale IMX.6 (CODA) and Exynos 4/5.

In this context, I would be very happy to see v4l2videoenc merged soon :)

> 
>>>
>>> I'm using the following pipeline:
>>>
>>> GST_GL_PLATFORM=egl GST_GL_API=gles2 gst-launch-1.0 $GSTDEBUG
>>> $GSTFILESRC ! qtdemux name=m m.video_0 ! h264parse ! v4l2video32dec
>>> capture-io-mode=dmabuf ! glimagesink
>>>
>>> I stalled on this error:
>>>
>>> eglimagememory
>>> gsteglimagememory.c:473:gst_egl_image_memory_from_dmabuf:<eglimagea
>>> llocator0>
>>> eglCreateImage failed: EGL_BAD_MATCH
>>>
>>> which in Mesa is:
>>>
>>> libEGL debug: EGL user error 0x3009 (EGL_BAD_MATCH) in
>>> dri2_create_image_khr_texture
>>>
>>> Do someone know how the dmabuf import is tested when the support
>>> has
>>> been added to glimagesink? Or some pointers how to continue with
>>> debugging?
> 
> So far the DMABuf support in glimagesink has been tested on Intel/Mesa
> and libMALI. There is work in progress in Gallium/Mesa, but until
> recently there was no support for offset in imported buffer, which
> would result in BAD_MATCH error. I cannot guaranty this is the exact
> reason here, BAD_MATCH is used for a very wide variety of reason in
> those extensions. The right place to dig into this issue would be
> through the Mesa list and/or Mesa code. Find out what is missing for
> you driver in Mesa and then I may help you further.

I came down to these conditions

https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/dri/dri2.c?h=11.2#n1063

but I don't know how this is related. The gstreamer
(gst_egl_image_memory_from_dmabuf) doesn't set this "level" so it will
be zero.

> 
> For the reference, the importation strategy we use in GStreamer has
> been inspired of Kodi (xmbc). It consist of importing each YUV plane
> seperatly using R8 and RG88 textures and doing the color conversion
> using shaders. Though, if the frame is allocated as a single DMABuf,
> this requires using offset to access the frame data, and that support

Yep that is my case, the driver capture buffers has one plain, hence one
dmabuf will be exported per buffer.

> had only been recently added in Gallium base code and in Radeon driver
> recently. I don't know if Freedreno, VC4 have that, and I know nouveau
> don't.

Rob, do we need to add something in Freedreno Gallium driver to handle
dmabuf import?

-- 
regards,
Stan