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.
Latest version of cargo-c and cargo are now producing files to
'build/target/x86_64-unknown-linux-gnu/debug/' instead of 'build/target/debug/'.
Fix this by making the glob pattern recursive.
Trying to write "" in order to erase characters in the caption
frame simply fails silently, the proper way to implement
delete_to_end_of_row and backspace was to memset the relevant
cells.
It's only accessed from the streaming thread and in PAUSED->READY after
the streaming thread was shut down, so it's already guaranteed that only
a single thread can access it at any time.
This element outputs the same format expected by tttocea608 in
json mode.
It notably differs from cea608tott in that it only uses libcaption's
low-level API, as it needs to maintain its own view of the current
state of the screen, and make fine-grained decisions as to when
to output data and how to timestamp it.
It covers a large portion of the 608 spec, with the exception of
a few features that probably haven't ever seen widespread usage,
those are listed in a TODO list at the top.
It has been tested with a reference file produced by CEA and covers
all the features it demonstrates.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/480>
AWS offers the option of creating "vocabularies", lists of words
that are likely to be encountered. Those can be created through
the AWS console, and are given a name. That name can then be
specified when starting a transcription job.
The element expects an array of "commands", as GstStructures,
in the form:
operation, pattern=<pattern>, ...
The only operation implemented for now is replace-all, eg:
replace-all, pattern=foo, replacement=bar
Other operations can be implemented if useful in the future,
eg. "match" could post a message to the bus when the pattern
is encountered.
The main use case for this is automatic speech recognition,
as implemented by eg awstranscribe as users may want to replace
swear words with tamer language.
Commands are applied in order.
The interface is usable through the CLI with the usual escaping
strategies, though trying to pass in actual regular expressions
through it is a bit tricky, as this introduces yet another
level of escaping.
