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.
Buffers are still forwarded until the timeout is reached even if they're
too late, but if they were continuously too late for more than the
duration of the timeout setting then switch to the fallback stream
instead.
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.
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.
