The current implementation only makes use of non-partial results,
requiring a crazy high latency.
With this mode, we use items from partial results when they're
older than latency - 2 * GRANULARITY_MS. Depending on the latency
that the user has set this may result in reduced accuracy, the
default latency has been modified to a pretty conservative sweet
spot of 8 seconds.
This complexifies the code a bit, as items aren't identified by
AWS, and their timings can change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/348>
This moves to Rusoto 0.43, which has moved from futures to async/.await.
As a result, we implement a utility function to convert the
async/streaming bits to blocking operations backed by a tokio runtime.
In the process, we also need to restructure s3sink a little, so that the
client is now part of the started state (like it is for s3src). This is
a better model than a separate client, as it reflects the condition that
the client is only available in the started state.
StateMachines are spawned on a runtime::Context which uses a tokio
runtime. The StateMachine doesn't need all the features from tokio
such as the IO and timers drivers.
This commit makes use of a light-weight futures executor to spawn
the StateMachines.
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.
Test was relying on 'blocksize' property on the source which can
only be used in push mode.
This change in baseparse broke it:
e906197c62
so ensure we are actually in push mode by using pushfilesrc.
When initializing Pad functions in `Pad{Src,Sink}`, we downgrade the
`Pad{Src,Sink}` and upgrade it when necessary. This was implemented
to avoid reference cycles:
`gst::Pad` -> pad function -> `Pad{Src,Sink}` -> `gst::Pad`.
Since `Pad{Src,Sink}` reset the pad functions when dropping, there is
no cycles, so we can use an `Arc<Pad{Src,Sink}>` in the pad functions,
thus saving an `upgrade`.
This is a wrapper around uridecodebin3 and fallbackswitch that allows to
switch to a still frame on errors and automatically retries the source
in the background on errors until a given retry timeout is reached.
