GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2024-03-08T23:18:33Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3367All GStreamer Commands Hang on Mac OS 14 EC22024-03-08T23:18:33ZStefan KieszkowskiAll GStreamer Commands Hang on Mac OS 14 EC2Running simple`gst-inspect-1.0 fakesink`, `gst-launch-1.0 -v --gst-version` commands just hang with no output. I am able to get a pipeline to successfully run programmatically in my application with `gst_bin_add_many`. In case it's relev...Running simple`gst-inspect-1.0 fakesink`, `gst-launch-1.0 -v --gst-version` commands just hang with no output. I am able to get a pipeline to successfully run programmatically in my application with `gst_bin_add_many`. In case it's relevant, I don't have full XCode installed only Command Line Tools due to this being a cloud compute instance I am SSHed into.
Out of the dozen or so GStreamer commands I tried in the command line, this one actually had some output:
```
gst-validate-1.0 foo
**-> Pipeline: 'foo'**
Failed to create pipeline: no element "foo"
```
#### Setup
- Mac OS 14
- EC2 Instance
- GStreamer installed via HomeBrew, latest versionhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3366gl: wayland: Event source keeps spinning after connection error, consider exi...2024-03-08T23:00:30ZRobert Madergl: wayland: Event source keeps spinning after connection error, consider exiting insteadWe are just printing a warning [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/2e1eaaec5e450b9fec035449958ecfef4302f720/subprojects/gst-plugins-base/gst-libs/gst/gl/wayland/wayland_event_source.c#L88-90), spamming the jo...We are just printing a warning [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/2e1eaaec5e450b9fec035449958ecfef4302f720/subprojects/gst-plugins-base/gst-libs/gst/gl/wayland/wayland_event_source.c#L88-90), spamming the journal
```
/* FIXME: this may return EAGAIN if the fd is full */
if (wl_display_flush (source->display) < 0)
g_critical ("Failed to flush Wayland connection\n");
```
where GTK would [exit](https://gitlab.gnome.org/GNOME/gtk/-/blob/09736dde938bee08292c67b348830422ace4012d/gdk/wayland/gdkeventsource.c#L85-89):
```
if (wl_display_flush (display->wl_display) < 0)
{
g_message ("Error flushing display: %s", g_strerror (errno));
_exit (1);
}
```
So this might keep Gstreamer alive, spamming the log, when it should actually exit. Let's consider following GTK here.
---
Related:
- https://gitlab.gnome.org/guidog/livi/-/merge_requests/35#note_2043141https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3362webrtc: ensure additional attributes in rtp_src pad CAPS don't interfere chai...2024-03-07T17:19:13ZFrançois Laignelwebrtc: ensure additional attributes in rtp_src pad CAPS don't interfere chaining webrtcbinsEnsure that additional attributes in `rtp_src` pad CAPS don't interfere when chaining `webrtcbin`s.
See the following discussion: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6119#note_2301896Ensure that additional attributes in `rtp_src` pad CAPS don't interfere when chaining `webrtcbin`s.
See the following discussion: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6119#note_2301896https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/510janusvrwebrtcsink: API exposing when WebRTC is UP2024-03-20T10:09:13ZGuillaume Desmottesjanusvrwebrtcsink: API exposing when WebRTC is UPI'd need API telling application when the Janus publisher is fully up so I can announce it to subscribers.
My current pre `janusvrwebrtcsink` code is waiting for the [`WebRTCUp`](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/...I'd need API telling application when the Janus publisher is fully up so I can announce it to subscribers.
My current pre `janusvrwebrtcsink` code is waiting for the [`WebRTCUp`](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/blob/main/net/webrtc/src/janusvr_signaller/imp.rs?ref_type=heads#L421) message from Janus.
What would be the proper way to expose this to applications?
- A `webrtc-up` signal on the signaller?
- A `janus-state` property tracking the different signaller states: `session-created`, `videoroom-attached`, `room-joined`, `negotiating`, `webrtc-up`?
- Or should this be exposed in a more generic way in the `webrtcsink` base class instead?
@thiblahute : what do you think?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3364lv2: Invalid pg:role port property for Calf patches2024-03-07T17:54:45ZVladimir Sadovnikovlv2: Invalid pg:role port property for Calf patchesHere's the patch for Calf that defines port roles.
https://github.com/GStreamer/gstreamer/blob/main/subprojects/gst-plugins-bad/ext/lv2/calf-lv2-port-groups.patch
But according to LV2 specification, there is no `pg:role` property (as a...Here's the patch for Calf that defines port roles.
https://github.com/GStreamer/gstreamer/blob/main/subprojects/gst-plugins-bad/ext/lv2/calf-lv2-port-groups.patch
But according to LV2 specification, there is no `pg:role` property (as a part of Port Group extension) for the port:
https://lv2plug.in/ns/ext/port-groups
The definition `pg:group` is correct but if we dig into the `pg:group` specification, we get:
https://lv2plug.in/ns/ext/port-groups#group
> Indicates that this port is a part of a group of ports on the plugin. The port should also have an lv2:designation property to define its designation within that group.
So actually instead of `pg:role` the right way to define the port role is usage of the `lv2:designation` property.
Also, there is no `pg:leftChannel` nor `pg:rightChannel` according to the LV2 spec. There are only `pg:left` and `pg:right` definitions:
https://lv2plug.in/ns/ext/port-groups#left
https://lv2plug.in/ns/ext/port-groups#right
This breaks compatibility with plugins that provide the right definition of port groups.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3358Rust-based plugin initialization hangs on Android with GStreamer 1.24.02024-03-28T11:25:48ZNoTuxNoBuxRust-based plugin initialization hangs on Android with GStreamer 1.24.0### Describe your issue
For Android it is necessary to copy `GStreamer.java` to your project and call its `init` so it can in turn call `nativeInit` that is injected by GStreamer. This worked fine on GStreamer 1.22.6 on a Meta Quest 2 fo...### Describe your issue
For Android it is necessary to copy `GStreamer.java` to your project and call its `init` so it can in turn call `nativeInit` that is injected by GStreamer. This worked fine on GStreamer 1.22.6 on a Meta Quest 2 for me, but with GStreamer 1.24.0 the call seems to get 'stuck' and never returns due to an unknown reason with no other code changes.
(Strictly related to 'application development', but since it worked before this sounds like a regression.)
#### Expected Behavior
The call doesn't get stuck and proceeds as was the case before.
#### Observed Behavior
The call never returns.
#### Setup
- **Operating System:**: Android
- **Device:** Mobile (Meta Quest 2)
- **GStreamer Version:** 1.24.0
- **Command line:** N.a.
### Steps to reproduce the bug
Call `init` from `org.freedesktop.gstreamer.GStreamer` from your Android application on a Meta Quest 2 (might also fail elsewhere on Android, I have no other devices to test with).
### How reproducible is the bug?
Every time.
### Solutions you have tried
Disabling the call, but without it none of the hardware-accelerated video decoders are available, from what I understand.
### Additional Information
Not sure if related to https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4115. I checked the source code to see if there have been any changes to the way the native function is injected or what `GStreamer.java` looks like, but no changes seem to have occurred to those files between 1.22.6 and 1.24.0.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/509meson: ERROR: Could not get pkg-config variable and no default provided for <...2024-03-06T13:23:30ZGuillaume Desmottesmeson: ERROR: Could not get pkg-config variable and no default provided for <PkgConfigDependency gstreamer-1.0: True ['>=1.20.0']>Trying to run `meson` in a gst main env from my toolbox F37 environment:
```
❯ meson setup build
The Meson build system
Version: 1.3.2
Source dir: /var/home/cassidy/dev/rust/gst-plugins-rs
Build dir: /var/home/cassidy/dev/rust/gst-plugi...Trying to run `meson` in a gst main env from my toolbox F37 environment:
```
❯ meson setup build
The Meson build system
Version: 1.3.2
Source dir: /var/home/cassidy/dev/rust/gst-plugins-rs
Build dir: /var/home/cassidy/dev/rust/gst-plugins-rs/build
Build type: native build
Project name: gst-plugins-rs
Project version: 0.13.0-alpha.1
C compiler for the host machine: ccache cc (gcc 12.3.1 "cc (GCC) 12.3.1 20230508 (Red Hat 12.3.1-1)")
C linker for the host machine: cc ld.bfd 2.38-27
Rust compiler for the host machine: rustc -C linker=cc (rustc 1.76.0)
Rust linker for the host machine: rustc -C linker=cc ld.bfd 2.38-27
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program python3 (tomllib) found: YES (/usr/bin/python3) modules: tomllib
Program cargo found: YES 1.76.0 1.76.0 (/var/home/cassidy/.cargo/bin/cargo)
Program cargo_wrapper.py found: YES (/usr/bin/python3 /var/home/cassidy/dev/rust/gst-plugins-rs/cargo_wrapper.py)
Program cargo-cbuild found: YES 0.9.30 0.9.30 (/var/home/cassidy/.cargo/bin/cargo-cbuild)
Found pkg-config: YES (/usr/bin/pkg-config) 1.8.0
Run-time dependency glib-2.0 found: YES 2.74.7
Run-time dependency gstreamer-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-app-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-audio-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-base-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-video-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-rtp-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-webrtc-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-sdp-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-check-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-gl-1.0 found: YES 1.25.0.1
Run-time dependency gstreamer-net-1.0 found: YES 1.25.0.1
Library csound64 found: YES
Program nasm found: YES (/usr/bin/nasm)
Run-time dependency openssl found: YES 3.0.9
Run-time dependency pangocairo found: YES 1.50.14
Dependency gstreamer-1.0 found: YES 1.25.0.1 (cached)
Run-time dependency pango found: YES 1.50.14
Dependency pangocairo found: YES 1.50.14 (cached)
Run-time dependency cairo-gobject found: YES 1.17.6
Run-time dependency dav1d found: YES 1.2.1
Dependency cairo-gobject found: YES 1.17.6 (cached)
Run-time dependency libwebpdemux found: YES 1.3.2
Run-time dependency gtk4 found: YES 4.8.3
Program pkg-config found: YES (/usr/bin/pkg-config)
Run-time dependency gobject-2.0 found: YES 2.74.7
Run-time dependency gmodule-2.0 found: YES 2.74.7
Run-time dependency libsodium found: YES 1.0.18
Found CMake: /usr/bin/cmake (3.27.7)
WARNING: CMake Toolchain: Failed to determine CMake compilers state
Run-time dependency csound found: NO (tried pkgconfig and cmake)
docs/meson.build:26:62: ERROR: Could not get pkg-config variable and no default provided for <PkgConfigDependency gstreamer-1.0: True ['>=1.20.0']>
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3356decodebin3: Issues with instant-uri switching with different inputs2024-03-06T08:29:12ZEdward Herveydecodebin3: Issues with instant-uri switching with different inputsWhen doing instant-uri switching between sources which have different number/type of media streams, `decodebin3` isn't "properly" switching over to the new collection/selection
This can be reproduced with the example in https://gitlab.f...When doing instant-uri switching between sources which have different number/type of media streams, `decodebin3` isn't "properly" switching over to the new collection/selection
This can be reproduced with the example in https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3345
The core issue is that:
* `decodebin->active_selection` isn't properly updated when streams replace other (which is used to figure out if the selection is done)
* That is only updated in
* `get_output_for_slot()` **if** the slot doesn't have an associated `DecodebinOutputStream` (which isn't the case since we're re-using it)
* `reassign_slot()` which will be called from `get_output_for_slot()` in the same conditions for a slot no longer usedEdward HerveyEdward Herveyhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3353python: test failures with pygobject 3.472024-03-20T14:29:42ZJeremy Bichapython: test failures with pygobject 3.47- gst-python 1.23.90, 1.24.0
- Debian
The gst-python tests are failing. There are several failures. I'm just pasting the first.
Build log excerpt
=========
```
test: Test fundamentals
start time: 15:00:05
duration: 2.75s
...- gst-python 1.23.90, 1.24.0
- Debian
The gst-python tests are failing. There are several failures. I'm just pasting the first.
Build log excerpt
=========
```
test: Test fundamentals
start time: 15:00:05
duration: 2.75s
result: exit status 1
command: MALLOC_PERTURB_=165
UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1
GST_OVERRIDE_SRC_PATH=/<<PKGBUILDDIR>>/testsuite/../gi/overrides
GST_PLUGIN_PATH_1_0=/<<PKGBUILDDIR>>/build-3.12:/usr/lib/aarch64-linux-gnu/gstreamer-1.0:
/usr/lib/aarch64-linux-gnu/gstreamer-1.0:/<<PKGBUILDDIR>>/build-3.12/plugin:
/<<PKGBUILDDIR>>/testsuite
GST_REGISTRY='/<<PKGBUILDDIR>>/build-3.12/testsuite/Test fundamentals.registry'
GST_OVERRIDE_BUILD_PATH=/<<PKGBUILDDIR>>/build-3.12/testsuite/../gi/overrides
GST_PLUGIN_LOADING_WHITELIST=gstreamer:gst-plugins-base:gst-python@/<<PKGBUILDDIR>>/build-3.12
/usr/bin/python3.12 /<<PKGBUILDDIR>>/build-3.12/../testsuite/runtests.py test_types.py
----------------------------------- stderr -----------------------------------
EEEEEEEEEEEE.EEEEEEEEEEEEEE.EEEE
======================================================================
ERROR: testConstructor (test_types.TestBitmask.testConstructor)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/<<PKGBUILDDIR>>/testsuite/test_types.py", line 387, in testConstructor
r = Gst.Bitmask(1 << 5)
^^^^^^^^^^^^^^^^^^^
TypeError: function takes at most 0 arguments (1 given)
```
Full build log
==============
Click Build-Attempted at https://buildd.debian.org/status/package.php?p=gst-python1.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3350h265parse: HEVC PPS setup for loop_filter_across_tiles_enabled_flag2024-03-05T17:42:06ZSteve Choh265parse: HEVC PPS setup for loop_filter_across_tiles_enabled_flag### Describe your issue
<!-- Please provide a clear and concise summary of the bug. -->
gstreamer might have an issue with this.
HEVC spec (p.86)
loop_filter_across_tiles_enabled_flag equal to 1 specifies that in-loop filtering operat...### Describe your issue
<!-- Please provide a clear and concise summary of the bug. -->
gstreamer might have an issue with this.
HEVC spec (p.86)
loop_filter_across_tiles_enabled_flag equal to 1 specifies that in-loop filtering operations may be performed across tile boundaries in pictures referring to the PPS. loop_filter_across_tiles_enabled_flag equal to 0 specifies that in-loop filtering operations are not performed across tile boundaries in pictures referring to the PPS. The in-loop filtering operations include the deblocking filter and sample adaptive offset filter operations. When not present, the value of loop_filter_across_tiles_enabled_flag is inferred to be equal to 1.
It seems that gstreamer doesn't have default setup.
<!-- For any GStreamer usage questions or application development support
please head over to our new GStreamer Discourse forum at
https://discourse.gstreamer.org/ instead, or find us on
the GStreamer Matrix room at https://matrix.to/#/#gstreamer:gstreamer.org -->
#### Expected Behavior
<!-- What did you expect to happen -->
loop_filter_across_tiles_enabled_flag = 1
#### Observed Behavior
<!-- What actually happened -->
loop_filter_across_tiles_enabled_flag = 0
#### Setup
- **Operating System:**
- **Device:** Computer / Tablet / Mobile / Virtual Machine <!-- Delete as appropriate !-->
- **GStreamer Version:**
- **Command line:**
gstreamer Debian
### 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`
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
### Screenshots if relevant
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3357Reconnecting to an element that uses OpenGL does not work2024-03-07T16:09:50ZBen ReinbergerReconnecting to an element that uses OpenGL does not workWhen trying to replace an element in a pipeline, reconnecting to a part of a pipeline that has OpenGL components (from gst-plugins-base) will not work.
To recreate, use the example code from the documentation: https://gstreamer.freedeskt...When trying to replace an element in a pipeline, reconnecting to a part of a pipeline that has OpenGL components (from gst-plugins-base) will not work.
To recreate, use the example code from the documentation: https://gstreamer.freedesktop.org/documentation/application-development/advanced/pipeline-manipulation.html?gi-language=c#changing-elements-in-a-pipeline and replace the xvimagesink with an glimagesink.
The new element will not connect to the downstream elements and the program will exit with code -1.
Alternatively, the glupload, gldownload combined with an autovideosink can be used.
To observe this behavior, the program has to be compiled for and run on the Windows platform.
This was observed on Windows 10 Pro 22H2 (Build 19045.4046).
The very same program runs fine on Linux using the egl or glx platforms.https://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/gstreamer/-/issues/3347MinGW build errors2024-03-11T21:32:37Zanonymix007MinGW build errorsBuild commands from README do not seem to work.
```
BUILDDIR=$PWD/winebuild/
export WINEPREFIX=$BUILDDIR/wine-prefix/ && mkdir -p $WINEPREFIX
export PREFIX=~/work/gstreamer-mingw_x86_64/
meson/meson.py $BUILDDIR --cross-file meson/cross/...Build commands from README do not seem to work.
```
BUILDDIR=$PWD/winebuild/
export WINEPREFIX=$BUILDDIR/wine-prefix/ && mkdir -p $WINEPREFIX
export PREFIX=~/work/gstreamer-mingw_x86_64/
meson/meson.py $BUILDDIR --cross-file meson/cross/linux-mingw-w64-64bit.txt -Dgst-plugins-bad:vulkan=disabled -Dorc:gtk_doc=disabled --prefix=$PREFIX -Djson-glib:gtk_doc=disabled
meson/meson.py install -C $BUILDDIR/
```
Same with static library:
```
meson/meson.py setup $BUILDDIR --cross-file meson/cross/linux-mingw-w64-64bit.txt -Dgst-plugins-bad:vulkan=disabled -Dorc:gtk_doc=disabled --prefix=$PREFIX --default-library=static -Dgood=enabled -Dbad=enabled -Dugly=enabled -Dgpl=enabled -Dgst-full-target-type=static_library -Djson-glib:gtk_doc=disabled
```
Setup is fine, but install fails with:
```
ninja: Entering directory `/home/user/work/gstreamer/winebuild'
ninja: error: 'subprojects/libsoup-2.74.3/libsoup/soup-enum-types.h', needed by 'subprojects/gst-plugins-good/ext/soup/libgstsoup.a.p/gstsoup.c.obj', missing and no known rule to make it
Could not rebuild /home/user/work/gstreamer/winebuild
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3346gst_plugin_add_dependency hash collision using more than 5 environment variables2024-03-14T17:37:17ZFabián Orccóngst_plugin_add_dependency hash collision using more than 5 environment variables[The hashing function](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/d0713e029cbc84a4e39912816dd9d90095a78f9b/subprojects/gstreamer/gst/gstplugin.c#L1539) left-shifts [5 bits](https://gitlab.freedesktop.org/gstreamer/gstreame...[The hashing function](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/d0713e029cbc84a4e39912816dd9d90095a78f9b/subprojects/gstreamer/gst/gstplugin.c#L1539) left-shifts [5 bits](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/d0713e029cbc84a4e39912816dd9d90095a78f9b/subprojects/gstreamer/gst/gstplugin.c#L1555 ) per environment variable.
In Fluendo, we have noticed that when using more than 5 environment variable, collisions may happen, probably because unsigned int is only 32 bits.
For example the following code, does not trigger plugin re-scanning when setting `LIBVA_DRIVER_NAME=iHD`.
```
const gchar *envvars[] = {
"LIBVA_DRIVER_NAME",
"LIBVA_DRIVER_PATH",
"VDPAU_DRIVER_PATH",
"VDPAU_DRIVER",
"DISPLAY",
"XDG_SESSION_TYPE",
"WAYLAND_DISPLAY",
"FLUVADEC_HW_BACKEND",
NULL
};
gst_plugin_add_dependency (
plugin, env, NULL, NULL, GST_PLUGIN_DEPENDENCY_FLAG_NONE);
```
This happens because **hashes are the same** whether setting or not `LIBVA_DRIVER_NAME` environment variable.
**Example of operations performed without setting `LIBVA_DRIVER_NAME`:**
```
guint sum = 0;
// LIBVA_DRIVER_NAME (unset)
sum = sum << 5;
// LIBVA_DRIVER_PATH (unset)
sum = sum << 5;
// VDPAU_DRIVER_PATH (unset)
sum = sum << 5;
// VDPAU_DRIVER (unset)
sum = sum << 5;
// DISPLAY=:0
sum = sum << 5;
sum += 5861871;
// XDG_SESSION_TYPE=wayland
sum = sum << 5;
sum += -1222592203;
// WAYLAND_DISPLAY=wayland-0
sum = sum << 5;
sum += 36954226;
// FLUVADEC_HW_BACKEND (unset)
sum = sum << 5;
// Result
// sum: -2108136896
```
**Example of operations performed setting `LIBVA_DRIVER_NAME`:**
```
guint sum = 0;
// LIBVA_DRIVER_NAME=iHD
sum = sum << 5;
sum += 193493786; // hash calculated with g_str_hash, same in all cases
// LIBVA_DRIVER_PATH (unset)
sum = sum << 5;
// VDPAU_DRIVER_PATH (unset)
sum = sum << 5;
// VDPAU_DRIVER (unset)
sum = sum << 5;
// DISPLAY=:0
sum = sum << 5;
sum += 5861871;
// XDG_SESSION_TYPE=wayland
sum = sum << 5;
sum += -1222592203;
// WAYLAND_DISPLAY=wayland-0
sum = sum << 5;
sum += 36954226;
// FLUVADEC_HW_BACKEND (unset)
sum = sum << 5;
// Result:
// sum: -2108136896
```
As we can see, in both cases, hash is the same. This is a bug.
Workaround: Call gst_plugin_add_dependency each time per environment variable.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3345uridecodebin3 randomly hangs while switching uris2024-03-06T08:29:14ZRares Braniciuridecodebin3 randomly hangs while switching uris### Describe your issue
<!-- Please provide a clear and concise summary of the bug. -->
uridecodebin3 randomly hangs while switching uris with instant-uri=true. Sometimes it crashes too.
I wrote a test program that simply switched uris b...### Describe your issue
<!-- Please provide a clear and concise summary of the bug. -->
uridecodebin3 randomly hangs while switching uris with instant-uri=true. Sometimes it crashes too.
I wrote a test program that simply switched uris between two files, waiting a few seconds. The playback hung up randomly after a switch, usually before the 10th switch.
<!-- For any GStreamer usage questions or application development support
please head over to our new GStreamer Discourse forum at
https://discourse.gstreamer.org/ instead, or find us on
the GStreamer Matrix room at https://matrix.to/#/#gstreamer:gstreamer.org -->
#### Expected Behavior
<!-- What did you expect to happen -->
uridecodebin3 should switch uris and play smoothly, no matter how many switches.
#### Observed Behavior
<!-- What actually happened -->
Playback hanged after a few switches. I would Ctrl+C and retry. Sometimes it crashed.
#### Setup
- **Operating System:**
- Windows 11
- **GStreamer Version:**
- 1.22.10 (update: also 1.23.90 / pre-1.24 git main)
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
I built and ran the following program. I can upload the video files, but the exact files don't seem to be significant.
Playback would hang usually under 10 iterations.
```
#include <iostream>
#include <gst/gst.h>
const char* files[] =
{
"file:///d:/data/test1920x1080x60_h264.mp4",
"file:///d:/data/test1920x1080x60_h265.mp4"
};
int main()
{
gst_init(NULL, NULL);
GstElement* pipeline = gst_parse_launch("uridecodebin3 name=decodebin instant-uri=true uri=file:///d:/data/test1920x1080x60_h264.mp4 ! autovideosink", nullptr);
GstElement* decodebin = gst_bin_get_by_name(GST_BIN(pipeline), "decodebin");
gst_element_set_state(pipeline, GST_STATE_PLAYING);
for (int i = 0; i < 10000; i++)
{
g_usleep(5000000);
g_object_set(decodebin, "uri", files[(i + 1) & 1]);
printf("%d\n", i);
}
gst_element_set_state(pipeline, GST_STATE_NULL);
gst_object_unref(decodebin);
gst_object_unref(pipeline);
gst_deinit();
}
```
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
It always hangs, although the number of iterations required varies.
It crashes intermittently.
### Screenshots if relevant!
Source and call stack for crash:
[bug](/uploads/6a890b0f5048935ef4ae7e9812e39b8d/bug.png)https://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/gstreamer/-/issues/3340asiosink: gstasioringbuffer.cpp:469:gst_asio_ring_buffer_get_caps: assertion ...2024-02-27T21:59:19ZJonas Kvingeasiosink: gstasioringbuffer.cpp:469:gst_asio_ring_buffer_get_caps: assertion failed: (buf->asio_object != nullptr)I periodically see this:
```
C:\>gst-launch-1.0 filesrc location=c:/Users/jonas/Music/Snowy_White/Highway_To_The_Sun/05_-_Snowy_White_-_Highway_To_The_Sun_-_The_Time_Has_Come.flac ! decodebin ! audioconvert ! asiosink device-clsid="\{90...I periodically see this:
```
C:\>gst-launch-1.0 filesrc location=c:/Users/jonas/Music/Snowy_White/Highway_To_The_Sun/05_-_Snowy_White_-_Highway_To_The_Sun_-_The_Time_Has_Come.flac ! decodebin ! audioconvert ! asiosink device-clsid="\{90140790-B6B9-4F97-82FD-5240982AAA7C\}"
Use Windows high-resolution clock, precision: 1 ms
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
CPU info (x86-64):
CMOV ....... Y
MMX ........ Y
SSE ........ Y
SSE2 ....... Y
SSE3 ....... Y
SSSE3 ...... Y
SSE41 ...... Y
SSE42 ...... Y
AVX ........ Y
FMA ........ Y
AVX2 ....... Y
BMI2 ....... Y
AVX OS sup . Y
Redistribute latency...
ERROR: from element /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstFlacParse:flacparse0: Internal data stream error.
Additional debug info:
../libs/gst/base/gstbaseparse.c(3702): gst_base_parse_loop (): /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstFlacParse:flacparse0:
streaming stopped, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
**
ERROR:../sys/asio/gstasioringbuffer.cpp:469:gst_asio_ring_buffer_get_caps: assertion failed: (buf->asio_object != nullptr)
Bail out! ERROR:../sys/asio/gstasioringbuffer.cpp:469:gst_asio_ring_buffer_get_caps: assertion failed: (buf->asio_object != nullptr)
```
The audio also periodically plays faster than normal speed.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3339wasapisink: Low distorted audio in exclusive mode2024-02-27T21:35:06ZJonas Kvingewasapisink: Low distorted audio in exclusive mode### Describe your issue
Low distorted audio in exclusive mode.
This is on a Mcintosh DA2 DAC. The display shows it's playing the file without resampling in 44.4KHz 16 bit.
#### Expected Behavior
Play audio.
#### Observed Behavior
Atta...### Describe your issue
Low distorted audio in exclusive mode.
This is on a Mcintosh DA2 DAC. The display shows it's playing the file without resampling in 44.4KHz 16 bit.
#### Expected Behavior
Play audio.
#### Observed Behavior
Attaching debug log.
#### Setup
- **Operating System:** Windows 10
- **Device:** Computer
- **GStreamer Version:** 1.23.90 (d474de8ff0d188fb5b0374f6fa2ad21df05ee5e3)
- **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`
SET GST_DEBUG=4,wasapi*:6
`gst-launch-1.0 filesrc location=c:/Users/jonas/Music/Snowy_White/Highway_To_The_Sun/05_-_Snowy_White_-_Highway_To_The_Sun_-_The_Time_Has_Come.flac ! decodebin ! audioconvert ! wasapisink device="\{0.0.0.00000000\}.\{6ae58894-0112-49fa-a790-6d7e9d27da23\}" exclusive=1`
### How reproducible is the bug?
Every time.
### Screenshots if relevant
### Solutions you have tried
### Related non-duplicate issues
### Additional Informationhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3336aja failure2024-02-25T07:36:25ZSolarAquarionaja failureCan't find the pkg-config and the source repository changed for libajantv2Can't find the pkg-config and the source repository changed for libajantv2https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/501rtpbasepay2: Consider RTP header extension size in max payload size2024-02-23T13:22:37ZSebastian Drögertpbasepay2: Consider RTP header extension size in max payload sizeThe following discussion from !1424 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1424#note_2293620):
> This is something that would be worth fixi...The following discussion from !1424 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1424#note_2293620):
> This is something that would be worth fixing, and I think we can fix this in the new base classes. But as the old ones have exactly the same bug, and API changes are not a problem here, I'd leave this for the future. It doesn't block this MR.