GNOME Bugzilla – Bug 775970
glimagesink: hang? on windows
Last modified: 2016-12-15 13:16:26 UTC
Created attachment 341801 [details] gst-debug output Starting with GStreamer version 10.0.2 the glimagesink does not show a window. On 10.0.1 it was still working. This is at least the case with default properties, e.g. with the following launch line: C:\Users\skimmer>gst-launch-1.0 --verbose videotestsrc ! glimagesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplay\)\ gldisplay0"; /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0.GstPad:src: caps = video/x-raw, format=(string)RGBA, width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0.GstGhostPad:sink.GstProxyPad:proxypad0: caps = video/x-raw, format=(string)RGBA, width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLUploadElement:gluploadelement0.GstPad:src: caps = video/x-raw(memory:GLMemory), width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, format=(string)RGBA, texture-target=(string)2D /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLColorConvertElement:glcolorconvertelement0.GstPad:src: caps = video/x-raw(memory:GLMemory), width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, format=(string)RGBA, texture-target=(string)2D /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLColorBalance:glcolorbalance0.GstPad:src: caps = video/x-raw(memory:GLMemory), width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, format=(string)RGBA, texture-target=(string)2D /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLImageSink:sink.GstPad:sink: caps = video/x-raw(memory:GLMemory), width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, format=(string)RGBA, texture-target=(string)2D /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLColorBalance:glcolorbalance0.GstPad:sink: caps = video/x-raw(memory:GLMemory), width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, format=(string)RGBA, texture-target=(string)2D /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLColorConvertElement:glcolorconvertelement0.GstPad:sink: caps = video/x-raw(memory:GLMemory), width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, format=(string)RGBA, texture-target=(string)2D /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0/GstGLUploadElement:gluploadelement0.GstPad:sink: caps = video/x-raw, format=(string)RGBA, width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive /GstPipeline:pipeline0/GstGLImageSinkBin:glimagesinkbin0.GstGhostPad:sink: caps = video/x-raw, format=(string)RGBA, width=(int)320, height=(int)240, framerate=(fraction)30/1, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive and then nothing happens A attached also the debug output for --gst-debug=gl*:5
Is this a hang? If so, a backtrace would be very helpful at the point of the hang.
(In reply to Matthew Waters (ystreet00) from comment #1) > Is this a hang? If so, a backtrace would be very helpful at the point of the > hang. I am not sure what you mean by a hang. But the command window is still responsive and the curser is blinking. In an own application version the application is running, just the the window does not show (The element does not go to playing state).
hang = there's no more output/gstreamer does not continue execution anymore. A backtrace of all threads at that point would still be very useful.
This is most likely caused by 782e7af4a6935ebf31555048c3050612ab771944 and the g_source_attach()'s not finding the thread default main context anymore. This should fix your issue. Let me know if it doesn't by reopening this bug. commit f58eb9844051479062f9c4dcb69da46d001625da Author: Matthew Waters <matthew@centricular.com> Date: Thu Dec 15 00:59:45 2016 +1100 gl/window: remove use of main_context_push/pop_thread_default() No-one's using/depending on it (it would have criticalled and not worked) and it's causing more problems than it's solving. Store the GMainContext in the public struct instead for subclasses to optionally use instead of relying on the push/pop state to be correct. https://bugzilla.gnome.org/show_bug.cgi?id=775970 and 1.10 3aaf645c7d16a01b49325367ab8403a73c4d624c