<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> Thanks! > I also believe that for Nvidia docker to work, the Nvidia driver version > both inside and outside of the docker image must match exactly. That caused me a lot of pain a while ago, but it turns out you only have to install the driver on the host, and then the container will use the host driver, so that's not it. I checked the differences between the gstglconfig.h files. 18.04 has #define GST_GL_HAVE_WINDOW_X11 1 #define GST_GL_HAVE_PLATFORM_GLX 1 whereas on 20.04 both of those are false (0) and #define GST_GL_HAVE_WINDOW_WAYLAND 1 But my host system isn't using Wayland... (time passes) Found it! Turns out it was missing libx11-xcb-dev for the x11-xcb dependency. I was installing libxcb1-dev but apparently that's not all you need on the newer Ubuntu. Thanks Matthew! Michiel <div class="moz-cite-prefix">On 25-07-2022 05:27, Matthew Waters wrote: </div> <blockquote type="cite" cite="mid:233815b6-992d-aeb2-0e6c-28aecfbab17e@gmail.com"> <pre class="moz-quote-pre" wrap="">There are dependencies for GStreamer's OpenGL that are specific to X11 and GLX, yes. GST_DEBUG=3,gl*:7 is a good start for why something may not be working however you would need to look at e.g. gstglconfig.h to see if Gstreamer's OpenGL was successfully built with X11/ (GLX or EGL) support. I also believe that for Nvidia docker to work, the Nvidia driver version both inside and outside of the docker image must match exactly. Cheers -Matt On 24/7/22 19:23, Michiel Konstapel via gstreamer-devel wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">I've worked around it by using xvimagesink instead of glimagesink, but I've been trying to narrow this down. It does not appear to be the gstreamer version but the environment. My previous message was mistaken: it used to be Ubuntu 18.04 and the new version is 20.04. I'm not sure I'm on the right track but this seems relevant: I am building and running gstreamer inside Docker containers based on the nvidia/cuda images. When I build/run inside nvidia/cuda:10.2-cudnn7-devel (Ubuntu 18.04) then gst-launch-1.0 videotestsrc ! glimagesink says Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0"; And it shows a window. However, on the nvidia/cuda:11.6.2-cudnn8-devel-ubuntu20.04 base image, it says Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayEGL\)\ gldisplayegl0"; and it runs, but doesn't show a window. However, xvimagesink works (shows a window) and f.e. glmark2 from inside the container also shows a window - so X11 appears to be available. I've tried to force it: GST_GL_PLATFORM=egl GST_GL_WINDOW=x11 gst-launch-1.0 -v videotestsrc ! glimagesink But that returns: (gst-launch-1.0:29): GStreamer-GL-CRITICAL **: 11:16:45.500: gst_gl_display_egl_from_gl_display: assertion 'native_display != 0' failed ERROR: from element /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink: Failed to create EGLDisplay from native display Additional debug info: ../subprojects/gst-plugins-base/ext/gl/gstglimagesink.c(1101): _ensure_gl_setup (): /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink Am I missing some kind of dependency that will let gstreamer create a GL X11 window? I am setting the DISPLAY environment variable to the same as the host's and binding .Xauthority into the container. Kind regards, Michiel On 18-07-2022 10:38, Michiel Konstapel wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">After updating from gstreamer from 1.18.3 to 1.20.3 (and Ubuntu from 20.04 to 22.04) my pipeline no longer works: nvdec gstnvdec.c:1770:gst_nvdec_check_cuda_device_from_context: CUDA call failed: CUDA_ERROR_INVALID_GRAPHICS_CONTEXT, invalid OpenGL or DirectX context nvdec gstnvdec.c:1822:gst_nvdec_ensure_gl_context:<nvh264dec0> Current OpenGL context is not CUDA-compatible nvdec gstnvdec.c:646:gst_nvdec_negotiate:<nvh264dec0> OpenGL context is not CUDA-compatible, fallback to system memory (Then negotiation fails because downstream expects memory:GLMemory) However, this only happens when there is a glimagesink in the pipeline. If I take that out, then apparently nvh264dec gets a context it likes and all is well. This gst-launch pipeline works, and prints helpful messages indicating both get different, suitable contexts? gst-launch-1.0 v4l2src device=/dev/video0 ! h264parse ! nvh264dec ! "video/x-raw(memory:GLMemory)" ! glimagesink Setting pipeline to PAUSED ... error: XDG_RUNTIME_DIR not set in the environment. Pipeline is live and does not need PREROLL ... Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayEGL\)\ gldisplayegl0"; Got context from element 'nvh264dec0': gst.cuda.context=context, gst.cuda.context=(GstCudaContext)"\(GstCudaContext\)\ cudacontext0", cuda-device-id=(int)0; Pipeline is PREROLLED ... Setting pipeline to PLAYING ... Any clue on how to fix this, or where to start debugging? Thanks in advance, Michiel </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> </pre> </blockquote> </body> </html>