The blocking probe will be called on buffer or downstream event.
So segment event might not be available at that moment if it was
called by downstream events.
This allows to update the URI just before configuring it on
uridecodebin3. It might be necessary to update the original URI because
it expired in the meantime, for example.
Otherwise the source might be blocked downstream in the pad probe on the
queue. Previously this was not a problem because the probes were
directly on the srcpads of the source but due to a workaround for
uridecodebin3 buffering bugs this is not the case anymore.
Let's print the name of the source's srcpad that is going to be blocked
instead of the "src" pad of the following queue. Without this it's hard
to distinguish the different streams from the logs.
The fallback stream will usually have a lower latency than the main
stream, so a too low latency would be configured if the fallback is
activated in the beginning.
This property allows to override this and does not require latency
reconfiguration.
This also fixes the bug that the source wouldn't be restarted another
time if we switched to the fallback stream before and didn't at least
shortly switch to the normal stream. There was no timeout for this.
Based on a patch by Mathieu Duponchelle <mathieu@centricular.com>
It's only used during construction of the internal bin after all.
Keeping it readable would cause e.g. creating a pipeline graph trying to
read it, which is not implemented.
Only two uses of unsafely setting the pad functions is left:
- fallbacksrc for overriding the chain function of the proxy pad of a
ghost pad
- threadshare for overriding the pad functions after creationg, which
probably needs some fixing at some point
If we switch to the fallback stream but the last buffering activity was
less than $timeout ago, we shouldn't restart the source yet but wait a
bit longer. However for that we actually need to schedule another
timeout, which was not happening before.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/116
It will take a moment for the fallbackswitch to actually switch to the
main stream. So instead take into account the time since the last
buffering update even when we reached 100%, and don't reset that time
when reaching 100%.
It might be a second stream collection that we receive at a later time,
and the previous pads would already be unblocked at that point. So block
all currently unblocked pads again and then adjust the offset
according to the new situation.
This fixes playback of various RTMP streams where usually we first get a
stream collection with only one of the two streams, and shortly
afterwards with both streams.
This works as an alternative to the "uri" property, which would use an
`uridecodebin3` element.
The provided source element can have static audio/video pads or provide
them as sometimes pad while signalling no-more-pads or a stream
collection message once all pads are available.
This is a wrapper around uridecodebin3 and fallbackswitch that allows to
switch to a still frame on errors and automatically retries the source
in the background on errors until a given retry timeout is reached.
