GNOME Bugzilla – Bug 729088
xvimagesink: catch XWindows errors when destroying xwindow
Last modified: 2018-11-03 11:29:48 UTC
Created attachment 275302 [details] [review] proposed patch When passing a window handle to xvimagesink, the whole application will abruptly exit when the window handle becomes invalid at some point. This happens, for instance, when the drawingarea owning the window handle is managed by a different process. If that process is killed, the window handle becomes invalid immediately. The proposed patch will catch the Xerrors generated when rendering to an xwindow whose handle is gone, and signal a flow error. Also, Xerrors are caught while destroying the xvcontext, and replaced by GStreamer errors. This enables the user to act on these errors, rather than having the application quit immediately.
Why do you switch the Warning to an Error? - GST_WARNING_OBJECT (xvimagesink, "could not output image - no window"); + GST_ERROR_OBJECT (xvimagesink, "could not output image - no window");
Review of attachment 275302 [details] [review]: The same change will be needed for ximagesink and probably ximagesrc, and the X11 part of libgstgl too. I'm not 100% of the threading effects here though, is setting the handler a global operation or only thread-local? We might temporarily override the handler of the UI toolkit if it's global, which might have funny effects.
(In reply to comment #1) > Why do you switch the Warning to an Error? > > - GST_WARNING_OBJECT (xvimagesink, "could not output image - no window"); > + GST_ERROR_OBJECT (xvimagesink, "could not output image - no window"); Because it will return a FLOW_ERROR as well. It seemed odd to me that it would be a warning if it resulted in an error after all. With this change, it behaves more like the 'activate_failed' label.
The x11 error handler is global. libgstgl already overrides it for GL 3 context creation. See gst_gl_window_x11_trap_x_errors() in x11/gstglwindow_x11.c
(In reply to comment #3) > (In reply to comment #1) > > Why do you switch the Warning to an Error? > > > > - GST_WARNING_OBJECT (xvimagesink, "could not output image - no window"); > > + GST_ERROR_OBJECT (xvimagesink, "could not output image - no window"); > > Because it will return a FLOW_ERROR as well. It seemed odd to me that it would > be a warning if it resulted in an error after all. With this change, it behaves > more like the 'activate_failed' label. if it's an unrecoverable error, most likely you want the pipeline to stop. Then you should communicate this error to the application by using GST_ELEMENT_ERROR(). If it's recoverable, it's a warning.
I just want to add that I'm also having problems with this bug. I have a video-wall application that can have many xvimagesinks running at the same time, right now if any one of them has a failure, the uncaught error ends up aborting my entire program. Failure of one display out of 25 is annoying, but not fatal. I would far rather just get a pipeline message of some kind, rather than an abrupt termination. However, looking at the xvimagesink code, I see its all Xlib based, and there are known issues with trying to get error handling to work using Xlib in a multi-threaded environment. All the recommendations are that in such circumstances, you should recode the application to use xcb instead. See here, for instance: http://www.remlab.net/op/xlib.shtml
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/118.