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.

Without this, custom sources that are live are not actually considered
live.

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.

utils/fallbacksrc: Add a 1s queue between uridecodebin and clocksync and do buffering after the queue

This adds 1s more buffering (of uncompressed data), but works around
gstreamer/gst-plugins-base#800

Otherwise errors are silently ignored.

It doesn't make sense in this context and the flag only exists since
1.12.

Can be made conditional if someone needs that.

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.

imagefreeze in live mode can handle only up to 1 frame of buffering
itself.

This mirrors the processing-deadline property on various elements, but
for now just with a hardcoded value.

Sebastian Dröge authored Jul 03, 2020 and Sebastian Dröge committed Jul 06, 2020

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.

EOS might be unexpected and the stream might be supposed to run forever,
in which case it should transparently be restarted on EOS.

Instead of the main stream, pretending all to be ok.

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>

Mathieu Duponchelle authored Jun 19, 2020 and Sebastian Dröge committed Jul 02, 2020

b3138ad0 added the field for
that purpose, let's also use it!

Workaround for gstreamer/gstreamer!553

Only 64k are allowed for the sum of all private instance structs in the
class hierarchy, as well as for the public instance structs.

The CdgInterpreter itself is huge and adding just another two integers
to GstVideoDecoderPrivate in libgstvideo is causing the limit to be
reached, so let's allocate it in a separate memory area.

Otherwise we would start outputting at running time 0, which is going to
be wrong if the pipeline was already running for a while.

Requires gstreamer/gst-plugins-good!653

And new video event APIs.