GNOME Bugzilla – Bug 393975
closing x/xvimagesink window crashes gst-launch
Last modified: 2007-05-18 08:23:24 UTC
$ gst-launch-0.10 videotestsrc ! ximagesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock <- now click the X in the popped up window -> X connection to :0.0 broken (explicit kill or server shutdown). The same happens with xvimagesink. This leads to problems in applications, such as gstreamer-properties, who are using the pop-up window. It would be better if the pipeline would go into READY or in some other way behaves decently.
Can't reproduce.. When i close the window gst-launch just exit without this X error message you are describing.
so what happens when you close the window in gstreamer-properties? And does the pipeline go into gst-state-ready like I suggested, i.e. is the app notified of the window closure so it can present said information to the user?
I get such a message (or some other Xlib-message) about one out of two times when I close the xwindow. At other times I don't get a message at all. In all cases exit() is called somewhere inside XLib (?) it seems, and the program just terminates (and the application can't do anything about it).
Any volunteers for migrating to xcb? :)
This bug (or, if you don't call this a bug, then call it unwanted behaviour) still exists in gst-properties, can this please be reopened?
> This bug (or, if you don't call this a bug, then call it unwanted behaviour) > still exists in gst-properties, can this please be reopened? Is this even fixable on our end?
You're asking me? I can come up with some ways to fix it, none of them completely pretty, but sure, there's some ways. Gtk has a way of having apps pop up a confirmation dialog when pressing 'X' in the window manager (not-gtk) bar, so you should be able to do that also. See what gtk does there. From there on, it's all on whatever API you decide this "feature" should have. I'd recommend that 'X' would send a request-for-eos or so to the app, but there's a variety of ways to make this work...
xcb will fix it :)
Fixed in CVS: 2007-05-17 Jan Schmidt <thaytan@mad.scientist.com> * sys/ximage/ximagesink.c: (gst_ximagesink_ximage_put), (gst_ximagesink_xwindow_new), (gst_ximagesink_handle_xevents), (gst_ximagesink_show_frame): * sys/xvimage/xvimagesink.c: (gst_xvimagesink_xvimage_put), (gst_xvimagesink_xwindow_new), (gst_xvimagesink_handle_xevents), (gst_xvimagesink_show_frame): When we create our own window, indicate that we handle the WM_DELETE client message from the window manager, so that it won't kill our window (and our app) along with it. Handle ClientMessage, post an error on the bus, and close the window. Further buffers arriving will result in a FlowError because the window has been destroyed. Fixes: #393975 The behaviour still looks a little strange, because gstreamer-properties doesn't seem to be handling errors on the bus. The test pattern window disappears when closed, but the throbber dialog stays open until it is explicitly closed too. That wouldn't happen if gstreamer-properties caught the error message and closed the window.
It is kind of weird that you close the bug if the testcase still doesn't behave as defined. Maybe you should open a new bug in gnome-media so that this will be addresses, also?
The 'testcase' of gst-launch-0.10 videotestsrc ! ximagesink works perfectly - when the window is closed, it receives an error on the bus that causes it to shut down cleanly. Feel free to open a gnome-media bug if you have a burning desire to make gstreamer-properties handle errors too, but I won't be because it just feels like turd-polishing to me.