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.
They were already converted to the running time a few lines above and
updated inside the buffer. Converting another time for the timeout
causes the timeout to happen at the wrong time, usually much later than
it should.
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.
