GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2024-02-10T18:25:31Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3291Rust: make debug builds instead of --release builds for monorepo subpipelines?2024-02-10T18:25:31ZTim-Philipp Müllertim@centricular.comRust: make debug builds instead of --release builds for monorepo subpipelines?Not 100% sure, but I was wondering if we're currently always creating `--release` builds, and if so if there's a way to create debug builds instead?
Might save some CI cycles for monorepo sub-pipelines.
(In fact we might not need to bu...Not 100% sure, but I was wondering if we're currently always creating `--release` builds, and if so if there's a way to create debug builds instead?
Might save some CI cycles for monorepo sub-pipelines.
(In fact we might not need to build plugins-rs at all for any monorepo change that doesn't affect public API, but I guess that's another discussion)https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/468msvc: gsttaglib.dll is looking for not-installed tag.dll2024-02-13T17:40:58ZSeungha Yangseungha@centricular.commsvc: gsttaglib.dll is looking for not-installed tag.dll`tag.dll` exists in build directory but not shipped by installer. Perhaps we are building shared library `tag.dll` unintentionally (instead of static lib) or need to ship `tag.dll`. Not sure what's intend direction.
![image](/uploads/88...`tag.dll` exists in build directory but not shipped by installer. Perhaps we are building shared library `tag.dll` unintentionally (instead of static lib) or need to ship `tag.dll`. Not sure what's intend direction.
![image](/uploads/8842b486fb3c4b346c60c428cf306a97/image.png)1.23.2https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3289aja: move ntv2 subproject to new repository / libaja version2024-02-25T07:36:21ZTim-Philipp Müllertim@centricular.comaja: move ntv2 subproject to new repository / libaja versionThe following discussion from !6087 should be addressed:
- [ ] @tpm started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6087#note_2276691): (+1 comment)
> Looks like we might also need to mov...The following discussion from !6087 should be addressed:
- [ ] @tpm started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6087#note_2276691): (+1 comment)
> Looks like we might also need to move the wrap to a new github repo and re-do the meson wrap: ![image](/uploads/9f9574c19fb6a5c1421b2d9f8fa29b3d/image.png)https://gitlab.freedesktop.org/gstreamer/orc/-/issues/64SIGILL on aarch64 when setting volume2024-02-20T14:39:20ZFabio ManganielloSIGILL on aarch64 when setting volume### Describe your issue
```
$ gst-launch-1.0 -v -m audiotestsrc ! volume volume=0.5 ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got message #7 from element "fakesink0" (state-changed): GstMessageStateChanged, ol...### Describe your issue
```
$ gst-launch-1.0 -v -m audiotestsrc ! volume volume=0.5 ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got message #7 from element "fakesink0" (state-changed): GstMessageStateChanged, old-state=(GstState)null, new-state=(GstState)ready, pending-state=(GstState)void-pending;
Got message #8 from element "volume0" (state-changed): GstMessageStateChanged, old-state=(GstState)null, new-state=(GstState)ready, pending-state=(GstState)void-pending;
Got message #9 from element "audiotestsrc0" (state-changed): GstMessageStateChanged, old-state=(GstState)null, new-state=(GstState)ready, pending-state=(GstState)void-pending;
Got message #10 from element "pipeline0" (state-changed): GstMessageStateChanged, old-state=(GstState)null, new-state=(GstState)ready, pending-state=(GstState)paused;
Got message #12 from element "volume0" (state-changed): GstMessageStateChanged, old-state=(GstState)ready, new-state=(GstState)paused, pending-state=(GstState)void-pending;
Got message #15 from pad "audiotestsrc0:src" (stream-status): GstMessageStreamStatus, type=(GstStreamStatusType)create, owner=(GstElement)"\(GstAudioTestSrc\)\ audiotestsrc0", object=(GstTask)"\(GstTask\)\ audiotestsrc0:src";
Got message #16 from element "audiotestsrc0" (state-changed): GstMessageStateChanged, old-state=(GstState)ready, new-state=(GstState)paused, pending-state=(GstState)void-pending;
Got message #17 from pad "audiotestsrc0:src" (stream-status): GstMessageStreamStatus, type=(GstStreamStatusType)enter, owner=(GstElement)"\(GstAudioTestSrc\)\ audiotestsrc0", object=(GstTask)"\(GstTask\)\ audiotestsrc0:src";
Got message #18 from element "pipeline0" (stream-start): GstMessageStreamStart, group-id=(uint)1;
Got message #22 from pad "audiotestsrc0:src" (property-notify): GstMessagePropertyNotify, property-name=(string)caps, property-value=(GstCaps)"audio/x-raw\,\ format\=\(string\)S16LE\,\ layout\=\(string\)interleaved\,\ rate\=\(int\)44100\,\ channels\=\(int\)1";
/GstPipeline:pipeline0/GstAudioTestSrc:audiotestsrc0.GstPad:src: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
Got message #24 from pad "volume0:src" (property-notify): GstMessagePropertyNotify, property-name=(string)caps, property-value=(GstCaps)"audio/x-raw\,\ format\=\(string\)S16LE\,\ layout\=\(string\)interleaved\,\ rate\=\(int\)44100\,\ channels\=\(int\)1";
/GstPipeline:pipeline0/GstVolume:volume0.GstPad:src: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
Got message #25 from pad "fakesink0:sink" (property-notify): GstMessagePropertyNotify, property-name=(string)caps, property-value=(GstCaps)"audio/x-raw\,\ format\=\(string\)S16LE\,\ layout\=\(string\)interleaved\,\ rate\=\(int\)44100\,\ channels\=\(int\)1";
/GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
Got message #26 from pad "volume0:sink" (property-notify): GstMessagePropertyNotify, property-name=(string)caps, property-value=(GstCaps)"audio/x-raw\,\ format\=\(string\)S16LE\,\ layout\=\(string\)interleaved\,\ rate\=\(int\)44100\,\ channels\=\(int\)1";
/GstPipeline:pipeline0/GstVolume:volume0.GstPad:sink: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
Got message #30 from element "fakesink0" (tag): GstMessageTag, taglist=(taglist)"taglist\,\ description\=\(string\)\"audiotest\\\ wave\"\;";
[1] 1587 illegal hardware instruction (core dumped) gst-launch-1.0 -v -m audiotestsrc ! volume volume=0.5 ! fakesink
```
#### Expected Behavior
Setting the volume of a pipeline shouldn't cause the application to crash.
#### Observed Behavior
The application crashed with SIGILL.
#### Setup
- **Operating System:** Arch Linux ARM aarch64
- **Device:** Raspberry Pi 5
- **GStreamer Version:** 1.22.9, installed via pacman
- **Command line:** Any command line involving the `volume` element
### Steps to reproduce the bug
See the command line above for an example.
In my case it causes a crash in mopidy whenever the volume is changed via the software mixer.
### How reproducible is the bug?
Always, and very easy to reproduce.
### Screenshots if relevant
N/A
### Solutions you have tried
- Using Pipewire instead of Pulseaudio
- Using raw ALSA instead of Pulseaudio
- Disabling the HDMI audio output
- Tried over audio jack, USB audio card and Bluetooth audio
### Related non-duplicate issues
https://github.com/mopidy/mopidy/issues/2148
### Additional Information
- [Core dump of the `gst-launch-1.0` command](https://github.com/mopidy/mopidy/files/14225920/core.tar.gz)
- [Logs with `GST_DEBUG=9`](https://github.com/mopidy/mopidy/files/14226210/log.tar.gz)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3288SIGILL on aarch64 when setting volume2024-02-11T16:59:16ZFabio ManganielloSIGILL on aarch64 when setting volume### Describe your issue
```
$ gst-launch-1.0 -v -m audiotestsrc ! volume volume=0.5 ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got message #7 from element "fakesink0" (state-changed): GstMessageStateChanged, ol...### Describe your issue
```
$ gst-launch-1.0 -v -m audiotestsrc ! volume volume=0.5 ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got message #7 from element "fakesink0" (state-changed): GstMessageStateChanged, old-state=(GstState)null, new-state=(GstState)ready, pending-state=(GstState)void-pending;
Got message #8 from element "volume0" (state-changed): GstMessageStateChanged, old-state=(GstState)null, new-state=(GstState)ready, pending-state=(GstState)void-pending;
Got message #9 from element "audiotestsrc0" (state-changed): GstMessageStateChanged, old-state=(GstState)null, new-state=(GstState)ready, pending-state=(GstState)void-pending;
Got message #10 from element "pipeline0" (state-changed): GstMessageStateChanged, old-state=(GstState)null, new-state=(GstState)ready, pending-state=(GstState)paused;
Got message #12 from element "volume0" (state-changed): GstMessageStateChanged, old-state=(GstState)ready, new-state=(GstState)paused, pending-state=(GstState)void-pending;
Got message #15 from pad "audiotestsrc0:src" (stream-status): GstMessageStreamStatus, type=(GstStreamStatusType)create, owner=(GstElement)"\(GstAudioTestSrc\)\ audiotestsrc0", object=(GstTask)"\(GstTask\)\ audiotestsrc0:src";
Got message #16 from element "audiotestsrc0" (state-changed): GstMessageStateChanged, old-state=(GstState)ready, new-state=(GstState)paused, pending-state=(GstState)void-pending;
Got message #17 from pad "audiotestsrc0:src" (stream-status): GstMessageStreamStatus, type=(GstStreamStatusType)enter, owner=(GstElement)"\(GstAudioTestSrc\)\ audiotestsrc0", object=(GstTask)"\(GstTask\)\ audiotestsrc0:src";
Got message #18 from element "pipeline0" (stream-start): GstMessageStreamStart, group-id=(uint)1;
Got message #22 from pad "audiotestsrc0:src" (property-notify): GstMessagePropertyNotify, property-name=(string)caps, property-value=(GstCaps)"audio/x-raw\,\ format\=\(string\)S16LE\,\ layout\=\(string\)interleaved\,\ rate\=\(int\)44100\,\ channels\=\(int\)1";
/GstPipeline:pipeline0/GstAudioTestSrc:audiotestsrc0.GstPad:src: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
Got message #24 from pad "volume0:src" (property-notify): GstMessagePropertyNotify, property-name=(string)caps, property-value=(GstCaps)"audio/x-raw\,\ format\=\(string\)S16LE\,\ layout\=\(string\)interleaved\,\ rate\=\(int\)44100\,\ channels\=\(int\)1";
/GstPipeline:pipeline0/GstVolume:volume0.GstPad:src: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
Got message #25 from pad "fakesink0:sink" (property-notify): GstMessagePropertyNotify, property-name=(string)caps, property-value=(GstCaps)"audio/x-raw\,\ format\=\(string\)S16LE\,\ layout\=\(string\)interleaved\,\ rate\=\(int\)44100\,\ channels\=\(int\)1";
/GstPipeline:pipeline0/GstFakeSink:fakesink0.GstPad:sink: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
Got message #26 from pad "volume0:sink" (property-notify): GstMessagePropertyNotify, property-name=(string)caps, property-value=(GstCaps)"audio/x-raw\,\ format\=\(string\)S16LE\,\ layout\=\(string\)interleaved\,\ rate\=\(int\)44100\,\ channels\=\(int\)1";
/GstPipeline:pipeline0/GstVolume:volume0.GstPad:sink: caps = audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1
Got message #30 from element "fakesink0" (tag): GstMessageTag, taglist=(taglist)"taglist\,\ description\=\(string\)\"audiotest\\\ wave\"\;";
[1] 1587 illegal hardware instruction (core dumped) gst-launch-1.0 -v -m audiotestsrc ! volume volume=0.5 ! fakesink
```
#### Expected Behavior
Setting the volume of a pipeline shouldn't cause the application to crash.
#### Observed Behavior
The application crashed with SIGILL.
#### Setup
- **Operating System:** Arch Linux ARM aarch64
- **Device:** Raspberry Pi 5
- **GStreamer Version:** 1.22.9, installed via pacman
- **Command line:** Any command line involving the `volume` element
### Steps to reproduce the bug
See the command line above for an example.
In my case it causes a crash in mopidy whenever the volume is changed via the software mixer.
### How reproducible is the bug?
Always, and very easy to reproduce.
### Screenshots if relevant
N/A
### Solutions you have tried
- Using Pipewire instead of Pulseaudio
- Using raw ALSA instead of Pulseaudio
- Disabling the HDMI audio output
- Tried over audio jack, USB audio card and Bluetooth audio
### Related non-duplicate issues
https://github.com/mopidy/mopidy/issues/2148
### Additional Information
- [Core dump of the `gst-launch-1.0` command](https://github.com/mopidy/mopidy/files/14225920/core.tar.gz)
- [Logs with `GST_DEBUG=9`](https://github.com/mopidy/mopidy/files/14226210/log.tar.gz)https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/467rust: shipped mingw-w64-gcc is too old to link i686-pc-windows-gnu objects2024-02-10T00:15:12Zamysparkrust: shipped mingw-w64-gcc is too old to link i686-pc-windows-gnu objects(related: #381)
The version shipped with Cerbero is GCC 8.3.0, which is too old to link the object files produced by Rust.
As of this writing, the `rust-mingw` component supplies such a linker, which is GCC 13.2. However, installing th...(related: #381)
The version shipped with Cerbero is GCC 8.3.0, which is too old to link the object files produced by Rust.
As of this writing, the `rust-mingw` component supplies such a linker, which is GCC 13.2. However, installing this component requires the toolchain to be switched to `stable-i386-pc-windows-gnu`. (This is a rustup bug for which I'll be filing an issue upstream after this.)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3290sdp: add source-filter in SDP information generated by gstreamer2024-02-12T09:45:51Zbigbrobrodysdp: add source-filter in SDP information generated by gstreamerEnhancement: Add support for SDP source-filter field as per RFC 4570.
The source-filter line should be added when a source-specific multicast (SSM) address is being used by the server.
As per RFC 3569 The address range 232/8 has been ass...Enhancement: Add support for SDP source-filter field as per RFC 4570.
The source-filter line should be added when a source-specific multicast (SSM) address is being used by the server.
As per RFC 3569 The address range 232/8 has been assigned by IANA for SSM service in IPv4. For IPv6, the range FF3x::/96 is defined for SSM services.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/1040sdp: add source-filter in SDP information generated by gstreamer2024-02-10T16:46:42Zbigbrobrodysdp: add source-filter in SDP information generated by gstreamerEnhancement: Add support for SDP source-filter field as per RFC 4570.
The source-filter line should be added when a source-specific multicast (SSM) address is being used by the server.
As per RFC 3569 The address range 232/8 has been ass...Enhancement: Add support for SDP source-filter field as per RFC 4570.
The source-filter line should be added when a source-specific multicast (SSM) address is being used by the server.
As per RFC 3569 The address range 232/8 has been assigned by IANA for SSM service in IPv4. For IPv6, the range FF3x::/96 is defined for SSM services.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/491webrtcsink: Errors while generating debug graph during shutdown of pipeline2024-02-09T15:44:54ZJordan Yellozwebrtcsink: Errors while generating debug graph during shutdown of pipeline### Describe your issue
During implementation of !1442 I found that when `GST_DEBUG_DUMP_DOT_DIR` is set, using GStreamer 1.22 and gst-plugins-rs 0.11 branch, the livekitwebrtcsink will occasionally cause lots of glib assertion errors t...### Describe your issue
During implementation of !1442 I found that when `GST_DEBUG_DUMP_DOT_DIR` is set, using GStreamer 1.22 and gst-plugins-rs 0.11 branch, the livekitwebrtcsink will occasionally cause lots of glib assertion errors to get logged when the pipeline is shutting down.
#### Expected Behavior
The pipeline should always shut down cleanly and graphviz dot files should be written to disk.
#### Observed Behavior
There is a long list of assertions failing while a dot file is being generated:
```
Freeing pipeline ...
(gst-launch-1.0:839730): GStreamer-CRITICAL **: 10:29:15.393: gst_mini_object_ref: assertion 'mini_object != NULL' failed
(gst-launch-1.0:839730): GStreamer-CRITICAL **: 10:29:15.393: gst_mini_object_unref: assertion 'mini_object != NULL' failed
(gst-launch-1.0:839730): GStreamer-CRITICAL **: 10:29:15.393: gst_caps_features_is_equal: assertion 'features1 != NULL' failed
(gst-launch-1.0:839730): GStreamer-CRITICAL **: 10:29:15.393: gst_mini_object_ref: assertion 'mini_object != NULL' failed
(gst-launch-1.0:839730): GStreamer-CRITICAL **: 10:29:15.393: gst_caps_is_any: assertion 'GST_IS_CAPS (caps)' failed
```
#### Setup
- **Operating System:** Fedora Linux 39
- **Device:** Computer
- **gst-plugins-rs Version:** 0.11 (https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/commit/5bba2f783632bb27687662017d703af2fb2fd4f1)
- **GStreamer Version:** 1.22.9+ (https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/23b88fe0f3060c216a03297f356c50c9a922a74b)
- **Command line:**
```shell
export GST_DEBUG_DUMP_DOT_DIR="$PWD/dot"
mkdir -p "$GST_DEBUG_DUMP_DOT_DIR"
gst-launch-1.0 livekitwebrtcsink name=sink \
signaller::ws-url=ws://localhost:7880 \
signaller::api-key=devkey \
signaller::secret-key=secret \
signaller::room-name=test \
video-caps='video/x-vp8' \
videotestsrc is-live=1 ! video/x-raw,framerate=30/1,width=320,height=180 ! queue ! sink. \
videotestsrc is-live=1 ! video/x-raw,framerate=30/1,width=640,height=360 ! queue ! sink. \
videotestsrc is-live=1 ! video/x-raw,framerate=30/1,width=1280,height=720 ! queue ! sink.
```
### Steps to reproduce the bug
1. Build specified versions of GStreamer and gst-plugins-rs
2. Run LiveKit server with `--dev` flag to allow developer credentials specified above to be accepted
3. type `command` and press ctrl-c a few seconds after starting. Repeat as necessary.
### How reproducible is the bug?
Intermittent, about 1/10 attempts have triggered the bug for me. So far I have only ever experienced the bug when using the livekitwebrtcsink, not the plain webrtcsink with the GST reference signalling server.
### Screenshots if relevant
N/A
### Solutions you have tried
N/A
### Related non-duplicate issues
N/A
### Additional Information
Stack trace:
<details>
<pre>
#0 g_logv (log_domain=0x7ff06a7dd1d8 "GStreamer", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7ff0428f2f60) at ../glib/gmessages.c:1423
#1 0x00007ff06a5e9463 in g_log (log_domain=log_domain@entry=0x7ff06a7dd1d8 "GStreamer", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ff06a651280 "%s: assertion '%s' failed") at ../glib/gmessages.c:1461
#2 0x00007ff06a5ea6dd in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ff06a7dd1d8 "GStreamer", pretty_function=pretty_function@entry=0x7ff06a7e3620 <__func__.4> "gst_caps_features_is_any", expression=expression@entry=0x7ff06a7e2991 "features != NULL") at ../glib/gmessages.c:2930
#3 0x00007ff06a746e6e in gst_caps_features_is_any (features=features@entry=0x0) at ../subprojects/gstreamer/gst/gstcapsfeatures.c:766
#4 0x00007ff06a743e1a in gst_caps_is_subset (subset=subset@entry=0x7ff00c0391c0, superset=superset@entry=0x7ff00c019e60) at ../subprojects/gstreamer/gst/gstcaps.c:1348
#5 0x00007ff06a7441e7 in gst_caps_is_equal (caps1=caps1@entry=0x7ff00c0391c0, caps2=caps2@entry=0x7ff00c019e60) at ../subprojects/gstreamer/gst/gstcaps.c:1473
#6 0x00007ff06a74f740 in debug_dump_element_pad_link (pad=0x7ff00c02b870, element=0x7ff00c02b150, details=GST_DEBUG_GRAPH_SHOW_VERBOSE, str=0x7ff00c1074d0, indent=<optimized out>) at ../subprojects/gstreamer/gst/gstdebugutils.c:502
#7 0x00007ff06a750477 in debug_dump_element (bin=bin@entry=0x7ff00c034c90, details=details@entry=GST_DEBUG_GRAPH_SHOW_VERBOSE, str=str@entry=0x7ff00c1074d0, indent=indent@entry=4) at ../subprojects/gstreamer/gst/gstdebugutils.c:714
#8 0x00007ff06a7502fa in debug_dump_element (bin=bin@entry=0x7ff00c0c7030, details=details@entry=GST_DEBUG_GRAPH_SHOW_VERBOSE, str=str@entry=0x7ff00c1074d0, indent=indent@entry=3) at ../subprojects/gstreamer/gst/gstdebugutils.c:694
#9 0x00007ff06a7502fa in debug_dump_element (bin=bin@entry=0x7ff030048f40, details=details@entry=GST_DEBUG_GRAPH_SHOW_VERBOSE, str=str@entry=0x7ff00c1074d0, indent=indent@entry=2) at ../subprojects/gstreamer/gst/gstdebugutils.c:694
#10 0x00007ff06a7502fa in debug_dump_element (bin=bin@entry=0x7ff030066af0, details=details@entry=GST_DEBUG_GRAPH_SHOW_VERBOSE, str=str@entry=0x7ff00c1074d0, indent=indent@entry=1) at ../subprojects/gstreamer/gst/gstdebugutils.c:694
#11 0x00007ff06a750580 in gst_debug_bin_to_dot_data (bin=bin@entry=0x7ff030066af0, details=details@entry=GST_DEBUG_GRAPH_SHOW_VERBOSE) at ../subprojects/gstreamer/gst/gstdebugutils.c:829
#12 0x00007ff06a750748 in gst_debug_bin_to_dot_file (bin=bin@entry=0x7ff030066af0, details=details@entry=GST_DEBUG_GRAPH_SHOW_VERBOSE, file_name=<optimized out>, file_name@entry=0x7ff030058680 "0.00.01.232958865-webrtcsink-session-unique-Paused-to-Ready") at ../subprojects/gstreamer/gst/gstdebugutils.c:873
#13 0x00007ff06a7509aa in gst_debug_bin_to_dot_file_with_ts (bin=0x7ff030066af0, details=GST_DEBUG_GRAPH_SHOW_VERBOSE, file_name=<optimized out>) at ../subprojects/gstreamer/gst/gstdebugutils.c:920
#14 0x00007ff05b88a993 in gstreamer::auto::functions::debug_bin_to_dot_file_with_ts<gstreamer::auto::pipeline::Pipeline, alloc::string::String> (bin=<optimized out>, details=..., file_name=...) at /var/home/jyelloz/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/8c286fa/gstreamer/src/auto/functions.rs:53
#15 0x00007ff05b7d6009 in gstreamer::bin::GstBinExtManual::debug_to_dot_file_with_ts<gstreamer::auto::pipeline::Pipeline, alloc::string::String> (self=0x7ff0428f3558, details=..., file_name=...) at /var/home/jyelloz/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/8c286fa/gstreamer/src/bin.rs:187
#16 gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block#5} () at net/webrtc/src/webrtcsink/imp.rs:2494
#17 0x00007ff05b7c08ef in tokio::runtime::task::core::{impl#6}::poll::{closure#0}<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>> (ptr=0x7ff03006e130) at /var/home/jyelloz/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.0/src/runtime/task/core.rs:328
#18 tokio::loom::std::unsafe_cell::UnsafeCell<tokio::runtime::task::core::Stage<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}>>::with_mut<tokio::runtime::task::core::Stage<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}>, core::task::poll::Poll<()>, tokio::runtime::task::core::{impl#6}::poll::{closure_env#0}<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>> (self=0x7ff03006e130, f=...) at /var/home/jyelloz/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.0/src/loom/std/unsafe_cell.rs:16
#19 tokio::runtime::task::core::Core<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>::poll<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>> (self=0x7ff03006e120, cx=...) at /var/home/jyelloz/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.0/src/runtime/task/core.rs:317
#20 0x00007ff05b81972a in tokio::runtime::task::harness::poll_future::{closure#0}<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>> () at /var/home/jyelloz/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.0/src/runtime/task/harness.rs:485
#21 core::panic::unwind_safe::{impl#23}::call_once<core::task::poll::Poll<()>, tokio::runtime::task::harness::poll_future::{closure_env#0}<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>> (self=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panic/unwind_safe.rs:272
#22 std::panicking::try::do_call<core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>>, core::task::poll::Poll<()>> (data=<optimized out>) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:552
#23 std::panicking::try<core::task::poll::Poll<()>, core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>>> (f=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:516
#24 std::panic::catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>>, core::task::poll::Poll<()>> (f=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panic.rs:142
#25 tokio::runtime::task::harness::poll_future<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>> (core=0x7ff03006e120, cx=...) at /var/home/jyelloz/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.0/src/runtime/task/harness.rs:473
#26 tokio::runtime::task::harness::Harness<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>::poll_inner<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>> (self=<optimized out>) at /var/home/jyelloz/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.0/src/runtime/task/harness.rs:208
#27 tokio::runtime::task::harness::Harness<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>::poll<gstrswebrtc::webrtcsink::imp::{impl#16}::start_session::{async_block_env#5}, alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>> (self=...) at /var/home/jyelloz/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.35.0/src/runtime/task/harness.rs:153
#28 0x00007ff05c184466 in tokio::runtime::task::raw::RawTask::poll (self=...) at src/runtime/task/raw.rs:201
#29 tokio::runtime::task::LocalNotified<alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>>::run<alloc::sync::Arc<tokio::runtime::scheduler::multi_thread::handle::Handle, alloc::alloc::Global>> (self=...) at src/runtime/task/mod.rs:416
#30 tokio::runtime::scheduler::multi_thread::worker::{impl#1}::run_task::{closure#0} () at src/runtime/scheduler/multi_thread/worker.rs:576
#31 tokio::runtime::coop::with_budget<core::result::Result<alloc::boxed::Box<tokio::runtime::scheduler::multi_thread::worker::Core, alloc::alloc::Global>, ()>, tokio::runtime::scheduler::multi_thread::worker::{impl#1}::run_task::{closure_env#0}> (budget=..., f=...) at src/runtime/coop.rs:107
#32 tokio::runtime::coop::budget<core::result::Result<alloc::boxed::Box<tokio::runtime::scheduler::multi_thread::worker::Core, alloc::alloc::Global>, ()>, tokio::runtime::scheduler::multi_thread::worker::{impl#1}::run_task::{closure_env#0}> (f=...) at src/runtime/coop.rs:73
#33 tokio::runtime::scheduler::multi_thread::worker::Context::run_task (self=0x7ff0428f3a78, task=..., core=<optimized out>) at src/runtime/scheduler/multi_thread/worker.rs:575
#34 0x00007ff05c183218 in tokio::runtime::scheduler::multi_thread::worker::Context::run (self=0x7ff0428f3a78, core=0x7ff050001160) at src/runtime/scheduler/multi_thread/worker.rs:526
#35 0x00007ff05c1882ec in tokio::runtime::scheduler::multi_thread::worker::run::{closure#0}::{closure#0} () at src/runtime/scheduler/multi_thread/worker.rs:491
#36 tokio::runtime::context::scoped::Scoped<tokio::runtime::scheduler::Context>::set<tokio::runtime::scheduler::Context, tokio::runtime::scheduler::multi_thread::worker::run::{closure#0}::{closure_env#0}, ()> (self=0x7ff030000ca8, t=<optimized out>, f=...) at src/runtime/context/scoped.rs:40
#37 0x00007ff05c180754 in tokio::runtime::context::set_scheduler::{closure#0}<(), tokio::runtime::scheduler::multi_thread::worker::run::{closure#0}::{closure_env#0}> (c=<optimized out>) at src/runtime/context.rs:176
#38 std::thread::local::LocalKey<tokio::runtime::context::Context>::try_with<tokio::runtime::context::Context, tokio::runtime::context::set_scheduler::{closure_env#0}<(), tokio::runtime::scheduler::multi_thread::worker::run::{closure#0}::{closure_env#0}>, ()> (self=<optimized out>, f=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/thread/local.rs:270
#39 std::thread::local::LocalKey<tokio::runtime::context::Context>::with<tokio::runtime::context::Context, tokio::runtime::context::set_scheduler::{closure_env#0}<(), tokio::runtime::scheduler::multi_thread::worker::run::{closure#0}::{closure_env#0}>, ()> (self=<optimized out>, f=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/thread/local.rs:246
#40 0x00007ff05c17b57c in tokio::runtime::context::set_scheduler<(), tokio::runtime::scheduler::multi_thread::worker::run::{closure#0}::{closure_env#0}> (v=0x7ff0428f3a70, f=...) at src/runtime/context.rs:176
#41 tokio::runtime::scheduler::multi_thread::worker::run::{closure#0} () at src/runtime/scheduler/multi_thread/worker.rs:486
#42 tokio::runtime::context::runtime::enter_runtime<tokio::runtime::scheduler::multi_thread::worker::run::{closure_env#0}, ()> (handle=<optimized out>, allow_block_in_place=<optimized out>, f=...) at src/runtime/context/runtime.rs:65
#43 0x00007ff05c1829d0 in tokio::runtime::scheduler::multi_thread::worker::run (worker=...) at src/runtime/scheduler/multi_thread/worker.rs:478
#44 0x00007ff05c1634e2 in tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure#0} () at src/runtime/scheduler/multi_thread/worker.rs:447
#45 tokio::runtime::blocking::task::{impl#2}::poll<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}, ()> (self=..., _cx=<optimized out>) at src/runtime/blocking/task.rs:42
#46 0x00007ff05c1609ca in tokio::runtime::task::core::{impl#6}::poll::{closure#0}<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule> (ptr=0x7ff05000d728) at src/runtime/task/core.rs:328
#47 tokio::loom::std::unsafe_cell::UnsafeCell<tokio::runtime::task::core::Stage<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>>::with_mut<tokio::runtime::task::core::Stage<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>>, core::task::poll::Poll<()>, tokio::runtime::task::core::{impl#6}::poll::{closure_env#0}<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule>> (self=0x7ff05000d728, f=...) at src/loom/std/unsafe_cell.rs:16
#48 tokio::runtime::task::core::Core<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule>::poll<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule> (self=0x7ff05000d720, cx=...) at src/runtime/task/core.rs:317
#49 0x00007ff05c15f6b5 in tokio::runtime::task::harness::poll_future::{closure#0}<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule> () at src/runtime/task/harness.rs:485
#50 core::panic::unwind_safe::{impl#23}::call_once<core::task::poll::Poll<()>, tokio::runtime::task::harness::poll_future::{closure_env#0}<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule>> (self=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panic/unwind_safe.rs:272
#51 std::panicking::try::do_call<core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule>>, core::task::poll::Poll<()>> (data=<optimized out>) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:552
#52 std::panicking::try<core::task::poll::Poll<()>, core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule>>> (f=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:516
#53 std::panic::catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<tokio::runtime::task::harness::poll_future::{closure_env#0}<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule>>, core::task::poll::Poll<()>> (f=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panic.rs:142
#54 tokio::runtime::task::harness::poll_future<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule> (core=0x440, cx=...) at src/runtime/task/harness.rs:473
#55 0x00007ff05c15e34b in tokio::runtime::task::harness::Harness<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule>::poll_inner<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule> (self=<optimized out>) at src/runtime/task/harness.rs:208
#56 0x00007ff05c162a58 in tokio::runtime::task::harness::Harness<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule>::poll<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule> (self=...) at src/runtime/task/harness.rs:153
#57 tokio::runtime::task::raw::poll<tokio::runtime::blocking::task::BlockingTask<tokio::runtime::scheduler::multi_thread::worker::{impl#0}::launch::{closure_env#0}>, tokio::runtime::blocking::schedule::BlockingSchedule> (ptr=...) at src/runtime/task/raw.rs:271
#58 0x00007ff05c162f20 in tokio::runtime::task::raw::RawTask::poll (self=...) at src/runtime/task/raw.rs:201
#59 tokio::runtime::task::UnownedTask<tokio::runtime::blocking::schedule::BlockingSchedule>::run<tokio::runtime::blocking::schedule::BlockingSchedule> (self=...) at src/runtime/task/mod.rs:453
#60 0x00007ff05c16a251 in tokio::runtime::blocking::pool::Task::run (self=...) at src/runtime/blocking/pool.rs:159
#61 tokio::runtime::blocking::pool::Inner::run (self=0x7ff05000c9c0, worker_thread_id=<optimized out>) at src/runtime/blocking/pool.rs:513
#62 0x00007ff05c16eb1d in tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure#0} () at src/runtime/blocking/pool.rs:471
#63 std::sys_common::backtrace::__rust_begin_short_backtrace<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()> (f=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys_common/backtrace.rs:154
#64 0x00007ff05c16f55c in std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure#0}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()> () at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/thread/mod.rs:529
#65 core::panic::unwind_safe::{impl#23}::call_once<(), std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>> (self=<error reading variable: Cannot access memory at address 0x0>) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panic/unwind_safe.rs:272
#66 std::panicking::try::do_call<core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>>, ()> (data=<optimized out>) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:552
#67 std::panicking::try<(), core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>>> (f=...) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:516
#68 std::panic::catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>>, ()> (f=<error reading variable: Cannot access memory at address 0x0>) at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panic.rs:142
#69 std::thread::{impl#0}::spawn_unchecked_::{closure#1}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()> () at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/thread/mod.rs:528
#70 core::ops::function::FnOnce::call_once<std::thread::{impl#0}::spawn_unchecked_::{closure_env#1}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()>, ()> () at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/ops/function.rs:250
#71 0x00007ff05c2222a5 in alloc::boxed::{impl#47}::call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:2007
#72 alloc::boxed::{impl#47}::call_once<(), alloc::boxed::Box<dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:2007
#73 std::sys::unix::thread::{impl#2}::new::thread_start () at library/std/src/sys/unix/thread.rs:108
#74 0x00007ff06a3d2897 in start_thread (arg=<optimized out>) at pthread_create.c:444
#75 0x00007ff06a45980c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
</pre>
</details>https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3287srt: If we build with srt disabled we will get complaints about srt_dep2024-02-09T18:33:05ZJonas Danielssonsrt: If we build with srt disabled we will get complaints about srt_dep```plaintext
../subprojects/gst-plugins-bad/tests/check/meson.build:72:35: ERROR: Unknown variable "srt_dep".
``````plaintext
../subprojects/gst-plugins-bad/tests/check/meson.build:72:35: ERROR: Unknown variable "srt_dep".
```Tim-Philipp Müllertim@centricular.comTim-Philipp Müllertim@centricular.comhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3286GStreamer 1.23.2 unstable development snapshot release tracker2024-02-19T19:51:34ZTim-Philipp Müllertim@centricular.comGStreamer 1.23.2 unstable development snapshot release tracker# Milestone 1.23.2
- Milestone 1.23.2 Overview: %1.23.2
- ETA: 12-16 Feb 2024
# Todo
- [~] [Merge Requests with `Needs backport` label](https://gitlab.freedesktop.org/groups/gstreamer/-/merge_requests?scope=all&state=merged&label_name...# Milestone 1.23.2
- Milestone 1.23.2 Overview: %1.23.2
- ETA: 12-16 Feb 2024
# 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.20)
- [~] [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)
- [x] [Merge Requests with `1.23.2` milestone](https://gitlab.freedesktop.org/groups/gstreamer/-/merge_requests?milestone_title=1.23.2)
- [x] [Issues with `1.23.2` milestone](https://gitlab.freedesktop.org/groups/gstreamer/-/issues?milestone_title=1.23.2)
- [x] [Issues with `Security` label](https://gitlab.freedesktop.org/groups/gstreamer/-/issues?scope=all&utf8=%E2%9C%93&state=all&label_name[]=Security)
- [x] Blockers / Todo
- [ ] theoradec regression: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4752
- [x] h264parse regression: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3264 (soft blocker for 1.23.2, hard for 1.23.90)
# Prep
- [x] gst-plugins-rs (1.24 will target 0.12 branch)
- [x] make sure `0.12` branch is up-to-date with regards to backports
- [x] update `Cargo.lock` in `0.12` branch (if needed)
- [x] double-check version in `meson.build` matches version in `Cargo.toml`
- [x] add `gstreamer-1.23.2` tag pointing to current tip of `0.12` branch
- [x] www: add release note entry and add contributors
- [x] update translations
# GStreamer
- [x] MR / commit for release
- [x] tag release
- [x] upload tarballs (plus checksums and GPG signatures)
- [x] back to dev
# Cerbero
- [x] build 1.23.2 tag
- [x] binaries
- [x] Windows x86 MinGW + MSVC (@nirbheek)
- [x] Windows x86_64 MinGW + MSVC (@nirbheek)
- [x] Windows UWP release-crt + debug-crt (@nirbheek)
- [x] Android (@thaytan)
- [x] macOS (@ystreet)
- [x] iOS (@ystreet)
- [x] source bundle (@thaytan)
- [x] check for sha265sums for binaries
- [x] check for GPG signatures for binaries
- [x] tag cerbero (@tpm)
- [x] build `main` branch again
- [~] ~~update download section on website~~ (not advertising unstable binaries at the moment)
- [x] announce binaries (twitter, gstreamer-devel)
# Announce
- [x] Mailing lists
- [x] Website: news item
- [x] Twitter (@tpm)
- [x] Mastodon (@slomo)
- [x] IRC channel topic
- [x] Discourse
# Post release
- [x] add 1.23.90 milestone
- [x] add 1.23.90 tracker issue
- [~] after 1.24.0 make sure gst-plugins-rs and orc wrap follow `main` branch again1.23.2Tim-Philipp Müllertim@centricular.comTim-Philipp Müllertim@centricular.com2024-02-13https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3285[Regression] good: qt6 plugin fails to build since replacing `configure_file`...2024-02-09T07:58:04ZMarvin Schmidt[Regression] good: qt6 plugin fails to build since replacing `configure_file` with `fs.copyfile`Trying to build current HEAD (60d9cfc95413c3075fc52c3ff4ae628f41e86b02) of gst-plugins-good with the qt6 plugin enabled fails with the following error for me (happens when running `ninja` after successful `meson setup`):
```
ninja: error...Trying to build current HEAD (60d9cfc95413c3075fc52c3ff4ae628f41e86b02) of gst-plugins-good with the qt6 plugin enabled fails with the following error for me (happens when running `ninja` after successful `meson setup`):
```
ninja: error: '/var/tmp/paludis/build/media-plugins-gst-plugins-good-scm/work/gst-plugins-good-scm/subprojects/gst-plugins-good/ext/qt6/R
GBA.frag.qsb', needed by 'ext/qt6/qt6-resources_qrc.cpp', missing and no known rule to make it
```
This is on Linux using meson 1.3.1:
```
The Meson build system
Version: 1.3.1
Source dir: /var/tmp/paludis/build/media-plugins-gst-plugins-good-scm/work/gst-plugins-good-scm/subprojects/gst-plugins-good
Build dir: /var/tmp/paludis/build/media-plugins-gst-plugins-good-scm/work/_build
[...]
```
Reverting the changes from commit f6f448bb80d05b84daff8943641b920fd661cd35 makes it work again, but re-introduces the warning about using `configure_file`'s deprecated `copy` argument.
It looks like meson uses the `resources.qrc` in the source directory instead of the build directory and subsequently tries to find the compiled shader files specified in the Qt resource file in the source directory as well. But I'm not sure about that as I'm not really familiar with meson's internals1.23.2https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/466gst-plugins-bad recipe : Use custom openssl on linux2024-02-26T16:16:54ZGithubUser8080gst-plugins-bad recipe : Use custom openssl on linuxHello, i would like to ask if it is possible to provide an option for a custom openssl directory on Linux, as the distribution we are using to build gstreamer (centos7) uses 1.0.2 and that does causes compilation to fail. Thank you
EDIT...Hello, i would like to ask if it is possible to provide an option for a custom openssl directory on Linux, as the distribution we are using to build gstreamer (centos7) uses 1.0.2 and that does causes compilation to fail. Thank you
EDIT: this is related to other recipes too like glib-networking. I have tried prepending the custom openssl dir to PKG_CONFIG_PATH, but it seems to be overridden by cerbero.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3284vah265dec - green image with raw output to timeoverlay2024-02-16T13:56:51ZJan Schmidtvah265dec - green image with raw output to timeoverlayI found that here, `va265dec` is producing a green frame when fed through `timeoverlay` to `xvimagesink`, but works without `timeoverlay`.
May be related to #2940, I'm not sure.
Works: `gst-play-1.0 test-h265.mp4 --videosink="xvimagesi...I found that here, `va265dec` is producing a green frame when fed through `timeoverlay` to `xvimagesink`, but works without `timeoverlay`.
May be related to #2940, I'm not sure.
Works: `gst-play-1.0 test-h265.mp4 --videosink="xvimagesink"`
Shows only green frame with time overlay: `gst-play-1.0 test-h265.mp4 --videosink="timeoverlay ! xvimagesink"
```
vainfo: VA-API version: 1.18 (libva 2.18.2)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 23.1.6 ()
```
GST_DEBUG has a lot of
```
0:00:01.824542742 471874 0x7fa5a8001180 DEBUG vamemory gstvaallocator.c:1587:_va_copy: 0x7fa5a01956d0: copy 0, 18446744073709551615
0:00:01.824839743 471874 0x7fa5a8001180 INFO vadisplay vasurfaceimage.c:414:va_copy_surface: vaCopy: invalid parameter
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3283aja: Global named semaphore is never unlinked2024-02-15T10:08:47ZXavier Claessensxclaesse@gmail.comaja: Global named semaphore is never unlinkedAJA plugin has a global named semaphore created with `sem_open("/gstreamer-aja-sem", O_CREAT, S_IRUSR | S_IWUSR, 1);`. That ensures that not 2 processes can configure the device concurrently. However, that semaphore is never closed/unlin...AJA plugin has a global named semaphore created with `sem_open("/gstreamer-aja-sem", O_CREAT, S_IRUSR | S_IWUSR, 1);`. That ensures that not 2 processes can configure the device concurrently. However, that semaphore is never closed/unlinked which means the first user to create the semaphore owns it until reboot. Other users get error `Failed to create SHM semaphore for GStreamer AJA plugin: Permission denied`. This is a problem in our project because the service running in prod runs under a different user (less privileged) than developers that could be running tests with e.g. gst-launch.
In addition, I think the semaphore name should include the `device-identifier` property. It should be a per-device lock and not global.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/490Segmentation fault running `gst-inspect -a` when libgstgtk4.so is installed2024-02-12T17:07:17ZRubén GonzalezSegmentation fault running `gst-inspect -a` when libgstgtk4.so is installed### Describe your issue
Segmentation fault when getting default value of `paintable` property from `gtk4paintablesink` element:
> cannot register existing type 'GdkDisplayManager'
#### Expected Behavior
No Segmentation fault
#### Ob...### Describe your issue
Segmentation fault when getting default value of `paintable` property from `gtk4paintablesink` element:
> cannot register existing type 'GdkDisplayManager'
#### Expected Behavior
No Segmentation fault
#### Observed Behavior
Segmentation fault
#### Setup
- **Operating System:** Arch
- **gst-plugins-rs Version:** main
- **GStreamer Version:** 1.22.9
- **Command line:** `gst-inspect-1.0 -a`
### Steps to reproduce the bug
Easily reproducible with:
```
mkdir lib
cp /usr/lib/gstreamer-1.0/libgstgtk4.so lib
cp /usr/lib/gstreamer-1.0/libgstgtk.so lib
G_DEBUG=fatal-warnings GST_PLUGIN_SYSTEM_PATH=$(realpath lib ) GST_INSPECT_NO_COLORS=true PAGER=cat gst-inspect-1.0 -a
```
### How reproducible is the bug?
Always
`libgstgtk4.so` uses `libgtk-4.so.1` and `libgstgtk.so` uses `libgtk-3.so.0`
### Additional Information
<details><summary>gdb backtrace</summary>
```
Thread 1 "gst-inspect-1.0" received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x7ffff7cd4015 "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd0a0) at ../glib/glib/gmessages.c:1423
1423 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
(gdb) bt
#0 g_logv (log_domain=0x7ffff7cd4015 "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd0a0) at ../glib/glib/gmessages.c:1423
#1 0x00007ffff7d54724 in g_log (log_domain=log_domain@entry=0x7ffff7cd4015 "GLib-GObject", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff7cdbea8 "cannot register existing type '%s'") at ../glib/glib/gmessages.c:1461
#2 0x00007ffff7cc604e in check_type_name_I (type_name=0x7ffff6f250e8 "GdkDisplayManager") at ../glib/gobject/gtype.c:791
#3 0x00007ffff7ccd52f in g_type_register_static (parent_type=parent_type@entry=0x50, type_name=0x7ffff6f250e8 "GdkDisplayManager", info=info@entry=0x7fffffffd1f0, flags=flags@entry=G_TYPE_FLAG_NONE) at ../glib/gobject/gtype.c:2881
#4 0x00007ffff7ccd789 in g_type_register_static_simple
(flags=G_TYPE_FLAG_NONE, instance_init=0x7fffea62dae0 <gdk_display_manager_init>, instance_size=40, class_init=0x7fffea635270 <gdk_display_manager_class_intern_init>, class_size=144, type_name=<optimized out>, parent_type=0x50) at ../glib/gobject/gtype.c:2849
#5 g_type_register_static_simple
(parent_type=parent_type@entry=0x50, type_name=<optimized out>, class_size=class_size@entry=144, class_init=class_init@entry=0x7fffea635270 <gdk_display_manager_class_intern_init>, instance_size=instance_size@entry=40, instance_init=instance_init@entry=0x7fffea62dae0 <gdk_display_manager_init>, flags=G_TYPE_FLAG_NONE) at ../glib/gobject/gtype.c:2822
#6 0x00007fffea62e10e in gdk_display_manager_get_type_once () at ../gtk/gdk/gdkdisplaymanager.c:123
#7 0x00007fffea62f695 in gdk_display_manager_get_type () at ../gtk/gdk/gdkdisplaymanager.c:123
#8 0x00007fffea62f6f2 in gdk_display_manager_get () at ../gtk/gdk/gdkdisplaymanager.c:298
#9 0x00007fffea62f7ce in gdk_display_get_default () at ../gtk/gdk/gdkdisplaymanager.c:332
#10 0x00007ffff2aeb00a in ??? () at /home/tmp/GdkDisplayManager/ws/lib/libgstgtk4.so
#11 0x00007ffff7d4c9e5 in g_main_context_invoke_full (context=0x5555555934e0, priority=200, function=0x7ffff2aeae50, data=0x55555573c360, notify=0x7ffff2aed4f0) at ../glib/glib/gmain.c:6549
#12 0x00007ffff2ad413d in ??? () at /home/tmp/GdkDisplayManager/ws/lib/libgstgtk4.so
#13 0x00007ffff2aed96f in ??? () at /home/tmp/GdkDisplayManager/ws/lib/libgstgtk4.so
#14 0x00007ffff7cb5ecc in object_get_property (value=0x7fffffffdd00, pspec=0x55555574b810, object=0x555555750fc0) at ../glib/gobject/gobject.c:1779
#15 g_object_get_property (object=0x555555750fc0, property_name=<optimized out>, value=0x7fffffffdd00) at ../glib/gobject/gobject.c:3093
#16 0x0000555555559786 in print_object_properties_info (obj=obj@entry=0x555555750fc0, obj_class=0x5555556d3700, desc=desc@entry=0x55555555f6e1 "Element Properties") at ../gstreamer/subprojects/gstreamer/tools/gst-inspect.c:461
#17 0x000055555555bbcb in print_element_properties_info (element=0x555555750fc0 [GstElement|gtk4paintablesink0]) at ../gstreamer/subprojects/gstreamer/tools/gst-inspect.c:799
#18 print_element_info (feature=feature@entry=0x555555592390 [GstPluginFeature|gtk4paintablesink], print_names=print_names@entry=1) at ../gstreamer/subprojects/gstreamer/tools/gst-inspect.c:1773
#19 0x000055555555de3c in print_element_list (ftypes=<optimized out>, print_all=1) at ../gstreamer/subprojects/gstreamer/tools/gst-inspect.c:1389
#20 real_main (argc=<optimized out>, argv=<optimized out>) at ../gstreamer/subprojects/gstreamer/tools/gst-inspect.c:2317
#21 0x00007ffff7ad3cd0 in __libc_start_call_main (main=main@entry=0x555555558020 <main>, argc=argc@entry=2, argv=argv@entry=0x7fffffffe2e8) at ../sysdeps/nptl/libc_start_call_main.h:58
#22 0x00007ffff7ad3d8a in __libc_start_main_impl (main=0x555555558020 <main>, argc=2, argv=0x7fffffffe2e8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe2d8) at ../csu/libc-start.c:360
#23 0x0000555555558055 in _start ()
```
</details>https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3282webrtcbin: does not properly report internal queue overrun when receiving2024-02-22T22:54:38ZHugo Svirakwebrtcbin: does not properly report internal queue overrun when receivingIn the leaky queue inside of transportreceivebin there is a warning message "Internal receive queue overrun. Dropping data" but this information does not make its way to either webrtcstats nor to a property nor to a signal that can be co...In the leaky queue inside of transportreceivebin there is a warning message "Internal receive queue overrun. Dropping data" but this information does not make its way to either webrtcstats nor to a property nor to a signal that can be connected to.
As a workaround instead of catching the warning message we add our own leaky queue after the webrtcbin.
Assuming I'm not mistaken anywhere, I think it would be great to be better informed of this lost data.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3281decodebin3: No valid frames decoded before end of stream2024-02-07T20:08:02ZJonas Kvingedecodebin3: No valid frames decoded before end of stream### Describe your issue
`./gst-libs/gst/audio/gstaudiodecoder.c(2492): gst_audio_decoder_sink_eventfunc (): /GstPlayBin3:pipeline-12-pipeline/GstURIDecodeBin3:uridecodebin3/GstDecodebin3:decodebin3-11/GstFlacDec:flacdec23: no valid fram...### Describe your issue
`./gst-libs/gst/audio/gstaudiodecoder.c(2492): gst_audio_decoder_sink_eventfunc (): /GstPlayBin3:pipeline-12-pipeline/GstURIDecodeBin3:uridecodebin3/GstDecodebin3:decodebin3-11/GstFlacDec:flacdec23: no valid frames found`
File: https://mega.nz/file/bYVSSAaa#_p_6lwzA015i0nWGgB5vmave3qwbizR8f_hV5kY89zs
Not sure if the file is broken, or this is a bug in GStreamer. Could you please have a look.
#### Expected Behavior
Play file
#### Observed Behavior
Error
#### Setup
- **Operating System: Linux
- **Device:** Computer
- **GStreamer Version:** 1.22.9
- **Command line:
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open terminal
2. type `command`:
`GST_DEBUG=*:5 gst-launch-1.0 playbin3 uri=file:////home/jonas/Downloads/test.flac`
### How reproducible is the bug?
Every time
### Screenshots if relevant
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
https://github.com/strawberrymusicplayer/strawberry/issues/1373https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3280qtmux with non-seekable downstream collects all input buffers before outputti...2024-02-07T14:38:53ZJan Schmidtqtmux with non-seekable downstream collects all input buffers before outputting anySince https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/732 if qtmux has a non-seekable downstream, it will in the default mode, collect the entire input stream into the `output_buffers` list before outputting an...Since https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/732 if qtmux has a non-seekable downstream, it will in the default mode, collect the entire input stream into the `output_buffers` list before outputting any of them.
Not only does that mean that memory usage is potentially unbounded, but also CPU consumption is dominated by `g_list_append` walking the super-long output buffers list repeatedly.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3279glcolorconvert: Prefer xRGB formats if downstream supports it and the input i...2024-02-08T15:11:47ZSebastian Drögeglcolorconvert: Prefer xRGB formats if downstream supports it and the input is not an alpha formatBased on discussions on IRC earlier.
```
11:26 <Company> slomo: oh yeah, GTK gained xrgb formats at some point, no idea when, so detecting that when not using alpha would avoid that mess for apps like snapshot
[...]
11:29 <ystreet00> gs...Based on discussions on IRC earlier.
```
11:26 <Company> slomo: oh yeah, GTK gained xrgb formats at some point, no idea when, so detecting that when not using alpha would avoid that mess for apps like snapshot
[...]
11:29 <ystreet00> gstgl kinda always prefers RGBA textures over RGBx atm
11:30 <slomo> ystreet00: yeah was going to ask about that. can we make glupload prefer RGB if downstream handles it and the input is not an alpha format?
11:30 <Company> GL doesn't have the RGBx concept, or?
11:30 <Company> you need to manually carry that information
11:31 <Company> and setup GL_ONE alpha swizzle on the texture
11:32 <ystreet00> gstreamer does have RGBx formats which are represented in gstgl as a RGBA texture with the alpha channel undefined
11:32 <ystreet00> you also want to do this in glcolorconvert and not glupload
11:33 <Company> you don't set a swizzle?
11:33 <Company> I think GTK assumes that a swizzle is set, but I don't remember
11:34 <Company> otherwise we'd need different shaders when blending from it, and that'd be more work
11:35 <ystreet00[m]> we do not set a swizzle
11:36 <Company> so you do custom shaders?
11:36 <ystreet00> yes
11:36 <Company> any reason for that?
11:36 <Company> supporting old GLES that didn't have swizzles?
11:36 <ystreet00> I don't remember off the top of my head about GLES 2.0 support for swizzles
11:37 <Company> I think it doesn't
11:37 <ystreet00> we already had the shader templating infrastructure for different YUV layouts, so more or less reused that for RGBA vs RGBx differences as well
11:37 <Company> that makes sense
11:38 <Company> GLES 2.0 doesn't have swizzles
11:39 <Company> the new renderer doesn't support GLES 2.0 and I think the old one just treats those formats as unsupported then
```
CC @ystreet @Company