Change the pad health calculation to consider a pad 'healthy'
if it has received data within the last 'timeout' window. Previously,
inactive pads were constantly flip-flopping between healthy and not
healthy depending on whether they were slightly ahead of or behind
the active pad running_time.
When the health status of a pad changes, make sure to always notify
the property, so that applications that are manually controlling
the active pad can make their switching decisions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1285>
Fix the following use case:
- main input of fallbackswitch is finite (a media file)
- fallback input is infinite (videotestsrc)
- main input is done and send eos, which is propagated downstream
- fallbackswitch switches to fallback, sending STREAM_START which reset
EOS downstream (aggregator does that)
- fallback input keeps pushing buffers forever.
Solve it by adding a 'stop-on-eos' property so fallbackswitch stops
pushing property once the main input is eos.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1249>
Commit 24b7cfc8 applied changes related to nullability as declared
by gir. One consequence was that some functions signature ended up
requiring users to pass `Some(val)` when they could use `val`
before.
This commit applies changes on `gstreamer-rs` which, will honoring
the nullability stil allow users to pass `val` for the few affected
functions.
This commit also fixes the signature for `Element::request_new_pad`
which was updated upstream.
Internal conversion element can cause unexpected format/resolution
change depending negotiated result, which didn't happen before
the recent fallbacksrc update for fallback stream support.
Configure conversion objects only for fallback streams and also
fallback-{audio,video}-caps are specified, in order to keep
previous behavior.
An element which creates QoS event might reference different
GstSegment timeline (e.g., fallback testsrc's one).
Then it can cause lots of buffers are being dropped in decoder,
because of the QoS events.
Drops the QoS event before we calculate appropriate pad offsets
from blocking pad probe.
This was broken by the rewrite, receiving gaps on the main pad
should let the position progress, reset timeouts and keep the main
pad active.
This picks the simplest solution, transforming gap events into GAP
buffers and letting them go through chain(), this achieves the desired
effect.
We shouldn't leave the used clock ID around. Otherwise, we might never
schedule a new timeout from an inactive pad if the active pad doesn't
get a buffer.
`schedule_timeout` can synchronously call `handle_timeout` and change the
active pad. We need to update `is_active` afterwards.
After calling `schedule_timeout` with `end_running_time`, we used to
assume there was no pad switch and reset `switched_pad` immediately. If
the pad actually got switched, this would make us miss a sticky events
update.
As described in issue #200, we hold the srcpad's stream lock in some
situations where we notify the `active-pad` property.
If there's a handler installed it will most likely attempt to read the
property, which had to take the `state` lock. Another thread could
already be holding this lock and attempting to obtain the srcpad's
stream lock. This resulted in a deadlock.
To avoid this, move the `active_sinkpad` field into its own Mutex, which
we never hold for long.
Fixes: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/200
