Dynamically changing the pipeline (manual example)

[Adam Goodwin]

I'm looking at the manual example here:

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-dynamic-pipelines.html

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.

***

What I mean is:

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:

gst_pad_add_probe (blockpad, GST_PAD_PROBE_TYPE_BLOCK_DOWNSTREAM,
pad_probe_cb, user_data, NULL);

Then in the callback function for the probe (pad_probe_cb) the first thing
that happens is that the probe is removed using:

gst_pad_remove_probe (pad, GST_PAD_PROBE_INFO_ID (info));

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:

1. The callback has to return a special value (GST_PAD_PROBE_REMOVE) on a
subsequent call.

Or:

2. The probe has to be removed using the gst_pad_remove_probe function.

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.

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.

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.

Thanks if anyone can do this for me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130903/04defe7d/attachment.html>