GNOME Bugzilla – Bug 767022
glimagesink + Python + Qt4 does not work as expected
Last modified: 2018-05-06 13:01:26 UTC
Created attachment 328729 [details] Failing case I have a simple Python application using Qt where I want to embed a glimagesink in a QGraphicsView running on Linux using the x-backend for Gl. Now, it works 100% of the time if I: 1. Set the glimagesink to READY 2. Set the window handle 3. Set the glimagesink to PLAYING But if I do: 1. Leave the glimagesink at NULL 2. Set the window handle 3. set the glimagesink to PLAYING The content don't get embedded, but instead it creates a free-floating window. Speaking to ystreet00 about it on #gstreamer he said it smells like a bug, so attached is two logs of gl*:6, one from the working and one from the failing case.
Created attachment 328730 [details] Working Case
Are these both run with the exact same scenario except for the differences outlined above. What I'm seeing is that the non-working case is going to a much bigger resolution compared to the working one. i.e. 1855x1056 vs 362x221. The log is also much more chatty about X11 events in the non-working case.
(In reply to Matthew Waters (ystreet00) from comment #2) > Are these both run with the exact same scenario except for the differences > outlined above. > > What I'm seeing is that the non-working case is going to a much bigger > resolution compared to the working one. i.e. 1855x1056 vs 362x221. The log > is also much more chatty about X11 events in the non-working case. Yes they are, and the resolution would nicely reflect the fact that the window that got auto-created in the failing case filled my entire screen.
I also discovered that by setting the glimagesink to READY before setting the window-id (my working scenario), this fixes a crash I was having on OSX when using 2 glimagesinks at he same time. 50% of the time it would crash with messages like: gst_gl_context_get_window: assertion 'GST_IS_GL_CONTEXT (context)' failed gst_gl_window_get_context: assertion 'GST_IS_GL_WINDOW (window)' failed So by doing the READY-trick, this problems also goes away completely! It seems to me that the stuff the sink is doing when going from NULL_TO_READY: if (!gst_gl_ensure_element_data (glimage_sink, &glimage_sink->display, &glimage_sink->other_context)) return GST_STATE_CHANGE_FAILURE; gst_gl_display_filter_gl_api (glimage_sink->display, SUPPORTED_GL_APIS); if (!_ensure_gl_setup (glimage_sink)) return GST_STATE_CHANGE_FAILURE; break; Should complete first and not have the external window-handle (glimage_sink->new_window_id) set before or during these operations to have smooth runnings.
NULL->READY is a sync transition so unless you're performing the set_state() in a different thread from the set_window_handle(), you wouldn't be hitting that. Question, does the patch in bug 764947 help this situation?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!