<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 31, 2013 at 1:46 PM, Pedro Côrte-Real <span dir="ltr"><<a href="mailto:pedro@pedrocr.net" target="_blank">pedro@pedrocr.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">...<span style="color:rgb(34,34,34)"> </span></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)"> </span></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Add the probe callback to the queue again<br>
- Remove the old probe callback from the queue thus unblocking it and<br>
letting the pipeline flow again<br>
<br>
These two last steps are needed for lack of a<br>
"gst_pad_probe_unblock()". slomo and wtay seemed to be discussing on<br>
IRC that it could be a good addition.<br></blockquote><div><br></div><div><br></div><div>I find now that if I add the new blocking probe and then remove the old blocking probe, that data flow doesn't resume. If I just remove the old blocking probe, data flow does resume.</div>
<div><br></div><div>Does this seem like a bug? Or does the app need to do something else to kickstart a pad that was blocked by probe A, becomes blocked by probe B, and then has probe A removed?</div><div><br></div></div>
</div></div>