As awstranscriber might in theory push out gap events without
any flow of input data, it needs to send its mandatory events
(stream-start, caps, segment) independently.
In addition, track a start time and use it to offset the 0-based
timestamps returned by AWS in order to output buffers timestamped
in the running-time domain, and perform item timing adjustment
only when dequeuing, instead of when queuing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/525>
and use 0 instead of -1 to disable accumulation. In practice 0
already had the same effect, and this lets us get rid of unsafe
code that actually breaks inspection of the element.
<https://aws.amazon.com/blogs/machine-learning/amazon-transcribe-now-supports-partial-results-stabilization-for-streaming-audio/>
Amazon seem to have realized the previous iteration of their API
made it difficult to identify items from one result to the next,
which made the element much more complicated than it should have
been. With that new "stability" option, we can enqueue items as
soon as they stabilize, and simply rely on the current index in
the transcript to output them exactly once.
This also means the "use_partial_results" is now useless, as there
will be no difference in accuracy between a non-partial result and
and of its stable items that might have been pushed from previous
partial versions of the result.
The property is removed, instead a new option is exposed to let
users control how fast results should stabilize.
This greatly simplifies the code, and also improves the output as
punctuation doesn't need to be randomly discarded anymore.
As stated in the spec:
> In addition, the user must have the capability to select a black
> background over which the captioned letters are displaced.
The property is MUTABLE_PLAYING
It rejects code such as:
```rust
if state
.start_ts
.zip(accumulate_time)
.map_or(false, |(start_ts, accumulate_time)| {
start_ts + accumulate_time < pts
})
```
because it looks like:
```rust
if { true }
```
csound-sys can detect the system lib using either pkg-config or using
the CSOUND_LIB_DIR env variable.
The former case just work but the second is trickier as we need to
ensure that CSOUND_LIB_DIR is defined when building.
So we no longer try to detect the lib using find_library() if user
didn't define the env variable as the build will fail later.
Also explicitly pass the env variable to cargo so user can now call
'CSOUND_LIB_DIR=/usr/lib64 meson build && ninja -C build'
and have it work without repassing the env variable to ninja.
Using ubuntu 20.04, the build was failing with version
cargo 0.47 / rustc 1.47.
Following this discussion:
https://github.com/rust-lang/cargo/issues/9340
it appears that rustc 1.52 is the minimum version.
Implemented analogously to souphttpsrc for compatibility. Proxy
prevents sharing the client between element instances.
Change-Id: I50d676fd55f0e1d7051d8cd7d5922b7be4f0c6e8
With the URI handler interface implemented, we can drop the old method
of specifying bucket, key and region. This also brings it in line with
how it is for s3src.
It's supported with the latest version.
Also ignore build.rs when generating reports.
The new gitlab summary parsing regexp is now:
<abbr .*>(\d+.\d+) %<\/abbr>
In roll-up modes, we open new lines when the last column is reached.
This commit implements lookahead on a word basis, in order to avoid
splitting words unless absolutely necessary (when a word won't fit
on a full row)
For some reason (compiler bug?), the rust compiler fails to compare u32 and f64 types
when doing a wildcard cast on i586 with the following error:
error[E0282]: type annotations needed
--> audio/csound/src/filter/imp.rs:611:47
|
611 | if rate != out_info.rate() || rate != csound.get_sample_rate() as _ {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type
|
= note: type must be known at this point
Using an explicit cast solves the issue.
