Hi everyone,
I need to build a dynamic pipeline which starts paused with no sink, and then sinks are added based on external conditions.
I searched a lot, found many resources and I now understand that this use case is solved with blocking probes and dynamic creation and linking of elements.
One of the most useful resources is the blog post by @slomo at this link GStreamer Dynamic Pipelines – coaxion.net – slomo's blog which goes in depth in explaining the details of this approach.
However, I have some leftover doubts on this: the first one is that I still do not understand why sometimes an EOS signal is needed to drain the elements from leftover buffers before unlinking, and sometimes it is not needed.
Here is more context on this.
The first example in slomo’s blog is the following: dynamic-filter.c, and this is the original description of the code:
In this example we will have a decodebin, connected to a video sink with the navseek element. This allows us to watch any supported video file and seek with the cursor keys. Every 5 seconds a video effect filter will be inserted in front of the sink, or removed if it was inserted last time. All this without ever stopping playback or breaking because of seeking. […]
The second code example is called “A slightly more advanced variant” and refers to this code: test-effect-switch.c (the blog post points to an older version, but it is functionally the same content).
Here is the original description:
A slightly more complex variant of this [the first example cited here] is also in gst-plugins-base. The main difference is that BLOCK probes are used here, and the filter is drained with an EOS event before it is replaced. […]
Now, I cannot understand why the filter must be drained in the second example and not in the first one: is it simply because the filter used in the first example does not have an internal queue of buffers, so it just cannot happen that buffers are dropped due to the filter not being correctly flushed?
Another source of confusion for me is when to use a block probe or an idle probe. I do get that idle probes might be called from the main thread in case the pad is idle when the callback is called, and I am ok with that. Other than that, block and idle probes seem quite similar to me, and I cannot understand how one must choose one or the other. Someone can explain this a bit better?
By the way, the docs are not super clear on the fact that IDLE probes only block the pad when the callback is executing and BLOCK probes block the pad as long as they are installed. Maybe this should be fixed in the docs, even if this has apparently already been addressed, see Bug 766002 – pad: IDLE probes don't block when returning GST_PAD_PROBE_OK. Finally, I understood that callbacks may be called multiple times only from slomo’s blog, not from the documentation, so I suggest that this information is added in the probes section.