<div dir="ltr"><div>Hi all.</div><div><br></div><div>No need to shut down the pipeline but there is there any way to pause</div><div>or stop the dataflow immediately from the callback ?</div><div><br></div><div>I am trying to detect a situation that triggers a bug in a videosink.</div><div>When I detect this I must make sure that the dataflow is stopped</div><div>immediately so that the bug is not triggered.</div><div><br></div><div>Cheers</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-09-17 10:27 GMT+02:00 Tim Müller <span dir="ltr"><<a href="mailto:tim@centricular.com" target="_blank">tim@centricular.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, 2015-09-17 at 09:55 +0200, Guillermo Rodriguez Garcia wrote:<br>
<br>
<br>
<br>
> 2015-09-16 12:15 GMT+02:00 Alejandro Vázquez <<a href="mailto:vazlup@gmail.com">vazlup@gmail.com</a>>:<br>
> > > I want to know if it is right to modify the status of a pipeline<br>
> > > within a<br>
> > callback.<br>
> > The application works but I'm not sure if it can cause a problem in<br>
> > the<br>
> > future.<br>
> ><br>
> > e.g.<br>
> ><br>
> > ...<br>
> > GstPad *pad = gst_element_get_static_pad(videoScr, "src");<br>
> > g_signal_connect(pad, "notify::caps", G_CALLBACK(video_changed),<br>
> > NULL);<br>
> > ...<br>
> ><br>
> > video_changed<br>
> > {<br>
> > ...<br>
> > gst_element_set_state(GST_ELEMENT(pipeline), GST_STATE_PAUSED);<br>
> > ...<br>
> > }<br>
><br>
> The documentation<br>
> (<a href="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html" rel="noreferrer" target="_blank">http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html</a><br>
> /chapter-dataaccess.html)<br>
> says the following regarding "data probes":<br>
><br>
> "Data probes run in pipeline streaming thread context, so callbacks<br>
> should try to not block and generally not do any weird stuff, since<br>
> this could have a negative impact on pipeline performance or, in case<br>
> of bugs, cause deadlocks or crashes. More precisely, one should<br>
> usually not call any GUI-related functions from within a probe<br>
> callback, nor try to change the state of the pipeline [...]"<br>
><br>
> Now what you are using is not a data probe but I do not know if the<br>
> same constrains apply. I couldn't find any information on what can<br>
> and<br>
> can't be done from a callback that was registered with<br>
> g_signal_connect..<br>
><br>
> Can anyone shed some light here?<br>
<br>
</div></div>Most signal callbacks on GStreamer objects (other than GstBus::message)<br>
will be emitted from a streaming thread. The notify::caps callback is<br>
one of those that gets emitted from a streaming thread. You can't shut<br>
down the pipeline or change global pipeline state from that callback.<br>
<br>
What are you trying to do (big picture)?<br>
<br>
 Cheers<br>
<span class="HOEnZb"><font color="#888888">  -Tim<br>
<br>
--<br>
Tim Müller, Centricular Ltd - <a href="http://www.centricular.com" rel="noreferrer" target="_blank">http://www.centricular.com</a><br>
<br>
Join us at the GStreamer Conference: 8-9 October 2015 in Dublin, Ireland<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</div></div></blockquote></div><br></div>