After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 729088 - xvimagesink: catch XWindows errors when destroying xwindow
xvimagesink: catch XWindows errors when destroying xwindow
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-04-28 08:58 UTC by Dirk Van Haerenborgh
Modified: 2018-11-03 11:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (5.96 KB, patch)
2014-04-28 08:58 UTC, Dirk Van Haerenborgh
reviewed Details | Review

Description Dirk Van Haerenborgh 2014-04-28 08:58:50 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.
Comment 1 Luis de Bethencourt 2014-04-28 19:54:19 UTC
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");
Comment 2 Sebastian Dröge (slomo) 2014-04-29 06:57:04 UTC
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.
Comment 3 Dirk Van Haerenborgh 2014-04-29 07:12:25 UTC
(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.
Comment 4 Matthew Waters (ystreet00) 2014-04-29 07:20:05 UTC
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
Comment 5 Nicolas Dufresne (ndufresne) 2014-04-29 13:44:59 UTC
(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.
Comment 6 Stirling Westrup 2016-02-03 21:23:56 UTC
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
Comment 7 GStreamer system administrator 2018-11-03 11:29:48 UTC
-- 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.