gstreamer: v4l2videodec plugin

[Stanimir Varbanov]

cc: mesa-dev ML

On 04/28/2016 02:33 PM, Stanimir Varbanov wrote:
> On 04/15/2016 07:09 PM, Nicolas Dufresne wrote:
>> Le vendredi 15 avril 2016 à 11:58 -0400, Rob Clark a écrit :
>>> The issue is probably the YUV format, which we cannot really deal
>>> with
>>> properly in gallium..  it's a similar issue to multi-planer even if
>>> it
>>> is in a single buffer.
>>>
>>> The best way to handle this would be to import the same dmabuf fd
>>> twice, with appropriate offsets, to create one GL_RED eglimage for Y
>>> and one GL_RG eglimage for UV, and then combine them in shader in a
>>> similar way to how you'd handle separate Y and UV planes..
>>
>> That's the strategy we use in GStreamer, as very few GL stack support
>> implicit color conversions. For that to work you need to implement the
>> "offset" field in winsys_handle, that was added recently, and make sure
>> you have R8 and RG88 support (usually this is just mapping).
> 
> Thanks,
> 
> OK, I have made the relevant changes in Mesa and now I have image but
> the U and V components are swapped (the format is NV12, the UV plane is
> at the same buffer but at offset). Digging further and tracing gstreamer
> with apitrace I'm observing something weird.
> 
> The gst import dmabuf with following call:
> 
> eglCreateImageKHR(dpy = 0x7fa8013030, ctx = NULL, target =
> EGL_LINUX_DMA_BUF_EXT, buffer = NULL, attrib_list = {EGL_WIDTH, 640,
> EGL_HEIGHT, 360, EGL_LINUX_DRM_FOURCC_EXT, 943215175,
> EGL_DMA_BUF_PLANE0_FD_EXT, 29, EGL_DMA_BUF_PLANE0_OFFSET_EXT, 942080,
> EGL_DMA_BUF_PLANE0_PITCH_EXT, 1280, EGL_NONE}) = 0x7f980027d0
> 
> the fourcc format is DRM_FORMAT_GR88 (943215175 decimal).
> 
> after that:
> 
> glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_RG8,
> width = 640, height = 360, border = 0, format = GL_RG, type =
> GL_UNSIGNED_BYTE, pixels = NULL)
> 
> and finally on the fragment shader we have:
> 
> yuv.x=texture2D(Ytex, texcoord * tex_scale0).r;
> yuv.yz=texture2D(UVtex, texcoord * tex_scale1).rg;
> 
> I was expecting to see DRM_FORMAT_RG88 / GL_RG and shader sampling
> y <- r
> z <- g
> 
> or DRM_FORMAT_GR88 / GL_RG and shader sampling
> y <- g
> z <- r
> 
> Also, browsing the code in Mesa for Intel i965 dri driver I found where
> the __DRI_IMAGE_FORMAT_GR88 becomes MESA_FORMAT_R8G8_UNORM [1].
> 
> So I'm wondering is that intensional?
> 
> Depending on the answer I should make the same in the Gallium dri2 in
> dri2_from_dma_bufs().
>