The logic of the element requires the next buffer to be available
immediately after we are done pushing the previous, otherwise we insert
a repeat.
Making the src loop handle events and queries broke this, as upstream is
almost guaranteed not to deliver a buffer in time if we allow non-buffer
items to block upstream's push.
To fix this, replace our single-item `Option` with a `VecDeque` that we
allow to hold an unlimited number of events or queries, but only one
buffer at a time.
In addition, the code was confused about the current caps and segment.
This wasn't an issue before making the src loop handle events and
queries, as only the sinkpad cared about the current segment, using it
to buffers received, and only the srcpad cared about the current caps,
sending it just before sending the next received buffer.
Now the sinkpad cares about caps (through `update_fallback_duration`)
and the srcpad cares about the segment (when not in single-segment
mode).
Fix this by
- making `in_caps` always hold the current caps of the sinkpad,
- adding `pending_caps`, which is used by the srcpad to store
caps to be sent with the next received buffer,
- adding `in_segment`, holding the current segment of the sinkpad,
- adding `pending_segment`, which is used by the srcpad to store
the segment to be sent with the next received buffer,
- adding `out_segment`, holding the current segment of the srcpad.
Maybe a fix for
https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/298.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1082>
It attempts to produce a (nearly) gapless live stream by synchronizing
its output to the running time and forwarding the next input buffer if
its start is (nearly) flush with the end of the last output buffer.
If the input buffer is missing or too far in the future, it duplicates
the last output buffer with adjusted timestamps. If it is operating on a
raw audio stream, it will fill duplicate buffers with silence.
If an input buffer arrives too late, it is thrown away. If the last
input buffer was accepted too long ago (according to `late-threshold`),
a late input buffer is accepted anyway, but immediately considered a
duplicate. Due to the silence-filling, this has no effect on audio, but
video gets a "slideshow" effect instead of freezing completely.
The "many-repeats" property will be notified when this element has
recently duplicated a lot of buffers or recovered from such a state.
Co-authored-by: Vivia Nikolaidou <vivia@ahiru.eu>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/708>
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
The element has a small race condition where it might output two buffers
with the same running time during e.g. a manual switch. In practice this
is not a problem, so the test takes this race into account.
Fixes: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/195
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.
I give up on crossbeam_channel. For some reasons some receivers are not
always unblocked and I was not able to reproduce using simpler test
cases.
Use with mpsc channels instead which are more reliable.
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>
Keep the state mutex during the whole decodebin pad-added callback.
Fix a race when we were checking if state.waiting_for_ss_eos was set and
it was removed before we actually processed the item.
Fix#184
It might still be blocked downstream for a while, e.g. in the clocksync.
Flushing does not cause any problems as fallbackswitch is not going to
forward it and will only unblock everything up to there.
In `sink_chain` when the Segment is pending, attempting to lock
rec state could lead to a dead lock because the stream state is
already locked while the main stream state was not locked.
Function `check_and_update_stream_start` checks whether other streams
reached EOS. The stream being checked might already have locked its
state. If it's about to check other streams too, this results in a
deadlock.
The problem was due to the `main_state` guard being dropped handling
event `StreamStart` checking whether the main stream is EOS:
```rust
let main_is_eos = if let Some(main_state) = main_state {
main_state.eos
} else {
false
};
```
In the above code, `main_state` main state is comsumed and dropped
after evaluating `main_state.eos`.
This is also the case before handling event `Eos`.
This revealed another deadlock handling event `Eos` which is under
investigation.
