<div dir="ltr"><div><div><div>I'm looking at the manual example here:<br><br><a href="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-dynamic-pipelines.html">http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-dynamic-pipelines.html</a><br>
</div><br>And there's something which is confusing me. I understand that to change a pipeline (while it's running) you need to block source pads from sending buffers to downstream pads which you are unlinking/linking. So I understand the plain-English algorithm at the top of the manual page. What I don't understand is the actual code. To me it doesn't seem to follow the description above it.<br>
<br>***<br><br></div><div>What I mean is:<br></div><div><br></div>I see that in the example there's a timeout callback which runs every second to swap an element in the pipeline. In this callback, an event probe is added to block all downstream events and buffers (on the source pad of the element preceding the element to be swapped) using this line:<br>
<pre class="">gst_pad_add_probe (blockpad, GST_PAD_PROBE_TYPE_BLOCK_DOWNSTREAM, pad_probe_cb, user_data, NULL);</pre>Then in the callback function for the probe (pad_probe_cb) the first thing that happens is that the probe is removed using:<br>
<pre class="">gst_pad_remove_probe (pad, GST_PAD_PROBE_INFO_ID (info));</pre>This is what I don't understand. From the documentation I thought that blocking probes begin to block things from leaving their pad once their callback is first returned from. Then to stop the blocking, I thought that either:<br>
<br>1. The callback has to return a special value (GST_PAD_PROBE_REMOVE) on a subsequent call.<br><br>Or:<br><br>2. The probe has to be removed using the gst_pad_remove_probe function.<br><br></div><div>So it seems to me that the probe callback in the manual example stops any events/buffers from being blocked in the first place. As soon as the probe callback is called, to start blocking, it immediately disables itself.<br>
<br>So when the element is swapped and the new one is linked in to the pipeline (after an EOS event on the source pad of the element to be swapped) it looks to me like this is happening while the source pad of the source element is not blocked.<br>
<br></div><div>I think the best way for me to understand this is if someone could describe an iteration of the example program. For example, could someone explain the sequence of the function calls and the exact lines where pads become blocked/unblocked? Basically, I just need to understand how it is that the example code corresponds to the plain-English algorithm at the start of the manual page.<br>
<br></div><div>Thanks if anyone can do this for me.<br> </div></div>