GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2024-03-28T12:41:31Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3358Rust-based plugin initialization hangs on Android with GStreamer 1.24.02024-03-28T12:41:31ZNoTuxNoBuxRust-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/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/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/33551.24.0: gst-ptp-helper in rust is MORE THAN 30 times bigger2024-03-06T13:15:31ZTomasz Kłoczko1.24.0: gst-ptp-helper in rust is MORE THAN 30 times bigger```
[tkloczko@pers-jacek gstreamer-1.0]$ size gst-ptp-helper-test gst-ptp-helper gst-ptp-helper.old
text data bss dec hex filename
814256 49000 384 863640 d2d98 gst-ptp-helper-test
393455 17584 296 411...```
[tkloczko@pers-jacek gstreamer-1.0]$ size gst-ptp-helper-test gst-ptp-helper gst-ptp-helper.old
text data bss dec hex filename
814256 49000 384 863640 d2d98 gst-ptp-helper-test
393455 17584 296 411335 646c7 gst-ptp-helper
11639 1256 80 12975 32af gst-ptp-helper.old
```
Is it really necessary to rewrite that small helper in rust to increase binary size by MORE THAN 30 times? :thumbsup:
Rust never was and never will be secure https://github.com/Qwaz/rust-cvehttps://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/gst-plugins-base/-/issues/1013Reconnecting to an element that uses OpenGL does not work on Windows (wgl)2024-03-06T10:40:31ZBen ReinbergerReconnecting to an element that uses OpenGL does not work on Windows (wgl)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.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/3349Hangs and assertions with validate.test.playbin3.intensive_state_change_selec...2024-03-11T12:23:01ZEdward HerveyHangs and assertions with validate.test.playbin3.intensive_state_change_selecting_streamThe biggest issue is ending up "reconfiguring" output slots which don't yet have the active stream yet (it's pending, traversing the multiqueue but hasn't come out yet).
This causes a bunch of assertions.
It would seem as thought the s...The biggest issue is ending up "reconfiguring" output slots which don't yet have the active stream yet (it's pending, traversing the multiqueue but hasn't come out yet).
This causes a bunch of assertions.
It would seem as thought the stream switching code doesn't 100% handle the case where the various streams are traversing the multiqueue. See code in `handle_stream_switch()` and where we add a `idle_reconfigure()` on slots which don't yet have an active stream.Edward HerveyEdward Herveyhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/507nasm build failed during building gstreamer with gstreamer rs plugin2024-03-01T10:02:56ZRoshan Avhadnasm build failed during building gstreamer with gstreamer rs pluginWhen i am building gstreamer with this :
run meson setup --reconfigure . ../$SOURCE_DIR \
--buildtype release --unity off --strip \
--prefix=$INSTALL_PREFIX \
--libdir=$INSTALL_PREFIX/lib \
--default...When i am building gstreamer with this :
run meson setup --reconfigure . ../$SOURCE_DIR \
--buildtype release --unity off --strip \
--prefix=$INSTALL_PREFIX \
--libdir=$INSTALL_PREFIX/lib \
--default-library shared \
--wrap-mode=nofallback \
-Dorc-source=system \
-Dgpl=enabled \
-Drs=enabled \
-Dgstreamer:check=enabled \
-Dexamples=disabled -Dtests=enabled -Dgtk_doc=disabled \
-Dpackage-origin="$GIT_REPO" $OPTS \
"$@"
I am getting below error : ![Screenshot_from_2024-03-01_14-43-30](/uploads/b5f09741558486950bb9693ab89c7e79/Screenshot_from_2024-03-01_14-43-30.png)
how to resolve this ?https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/506Can't connect nvh264enc to webrtcsink2024-03-01T09:51:14ZChris Del GuercioCan't connect nvh264enc to webrtcsinkI have a **webrtcsink** element that I am adding a **nvh264enc** encoder to via the "encoder-setup" signal.
I see vram being used by the program in `nvidia-smi` and I see an encoder session being created, however the encoder session sho...I have a **webrtcsink** element that I am adding a **nvh264enc** encoder to via the "encoder-setup" signal.
I see vram being used by the program in `nvidia-smi` and I see an encoder session being created, however the encoder session shows 0, 0 for fps and latency
```
# GPU Session Process Codec H V Average Average
# Idx Id Id Type Res Res FPS Latency(us)
0 9 623032 H.264 480 304 0 0
```
I also know that it isn't using the nvh264enc encoder because changing the bitrate and max-bitrate does nothing to the bandwidth usage observed via `nload`
I am using **HEAD** of _gst-plugins-rs_ and I've tried using both **1.22.10** and **1.23.90** for _nvcodec_.
I am running this in a podman container and I'm 99% sure I've set up the nvidia container stuff up correct since if I don't, `nvidia-smi` complains if I try to run it in the container.
Here are the relevant snippets of my code. Any help would be greatly appreciated :)
```cpp
// main
///////
g_object_set(G_OBJECT(webrtcsink), "meta",
gst_structure_from_string(("meta,name=" + webrtc_stream_id).c_str(), nullptr), nullptr);
GstCaps* webrtcsink_caps = gst_caps_from_string("video/x-h264,stream-format=byte-stream,alignment=au");
g_object_set(G_OBJECT(webrtcsink), "video-caps", webrtcsink_caps, nullptr);
gst_caps_unref(webrtcsink_caps);
g_object_set(G_OBJECT(webrtcsink), "congestion-control", 0, nullptr);
//g_object_set(G_OBJECT(webrtcsink), "max-bitrate", 2048000, nullptr);
g_signal_connect(webrtcsink, "encoder-setup", G_CALLBACK(EncoderSetupCallback), nullptr);
// pipeline
///////////
src -> watchdog -> bayer2rgb -> videorate -> videorate_capsfilter -> videoconvert -> queue -> webrtcsink
// callback
///////////
gboolean EncoderSetupCallback(GstElement* webrtcsink, gchararray arg0, gchararray arg1,
GstElement* encoder, gpointer udata) {
if (!GST_IS_ELEMENT(webrtcsink) || !arg0 || !arg1 || !GST_IS_ELEMENT(encoder)) {
g_warning("Invalid arguments received in EncoderSetupCallback.");
return false;
}
// Create an instance of the nvh264enc encoder.
encoder = gst_element_factory_make("nvh264enc", "nvh264enc");
if (encoder == nullptr || !GST_IS_ELEMENT(encoder)) {
g_warning("Failed to create nvh264enc encoder.");
return false;
}
g_warning("Created nvh264enc encoder.");
g_object_set(G_OBJECT(encoder), "preset", 3, nullptr);
g_object_set(G_OBJECT(encoder), "bitrate", 2048, nullptr);
g_object_set(G_OBJECT(encoder), "max-bitrate", 2048, nullptr);
g_object_set(G_OBJECT(encoder), "rc-mode", 3, nullptr);
return encoder != nullptr;
}
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3348libav possible overflow error when linking on android2024-03-12T16:05:43ZBen Greenwoodlibav possible overflow error when linking on androidI am attempting to link libav into an Android application (via Flutter framework, version 3.16.8). I'm using GStreamer 1.22, Android NDK version 21.4.7075529, and SDK version 21 (minimum). The build is assisted by CMake, using version 3....I am attempting to link libav into an Android application (via Flutter framework, version 3.16.8). I'm using GStreamer 1.22, Android NDK version 21.4.7075529, and SDK version 21 (minimum). The build is assisted by CMake, using version 3.18. I am building on an Apple M1 machine running Sonoma 14.2.1.
I used pkgconfig in a CMakeLists.txt in a way that works for all the other packages I am linking, but I get this error (and many others like it):
```requires dynamic R_X86_64_PC32 reloc against 'ff_pw_1' which may overflow at runtime; recompile with -fPIC```
From what I can tell from folks who have had this error in other situations, the solution is to recompile libav with -fPIC flag.
You can try to reproduce the issue by cloning a repo I made specifically for this:
https://github.com/bgreenbones/gstreamerAndroidLibavIssueamysparkamysparkhttps://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/gst-plugins-rs/-/issues/505Issue setting signaller:channel-name for awskvswebrtcsink in rust2024-03-01T09:49:05Zmzang3Issue setting signaller:channel-name for awskvswebrtcsink in rust### Describe your issue
Trying to change update the properties of the awskvswebrtcsink
```rust
let aws_kvs_signaller = gst::ElementFactory::make_with_name("awskvswebrtcsink", Some("awskvswebrtcsink"));
```
I've tried this:
```rust
...### Describe your issue
Trying to change update the properties of the awskvswebrtcsink
```rust
let aws_kvs_signaller = gst::ElementFactory::make_with_name("awskvswebrtcsink", Some("awskvswebrtcsink"));
```
I've tried this:
```rust
let signaller = aws_kvs_signaller.property_value("signaller");
let new_signaller = signaller.get_owned().unwrap();
new_signaller.set_property("channel-name", "xxxx");
aws_kvs_signaller.set_property("signaller", signaller);
```
also:
```rust
aws_kvs_signaller.set_property("signaller", "signaller, channel-name=xxx");
```
and also
```rust
aws_kvs_signaller.set_property("signaller::channel-name", "xxx");
```
#### Expected Behavior
Be able to change the signaller properties like in the CLI
#### Observed Behavior
`GstAwsKvsWebRTCSinkSignaller` is read onlyhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3344Official documentation lacks infos compared to mirrors2024-03-01T00:55:57ZManuel WagesreitherOfficial documentation lacks infos compared to mirrorsHi all,
the official GStreamer documentation seems to lack infos that is available in mirrors.
Example:
* The [official doc on `vp8enc`](https://gstreamer.freedesktop.org/documentation/vpx/vp8enc.html) lacks infos on all the properties...Hi all,
the official GStreamer documentation seems to lack infos that is available in mirrors.
Example:
* The [official doc on `vp8enc`](https://gstreamer.freedesktop.org/documentation/vpx/vp8enc.html) lacks infos on all the properties.
* Some [3rd party mirror](https://thiblahute.github.io/GStreamer-doc/vpx-1.0/vp8enc.html) has them.
I'm creating this issues because the user _slomo_ on irc://irc.oftc.net:6697/#gstreamer asked me to do so.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3343Allow for multiple qmlglsink instances on Anrdoid2024-02-28T23:21:57ZJordan MaoAllow for multiple qmlglsink instances on AnrdoidI am working on a fork of QGroundControl, where I am trying to get multiple qmlglsink instances to work on Android. It works on my Linux and Windows build, but I am getting the following log error on Android.
`Cannot map External OES te...I am working on a fork of QGroundControl, where I am trying to get multiple qmlglsink instances to work on Android. It works on my Linux and Windows build, but I am getting the following log error on Android.
`Cannot map External OES textures`
I found this related fix for Windows Allow for multiple qmlglsink instances on https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1004 and was wondering how I could apply this to Android. Any pointers are appreciated.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.