Hello,
The typical reaction to getting an error posted to glib bus is to quick the loop and hence the app. I my case I have multiple pipelines running, so I can't just exit the app. What I want to do is to stop the failing pipeline and later delete it. Is it safe to call gst_element_set_state(NULL) from the bus error callback? From what I can read in the source it seems like it should OK, but I'd love for people in the know to confirm that. I wouldn't want to cause an occasional deadlock. Thanks, -- Max. _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
On Wed, 2011-12-07 at 13:05 -0800, Max Paklin wrote:
Hi, > The typical reaction to getting an error posted to glib bus is to quick the > loop and hence the app. GStreamer bus you meant, presumably. > I my case I have multiple pipelines running, so I can't just exit the app. > What I want to do is to stop the failing pipeline and later delete it. > Is it safe to call gst_element_set_state(NULL) from the bus error callback? Yes, assuming the main loop / main context iteration is happening in a thread other than a thread created by GStreamer. Usually this is the case, because usually you run gtk_main() or g_main_loop_run() from your application's main thread. > From what I can read in the source it seems like it should OK, but I'd love > for people in the know to confirm that. > I wouldn't want to cause an occasional deadlock. Should be fine. _set_state() is only problematic when done from the context of a GStreamer streaming thread (e.g. a signal callback emitted by an element, a *sync* bus watch or a pad probe callback or so). Cheers -Tim _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Thanks Tim!
I appreciate the answer. Yes, the app calls g_main_loop_run() from one of its non-GStreamer threads and no, I wouldn't call _state_stop() from under STREAM_LOCK. Deadlock prone or maybe even guaranteed to deadlock. -- Max. -----Original Message----- From: gstreamer-devel-bounces+mpaklin=[hidden email] [mailto:gstreamer-devel-bounces+mpaklin=[hidden email]] On Behalf Of Tim-Philipp Müller Sent: Wednesday, December 07, 2011 3:28 PM To: [hidden email] Subject: Re: Calling set_state(NULL) from glib bus error callback On Wed, 2011-12-07 at 13:05 -0800, Max Paklin wrote: Hi, > The typical reaction to getting an error posted to glib bus is to > quick the loop and hence the app. GStreamer bus you meant, presumably. > I my case I have multiple pipelines running, so I can't just exit the app. > What I want to do is to stop the failing pipeline and later delete it. > Is it safe to call gst_element_set_state(NULL) from the bus error callback? Yes, assuming the main loop / main context iteration is happening in a thread other than a thread created by GStreamer. Usually this is the case, because usually you run gtk_main() or g_main_loop_run() from your application's main thread. > From what I can read in the source it seems like it should OK, but I'd > love for people in the know to confirm that. > I wouldn't want to cause an occasional deadlock. Should be fine. _set_state() is only problematic when done from the context of a GStreamer streaming thread (e.g. a signal callback emitted by an element, a *sync* bus watch or a pad probe callback or so). Cheers -Tim _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |