gstreamer-rs issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues2023-11-22T03:50:41Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/391video output to Rust GUI library example2023-11-22T03:50:41ZBevideo output to Rust GUI library exampleAre there any examples of integrating GStreamer video output into a Rust GUI library such as Slint or egui? Maybe it could be done with one of the GStreamer OpenGL elements? The [tutorial](https://gitlab.freedesktop.org/gstreamer/gstream...Are there any examples of integrating GStreamer video output into a Rust GUI library such as Slint or egui? Maybe it could be done with one of the GStreamer OpenGL elements? The [tutorial](https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/50f3eee8ebd85a1d71c83e317383e070201e8695/tutorials/Cargo.toml#L11) and [examples](https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/50f3eee8ebd85a1d71c83e317383e070201e8695/examples/Cargo.toml#L28) in this repository use GTK3.
I found this [GTK4 example](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/blob/main/video/gtk4/examples/gtksink.rs) though I'm unclear how I'd use it. Unless I'm missing something, it seems Fedora hasn't packaged gst-plugins-rs, and I suspect it is missing in other distros too. Could `gtk4paintablesink` be used in a Rust application by simply adding `gst-plugin-gtk4` to Cargo.toml to statically link the GStreamer plugin, or would there be more setup needed for GStreamer to detect the plugin?https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/389Add gstreamer-vulkan2023-12-14T09:53:31ZPhilippe RenonAdd gstreamer-vulkanWould it make sense to add `gstreamer-vulkan` ? There is a `gstreamer-gl` so, I guess, yes it would.
Anyways, I had a first try and hit a roadblock when generating `gstreamer-vulkan-sys` :
```
error[E0433]: failed to resolve: use of und...Would it make sense to add `gstreamer-vulkan` ? There is a `gstreamer-gl` so, I guess, yes it would.
Anyways, I had a first try and hit a roadblock when generating `gstreamer-vulkan-sys` :
```
error[E0433]: failed to resolve: use of undeclared crate or module `vulkan`
--> gstreamer-vulkan\sys\src\lib.rs:767:79
|
767 | unsafe extern "C" fn(*mut GstVulkanWindow, *mut *mut glib::GError) -> vulkan::VkSurfaceKHR,
| ^^^^^^ use of undeclared crate or module `vulkan`
```
The Vulkan objects are not generated.
The Vulkan gir file is quite terse: https://github.com/gtk-rs/gir-files/blob/master/Vulkan-1.0.gir.
I am missing something ?Marijn SuijtenMarijn Suijtenhttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/375rtpheaderextension: Allows to get multiple mutable references to the extensio...2024-02-22T23:18:01ZSebastian Drögertpheaderextension: Allows to get multiple mutable references to the extension datahttps://gstreamer.pages.freedesktop.org/gstreamer-rs/git/docs/gstreamer_rtp/subclass/prelude/trait.RTPHeaderExtensionImpl.html#method.write
One is passed directly into the method, the other can be retrieved by mapping the `output` buffe...https://gstreamer.pages.freedesktop.org/gstreamer-rs/git/docs/gstreamer_rtp/subclass/prelude/trait.RTPHeaderExtensionImpl.html#method.write
One is passed directly into the method, the other can be retrieved by mapping the `output` buffer another time.
Unclear how to solve that.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/363Refactor message view API2023-02-08T08:12:43ZGuillaume DesmottesRefactor message view API`gst::message::StreamCollection<'a>` can't easily be stored because of the lifetime, making the API less convenient to use. Having `gst::message::StreamCollection<gst::Message>` instead would make things easier for users.
See [here](htt...`gst::message::StreamCollection<'a>` can't easily be stored because of the lifetime, making the API less convenient to use. Having `gst::message::StreamCollection<gst::Message>` instead would make things easier for users.
See [here](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/586#note_1170554) and [here](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/586#note_1170555) for context.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/357Tracking issue for types missing `Since:` version annotation in C2021-09-28T12:39:49ZMarijn SuijtenTracking issue for types missing `Since:` version annotation in CAfter https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/863 two types remain with a `version =` override because their C specification is incomplete:
- [ ] `GstWebRTC.WebRTCSCTPTransport`
- [ ] `GstController.ProxyC...After https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/863 two types remain with a `version =` override because their C specification is incomplete:
- [ ] `GstWebRTC.WebRTCSCTPTransport`
- [ ] `GstController.ProxyControlBinding`
These need to be fixed in the C bindings and subsequently removed from `Gir.toml` when their `.gir` files reach `gst-gir-files`.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/352`extern "C"` functions called from C code should guard against unwinding2021-08-11T09:10:24ZSimonas Kazlauskas`extern "C"` functions called from C code should guard against unwindingAs far as I can tell https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/master/gstreamer/src/log.rs#L342-377 is called directly from GStreamer and then calls arbitrary Rust code. However it does not catch the unwinding that hap...As far as I can tell https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/master/gstreamer/src/log.rs#L342-377 is called directly from GStreamer and then calls arbitrary Rust code. However it does not catch the unwinding that happens from the Rust end, therefore being (I believe) unsound especially with versions of Rust that don't mitigate this by introducing trampolines that abort in these kinds of situations.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/346AppSinkStream is difficult to use2021-06-08T04:55:31ZAustin BonanderAppSinkStream is difficult to useI'm using Gstreamer to add a watermark to a video and then upload it to a video streaming service using a pipeline that looks something like this:
`appsrc ! decodebin ! rsvgoverlay ! encodebin ! appsink`
where the `appsrc` is being pus...I'm using Gstreamer to add a watermark to a video and then upload it to a video streaming service using a pipeline that looks something like this:
`appsrc ! decodebin ! rsvgoverlay ! encodebin ! appsink`
where the `appsrc` is being pushed data from a stream using `AppSrcSink` and then `AppSinkStream` is pushing data to the streaming service via `reqwest`.
However, I found that `AppSinkStream` will immediately yield `None` unless the `appsink` is actively streaming data (by looking at `AppSink::is_eos()`), which makes it difficult to use because I have to build the Gstreamer pipeline and start pushing to it to get that to start, but I'm doing something like this:
```rust
// build pipeline
// ...
// rsvgoverlay and its following elements aren't linked until `decodebin` emits the `pad-added` signal
tokio::try_join! {
appsrc.sink().send_all(&mut source_stream),
reqwest_client.post("some-url").body(appsink.stream().map(/* convert `Sample` to `bytes::Bytes` */)).send()
}
```
So the result is that the `reqwest` call uploads 0 bytes while the `appsrc` element is still being fed data.
I found a partial solution, to use `tokio::sync::Notify` to make the upload task wait until triggered:
```rust
let data_available = Arc::new(tokio::sync::Notify::new());
tokio::try_join! {
appsrc.sink().send_all(&mut source_stream),
async {
data_available.notified().await;
reqwest_client.post("some-url").body(appsink.stream().map(/* convert `Sample` to `bytes::Bytes` */)).send()
}
}
```
However, I can't find a suitable signal or callback to watch to know when to call `data_available.notify()`.
Connecting to the `pad-linked` signal on `appsink`'s `sink` pad doesn't quite get me there as data hasn't started flowing yet.
I thought of connecting to the notify signal for the `eos` property since I'd expect that to have a true->false transition as data starts being queued, but the code of `appsink` doesn't emit that signal internally.
I can set the `new-sample` callback but that would override what's set by `AppSink::stream()`, although I could just implement my own stream using a channel which wouldn't be too hard and is probably what I'll end up doing.
I could also set `emit-signals: true` connect to the `new-sample` signal but I don't want to take the performance hit (although maybe I could set `emit-signals: false` in the handler so it's only called once? would that break things?).
Any advice here? I don't know what I would change about `AppSinkStream` to make this easier. I think to fix it for my case would require it to always return `Pending` until it actually gets an `eos` callback, but would that be a breaking change to its behavior?https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/343Extend the example for EncodeBin by setting a specific encoder / bitrate / fr...2021-06-07T15:34:54ZRico BeierExtend the example for EncodeBin by setting a specific encoder / bitrate / framerate...It might be a useful addition the example of EncodeBin to show how the use can set more specific options for the Audio/Video-Encoding-Profiles like:
- a specific encoder (nvenc for h264, ...)
- bitrate, framerate, codec-specific quality ...It might be a useful addition the example of EncodeBin to show how the use can set more specific options for the Audio/Video-Encoding-Profiles like:
- a specific encoder (nvenc for h264, ...)
- bitrate, framerate, codec-specific quality options.
I combined the example of GES and EncodeBin to render a demo video. But I'm totally lost on how to be more specific about the used encoder and its settings.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/329Improve `TagList::add()` API to not require a reference2021-04-25T11:53:38ZSebastian DrögeImprove `TagList::add()` API to not require a referenceThe following discussion from !746 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/746#note_893002): (+5 comments)
> ```suggestion:-0+0
> pub ...The following discussion from !746 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/746#note_893002): (+5 comments)
> ```suggestion:-0+0
> pub fn add<'a, T: Tag<'a>>(&mut self, value: T::TagType, mode: TagMergeMode) {
> ```
>
> Would be better (we could pass `"foo"` instead of `&"foo"`) but that has the problem that we can then only pass a `gst::Buffer` and not a `&gst::Buffer`. Unclear how to allow both here.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/324Use `Pin<&CapsRef>` / `Pin<&mut CapsRef>` to prevent replacing them2021-05-09T16:18:05ZSebastian DrögeUse `Pin<&CapsRef>` / `Pin<&mut CapsRef>` to prevent replacing themNow that `Pin` is stable we can fix this soundness bug. I'll take a look at this in the next days.Now that `Pin` is stable we can fix this soundness bug. I'll take a look at this in the next days.Sebastian DrögeSebastian Drögehttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/321`embed-lgpl-docs` needs post-processing to make documentation valid and solve...2021-04-27T08:09:06ZMarijn Suijten`embed-lgpl-docs` needs post-processing to make documentation valid and solve warningsFrom https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/725#note_852087, so that we don't forget :)
Documenting for future reference: in the linked MR docs are now build-tested by the regular pipeline, showing quite ...From https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/725#note_852087, so that we don't forget :)
Documenting for future reference: in the linked MR docs are now build-tested by the regular pipeline, showing quite some warnings lately (mainly related to the addition of `autolinks` and `intra-doc-links` in `rustdoc`). See for example the latest run on `master` as of writing: https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/jobs/8363310.
- [ ] Links to preprocessor defines that do not exist anywhere in scope: `[GstValueArray](GST_TYPE_ARRAY)` - these should probably be `#GST_TYPE_ARRAY` or `%GST_TYPE_ARRAY` in the source;
- [ ] URLs that should have been auto-links wrapped in `<>`, otherwise they are not clickable;
- [ ] Links to ffi functions: `[Rendering settings](ges_pipeline_set_render_settings)` - this is valid if the link was `ffi::ges_pipeline_set_render_settings`, but the documentation should obviously link to the safe function: `Self::set_render_settings`.
_EDIT: This pattern seems more prevalent in the source, we probably just need to map `[](<something linkable>)` with C symbols just like we do for `[#%]` already_;
- [ ] `[something]` pattern is detected as intra-doc-link, ie. `[0,1]`. These should simply be escaped as `` `[0,1]` `` in the documentation IMO.
Future improvements, not necessarily related to these warnings:
- [x] ~~(gir) Stop emitting `` Feature: `XXX` `` when https://github.com/gtk-rs/gir/issues/1079 is solved: feature requirements are already displayed in a nice, uniform, obvious, consistent way. No need to repeat it in text~~ Will be fixed by https://github.com/gtk-rs/gir/pull/1086;
- [ ] C source does not use `@`/`#` everywhere, leading to missing links.
Part of these issues are probably better moved to the respective (GStreamer-XXX C repos, `gir`), but at least we can back-reference here and cross them off.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/309ci: couple of potential improvements2021-01-27T14:48:00ZGuillaume Desmottesci: couple of potential improvementsWhile [porting zbus's ci to fdo template](https://gitlab.freedesktop.org/zeenix/zbus/-/merge_requests/238) I experimented with a couple of changes:
- Installing Rust stable and nightly on the same image, using `rustup override set $x` i...While [porting zbus's ci to fdo template](https://gitlab.freedesktop.org/zeenix/zbus/-/merge_requests/238) I experimented with a couple of changes:
- Installing Rust stable and nightly on the same image, using `rustup override set $x` in each job to pick the version we want. This would help simplifying our ci setup as we'd have only one image instead of 3 (4 including the base one).
- Calling `cargo fetch` when generating the image so build deps are part of the image, saving each job to re-download them. Only worth if images are refreshed frequently enough that those deps stay relevant. Shouldn't be a problem if we regenerate the image each week for nightly I think.
We can wait a bit to see how it works for `zbus` and then consider doing the same for our ci here.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/292sys: rtpbuffer: onebyte and twobyte get functions have wrong signature2020-11-01T07:51:11ZThiago Sousa Santossys: rtpbuffer: onebyte and twobyte get functions have wrong signatureThe return data pointer is marked as `data: *mut u8` but it is a pointer to a pointer, so we need to do ugly pointer management on rust side to be able to use it.
```
let mut data = ptr::null_mut();
let data_ptr = &mut data as *mut *mut...The return data pointer is marked as `data: *mut u8` but it is a pointer to a pointer, so we need to do ugly pointer management on rust side to be able to use it.
```
let mut data = ptr::null_mut();
let data_ptr = &mut data as *mut *mut u8 as *mut u8;
```
it would be easier if it took a `*mut *mut u8` or some other way to make this easier to use and read.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/291sys: Wrong signature for GstBaseSrcClass create/alloc & GstBaseTransform tran...2020-11-01T07:50:56ZSebastian Drögesys: Wrong signature for GstBaseSrcClass create/alloc & GstBaseTransform transform_iphttps://github.com/sdroege/gstreamer-sys/blob/8b735ff536f096070735416c22d42153d272c06e/gstreamer-base-sys/src/lib.rs#L157-L158
These should be `*mut *mut GstBuffer`https://github.com/sdroege/gstreamer-sys/blob/8b735ff536f096070735416c22d42153d272c06e/gstreamer-base-sys/src/lib.rs#L157-L158
These should be `*mut *mut GstBuffer`https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/284Make GstClockTimeDiff a new type2024-01-16T12:55:59ZJan Alexander SteffensMake GstClockTimeDiff a new typeThe following discussion from !600 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/600#note_649479): (+2 comments)
> There's not much API using `Clock...The following discussion from !600 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/600#note_649479): (+2 comments)
> There's not much API using `ClockTimeDiff` but if you think that makes sense, go for it :)
>
> IMHO we should use it more often in C. Even something like `GST_BUFFER_DURATION()` is technically a `GstClockTimeDiff`: `GstClockTime` is an absolute point in time while `GstClockTimeDiff` is a duration.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/283Crash on GStreamer < 1.16.1 when adding a non-GstAggregatorPad pad to GstAggr...2020-10-21T13:46:20ZElie GénardCrash on GStreamer < 1.16.1 when adding a non-GstAggregatorPad pad to GstAggregator subclassesHello,
I'm writing a plugin that inherits from `Aggregator` and it segfaults when running on the Jetson Nano (Jetpack, based on Ubuntu 18.04 - ARM arch) but not on my laptop (Ubuntu 20.04 - x86 arch).
When I run a simple pipeline with ...Hello,
I'm writing a plugin that inherits from `Aggregator` and it segfaults when running on the Jetson Nano (Jetpack, based on Ubuntu 18.04 - ARM arch) but not on my laptop (Ubuntu 20.04 - x86 arch).
When I run a simple pipeline with `gdb`, the backtrace is not very explicit:
```
#0 0x0000007fb7d657a8 in g_slice_alloc () at /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#1 0x0000007fb7d65d44 in g_slice_alloc0 () at /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#2 0x0000007fb7e3fbe0 in g_type_create_instance () at /usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0
#3 0x0000007fb7e1f764 in () at /usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0
#4 0x0000007fffffc538 in ()
```
I've been able to reproduce it with a minimal implementation of the aggregator and I put it [here](https://github.com/elaye/gst-agg-bug).
The funny thing is that it works when I run it with `valgrind`, so it seems like it may be a race condition.
Am I missing something in my Aggregator implementation? If not, do you have an idea about how I can debug this?https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/279basetransform: confusing error message when implementing the wrong `transform...2020-07-29T12:14:22ZMatthew Watersmatthew@centricular.combasetransform: confusing error message when implementing the wrong `transform_ip`When configuring GstBaseTransfrom with:
```
klass.configure(
gst_base::subclass::BaseTransformMode::AlwaysInPlace,
true,
true,
);
```
but overriding `transfrom_ip` instead of `transform_ip_passthrough`, results in this slig...When configuring GstBaseTransfrom with:
```
klass.configure(
gst_base::subclass::BaseTransformMode::AlwaysInPlace,
true,
true,
);
```
but overriding `transfrom_ip` instead of `transform_ip_passthrough`, results in this slightly confusing message:
```
---- test_cc_data_window stdout ----
thread 'thread_name' panicked at 'Missing parent function `transform_ip`. Required because transform element operates in-place (passthrough mode)', <::std::macros::panic macros>:2:4
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:77
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:59
4: core::fmt::write
at src/libcore/fmt/mod.rs:1052
5: std::io::Write::write_fmt
at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/io/mod.rs:1426
6: std::io::impls::<impl std::io::Write for alloc::boxed::Box<W>>::write_fmt
at src/libstd/io/impls.rs:156
7: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:62
8: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:49
9: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:204
10: std::panicking::default_hook
at src/libstd/panicking.rs:221
11: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:472
12: std::panicking::begin_panic
at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panicking.rs:399
13: <T as gstreamer_base::subclass::base_transform::BaseTransformImplExt>::parent_transform_ip_passthrough::{{closure}}
at /home/matt/Projects/gst/gst-build/subprojects/gst-plugins-rs/<::std::macros::panic macros>:2
14: core::option::Option<T>::unwrap_or_else
at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libcore/option.rs:422
15: <T as gstreamer_base::subclass::base_transform::BaseTransformImplExt>::parent_transform_ip_passthrough
at /home/matt/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/4648cf1/gstreamer-base/src/subclass/base_transform.rs:659
16: gstreamer_base::subclass::base_transform::BaseTransformImpl::transform_ip_passthrough
at /home/matt/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/4648cf1/gstreamer-base/src/subclass/base_transform.rs:135
17: gstreamer_base::subclass::base_transform::base_transform_transform_ip::{{closure}}
at /home/matt/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/4648cf1/gstreamer-base/src/subclass/base_transform.rs:1232
18: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panic.rs:318
19: std::panicking::try::do_call
at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panicking.rs:305
20: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:86
21: std::panicking::try
at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panicking.rs:281
22: std::panic::catch_unwind
at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panic.rs:394
23: gstreamer_base::subclass::base_transform::base_transform_transform_ip
at /home/matt/Projects/gst/gst-build/subprojects/gst-plugins-rs/<::gstreamer::subclass::error::gst_panic_to_error macros>:15
24: default_generate_output
at ../subprojects/gstreamer/libs/gst/base/gstbasetransform.c:2178
```https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/278gtksink.rs example doesn't handle missing GL dependencies2020-10-21T13:46:39ZIvan Molodetskikhgtksink.rs example doesn't handle missing GL dependenciesThe gtksink.rs example [handles](https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/9cb40878f01f6ca3d6c20b0fe9843cacfbc69b8f/examples/src/bin/gtksink.rs#L30) a failing `gtkglsink` construction, however I've never hit that in pr...The gtksink.rs example [handles](https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/9cb40878f01f6ca3d6c20b0fe9843cacfbc69b8f/examples/src/bin/gtksink.rs#L30) a failing `gtkglsink` construction, however I've never hit that in practice on any of the VMs I've tested on. What I did hit was Ubuntu 18.04 Software not installing the GL dependency for an application, which results in `pipeline.set_state(Playing)` returning an error with subsequent GL errors delivered to the bus:
```
(video-trimmer:2): VideoTrimmer-WARNING **: 10:45:50.977: pipeline.set_state(Playing) error: Element failed to change its state
(video-trimmer:2): VideoTrimmer-WARNING **: 10:45:50.989: Error from Some(GString(Foreign(0x562b5ab95040, 42))): Failed to initialize OpenGL with Gtk (Some("../ext/gtk/gstgtkglsink.c(186): gst_gtk_gl_sink_start (): /GstGLSinkBin:glsinkbin0/GstGtkGLSink:sink"))
(video-trimmer:2): VideoTrimmer-WARNING **: 10:45:50.989: Error from Some(GString(Foreign(0x562b5ab95040, 42))): GStreamer error: state change failed and some element failed to post a proper error message with the reason for the failure. (Some("../libs/gst/base/gstbasesink.c(5367): gst_base_sink_change_state (): /GstGLSinkBin:glsinkbin0/GstGtkGLSink:sink:\nFailed to start"))
```https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/262ci: add job trying to update gir and generated code2022-09-16T07:41:08ZGuillaume Desmottesci: add job trying to update gir and generated codeIt would be nice to have a scheduled job trying to update gir files from gst-build and regenerate code. It won't actually do the upgrade (no commit) but would help finding issues sooner than later.It would be nice to have a scheduled job trying to update gir files from gst-build and regenerate code. It won't actually do the upgrade (no commit) but would help finding issues sooner than later.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/253Pin gst-build to a specific commit2020-05-05T07:25:59ZVivia NikolaidouPin gst-build to a specific commitSee https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/483#note_483867
cc @slomo @gdesmottSee https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/483#note_483867
cc @slomo @gdesmott