error[E0412]: cannot find type `Error` in this scope
--> generic\threadshare\src\socket.rs:237:56
|
237 | pub fn set_tos(&self, qos_dscp: i32) -> Result<(), Error> {
| ^^^^^ not found in this scope
There have been some very weird issues, where
cargo keeps fetching older commits of glib-rs
and breaking the build like so [1]
Might be stale cache, or some http/git mirroring
shenanigans, so lets stop trying to use the
cache for now and check if the issue persists.
[1]: https://gitlab.freedesktop.org/slomo/gst-plugins-rs/-/jobs/4715922
This allows to update the URI just before configuring it on
uridecodebin3. It might be necessary to update the original URI because
it expired in the meantime, for example.
We don't need JPEG, GIF, etc. support so depending on the whole
dependency chain of them is not needed and only wastes CPU time.
As a result we can remove the gif crate exception in deny.toml.
We are caching the CARGO_HOME which includes git repos of
the gtk-rs bindings. Since we don't specify a branch
so it uses the default branch for the ref.
cargo build usually does an update if it has network access,
but its not guaranteed or the case for other tools like clippy
which may still point to the stale git snapshot like here:
https://gitlab.freedesktop.org/thaytan/gstreamer-rs/-/jobs/4165449
The audiornnoise element can be used as playbin audio-filter for instance, to
suppress noise in the audio stream.
This plugin relies on the nnnoiseless crate which implements the noise removal
algorithm of the Xiph RNNoise library, in Rust. Some demos and documentation of
the RNNoise C library can be found on:
https://people.xiph.org/~jm/demo/rnnoise/Fixes#114
Otherwise we can deadlock because of a lock order issue:
- render() is called with the sink pad handler lock and takes the
settings lock
- clearing clients takes the sink pad handler lock
Otherwise the source might be blocked downstream in the pad probe on the
queue. Previously this was not a problem because the probes were
directly on the srcpads of the source but due to a workaround for
uridecodebin3 buffering bugs this is not the case anymore.
Let's print the name of the source's srcpad that is going to be blocked
instead of the "src" pad of the following queue. Without this it's hard
to distinguish the different streams from the logs.
The fallback stream will usually have a lower latency than the main
stream, so a too low latency would be configured if the fallback is
activated in the beginning.
This property allows to override this and does not require latency
reconfiguration.
Buffers are still forwarded until the timeout is reached even if they're
too late, but if they were continuously too late for more than the
duration of the timeout setting then switch to the fallback stream
instead.
