<div dir="ltr">Thank you. I was just missing the fact that EOS blocks the pad from receiving more data. </div><div class="gmail_extra"> <div class="gmail_quote">On 9 February 2016 at 15:42, Tim Müller <<a href="mailto:tim@centricular.com" target="_blank">tim@centricular.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 2016-02-09 at 15:17 +0000, David Jaggard wrote: Hi David, > But it appears that all the callback does is inject the EOS event and > then exit. It does not appear to wait for the EOS event to reach the > next probe (which could happen several seconds later if the element > is a queue, for example). So as the blocking probe has now been > removed from the element sink it appears to be possible for data to > flow again into the element. Or does the EOS event itself prevent > that element from accepting any more data? That's right, when you push an EOS event on a pad, the pad will be flagged as EOS and when someone tries to push more data to it, they'll get a GST_FLOW_EOS flow return and upstream will stop streaming in response to that. The application will have to wait for an EOS message on the bus to make sure the EOS has filtered through to the sink and everything has finished up as it should. Cheers -Tim -- Tim Müller, Centricular Ltd - <a href="http://www.centricular.com" rel="noreferrer" target="_blank">http://www.centricular.com</a> _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </blockquote></div> </div>