When "{:?}" printing a Message[Ref], the following issues lower the
experience:
- If the Message seqnum is GST_SEQNUM_INVALID (0), a panic occurs due
to an assertion failure in MessageRef::get_seqnum.
- The src of the Message displays the GString address.
Origin issue for an occurrence of the first case above fixed in
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/860
There is now a separate type for Single and Periodic clock ids. This
allows to have API that is only for one type on that specific type
instead of doing runtime checks, and allows for more refined async
waiting API.
Crates using gst_plugin_define might not (need to) import `glib`
directly into their scope; use the one imported in `gstreamer`s root
to make this macro more portable.
Besides, `glib` is prefixed with `$crate::` just below.
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
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.
We have to pass `NULL` / `None` instead of the actual default log
function as because of `-Bsymbolic` or how DLLs work on Windows the
external function pointer is different to the internal one.
If a user ends up changing the configured mode later on previously
registered vfuncs are not reset meaning the object is effectively stuck
in mode `Both`.
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
its confusing and it took 3 attempts to get `before_script`
to fucntion as expected. Instead get rid of the anchor
and use a (questionable) but simpler heuristic to detemine
when to update the lockfile.
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 guaranted 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
