<snip> >>>> >>>> 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. That was wrong assumption, the error comes from another Mesa function. I'm not sure still which one dri2_from_dma_bufs() or dri2_create_image_dma_buf(). Will try to rebuild Mesa. -- regards, Stan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
