GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2024-03-05T11:29:29Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3351GStreamer 1.25.1 unstable development snapshot release tracker2024-03-05T11:29:29ZTim-Philipp Müllertim@centricular.comGStreamer 1.25.1 unstable development snapshot release tracker# Milestone 1.25.1
- Milestone 1.25.1 Overview: %1.25.1
- ETA: tbd
# Todo
- [~] [Merge Requests with `Needs backport` label](https://gitlab.freedesktop.org/groups/gstreamer/-/merge_requests?scope=all&state=merged&label_name[]=Needs%20...# Milestone 1.25.1
- Milestone 1.25.1 Overview: %1.25.1
- ETA: tbd
# Todo
- [~] [Merge Requests with `Needs backport` label](https://gitlab.freedesktop.org/groups/gstreamer/-/merge_requests?scope=all&state=merged&label_name[]=Needs%20backport¬[label_name][]=Backported%20into%201.24)
- [~] [Issues with `Needs backport` label](https://gitlab.freedesktop.org/groups/gstreamer/-/issues?scope=all&utf8=%E2%9C%93&state=all&label_name[]=Needs%20backport)
- [~] [Merge Requests with `Maybe backport` label](https://gitlab.freedesktop.org/groups/gstreamer/-/merge_requests?scope=all&utf8=%E2%9C%93&state=all&label_name[]=Maybe%20backport)
- [ ] [Merge Requests with `1.25.1` milestone](https://gitlab.freedesktop.org/groups/gstreamer/-/merge_requests?milestone_title=1.25.1)
- [ ] [Issues with `1.25.1` milestone](https://gitlab.freedesktop.org/groups/gstreamer/-/issues?milestone_title=1.25.1)
- [ ] [Issues with `Security` label](https://gitlab.freedesktop.org/groups/gstreamer/-/issues?scope=all&utf8=%E2%9C%93&state=all&label_name[]=Security)
- [ ] Blockers / Todo
- nothing so far
# Prep
- [ ] gst-plugins-rs
- [~] make sure `main` branch is up-to-date with regards to backports
- [~] update `Cargo.lock` in `main` branch (if needed)
- [ ] double-check version in `meson.build` matches version in `Cargo.toml`
- [ ] add `gstreamer-1.25.1` tag pointing to current tip of `main` branch
- [ ] www: add release note entry and add contributors
- [ ] update translations
# GStreamer
- [ ] MR / commit for release
- [ ] tag release
- [ ] upload tarballs (plus checksums and GPG signatures)
- [ ] back to dev
# Cerbero
- [ ] build 1.25.1 tag
- [ ] binaries
- [ ] Windows x86 MinGW + MSVC (@nirbheek)
- [ ] Windows x86_64 MinGW + MSVC (@nirbheek)
- [ ] Android
- [ ] macOS (@ystreet)
- [ ] iOS (@ystreet)
- [ ] source bundle
- [ ] check for sha265sums for binaries
- [ ] check for GPG signatures for binaries
- [ ] tag cerbero (@tpm)
- [ ] build `main` branch again
- [~] update download section on website~~ (not advertising unstable binaries at the moment
- [ ] announce binaries (twitter, gstreamer-devel)
# Announce
- [ ] Discourse
- [ ] Website: news item
- [ ] Twitter (@tpm)
- [ ] Mastodon (@slomo)
- [ ] IRC channel topic
- [ ] Mailing lists
# Post release
- [ ] add 1.25.2 milestone
- [ ] add 1.25.2 tracker issue
- [~] after 1.26.0 make sure gst-plugins-rs and orc wrap follow `main` branch again1.25.1Tim-Philipp Müllertim@centricular.comTim-Philipp Müllertim@centricular.com2024-04-05https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/335vp9 causes Internal data stream error2024-03-05T06:54:41ZBram Stolkvp9 causes Internal data stream errorA pipeline with `vaapih264enc ! vaapih264dec` works fine.
Similarly, `vaapih265enc ! vaapih265dec` works, but if I try `vaapivp9enc ! vaapivp9dec` I get an internal data stream error:
```
$ gst-launch-1.0 videotestsrc ! video/x-raw,wi...A pipeline with `vaapih264enc ! vaapih264dec` works fine.
Similarly, `vaapih265enc ! vaapih265dec` works, but if I try `vaapivp9enc ! vaapivp9dec` I get an internal data stream error:
```
$ gst-launch-1.0 videotestsrc ! video/x-raw,width=1920,height=1080 ! vaapivp9enc ! vaapivp9dec ! vaapisink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapisink0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayWayland\)\ vaapidisplaywayland0", gst.vaapi.Display.GObject=(GstObject)"\(GstVaapiDisplayWayland\)\ vaapidisplaywayland0";
ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Internal data stream error.
Additional debug info:
../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0:
streaming stopped, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
```
OS: Ubuntu 22.10
CPU: 12600k
GPU: Intel ADL-S
gstreamer version: 1.20.3-2
vainfo:
```
$ vainfo
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/local/lib/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.17 (libva 2.12.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 22.6.0 (54d0e8288)
```
package versions:
```
$ dpkg --list | grep gstreamer
ii gir1.2-gstreamer-1.0:amd64 1.20.3-1 amd64 GObject introspection data for the GStreamer library
ii gstreamer1.0-alsa:amd64 1.20.3-2 amd64 GStreamer plugin for ALSA
ii gstreamer1.0-gl:amd64 1.20.3-2 amd64 GStreamer plugins for GL
ii gstreamer1.0-libav:amd64 1.20.3-1ubuntu2 amd64 ffmpeg plugin for GStreamer
ii gstreamer1.0-packagekit 1.2.5-2ubuntu2 amd64 GStreamer plugin to install codecs using PackageKit
ii gstreamer1.0-pipewire:amd64 0.3.58-2ubuntu1 amd64 GStreamer 1.0 plugin for the PipeWire multimedia server
ii gstreamer1.0-plugins-base:amd64 1.20.3-2 amd64 GStreamer plugins from the "base" set
ii gstreamer1.0-plugins-base-apps 1.20.3-2 amd64 GStreamer helper programs from the "base" set
ii gstreamer1.0-plugins-good:amd64 1.20.3-1ubuntu1 amd64 GStreamer plugins from the "good" set
ii gstreamer1.0-plugins-ugly:amd64 1.20.3-1 amd64 GStreamer plugins from the "ugly" set
ii gstreamer1.0-tools 1.20.3-1 amd64 Tools for use with GStreamer
ii gstreamer1.0-vaapi:amd64 1.20.3-1 amd64 VA-API plugins for GStreamer
ii gstreamer1.0-x:amd64 1.20.3-2 amd64 GStreamer plugins for X11 and Pango
ii libgstreamer-gl1.0-0:amd64 1.20.3-2 amd64 GStreamer GL libraries
ii libgstreamer-plugins-bad1.0-0:amd64 1.20.3-1ubuntu6 amd64 GStreamer libraries from the "bad" set
ii libgstreamer-plugins-base1.0-0:amd64 1.20.3-2 amd64 GStreamer libraries from the "base" set
ii libgstreamer-plugins-good1.0-0:amd64 1.20.3-1ubuntu1 amd64 GStreamer development files for libraries from the "good" set
ii libgstreamer1.0-0:amd64 1.20.3-1 amd64 Core GStreamer libraries and elements
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3208d3d11screencapturesrc: frames lost2024-03-04T15:46:51ZMaurizio Buratod3d11screencapturesrc: frames lostI noticed that periodically some frames are missing in the d3d11screencapturesrc capture.
To reproduce the problem I used this test video: ![30fps_judder_test](/uploads/28c751a92185986bb700406f7f18e428/30fps_judder_test.mp4) played in v...I noticed that periodically some frames are missing in the d3d11screencapturesrc capture.
To reproduce the problem I used this test video: ![30fps_judder_test](/uploads/28c751a92185986bb700406f7f18e428/30fps_judder_test.mp4) played in vlc. then i capture vlc with this pipeline:
`gst-launch-1.0.exe -e d3d11screencapturesrc capture-api=1 window-handle=2229322 window-capture-mode=1 ! queue ! d3d11videosink`
in this video you can see the results: ![20240107_022310](/uploads/642deccb787c2c6ddace7d0698fa30a4/20240107_022310.mp4)
on the right vlc player, on the left d3d11screencapturesrc capturing vlc
if you look at 00:05 the captured video is not smooth and it looks like some frames are dropped. this problem occurs occasionally however at least 1 time every 5 minutes. I tried the same test with other tools that use windows graphics capture api and and i didn't see this problem.
Could you please check if d3d11screencapturesrc can loose frames in some situation?
i'm testing Gstreamer version=1.23.0.1 artifactshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1171soup, adaptivedemux2: soup loader is broken on macOS devenv and brew2024-03-04T14:58:30ZTim-Philipp Müllertim@centricular.comsoup, adaptivedemux2: soup loader is broken on macOS devenv and brew~~WIN32: Looks like it might not be found in a dev build, possibly owing to the versioned DLL filename. Needs investigating/fixing.~~
MACOS: Unable to find the dylibs:
```
$ rm -f foo.bin && GST_REGISTRY=foo.bin GST_DEBUG=*soup*:6 gst-...~~WIN32: Looks like it might not be found in a dev build, possibly owing to the versioned DLL filename. Needs investigating/fixing.~~
MACOS: Unable to find the dylibs:
```
$ rm -f foo.bin && GST_REGISTRY=foo.bin GST_DEBUG=*soup*:6 gst-inspect-1.0 adaptivedemux2
0:00:00.442620000 98329 0x7f8edff0b380 DEBUG adaptivedemux2-soup gstsouploader.c:179:gst_soup_load_library: Trying all libsoups
0:00:00.443058000 98329 0x7f8edff0b380 DEBUG adaptivedemux2-soup gstsouploader.c:303:gst_soup_load_library: Module libsoup-3.0.0.dylib not found
0:00:00.443440000 98329 0x7f8edff0b380 DEBUG adaptivedemux2-soup gstsouploader.c:303:gst_soup_load_library: Module libsoup-2.4.1.dylib not found
0:00:00.444688000 98329 0x7f8edff0b380 DEBUG adaptivedemux2-soup gstsouploader.c:179:gst_soup_load_library: Trying all libsoups
0:00:00.445022000 98329 0x7f8edff0b380 DEBUG adaptivedemux2-soup gstsouploader.c:303:gst_soup_load_library: Module libsoup-3.0.0.dylib not found
0:00:00.445450000 98329 0x7f8edff0b380 DEBUG adaptivedemux2-soup gstsouploader.c:303:gst_soup_load_library: Module libsoup-2.4.1.dylib not found
0:00:00.446701000 98329 0x7f8edff0b380 DEBUG adaptivedemux2-soup gstsouploader.c:179:gst_soup_load_library: Trying all libsoups
0:00:00.447036000 98329 0x7f8edff0b380 DEBUG adaptivedemux2-soup gstsouploader.c:303:gst_soup_load_library: Module libsoup-3.0.0.dylib not found
0:00:00.447401000 98329 0x7f8edff0b380 DEBUG adaptivedemux2-soup gstsouploader.c:303:gst_soup_load_library: Module libsoup-2.4.1.dylib not found
0:00:00.475441000 98329 0x7f8edff0b380 DEBUG souputils gstsoupelement.c:38:soup_element_init: binding text domain gst-plugins-good-1.0 to locale dir /usr/local/share/locale
0:00:00.476567000 98329 0x7f8edff0b380 DEBUG soup gstsouploader.c:179:gst_soup_load_library: Trying all libsoups
0:00:00.476947000 98329 0x7f8edff0b380 DEBUG soup gstsouploader.c:303:gst_soup_load_library: Module libsoup-3.0.0.dylib not found
0:00:00.477404000 98329 0x7f8edff0b380 DEBUG soup gstsouploader.c:303:gst_soup_load_library: Module libsoup-2.4.1.dylib not found
0:00:00.477417000 98329 0x7f8edff0b380 WARN souputils gstsoupelement.c:61:soup_element_init: Failed to load libsoup library
0:00:00.478545000 98329 0x7f8edff0b380 DEBUG soup gstsouploader.c:179:gst_soup_load_library: Trying all libsoups
0:00:00.478917000 98329 0x7f8edff0b380 DEBUG soup gstsouploader.c:303:gst_soup_load_library: Module libsoup-3.0.0.dylib not found
0:00:00.479374000 98329 0x7f8edff0b380 DEBUG soup gstsouploader.c:303:gst_soup_load_library: Module libsoup-2.4.1.dylib not found
0:00:00.479386000 98329 0x7f8edff0b380 WARN souputils gstsoupelement.c:61:soup_element_init: Failed to load libsoup library
Plugin Details:
Name adaptivedemux2
Description Adaptive Streaming 2 plugin
Filename /path/to/builddir/subprojects/gst-plugins-good/ext/adaptivedemux2/libgstadaptivedemux2.dylib
Version 1.21.1.1
License LGPL
Source module gst-plugins-good
Documentation https://gstreamer.freedesktop.org/documentation/adaptivedemux2/
Binary package GStreamer Good Plug-ins git
Origin URL Unknown package origin
0 features:
```1.23.90Stéphane Cerveauscerveau@igalia.comStéphane Cerveauscerveau@igalia.comhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3268gst-plugins-good: soup test does not respect the library option2024-03-04T14:58:30Zamysparkgst-plugins-good: soup test does not respect the library optionHi,
I was testing a build of GStreamer here, and I discovered that when specifying `-Dsoup=disabled` this is not respected by the testsuite, ie. the library lookup is repeated and the corresponding tests added, despite the actual plugin...Hi,
I was testing a build of GStreamer here, and I discovered that when specifying `-Dsoup=disabled` this is not respected by the testsuite, ie. the library lookup is repeated and the corresponding tests added, despite the actual plugin being missing.
Is this an expected outcome? In my case, since I was working around conflicting libsoup versions, it means that I will 100% get a linker failure in the plugin or in the test executable (depending on which gets linked first).https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/193uriplaylistbin: rewrite pad blocking logic2024-03-04T13:18:27ZGuillaume Desmottesuriplaylistbin: rewrite pad blocking logic[As discussed here](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/718#note_1330617) the current code blocking pads using channels is very prone to deadlocks. It may be good to rewrite it using a safer pattern.[As discussed here](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/718#note_1330617) the current code blocking pads using channels is very prone to deadlocks. It may be good to rewrite it using a safer pattern.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/268uriplaylistbin: look at decodebin32024-03-04T13:18:27ZGuillaume Desmottesuriplaylistbin: look at decodebin3`decodebin3` [received a bunch of gapless related improvements](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2784) in 1.22.
It would be interesting to look if some of those could be used to simplify `uriplaylistbin`.`decodebin3` [received a bunch of gapless related improvements](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2784) in 1.22.
It would be interesting to look if some of those could be used to simplify `uriplaylistbin`.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/194uriplaylistbin: racy tests2024-03-04T13:18:26ZGuillaume Desmottesuriplaylistbin: racy testsThe `missing_http` test is racy: https://gitlab.freedesktop.org/gdesmott/gst-plugins-rs/-/jobs/20908861The `missing_http` test is racy: https://gitlab.freedesktop.org/gdesmott/gst-plugins-rs/-/jobs/20908861https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/508gtk4paintablesink: causes entire memory to fill up when use-scaling-filter=tr...2024-03-03T14:44:03ZDave Patrick Cabertogtk4paintablesink: causes entire memory to fill up when use-scaling-filter=true and on 2x desktop scaling### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstream...### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstreamer.freedesktop.org/lists/ -->
Running the example in the tree with `gtk_v4_14` feature enabled, `use-scaling-filter=true` on the paintable, and using 2x desktop scaling cause system memory to fill up and eventually freeze the system and trigger `systemd-oomd`.
I btw didn't test this in fractional scaling, but works just fine with default 1x scaling.
#### Expected Behavior
<!-- What did you expect to happen -->
It should work just fine with as-usual KB/MB usage of memory.
#### Observed Behavior
<!-- What actually happened -->
16GB of memory gets filled up.
#### Setup
- **Operating System:** Fedora Linux 39.20240228.0 (Silverblue) (Linux 6.7.6-200.fc39.x86_64)
- **Device:** Computer (AMD Ryzen 5 5600G)
- **gst-plugins-rs Version:** 0.12 (also reproducible in main branch)
- **GTK version:** 4.13.9-74860f7
- **GStreamer Version:** 1.22.8
- **Command line:** bash
This is also reproducible on an Intel Laptop.
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. Clone repository
1. Modify `gst-plugins-rs/video/gtk4/examples/gtksink.rs` by setting paintable `use-scaling-filter=true`:
```rust
paintable.set_property("use-scaling-filter", true);
```
3. Run `cd gst-plugins-rs/video/gtk4`
3. Set device scaling to 2x (This is on `Displays > Scale > 200%` in GNOME Control Center)
3. Run `cargo run --example gtksink --features gtk_v4_14`
3. Wait memory to fill up and freeze system (this happens within the first 3 seconds after running the command)
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Always
### Solutions you have tried
* Leaving `use-scaling-filter` to default
* Using default 100% scalinghttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/507nasm build failed during building gstreamer with gstreamer rs plugin2024-03-01T10:02:56ZRoshan Avhadnasm build failed during building gstreamer with gstreamer rs pluginWhen i am building gstreamer with this :
run meson setup --reconfigure . ../$SOURCE_DIR \
--buildtype release --unity off --strip \
--prefix=$INSTALL_PREFIX \
--libdir=$INSTALL_PREFIX/lib \
--default...When i am building gstreamer with this :
run meson setup --reconfigure . ../$SOURCE_DIR \
--buildtype release --unity off --strip \
--prefix=$INSTALL_PREFIX \
--libdir=$INSTALL_PREFIX/lib \
--default-library shared \
--wrap-mode=nofallback \
-Dorc-source=system \
-Dgpl=enabled \
-Drs=enabled \
-Dgstreamer:check=enabled \
-Dexamples=disabled -Dtests=enabled -Dgtk_doc=disabled \
-Dpackage-origin="$GIT_REPO" $OPTS \
"$@"
I am getting below error : ![Screenshot_from_2024-03-01_14-43-30](/uploads/b5f09741558486950bb9693ab89c7e79/Screenshot_from_2024-03-01_14-43-30.png)
how to resolve this ?https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/506Can't connect nvh264enc to webrtcsink2024-03-01T09:51:14ZChris Del GuercioCan't connect nvh264enc to webrtcsinkI have a **webrtcsink** element that I am adding a **nvh264enc** encoder to via the "encoder-setup" signal.
I see vram being used by the program in `nvidia-smi` and I see an encoder session being created, however the encoder session sho...I have a **webrtcsink** element that I am adding a **nvh264enc** encoder to via the "encoder-setup" signal.
I see vram being used by the program in `nvidia-smi` and I see an encoder session being created, however the encoder session shows 0, 0 for fps and latency
```
# GPU Session Process Codec H V Average Average
# Idx Id Id Type Res Res FPS Latency(us)
0 9 623032 H.264 480 304 0 0
```
I also know that it isn't using the nvh264enc encoder because changing the bitrate and max-bitrate does nothing to the bandwidth usage observed via `nload`
I am using **HEAD** of _gst-plugins-rs_ and I've tried using both **1.22.10** and **1.23.90** for _nvcodec_.
I am running this in a podman container and I'm 99% sure I've set up the nvidia container stuff up correct since if I don't, `nvidia-smi` complains if I try to run it in the container.
Here are the relevant snippets of my code. Any help would be greatly appreciated :)
```cpp
// main
///////
g_object_set(G_OBJECT(webrtcsink), "meta",
gst_structure_from_string(("meta,name=" + webrtc_stream_id).c_str(), nullptr), nullptr);
GstCaps* webrtcsink_caps = gst_caps_from_string("video/x-h264,stream-format=byte-stream,alignment=au");
g_object_set(G_OBJECT(webrtcsink), "video-caps", webrtcsink_caps, nullptr);
gst_caps_unref(webrtcsink_caps);
g_object_set(G_OBJECT(webrtcsink), "congestion-control", 0, nullptr);
//g_object_set(G_OBJECT(webrtcsink), "max-bitrate", 2048000, nullptr);
g_signal_connect(webrtcsink, "encoder-setup", G_CALLBACK(EncoderSetupCallback), nullptr);
// pipeline
///////////
src -> watchdog -> bayer2rgb -> videorate -> videorate_capsfilter -> videoconvert -> queue -> webrtcsink
// callback
///////////
gboolean EncoderSetupCallback(GstElement* webrtcsink, gchararray arg0, gchararray arg1,
GstElement* encoder, gpointer udata) {
if (!GST_IS_ELEMENT(webrtcsink) || !arg0 || !arg1 || !GST_IS_ELEMENT(encoder)) {
g_warning("Invalid arguments received in EncoderSetupCallback.");
return false;
}
// Create an instance of the nvh264enc encoder.
encoder = gst_element_factory_make("nvh264enc", "nvh264enc");
if (encoder == nullptr || !GST_IS_ELEMENT(encoder)) {
g_warning("Failed to create nvh264enc encoder.");
return false;
}
g_warning("Created nvh264enc encoder.");
g_object_set(G_OBJECT(encoder), "preset", 3, nullptr);
g_object_set(G_OBJECT(encoder), "bitrate", 2048, nullptr);
g_object_set(G_OBJECT(encoder), "max-bitrate", 2048, nullptr);
g_object_set(G_OBJECT(encoder), "rc-mode", 3, nullptr);
return encoder != nullptr;
}
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/505Issue setting signaller:channel-name for awskvswebrtcsink in rust2024-03-01T09:49:05Zmzang3Issue setting signaller:channel-name for awskvswebrtcsink in rust### Describe your issue
Trying to change update the properties of the awskvswebrtcsink
```rust
let aws_kvs_signaller = gst::ElementFactory::make_with_name("awskvswebrtcsink", Some("awskvswebrtcsink"));
```
I've tried this:
```rust
...### Describe your issue
Trying to change update the properties of the awskvswebrtcsink
```rust
let aws_kvs_signaller = gst::ElementFactory::make_with_name("awskvswebrtcsink", Some("awskvswebrtcsink"));
```
I've tried this:
```rust
let signaller = aws_kvs_signaller.property_value("signaller");
let new_signaller = signaller.get_owned().unwrap();
new_signaller.set_property("channel-name", "xxxx");
aws_kvs_signaller.set_property("signaller", signaller);
```
also:
```rust
aws_kvs_signaller.set_property("signaller", "signaller, channel-name=xxx");
```
and also
```rust
aws_kvs_signaller.set_property("signaller::channel-name", "xxx");
```
#### Expected Behavior
Be able to change the signaller properties like in the CLI
#### Observed Behavior
`GstAwsKvsWebRTCSinkSignaller` is read onlyhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3342mpegtsmux: adjusting input buffer pts doesn't fully control output pts2024-03-01T03:33:05ZFrans de Jongempegtsmux: adjusting input buffer pts doesn't fully control output pts`mpegtsmux` seems to only write MPEGTS PTS values based on an internal clock. Controlling these values is important if you want to create matching segments for HLS for example.
Take a command like the following:
```
gst-launch-1.0 audio...`mpegtsmux` seems to only write MPEGTS PTS values based on an internal clock. Controlling these values is important if you want to create matching segments for HLS for example.
Take a command like the following:
```
gst-launch-1.0 audiotestsrc timestamp-offset=50000000000 ! fdkaacenc ! mpegtsmux ! filesink location=/tmp/test.ts
```
Then run:
```
ffprobe -show_frames /tmp/test.ts | head -n 10
```
#### Expected Behavior
The expected output might look something like this:
```
[FRAME]
media_type=audio
stream_index=0
key_frame=1
pts=4500000
pts_time=50.000000
pkt_dts=4500000
pkt_dts_time=50.000000
best_effort_timestamp=4500000
best_effort_timestamp_time=50.000000
```
#### Observed Behavior
The actual output looks like this:
```
[FRAME]
media_type=audio
stream_index=0
key_frame=1
pts=328500000
pts_time=3650.000000
pkt_dts=328500000
pkt_dts_time=3650.000000
best_effort_timestamp=328500000
best_effort_timestamp_time=3650.000000
```
#### Setup
- **Operating System:** Debian/Ubuntu
- **Device:** Computer
- **GStreamer Version:** 1.18.4 – 1.23.90
### How reproducible is the bug?
Always.
### Solutions you have tried
`avmux_mpegts` works as expected.
So does `mpegtsmux` when commenting out these lines:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/dd8ef3ec1bebb20bb12474bce21f0b61c53a376c/subprojects/gst-plugins-bad/gst/mpegtsmux/tsmux/tsmux.c#L1660-1663
They were added in ead42a5e270d5faef419d6b5d2885d9cb1b537cf.https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/37android x86_64 fails to link with possible overflows for relocations in custo...2024-03-01T02:40:51ZBugzilla Migration Userandroid x86_64 fails to link with possible overflows for relocations in custom assembly## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#795190)](https://bugzilla.gnome.org/show_bug.cgi?id=795190)**
## Description
Linking an android application including libav (e.g. the gstplayer android example) fai...## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#795190)](https://bugzilla.gnome.org/show_bug.cgi?id=795190)**
## Description
Linking an android application including libav (e.g. the gstplayer android example) fails to link for x86_64 with the following error.
Compiling against v23 of the Android SDK with v26.0.2 of the build tools targeting android-15.
A quick look into fixing this involves fixing the assembly to be more PIC aware and use the appropriate ELF offset symbols/tables.
Log:
/home/matt/Projects/cerbero/build/android-ndk-r16/toolchains/x86_64-4.9/prebuilt/linux-x86_64/lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin/ld.gold: error: /home/matt/Projects/cerbero/build/dist/android_universal/x86_64/lib/libavcodec.a(simple_idct10.o): requires dynamic R_X86_64_PC32 reloc against 'ff_pw_32' which may overflow at runtime; recompile with -fPIC
/home/matt/Projects/cerbero/build/android-ndk-r16/toolchains/x86_64-4.9/prebuilt/linux-x86_64/lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin/ld.gold: error: /home/matt/Projects/cerbero/build/dist/android_universal/x86_64/lib/libavcodec.a(vc1dsp_loopfilter.o): requires dynamic R_X86_64_PC32 reloc against 'ff_pw_5' which may overflow at runtime; recompile with -fPIC
/home/matt/Projects/cerbero/build/android-ndk-r16/toolchains/x86_64-4.9/prebuilt/linux-x86_64/lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin/ld.gold: error: /home/matt/Projects/cerbero/build/dist/android_universal/x86_64/lib/libavcodec.a(vc1dsp_mc.o): requires dynamic R_X86_64_PC32 reloc against 'ff_pw_9' which may overflow at runtime; recompile with -fPIC
/home/matt/Projects/cerbero/build/android-ndk-r16/toolchains/x86_64-4.9/prebuilt/linux-x86_64/lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin/ld.gold: error: /home/matt/Projects/cerbero/build/dist/android_universal/x86_64/lib/libavcodec.a(vc1dsp_mmx.o): requires dynamic R_X86_64_PC32 reloc against 'ff_pw_9' which may overflow at runtime; recompile with -fPIC
/home/matt/Projects/cerbero/build/android-ndk-r16/toolchains/x86_64-4.9/prebuilt/linux-x86_64/lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin/ld.gold: error: /home/matt/Projects/cerbero/build/dist/android_universal/x86_64/lib/libavcodec.a(vc1dsp_mmx.o): requires dynamic R_X86_64_PC32 reloc against 'ff_pw_9' which may overflow at runtime; recompile with -fPIC
and 100 other symbols that follow the same pattern1.15.1Matthew Watersmatthew@centricular.comMatthew Watersmatthew@centricular.comhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3344Official documentation lacks infos compared to mirrors2024-03-01T00:55:57ZManuel WagesreitherOfficial documentation lacks infos compared to mirrorsHi all,
the official GStreamer documentation seems to lack infos that is available in mirrors.
Example:
* The [official doc on `vp8enc`](https://gstreamer.freedesktop.org/documentation/vpx/vp8enc.html) lacks infos on all the properties...Hi all,
the official GStreamer documentation seems to lack infos that is available in mirrors.
Example:
* The [official doc on `vp8enc`](https://gstreamer.freedesktop.org/documentation/vpx/vp8enc.html) lacks infos on all the properties.
* Some [3rd party mirror](https://thiblahute.github.io/GStreamer-doc/vpx-1.0/vp8enc.html) has them.
I'm creating this issues because the user _slomo_ on irc://irc.oftc.net:6697/#gstreamer asked me to do so.https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/82ges-launch-1.0 clipping getting stuck on HLS discontinuity2024-03-01T00:08:48ZRamon Blanquerges-launch-1.0 clipping getting stuck on HLS discontinuityHello developers.
# Description
I observed an abnormal behaviour with GStreamer’s editing tool `ges-launch-1.0` (version 1.16.1) recently that resulted in stuck processes that would not exit.
Our application case simply cuts an input ...Hello developers.
# Description
I observed an abnormal behaviour with GStreamer’s editing tool `ges-launch-1.0` (version 1.16.1) recently that resulted in stuck processes that would not exit.
Our application case simply cuts an input HLS stream (audio+video), that’s the only thing `ges-launch-1.0` would do in that scope. It’s all OK but sometimes the HLS we process have a particularly interesting discontinuity. **If the HLS goes from stereo fragments (1 AAC stream with 2 channels) to a segment with an AAC stream with 0 channels then it gets stuck.**
```
(the segments have video too, just showing the audio here)
a0.ts a1.ts b8.ts a2.ts
-------------------------------------------------------------------------
| 1 aac stream | 1 aac stream | 1 aac stream | 1 aac stream |
| with 2 channels | with 2 channels | with 0 channels | with 2 channels |
-------------------------------------------------------------------------
X X
X: EXT-X-DISCONTINUITY
```
It’s clearly the case of a buggy HLS.
But... do you guys know how can we protect against those cases so we don’t end up with various processes stuck forever?
# Reproduction Steps
In order to facilitate debugging, we have created a simple manifest and we have manually included only one problematic segment. The behaviour is the same as using the whole problematic original manifest.
You can reproduce the issue by simply running:
```
$ ges-launch-1.0 +clip https://watchity-ramon-videos-ireland.s3-eu-west-1.amazonaws.com/rabbit/rabbit.m3u8 i=0 d=20 -o out.ogg
```
And you will see how it gets stuck at second 13.08.
```
<position: 0:00:12.920000000 duration: 0:00:20.000000000/>
<position: 0:00:13.080000000 duration: 0:00:20.000000000/>
0:00:42.266508848 4139 0x7f5e5c002680 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.160000000 < 0:00:13.620000000)
0:00:42.273261779 4139 0x7f5e5c002680 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.040000000 < 0:00:13.620000000)
0:00:42.278908361 4139 0x7f5e5c002680 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.080000000 < 0:00:13.620000000)
0:00:42.281074149 4139 0x7f5e5c002680 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.120000000 < 0:00:13.620000000)
0:00:42.283356575 4139 0x7f5e5c002680 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.160000000 < 0:00:13.620000000)
0:00:42.285818489 4139 0x7f5e5c002680 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.160000000 < 0:00:13.620000000)
0:00:42.289001944 4139 0x7f5e5c002680 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.200000000 < 0:00:13.620000000)
0:00:42.293169852 4139 0x7f5e5c002680 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.240000000 < 0:00:13.620000000)
<position: 0:00:13.080000000 duration: 0:00:20.000000000/>
0:00:42.378823196 4139 0x7f5e5c002680 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.280000000 < 0:00:13.620000000)
0:00:42.489892422 4139 0x7f5e5c002680 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.320000000 < 0:00:13.620000000)
0:00:42.599481829 4139 0x7f5e5c002680 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.360000000 < 0:00:13.620000000)
0:00:42.706562443 4139 0x7f5e5c002680 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.400000000 < 0:00:13.620000000)
0:00:42.814879764 4139 0x7f5e5c002680 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.440000000 < 0:00:13.620000000)
0:00:42.928247916 4139 0x7f5e5c002680 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.480000000 < 0:00:13.620000000)
0:00:43.033689309 4139 0x7f5e5c002680 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.520000000 < 0:00:13.620000000)
<position: 0:00:13.080000000 duration: 0:00:20.000000000/>
0:00:43.270556967 4139 0x7f5e5c002680 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.600000000 < 0:00:13.620000000)
<position: 0:00:13.080000000 duration: 0:00:20.000000000/>
<position: 0:00:13.080000000 duration: 0:00:20.000000000/>
<position: 0:00:13.080000000 duration: 0:00:20.000000000/>
<position: 0:00:13.080000000 duration: 0:00:20.000000000/>
<position: 0:00:13.080000000 duration: 0:00:20.000000000/>
...
```
If you instead play it (by omitting the -o flag) then you will see it plays the entire video but doesn’t close the window afterwards as it does with healthy HLS streams.
```
<position: 0:00:05.164808141 duration: 0:00:20.000000001/>
0:00:13.274872869 4088 0x7fd1700019e0 WARN codecparsers_h264 gsth264parser.c:1237:gst_h264_parser_parse_sei_message: Bit non equal to one.
0:00:13.274895193 4088 0x7fd1700019e0 WARN codecparsers_h264 gsth264parser.c:1243:gst_h264_parser_parse_sei_message: Bit non equal to zero.
0:00:13.274900599 4088 0x7fd1700019e0 WARN codecparsers_h264 gsth264parser.c:1243:gst_h264_parser_parse_sei_message: Bit non equal to zero.
0:00:13.677449587 4088 0x7fd1700019e0 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.160000000 < 0:00:13.620000000)
0:00:13.685138590 4088 0x7fd1700019e0 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.040000000 < 0:00:13.620000000)
0:00:13.688876097 4088 0x7fd1700019e0 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.080000000 < 0:00:13.620000000)
0:00:13.695164645 4088 0x7fd1700019e0 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.120000000 < 0:00:13.620000000)
0:00:13.699870528 4088 0x7fd1700019e0 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.160000000 < 0:00:13.620000000)
0:00:13.701827595 4088 0x7fd1700019e0 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.160000000 < 0:00:13.620000000)
0:00:13.707254573 4088 0x7fd1700019e0 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.200000000 < 0:00:13.620000000)
0:00:13.714031598 4088 0x7fd1700019e0 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.240000000 < 0:00:13.620000000)
0:00:13.747354620 4088 0x7fd1700019e0 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.280000000 < 0:00:13.620000000)
0:00:13.765969317 4088 0x7fd1700019e0 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.320000000 < 0:00:13.620000000)
0:00:13.800168936 4088 0x7fd1700019e0 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.360000000 < 0:00:13.620000000)
0:00:13.834934563 4088 0x7fd1700019e0 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.400000000 < 0:00:13.620000000)
0:00:13.878851712 4088 0x7fd1700019e0 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.440000000 < 0:00:13.620000000)
0:00:13.932485432 4088 0x7fd1700019e0 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.480000000 < 0:00:13.620000000)
0:00:13.995678540 4088 0x7fd1700019e0 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.520000000 < 0:00:13.620000000)
0:00:14.016629730 4088 0x7fd1700019e0 WARN videodecoder gstvideodecoder.c:2762:gst_video_decoder_prepare_finish_frame:<avdec_h264-1> decreasing timestamp (0:00:13.600000000 < 0:00:13.620000000)
0:00:20.073656162 4088 0x786940 WARN aggregator gstaggregator.c:1757:gst_aggregator_query_latency_unlocked:<gessmartmixer0-compositor> Latency query failed
0:00:20.074010609 4088 0x7fd1d489b1e0 WARN aggregator gstaggregator.c:1757:gst_aggregator_query_latency_unlocked:<gessmartmixer0-compositor> Latency query failed
0:00:20.102896990 4088 0x7fd1d46a1e80 WARN ges ges-smart-video-mixer.c:189:parse_metadata: The current source should use a framepositioner
<position: 0:00:20.000000000 duration: 0:00:20.000000001/>
<position: 0:00:20.000000000 duration: 0:00:20.000000001/>
<position: 0:00:20.000000000 duration: 0:00:20.000000001/>
<position: 0:00:20.000000000 duration: 0:00:20.000000001/>
<position: 0:00:20.000000000 duration: 0:00:20.000000001/>
<position: 0:00:20.000000000 duration: 0:00:20.000000001/>
<position: 0:00:20.000000000 duration: 0:00:20.000000001/>
...
```
Here’s the manifest (rabbit.m3u8):
```
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:8
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:8.400000,
rabbit0.ts
#EXTINF:4.560000,
rabbit1.ts
#EXT-X-DISCONTINUITY
#EXTINF:3.840000,
copy734.ts <------------- PROBLEMATIC TS, if you replace it with rabbit2.ts works
#EXT-X-DISCONTINUITY
#EXTINF:5.640000,
rabbit3.ts
#EXTINF:1.880000,
rabbit4.ts
#EXTINF:2.160000,
rabbit5.ts
#EXTINF:3.800000,
rabbit6.ts
#EXT-X-ENDLIST
```
The problematic segment has an AAC stream with 0 channels in it...
```
$ ffprobe -hide_banner copy734.ts
[h264 @ 0x7f8339816600] non-existing SPS 0 referenced in buffering period
[h264 @ 0x7f8339816600] SPS unavailable in decode_picture_timing
[h264 @ 0x7f8339816600] non-existing SPS 0 referenced in buffering period
[h264 @ 0x7f8339816600] SPS unavailable in decode_picture_timing
[mpegts @ 0x7f8339802a00] start time for stream 1 is not set in estimate_timings_from_pts
[mpegts @ 0x7f8339802a00] Could not find codec parameters for stream 1 (Audio: aac ([15][0][0][0] / 0x000F), 0 channels, fltp): unspecified sample rate
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, mpegts, from 'copy734.ts':
Duration: 00:00:03.84, start: 0.200000, bitrate: 10457 kb/s
Program 1
Metadata:
service_name : Service01
service_provider: FFmpeg
Stream #0:0[0x100]: Video: h264 (Constrained Baseline) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:1[0x101]: Audio: aac ([15][0][0][0] / 0x000F), 0 channels, fltp
```
... whereas the rest of the segments are stereo:
```
$ ffprobe -hide_banner rabbit0.ts
Input #0, mpegts, from 'rabbit0.ts':
Duration: 00:00:08.42, start: 1.400000, bitrate: 4126 kb/s
Program 1
Metadata:
service_name : Service01
service_provider: FFmpeg
Stream #0:0[0x100]: Video: h264 (Constrained Baseline) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:1[0x101](und): Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 129 kb/s
```
# Observations
* GStreamer won’t get stuck If instead of 1 aac stream with 0 channels we simply remove the aac stream entirely resulting in 1 video stream alone, then it’s fine, it won’t get stuck.
* GStreamer won’t get stuck if instead of 1 aac stream with 0 channels we give it a mono aac stream (1 channel), this works and doesn’t get stuck.https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/45example concatenate.c hangs2024-03-01T00:08:46ZBugzilla Migration Userexample concatenate.c hangs## Submitted by ham..@..gmx.de
**[Link to original bug (#797341)](https://bugzilla.gnome.org/show_bug.cgi?id=797341)**
## Description
i checked out the git repo of gst-editing-service (tag 1.14.4 - hash
712ad28de2874439881d28fa0a1...## Submitted by ham..@..gmx.de
**[Link to original bug (#797341)](https://bugzilla.gnome.org/show_bug.cgi?id=797341)**
## Description
i checked out the git repo of gst-editing-service (tag 1.14.4 - hash
712ad28de2874439881d28fa0a1e96f8c55494f7).
i compiled and ran gst-editing-services/examples/c/concatenate.c
./concatenate file:///tmp/result.mp4 file:///tmp/1.mp4 file:///tmp/2.mp4
It just hangs and never ends without any errors. I tried several things without success. I waited several minutes and had to kill the process with CTRL+c. The file /tmp/result.mp4 is created but has size of 0 bytes.
The input files are from smartphone 1920x1080. i copied one file twice.
Version: 1.14.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/398Breaking installation on Ubuntu 20.04. Requires `glib-2.0 >= 2.66`.2024-02-29T21:15:03ZRajrup GhoshBreaking installation on Ubuntu 20.04. Requires `glib-2.0 >= 2.66`.The `gst-plugins-rs` is not compiling now on Ubuntu 20.04, but used to compile 2 months ago. There is version requirement for the `glib-2.0 >= 2.66` package which default comes `2.64.x` in Ubuntu <= 20.04. Any workaround for this?
ERROR...The `gst-plugins-rs` is not compiling now on Ubuntu 20.04, but used to compile 2 months ago. There is version requirement for the `glib-2.0 >= 2.66` package which default comes `2.64.x` in Ubuntu <= 20.04. Any workaround for this?
ERROR LOG:
```bash
warning: `PKG_CONFIG_ALLOW_SYSTEM_CFLAGS="1" PKG_CONFIG_PATH="/home/lei/gstreamer/build/meson-uninstalled" "pkg-config" "--libs" "--cflags" "glib-2.0" "glib-2.0 >= 2.66"` did not exit successfully: exit status: 1
error: failed to run custom build command for `glib-sys v0.19.0 (https://github.com/gtk-rs/gtk-rs-core#9e0abefb)`
Caused by:
process didn't exit successfully: `/home/lei/gstreamer/build/subprojects/gst-plugins-rs/target/debug/build/glib-sys-f19ed6a85515468c/build-script-build` (exit status: 1)
--- stdout
cargo:rerun-if-env-changed=GLIB_2.0_NO_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
cargo:rerun-if-env-changed=PKG_CONFIG_PATH
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
cargo:warning=`PKG_CONFIG_ALLOW_SYSTEM_CFLAGS="1" PKG_CONFIG_PATH="/home/lei/gstreamer/build/meson-uninstalled" "pkg-config" "--libs" "--cflags" "glib-2.0" "glib-2.0 >= 2.66"` did not exit successfully: exit status: 1
error: could not find system library 'glib-2.0' required by the 'glib-sys' crate
--- stderr
Requested 'glib-2.0 >= 2.66' but version of GLib is 2.64.6
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2606rtspclientsink: port-range property is not used for RTCP port-range selection2024-02-29T15:58:24ZTalha Khanrtspclientsink: port-range property is not used for RTCP port-range selectionAs per the current upstream state of the rtspclientsink element, it appears that the port-range property has both getter and setter functionality on the element. However, the actual value of the property is not being used when getting th...As per the current upstream state of the rtspclientsink element, it appears that the port-range property has both getter and setter functionality on the element. However, the actual value of the property is not being used when getting the client port(s) for rtspclientsink. Instead, the ephemeral port range is used for all client port selection, regardless of the value of the port-range property.
Is port-range intended to have no effect on the selected RTCP client ports for rtspclientsink? Or is this an oversight?
See: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-rtsp-server/gst/rtsp-sink/gstrtspclientsink.c#L3805
https://gstreamer.freedesktop.org/documentation/rtspclientsink/index.html?gi-language=c#rtspclientsink:port-range1.24.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2421Segmentation fault in QtGLVideoItem::onSceneGraphInitialized (ext/qt/qtitem.c...2024-02-29T13:21:18ZVincas DargisSegmentation fault in QtGLVideoItem::onSceneGraphInitialized (ext/qt/qtitem.cc:695)I'm migrating from QtMultimedia to GstGLVideoItem. Using 1.22.1 on Debian 11 amd64.
I sometimes get this crash while, it seems, QML scene is being initialized?
```
#0 QtGLVideoItem::onSceneGraphInitialized (this=0x555ce25e29e0) at ../...I'm migrating from QtMultimedia to GstGLVideoItem. Using 1.22.1 on Debian 11 amd64.
I sometimes get this crash while, it seems, QML scene is being initialized?
```
#0 QtGLVideoItem::onSceneGraphInitialized (this=0x555ce25e29e0) at ../source_subfolder/ext/qt/qtitem.cc:695
#1 0x00007f2120d22ad9 in std::__invoke_impl<void, void (QtGLVideoItem::*&)(), QtGLVideoItem*&> (__f=@0x555ce24d3ec0: (void (QtGLVideoItem::*)(QtGLVideoItem * const)) 0x7f2120d20356 <QtGLVideoItem::onSceneGraphInitialized()>, __t=@0x555ce24d3ed0: 0x555ce25e29e0)
at /usr/include/c++/10/bits/invoke.h:73
#2 0x00007f2120d22a35 in std::__invoke<void (QtGLVideoItem::*&)(), QtGLVideoItem*&> (__fn=@0x555ce24d3ec0: (void (QtGLVideoItem::*)(QtGLVideoItem * const)) 0x7f2120d20356 <QtGLVideoItem::onSceneGraphInitialized()>) at /usr/include/c++/10/bits/invoke.h:95
#3 0x00007f2120d229be in std::_Bind<void (QtGLVideoItem::*(QtGLVideoItem*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (this=0x555ce24d3ec0, __args=...) at /usr/include/c++/10/functional:416
#4 0x00007f2120d22950 in std::_Bind<void (QtGLVideoItem::*(QtGLVideoItem*))()>::operator()<, void>() (this=0x555ce24d3ec0) at /usr/include/c++/10/functional:499
#5 0x00007f2120d2289c in std::__invoke_impl<void, std::_Bind<void (QtGLVideoItem::*(QtGLVideoItem*))()>&>(std::__invoke_other, std::_Bind<void (QtGLVideoItem::*(QtGLVideoItem*))()>&) (__f=...) at /usr/include/c++/10/bits/invoke.h:60
#6 0x00007f2120d22709 in std::__invoke_r<void, std::_Bind<void (QtGLVideoItem::*(QtGLVideoItem*))()>&>(std::_Bind<void (QtGLVideoItem::*(QtGLVideoItem*))()>&) (__fn=...) at /usr/include/c++/10/bits/invoke.h:153
#7 0x00007f2120d22485 in std::_Function_handler<void (), std::_Bind<void (QtGLVideoItem::*(QtGLVideoItem*))()> >::_M_invoke(std::_Any_data const&) (__functor=...) at /usr/include/c++/10/bits/std_function.h:291
#8 0x00007f2120d21eb0 in std::function<void ()>::operator()() const (this=0x555ce3720c80) at /usr/include/c++/10/bits/std_function.h:622
#9 0x00007f2120d21c26 in RenderJob::run (this=0x555ce3720c70) at ../source_subfolder/ext/qt/gstqtglutility.h:37
#10 0x00007f2128ce6871 in QQuickWindowPrivate::runAndClearJobs(QList<QRunnable*>*) () from /home/user/myapp/lib/libQt5Quick.so.5
#11 0x00007f2128ce762a in QQuickWindowPrivate::syncSceneGraph() () from /home/user/myapp/lib/libQt5Quick.so.5
#12 0x00007f2128c8c5f5 in QSGRenderThread::sync(bool, bool) () from /home/user/myapp/lib/libQt5Quick.so.5
#13 0x00007f2128c8ea31 in QSGRenderThread::syncAndRender(QImage*) () from /home/user/myapp/lib/libQt5Quick.so.5
#14 0x00007f2128c9238b in QSGRenderThread::run() () from /home/user/myapp/lib/libQt5Quick.so.5
#15 0x00007f212633545d in QThreadPrivate::start(void*) () from /home/user/myapp/lib/libQt5Core.so.5
#16 0x00007f2128268ea7 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#17 0x00007f2125e7ba2f in clone () from /lib/x86_64-linux-gnu/libc.so.6
```
It happens here:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/3ab8a0bc3ef642f01fe7152cf08bb06d21419677/subprojects/gst-plugins-good/ext/qt/qtitem.cc#L695
But if I raise GST_DEBUG level, I get crash earlier, on the attempt to log message:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/3ab8a0bc3ef642f01fe7152cf08bb06d21419677/subprojects/gst-plugins-good/ext/qt/qtitem.cc#L692
So I assume that it's bug because case when `this->window()->openglContext()` is null is not handled?
This reproduces easily in our complex QML application (it's SwipeView with Repeater and Loaders...) on "weaker" Celeron-based machine, and rarer on i7 one. So I guess it's sort of race condition?