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
Also clip raw audio/video buffers according to the caps if they have the
relevant information in the caps, and drop raw audio samples if they're
outside the segment too.
In addition also set durations on raw audio/video buffers based on the
caps if no duration is set.
fallbackswitch might forward flush event if it's for the currently
active pad. But forwarded flush event will be problematic in various
reasons and that's not a behavior we expected.
Requesting the first pad will emit the property because the first pad is
then selected. That will cause the callback to be called, which tries to
take the same mutex that is already locked during element setup and
causes a deadlock.
fallbackswitch now supports multiple sink pads, and on a timeout of the
active pad, it will automatically switch to the next lowest priority pad
that has data available.
fallbackswitch sink pads follow the `sink_%u` template and have
`priority` as a pad property.
Co-authored-by: Vivia Nikolaidou <vivia.nikolaidou@ltnglobal.com>
