GNOME Bugzilla – Bug 781170
glimagesink: displays no window on macOS
Last modified: 2017-04-24 13:57:26 UTC
Created attachment 349661 [details] GST_DEBUG log Using GStreamer 1.11.90 (binary release) on macOS 10.12.4. Testing with "gst-launch-1.0 videotestsrc ! glimagesink". Pipeline seems running but no window displays video. When running with "gst-launch-1.0 -v videotestsrc ! fpsdisplaysink". The pipeline still runs and spills out statistics on successful rendered frames. Reported frame rate seems ok. Still no output window though. I do have some success with GstVideoOverlay in my application though. So it seems it just won't create its own window when there is no window handle provided from outside. Attached is a GST_DEBUG=glimagesink:6 log file.
Same as bug #781137 ?
Could be. Maybe related, "osxvideosink" is not working either. I _think_ the pipeline is stuck in prerolling and no window opens. Do these elements share the same Cocoa window handling code?
No, and osxvideosink also did not change since ages. It must be a problem elsewhere, e.g. in the GLib Cocoa changes. (So likely both bugs are the same) Can you get a backtrace of where it hangs?
I could not figure out to get decent traces with GDB on this system. So here is function trace of the streaming thread with LLDB. I hope it is enough to make assumptions: ``` (lldb) thread select 6 * thread #6, name = 'videotestsrc0:src' frame #0: 0x00007fffb9e6abf2 libsystem_kernel.dylib`__psynch_cvwait + 10 libsystem_kernel.dylib`__psynch_cvwait: -> 0x7fffb9e6abf2 <+10>: jae 0x7fffb9e6abfc ; <+20> 0x7fffb9e6abf4 <+12>: movq %rax, %rdi 0x7fffb9e6abf7 <+15>: jmp 0x7fffb9e63caf ; cerror_nocancel 0x7fffb9e6abfc <+20>: retq (lldb) bt * thread #6, name = 'videotestsrc0:src' * frame #0: 0x00007fffb9e6abf2 libsystem_kernel.dylib`__psynch_cvwait + 10 frame #1: 0x00007fffb9f5686e libsystem_pthread.dylib`_pthread_cond_wait + 712 frame #2: 0x00007fffa5ffbd2b Foundation`-[NSCondition wait] + 240 frame #3: 0x00007fffa5ffade8 Foundation`-[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] + 904 frame #4: 0x00007fffa607b8c7 Foundation`-[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:] + 119 frame #5: 0x00000001004e5228 libgstosxvideosink.so`gst_osx_video_sink_setcaps + 392 frame #6: 0x000000010048d106 libgstbase-1.0.0.dylib`gst_base_sink_default_event + 1014 frame #7: 0x000000010048dda0 libgstbase-1.0.0.dylib`gst_base_sink_event + 176 frame #8: 0x00000001000e8d05 libgstreamer-1.0.0.dylib`gst_pad_send_event_unchecked + 1173 frame #9: 0x00000001000e8126 libgstreamer-1.0.0.dylib`gst_pad_push_event_unchecked + 710 frame #10: 0x00000001000eb0ab libgstreamer-1.0.0.dylib`push_sticky + 203 frame #11: 0x00000001000e3986 libgstreamer-1.0.0.dylib`events_foreach + 150 frame #12: 0x00000001000e488b libgstreamer-1.0.0.dylib`check_sticky + 91 frame #13: 0x00000001000e7bb6 libgstreamer-1.0.0.dylib`gst_pad_push_event + 518 frame #14: 0x00000001004961ef libgstbase-1.0.0.dylib`gst_base_src_set_caps + 191 frame #15: 0x0000000100498120 libgstbase-1.0.0.dylib`gst_base_src_default_negotiate + 368 frame #16: 0x000000010049a322 libgstbase-1.0.0.dylib`gst_base_src_loop + 194 frame #17: 0x000000010011505b libgstreamer-1.0.0.dylib`gst_task_func + 251 frame #18: 0x00000001002c14a2 libglib-2.0.0.dylib`g_thread_pool_thread_proxy + 50 frame #19: 0x00000001002c050a libglib-2.0.0.dylib`g_thread_proxy + 90 frame #20: 0x00007fffb9f559af libsystem_pthread.dylib`_pthread_body + 180 frame #21: 0x00007fffb9f558fb libsystem_pthread.dylib`_pthread_start + 286 frame #22: 0x00007fffb9f55101 libsystem_pthread.dylib`thread_start + 13 ```
I need a backtrace of all threads, but otherwise that's good
Right, here is a new trace: (lldb) bt all * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x00007fffb9e6aeb6 libsystem_kernel.dylib`__select + 10 frame #1: 0x00000001002a7491 libglib-2.0.0.dylib`g_poll + 433 frame #2: 0x00000001002983c4 libglib-2.0.0.dylib`g_main_context_iterate + 340 frame #3: 0x000000010029873f libglib-2.0.0.dylib`g_main_loop_run + 223 frame #4: 0x00000001000b0b8b libgstreamer-1.0.0.dylib`gst_bus_poll + 283 frame #5: 0x000000010000505d gst-launch-1.0`event_loop + 3485 frame #6: 0x0000000100003ba8 gst-launch-1.0`main + 1768 frame #7: 0x00007fffb9d3c235 libdyld.dylib`start + 1 frame #8: 0x00007fffb9d3c235 libdyld.dylib`start + 1 thread #2 frame #0: 0x00007fffb9e6b44e libsystem_kernel.dylib`__workq_kernreturn + 10 frame #1: 0x00007fffb9f55502 libsystem_pthread.dylib`_pthread_wqthread + 1023 frame #2: 0x00007fffb9f550f1 libsystem_pthread.dylib`start_wqthread + 13 thread #3 frame #0: 0x00007fffb9e6b44e libsystem_kernel.dylib`__workq_kernreturn + 10 frame #1: 0x00007fffb9f55695 libsystem_pthread.dylib`_pthread_wqthread + 1426 frame #2: 0x00007fffb9f550f1 libsystem_pthread.dylib`start_wqthread + 13 thread #4 frame #0: 0x00007fffb9e6b44e libsystem_kernel.dylib`__workq_kernreturn + 10 frame #1: 0x00007fffb9f55695 libsystem_pthread.dylib`_pthread_wqthread + 1426 frame #2: 0x00007fffb9f550f1 libsystem_pthread.dylib`start_wqthread + 13 thread #6, name = 'videotestsrc0:src' frame #0: 0x00007fffb9e6abf2 libsystem_kernel.dylib`__psynch_cvwait + 10 frame #1: 0x00007fffb9f5686e libsystem_pthread.dylib`_pthread_cond_wait + 712 frame #2: 0x00007fffa5ffbd2b Foundation`-[NSCondition wait] + 240 frame #3: 0x00007fffa5ffade8 Foundation`-[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] + 904 frame #4: 0x00007fffa607b8c7 Foundation`-[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:] + 119 frame #5: 0x00000001004e5228 libgstosxvideosink.so`gst_osx_video_sink_setcaps + 392 frame #6: 0x000000010048d106 libgstbase-1.0.0.dylib`gst_base_sink_default_event + 1014 frame #7: 0x000000010048dda0 libgstbase-1.0.0.dylib`gst_base_sink_event + 176 frame #8: 0x00000001000e8d05 libgstreamer-1.0.0.dylib`gst_pad_send_event_unchecked + 1173 frame #9: 0x00000001000e8126 libgstreamer-1.0.0.dylib`gst_pad_push_event_unchecked + 710 frame #10: 0x00000001000eb0ab libgstreamer-1.0.0.dylib`push_sticky + 203 frame #11: 0x00000001000e3986 libgstreamer-1.0.0.dylib`events_foreach + 150 frame #12: 0x00000001000e488b libgstreamer-1.0.0.dylib`check_sticky + 91 frame #13: 0x00000001000e7bb6 libgstreamer-1.0.0.dylib`gst_pad_push_event + 518 frame #14: 0x00000001004961ef libgstbase-1.0.0.dylib`gst_base_src_set_caps + 191 frame #15: 0x0000000100498120 libgstbase-1.0.0.dylib`gst_base_src_default_negotiate + 368 frame #16: 0x000000010049a322 libgstbase-1.0.0.dylib`gst_base_src_loop + 194 frame #17: 0x000000010011505b libgstreamer-1.0.0.dylib`gst_task_func + 251 frame #18: 0x00000001002c14a2 libglib-2.0.0.dylib`g_thread_pool_thread_proxy + 50 frame #19: 0x00000001002c050a libglib-2.0.0.dylib`g_thread_proxy + 90 frame #20: 0x00007fffb9f559af libsystem_pthread.dylib`_pthread_body + 180 frame #21: 0x00007fffb9f558fb libsystem_pthread.dylib`_pthread_start + 286 frame #22: 0x00007fffb9f55101 libsystem_pthread.dylib`thread_start + 13 thread #7, name = 'gmain' frame #0: 0x00007fffb9e6aeb6 libsystem_kernel.dylib`__select + 10 frame #1: 0x00000001002a7491 libglib-2.0.0.dylib`g_poll + 433 frame #2: 0x00000001002983c4 libglib-2.0.0.dylib`g_main_context_iterate + 340 frame #3: 0x00000001002984a4 libglib-2.0.0.dylib`g_main_context_iteration + 100 frame #4: 0x0000000100299c46 libglib-2.0.0.dylib`glib_worker_main + 54 frame #5: 0x00000001002c050a libglib-2.0.0.dylib`g_thread_proxy + 90 frame #6: 0x00007fffb9f559af libsystem_pthread.dylib`_pthread_body + 180 frame #7: 0x00007fffb9f558fb libsystem_pthread.dylib`_pthread_start + 286 frame #8: 0x00007fffb9f55101 libsystem_pthread.dylib`thread_start + 13
You have to use "thread apply all bt". But this looks very much like what I guessed
In lldb it seems to be "bt all" indeed. That's actually multiple threads there, I failed to read the output before. Thanks!
Yeah basically what happens here is that the sink waits for the main thread to do something... but the main thread is stuck in the GLib event loop instead of doing the Cocoa one. This patch should've solved that, and did so in the past: https://cgit.freedesktop.org/gstreamer/cerbero/tree/recipes/glib/0015-Implementation-of-Cocoa-event-loop-integration-in-GM.patch It must've been broken in one way or another during a glib update.
*** Bug 781137 has been marked as a duplicate of this bug. ***
Fixed in master: Module: cerbero Branch: master Commit: 5cf083525e9f7bc0955db8d4a7e4a04a5b9f0b8c URL: http://cgit.freedesktop.org/gstreamer/cerbero/commit/?id=5cf083525e9f7bc0955db8d4a7e4a04a5b9f0b8c Author: Jan Schmidt <jan@centricular.com> Date: Mon Apr 24 22:30:35 2017 +1000 glib: Fix up Cocoa main loop integration patch for 2.50.3 The patch was silently applying with fuzz, inserting a block in the wrong place.