GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2024-02-01T19:05:21Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3222Incorrect RTSP SETUP Command Format in GStreamer 1.22.02024-02-01T19:05:21ZLuc BusquinIncorrect RTSP SETUP Command Format in GStreamer 1.22.0**Description:**
With GStreamer version 1.22.0, I am encountering an issue when establishing an RTSP connection to an IP camera. The SETUP command in the RTSP handshake is missing essential credentials, preventing the stream from being ...**Description:**
With GStreamer version 1.22.0, I am encountering an issue when establishing an RTSP connection to an IP camera. The SETUP command in the RTSP handshake is missing essential credentials, preventing the stream from being established. While other commands, such as OPTIONS and DESCRIBE, are formatted correctly, the SETUP command is incomplete compared to previous versions and other RTSP clients like VLC.
This issue was not present in GStreamer version 1.14.
**Expected SETUP Command (GStreamer 1.14 and VLC):**
`SETUP rtsp://192.168.42.10:554/user=admin&password=&channel=1&stream=0.sdp/trackID=3 RTSP/1.0`
**Actual SETUP Command in GStreamer 1.22.0:**
`SETUP rtsp://192.168.42.10:554/trackID=3 RTSP/1.0`
#### Environment
- OS: Debian 12
- Device: Raspberry Pi 5
- GStreamer Version: 1.22.0
- Pipeline Used: `gst-launch-1.0 rtspsrc location='rtsp://192.168.42.10:554/user=admin&password=&channel=1&stream=0.sdp'`
### Steps to Reproduce
1. Open a terminal.
2. Execute the command: `gst-launch-1.0 rtspsrc location='rtsp://192.168.42.10:554/user=admin&password=&channel=1&stream=0.sdp'`.
3. Use Wireshark to observe the RTSP SETUP command.
### Frequency of Occurrence
The bug occurs consistently and is reproducible every time the above command is executed.
### Impact
The malformed SETUP command results in the failure to establish an RTSP stream from the IP camera, which is a critical functionality for applications relying on real-time video feeds.
### Additional Information
- The RTSP stream from the IP camera works as expected when accessed using VLC, which suggests that the camera's RTSP server is functioning correctly.
- The issue seems to be specific to the GStreamer version 1.22.0, as earlier versions (e.g., 1.14) do not exhibit this behavior.
- Network traffic analysis via Wireshark confirms the discrepancy in the SETUP command between GStreamer versions.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3223dashsink: Why there is no implementation for segment timeline?2024-01-15T10:12:44ZJasur Dovurovdashsink: Why there is no implementation for segment timeline?There are some implementation files for Segment Timeline Representation [gstmpdsegmenttimelinenode.h](ext/dash/gstmpdsegmenttimelinenode.h) and [gstmpdsegmenttimelinenode.c](ext/dash/gstmpdsegmenttimelinenode.c), but it has not been impl...There are some implementation files for Segment Timeline Representation [gstmpdsegmenttimelinenode.h](ext/dash/gstmpdsegmenttimelinenode.h) and [gstmpdsegmenttimelinenode.c](ext/dash/gstmpdsegmenttimelinenode.c), but it has not been implemented inside struct [_GstMPDRepresentationNode](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/discontinued-for-monorepo/ext/dash/gstmpdrepresentationnode.h#L35) and also not implemented in [gstdashsink.c](ext/dash/gstdashsink.c) and there is only boolean choice `use-segment-list` to select SegmentList or SegmentTemplate. Are there any plans to continue to integrate this feature to the dashsink?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3220webrtcdsp: echo cancellation issue with stereo signal2024-01-27T16:52:46ZFabien Danieauwebrtcdsp: echo cancellation issue with stereo signal### Describe your issue
The echo cancellation feature of webrtcdsp breaks the stereo of an audio signal.
Discussed here: https://discourse.gstreamer.org/t/webrtcdsp-stereo-echo-cancellation/739/2
#### Expected Behavior
Captured stereo ...### Describe your issue
The echo cancellation feature of webrtcdsp breaks the stereo of an audio signal.
Discussed here: https://discourse.gstreamer.org/t/webrtcdsp-stereo-echo-cancellation/739/2
#### Expected Behavior
Captured stereo should be played back as is by the speakers.
`gst-launch-1.0 alsasrc ! webrtcdsp echo-cancel=true ! webrtcechoprobe ! audioconvert ! alsasink`
#### Observed Behavior
Only one channel is output. Goes back to normal with echo-cancel=false.
#### Setup
- **Operating System:** Ubuntu 22.04
- **Device:** Computer
- **GStreamer Version:** 1.23.1 (commit 79ffe4f4)
### Steps to reproduce the bug
This pipeline sends two different signals on the left and right channels. Using echo-cancel=true or false, the stereo is degraded.
```
gst-launch-1.0 \
audiotestsrc volume=0.1 ! capsfilter caps=audio/x-raw,format=S16LE,rate=8000,channels=1,channel-mask=\(bitmask\)0x1 name=left \
audiotestsrc freq=1320 volume=0.1 ! capsfilter caps=audio/x-raw,format=S16LE,rate=8000,channels=1,channel-mask=\(bitmask\)0x2 name=right \
interleave name=i left. ! i. right. ! i. \
i. ! webrtcdsp echo-cancel=true ! webrtcechoprobe \
! audioconvert ! audioresample ! alsasink
```
### How reproducible is the bug?
Systematic
### Additional Information
Discussed with @fengalin. The regression seems to have appeared since https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/d5755744c3e2b70e9f04704ae9d18b928d9fa456https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/461Error Android. Generated package with qt5 support fails to link to qmlglsink2024-01-15T17:45:31ZJose Diego Avila RuizError Android. Generated package with qt5 support fails to link to qmlglsinkHello to everyone.
I´ve been strugling for many days and I can not find a solution. I hope you could help me. I've been using gstreamer on Android for a long time. I would like to render a video on a qml item. So i found **qmlglsink**.
...Hello to everyone.
I´ve been strugling for many days and I can not find a solution. I hope you could help me. I've been using gstreamer on Android for a long time. I would like to render a video on a qml item. So i found **qmlglsink**.
**Relevant note:** I'm writing a beginners guide of how to use gstreamer on Android with qt support Audio / Video. By using Android Activity ( Native window ) And qmlglsink ( When we find a working solution )
First at all I build the package with te following command :
**./cerbero-uninstalled -v qt5 -c config/cross-android-universal.cbc package gstreamer-1.0**
( BTW I set the qmake path to : /opt/Qt/5.15.2/android/bin )
Then I uncompress the generated tar package. And I link it to my cmake...
At this point I have 2 big questions:
1 - The ndk path should be pointing to: **/cerbero/build/android-ndk-25** or my "normal" used ndk ( In the 2 ways i got the same error)
2 - The second generated tar package ( runtime ) . Whats its purpose? Should I Use it?
**CMAKE PARAMS**
-GNinja
-DCMAKE_BUILD_TYPE:STRING=Debug
-DCMAKE_PROJECT_INCLUDE_BEFORE:PATH=%{IDE:ResourcePath}/package-manager/auto-setup.cmake
-DQT_QMAKE_EXECUTABLE:STRING=%{Qt:qmakeExecutable}
-DCMAKE_PREFIX_PATH:STRING=%{Qt:QT_INSTALL_PREFIX}
-DCMAKE_C_COMPILER:STRING=%{Compiler:Executable:C}
-DCMAKE_CXX_COMPILER:STRING=%{Compiler:Executable:Cxx}
-DANDROID_NATIVE_API_LEVEL:STRING=21
-DANDROID_NDK:PATH=/home/diego/Android/Sdk/ndk/21.3.6528147
-DCMAKE_TOOLCHAIN_FILE:PATH=/home/diego/Android/Sdk/ndk/21.3.6528147/build/cmake/android.toolchain.cmake
-DANDROID_ABI:STRING=arm64-v8a
-DANDROID_STL:STRING=c++_shared
-DCMAKE_FIND_ROOT_PATH:PATH=%{Qt:QT_INSTALL_PREFIX}
-DANDROID_SDK:PATH=/home/diego/Android/Sdk
**CMAKE**
cmake_minimum_required(VERSION 3.5)
project(TestAndroidVideo LANGUAGES CXX)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
set(CMAKE_AUTOUIC ON)
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTORCC ON)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
message(STATUS ${ANDROID_ABI} )
message(STATUS ${ANDROID_BUILD_ABI_arm64-v8a})
if ( ANDROID_ABI STREQUAL "armeabi-v7a" )
set(GSTREAMER_ARCH_FOLDER armv7)
elseif( ANDROID_ABI STREQUAL "arm64-v8a" )
set(GSTREAMER_ARCH_FOLDER arm64)
elseif( ANDROID_ABI STREQUAL "x86" )
set(GSTREAMER_ARCH_FOLDER x86)
endif()
message(STATUS "GSTREAMER_ARCH_FOLDER: " ${GSTREAMER_ARCH_FOLDER})
set(GST_ROOT_ANDROID "/home/diego/Desktop/cerbero/build/dist/android_universal/${GSTREAMER_ARCH_FOLDER}")
message(STATUS "GST_ROOT_ANDROID: " ${GST_ROOT_ANDROID})
set(ANDROID_PACKAGE_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/android")
set(LIB_GSTREAMER_ANDROID "${ANDROID_PACKAGE_SOURCE_DIR}/libs/${ANDROID_ABI}/libgstreamer_android.so")
message(STATUS "LIB_GSTREAMER_ANDROID: " ${LIB_GSTREAMER_ANDROID})
add_custom_command(OUTPUT ${LIB_GSTREAMER_ANDROID}
COMMAND "${ANDROID_PACKAGE_SOURCE_DIR}/build_gstreamer.sh" "${ANDROID_PACKAGE_SOURCE_DIR}" --argument )
add_custom_target(gstreamer_lib ALL DEPENDS ${LIB_GSTREAMER_ANDROID})
set(ANDROID_EXTRA_LIBS ${LIB_GSTREAMER_ANDROID})
set(DISTFILES "${ANDROID_PACKAGE_SOURCE_DIR}/AndroidManifest.xml"
"${ANDROID_PACKAGE_SOURCE_DIR}/build.gradle"
"${ANDROID_PACKAGE_SOURCE_DIR}/res/values/libs.xml"
"${ANDROID_PACKAGE_SOURCE_DIR}/src/com/atr/amc/SurfaceViewManager.java")
find_package(Qt5 COMPONENTS Core Quick AndroidExtras REQUIRED)
file(GLOB_RECURSE HEADERS "*.h")
file(GLOB_RECURSE SOURCES "*.cpp")
set(RESOURCES "qml.qrc" )
add_library(TestAndroidVideo SHARED ${SOURCES} ${HEADERS} ${RESOURCES} )
target_link_libraries(TestAndroidVideo PRIVATE ${LIB_GSTREAMER_ANDROID} android)
target_include_directories(TestAndroidVideo PRIVATE
${GST_ROOT_ANDROID}/include/gstreamer-1.0
${GST_ROOT_ANDROID}/include/glib-2.0
${GST_ROOT_ANDROID}/lib/glib-2.0/include)
add_executable(TestAndroidVideo ${SOURCES} ${HEADERS} ${RESOURCES} )
target_compile_definitions(TestAndroidVideo PRIVATE $<$<OR:$<CONFIG:Debug>,$<CONFIG:RelWithDebInfo>>:QT_QML_DEBUG>)
target_link_libraries(TestAndroidVideo PRIVATE Qt5::Core Qt5::Quick Qt5::AndroidExtras)
**BUILD GSTREAMER SH**
echo $@;
. ~/.bashrc
cd $1
ndk-build
**Android.MK**
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := TestAndroidVideo
LOCAL_SHARED_LIBRARIES := gstreamer_android
LOCAL_LDLIBS := -llog
include $(BUILD_SHARED_LIBRARY)
ifndef GSTREAMER_ROOT_ANDROID
$(error GSTREAMER_ROOT_ANDROID is not defined!)
endif
ifeq ($(TARGET_ARCH_ABI),armeabi)
GSTREAMER_ROOT := $(GSTREAMER_ROOT_ANDROID)/arm
else ifeq ($(TARGET_ARCH_ABI),armeabi-v7a)
GSTREAMER_ROOT := $(GSTREAMER_ROOT_ANDROID)/armv7
else ifeq ($(TARGET_ARCH_ABI),arm64-v8a)
GSTREAMER_ROOT := $(GSTREAMER_ROOT_ANDROID)/arm64
else ifeq ($(TARGET_ARCH_ABI),x86)
GSTREAMER_ROOT := $(GSTREAMER_ROOT_ANDROID)/x86
else ifeq ($(TARGET_ARCH_ABI),x86_64)
GSTREAMER_ROOT := $(GSTREAMER_ROOT_ANDROID)/x86_64
else
$(error Target arch ABI not supported: $(TARGET_ARCH_ABI))
endif
GSTREAMER_NDK_BUILD_PATH := $(GSTREAMER_ROOT)/share/gst-android/ndk-build/
include $(GSTREAMER_NDK_BUILD_PATH)/plugins.mk
GSTREAMER_PLUGINS := $(GSTREAMER_PLUGINS_CORE) $(GSTREAMER_PLUGINS_QT5)
GSTREAMER_EXTRA_LIBS := -liconv
GSTREAMER_EXTRA_DEPS := gstreamer-controller-1.0 gstreamer-video-1.0 gstreamer-base-1.0 gstreamer-pbutils-1.0 openssl
include $(GSTREAMER_NDK_BUILD_PATH)/gstreamer-1.0.mkhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3218webrtcbin: set-description implementation is not spec-compliant2024-01-23T08:30:16ZPhilippe Normandwebrtcbin: set-description implementation is not spec-compliantOur implementation of https://w3c.github.io/webrtc-pc/#set-the-session-description doesn't look correct. For instance, we apply step 6.5 (https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/0d04660c5dca53096db1711d7925e1920685b137/...Our implementation of https://w3c.github.io/webrtc-pc/#set-the-session-description doesn't look correct. For instance, we apply step 6.5 (https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/0d04660c5dca53096db1711d7925e1920685b137/subprojects/gst-plugins-bad/ext/webrtc/gstwebrtcbin.c#L6454) before step 6.4 (https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/0d04660c5dca53096db1711d7925e1920685b137/subprojects/gst-plugins-bad/ext/webrtc/gstwebrtcbin.c#L6595)
Also, an addition to the spec from a couple years ago, calling `set-local-description` without description should either use an internally generated offer, or answer, depending on the signaling state. Currently we reject this case (bad input).https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3224Buffers Stuck When Pausing Live Source with Custom Sink2024-01-29T22:54:11ZStefan KieszkowskiBuffers Stuck When Pausing Live Source with Custom SinkHello, I'm having troubles pausing then playing the live source element of a pipeline. The issue is that there are frames that don't make it to the sink when I pause the live source element until after I play it again. Here is my pipelin...Hello, I'm having troubles pausing then playing the live source element of a pipeline. The issue is that there are frames that don't make it to the sink when I pause the live source element until after I play it again. Here is my pipeline sans caps filters:
`autovideosrc ! x264enc ! customSink`
When I change the `autovideosrc`'s state PLAYING->PAUSED, the pipeline immediately stops, and upon setting state back PAUSED->PLAYING, the first few frames that `customSink` receives are the old ones from just before pausing the element.
I've tried several things including ASYNC handling and flushing, and also came across resources suggesting it may involve pull/push configuration of elements or the pipeline clock settings. I've experimented with just about every possible configuration and order I could come up with, and still not getting the desired behavior. Any guidance would be greatly appreciated.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3216gl/glx: gst_gl_context_glx_activate causes leaks2024-02-06T13:39:05ZRobert Madergl/glx: gst_gl_context_glx_activate causes leaksFrom https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5727:
Adding passtrough support to `glcolorconvert` causes leaks on glx. There are [various tests blocklisted for valgrind](https://gitlab.freedesktop.org/gstreame...From https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5727:
Adding passtrough support to `glcolorconvert` causes leaks on glx. There are [various tests blocklisted for valgrind](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-devtools/validate/launcher/testsuites/check.py?ref_type=heads#L92-95) already mentioning reasons like "driver leaks" but not linking an issue, so I assume this is caused by the MR and figured it would make sense to create this issue, possibly allowing to remove a bunch of valgrind blocklist entries once fixed.
<details><summary>valgrind summary</summary>
Running suite(s): autovideoconvert
0%: Checks: 1, Failures: 0, Errors: 1
../subprojects/gst-plugins-bad/tests/check/elements/autovideoconvert.c:89:E:general:test_autovideoconvert_videoconvert:0: (after this point) Early exit with return value 20
Check suite autovideoconvert ran in 13.314s (tests failed: 1)
**Duration**: 17.789213180541992
## test_autovideoconvert_videoconvert.valgrind:
```
==17399== Memcheck, a memory error detector
==17399== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==17399== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==17399== Command: /builds/rmader/gstreamer/build/subprojects/gst-plugins-bad/tests/check/elements_autovideoconvert
==17399== Parent PID: 14558
==17399==
==17501==
==17501== HEAP SUMMARY:
==17501== in use at exit: 1,279,683 bytes in 8,547 blocks
==17501== total heap usage: 93,048 allocs, 84,501 frees, 73,210,986 bytes allocated
==17501==
==17501== 5,355 bytes in 255 blocks are definitely lost in loss record 4,227 of 4,250
==17501== at 0x484286F: malloc (vg_replace_malloc.c:381)
==17501== by 0x4C0114E: strdup (strdup.c:42)
==17501== by 0x9B73781: ???
==17501== by 0x9B73524: ???
==17501== by 0x89DFE91: FixupDispatchTable (GLdispatch.c:257)
==17501== by 0x89E0C1F: UnknownInlinedFun (GLdispatch.c:587)
==17501== by 0x89E0C1F: __glDispatchMakeCurrent (GLdispatch.c:555)
==17501== by 0x8902CD1: InternalMakeCurrentDispatch (libglx.c:921)
==17501== by 0x890711A: CommonMakeCurrent (libglx.c:1074)
==17501== by 0x865883A: gst_gl_context_glx_activate (gstglcontext_glx.c:878)
==17501== by 0x86230CC: gst_gl_context_activate (gstglcontext.c:777)
==17501== by 0x862513C: gst_gl_context_create_thread (gstglcontext.c:1335)
==17501== by 0x4A5DC41: g_thread_proxy (gthread.c:826)
==17501== by 0x4F532A4: start_thread (pthread_create.c:481)
==17501== by 0x4C71322: clone (clone.S:95)
==17501==
{
<insert_a_suppression_name_here>
Memcheck:Leak
match-leak-kinds: definite
fun:malloc
fun:strdup
obj:*
obj:*
fun:FixupDispatchTable
fun:UnknownInlinedFun
fun:__glDispatchMakeCurrent
fun:InternalMakeCurrentDispatch
fun:CommonMakeCurrent
fun:gst_gl_context_glx_activate
fun:gst_gl_context_activate
fun:gst_gl_context_create_thread
fun:g_thread_proxy
fun:start_thread
fun:clone
}
==17501== LEAK SUMMARY:
==17501== definitely lost: 5,355 bytes in 255 blocks
==17501== indirectly lost: 0 bytes in 0 blocks
==17501== possibly lost: 0 bytes in 0 blocks
==17501== still reachable: 264,722 bytes in 2,714 blocks
==17501== suppressed: 989,782 bytes in 5,403 blocks
==17501== Reachable blocks (those to which a pointer was found) are not shown.
==17501== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==17501==
==17501== For lists of detected and suppressed errors, rerun with: -s
==17501== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
==17399==
==17399== HEAP SUMMARY:
==17399== in use at exit: 655,371 bytes in 1,595 blocks
==17399== total heap usage: 59,723 allocs, 58,128 frees, 35,552,145 bytes allocated
==17399==
==17399== LEAK SUMMARY:
==17399== definitely lost: 0 bytes in 0 blocks
==17399== indirectly lost: 0 bytes in 0 blocks
==17399== possibly lost: 0 bytes in 0 blocks
==17399== still reachable: 96 bytes in 2 blocks
==17399== suppressed: 648,459 bytes in 1,526 blocks
==17399== Reachable blocks (those to which a pointer was found) are not shown.
==17399== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==17399==
==17399== For lists of detected and suppressed errors, rerun with: -s
==17399== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)
</details>https://gitlab.freedesktop.org/gstreamer/orc/-/issues/54Document on how to contribute a new target2024-01-22T10:12:03ZJorge ZapataDocument on how to contribute a new targetNow that ORC has a CONTRIBUTING.md file, and that a lot of excellent work has been done to add AVX support, it will be good to enhance the document with a brief explanation of what is required to add a new target, including the modificat...Now that ORC has a CONTRIBUTING.md file, and that a lot of excellent work has been done to add AVX support, it will be good to enhance the document with a brief explanation of what is required to add a new target, including the modification of generate_xml_table.c. This will help us update the target table at https://gstreamer.pages.freedesktop.org/orc/docs/latest/orc-opcodes.html. If a target has poor coverage, it should be include too to know where to improve ORC.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3212debug: Add API to push/pop current object to TLS for logging purposes2024-01-09T06:54:20ZSebastian Drögedebug: Add API to push/pop current object to TLS for logging purposesCurrently we either have to pass through objects to code that does not concern itself with the object just for logging purposes, or get logs that are unconnected to the object that initially initiated them.
It would be great if we had s...Currently we either have to pass through objects to code that does not concern itself with the object just for logging purposes, or get logs that are unconnected to the object that initially initiated them.
It would be great if we had some API that allows pushing/popping the current object to a TLS variable, and then `GST_DEBUG()` etc make use of that if set. This would, for example, allow the code in `GstVideoConverter` to print the `videoconvert` object as part of the debug logs instead of just printing generic logs.
Main question here would be if this has considerable performance impact if logging is disabled (you'd still need to push/pop the object because you don't know what actual debug category and level is used at a later time).https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3211mfvideosrc: add a video device dialog (feature request)2024-01-09T01:00:59ZMaurizio Buratomfvideosrc: add a video device dialog (feature request)the libavdevice offer a show_video_device_dialog option that if set to true, before capture starts, popup a display dialog to the end user, allowing them to change video device properties and configurations manually.
would it be possibl...the libavdevice offer a show_video_device_dialog option that if set to true, before capture starts, popup a display dialog to the end user, allowing them to change video device properties and configurations manually.
would it be possible to add such option to mfvideosrc? this is especially usefull when capturing a webcam because sometimes the user want to change some device setting before the capture start
thank youhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3210netsim: unclear how to use max-kbps2024-01-08T11:23:50ZGuillaume Desmottesnetsim: unclear how to use max-kbpsI tried using `netsim max-kbps=` but was surprised that the property is not working. Turned out we have to set `max-bucket-size` as well or the property is ignored.
It's really not that clear from the doc:
```
max-bucket-size : T...I tried using `netsim max-kbps=` but was surprised that the property is not working. Turned out we have to set `max-bucket-size` as well or the property is ignored.
It's really not that clear from the doc:
```
max-bucket-size : The size of the token bucket, related to burstiness resilience (-1 = unlimited)
flags: readable, writable
Integer. Range: -1 - 2147483647 Default: -1
max-kbps : The maximum number of kilobits to let through per second (-1 = unlimited)
flags: readable, writable
Integer. Range: -1 - 2147483647 Default: -1
```
```
/**
* GstNetSim:max-bucket-size:
*
* The size of the token bucket, related to burstiness resilience.
*
* Since: 1.14
*/
/**
* GstNetSim:max-kbps:
*
* The maximum number of kilobits to let through per second. Setting this
* property to a positive value enables network congestion simulation using
* a token bucket algorithm. Also see the "max-bucket-size" property,
*
* Since: 1.14
*/
```
We could raise a warning if `max-kbps=` is set but not `max-bucket-size`, and probably improve the documentation but I'm not even sure what `max-bucket-size` actually control.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/479Build for use in android app2024-01-09T17:09:53ZkodykaBuild for use in android appPlease help or share template setting for android app with rust plugins.
I test gstreamer-1.0-android-arm64-1.23.0.1-work-without-rust.tar.xz this works fine.
I test (lot of times) with rust plugins from build cerbero, and gst not init...Please help or share template setting for android app with rust plugins.
I test gstreamer-1.0-android-arm64-1.23.0.1-work-without-rust.tar.xz this works fine.
I test (lot of times) with rust plugins from build cerbero, and gst not init(
[lib.rs](/uploads/3dfb8bc268481c19699c4dfc4256dea2/lib.rs)`
[build_gst_so.sh](/uploads/2b46a4ce7b0e34cbd71b0d1887d106bf/build_gst_so.sh)
[build_and_copy.sh](/uploads/d2de99828ebf7843cb133d18c5018055/build_and_copy.sh)
[Android.mk](/uploads/6d6e8f55c659a7f371a4025fa8a7d166/Android.mk)
`
GSTREAMER_PLUGINS := $(GSTREAMER_PLUGINS_CORE) $(GSTREAMER_PLUGINS_CODECS) $(GSTREAMER_PLUGINS_ENCODING) $(GSTREAMER_PLUGINS_NET) $(GSTREAMER_PLUGINS_PLAYBACK) $(GSTREAMER_PLUGINS_SYS) $(GSTREAMER_PLUGINS_EFFECTS)
# GSTREAMER_PLUGINS := $(GSTREAMER_PLUGINS_CORE) $(GSTREAMER_PLUGINS_CODECS) $(GSTREAMER_PLUGINS_ENCODING) $(GSTREAMER_PLUGINS_NET) $(GSTREAMER_PLUGINS_PLAYBACK) $(GSTREAMER_PLUGINS_SYS) $(GSTREAMER_PLUGINS_EFFECTS) $(GSTREAMER_PLUGINS_VIS) $(GSTREAMER_PLUGINS_CAPTURE) $(GSTREAMER_PLUGINS_CODECS_RESTRICTED) $(GSTREAMER_PLUGINS_NET_RESTRICTED) $(GSTREAMER_PLUGINS_GES)
GSTREAMER_EXTRA_DEPS := glib-2.0 gobject-2.0 gstreamer-base-1.0 gstreamer-video-1.0 gstreamer-audio-1.0 gstreamer-player-1.0 gstreamer-sdp-1.0 gstreamer-webrtc-1.0 gstreamer-app-1.0 libsoup-2.4
`
Please share template setting what add GSTREAMER_EXTRA_DEPS for working rust plugins?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3209osxaudiosink not switching to new output device2024-01-07T22:20:31ZHuanosxaudiosink not switching to new output device### Describe your issue
<!-- Please provide a clear and concise summary of the bug. -->
Switching audio devices on macOS does not change the output device of osxaudiosink. It will keep playing on the device that it started with.
<!-- For...### Describe your issue
<!-- Please provide a clear and concise summary of the bug. -->
Switching audio devices on macOS does not change the output device of osxaudiosink. It will keep playing on the device that it started with.
<!-- 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 IRC channel on https://www.oftc.net -->
#### Expected Behavior
<!-- What did you expect to happen -->
Output should be on the newly selected audio device.
#### Observed Behavior
<!-- What actually happened -->
#### Setup
- **Operating System:** macOS 14.2.1
- **Device:** MacBook Pro 2023
- **GStreamer Version:** 1.22.8
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open terminal
2. type ``gst-launch-1.0 audiotestsrc volume=0.1 ! osxaudiosink``
3. In sound settings, switch audio output device
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Always
<!-- Any other information such as logs. Make use of <details> for long output -->
### Solutions you have tried
autoaudiosink does not work either.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3208d3d11screencapturesrc: frames lost2024-03-04T15:46:51ZMaurizio Buratod3d11screencapturesrc: frames lostI noticed that periodically some frames are missing in the d3d11screencapturesrc capture.
To reproduce the problem I used this test video: ![30fps_judder_test](/uploads/28c751a92185986bb700406f7f18e428/30fps_judder_test.mp4) played in v...I noticed that periodically some frames are missing in the d3d11screencapturesrc capture.
To reproduce the problem I used this test video: ![30fps_judder_test](/uploads/28c751a92185986bb700406f7f18e428/30fps_judder_test.mp4) played in vlc. then i capture vlc with this pipeline:
`gst-launch-1.0.exe -e d3d11screencapturesrc capture-api=1 window-handle=2229322 window-capture-mode=1 ! queue ! d3d11videosink`
in this video you can see the results: ![20240107_022310](/uploads/642deccb787c2c6ddace7d0698fa30a4/20240107_022310.mp4)
on the right vlc player, on the left d3d11screencapturesrc capturing vlc
if you look at 00:05 the captured video is not smooth and it looks like some frames are dropped. this problem occurs occasionally however at least 1 time every 5 minutes. I tried the same test with other tools that use windows graphics capture api and and i didn't see this problem.
Could you please check if d3d11screencapturesrc can loose frames in some situation?
i'm testing Gstreamer version=1.23.0.1 artifactshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3206Consider disabling telemetry events for ONNX runtime2024-01-05T14:08:55ZStephan SeitzConsider disabling telemetry events for ONNX runtimeThis issue just represents my personal consideration I had and does not represent the opinion of any company.
As per Microsoft's privacy notice https://github.com/microsoft/onnxruntime/blob/main/docs/Privacy.md, ONNX runtime builds prov...This issue just represents my personal consideration I had and does not represent the opinion of any company.
As per Microsoft's privacy notice https://github.com/microsoft/onnxruntime/blob/main/docs/Privacy.md, ONNX runtime builds provided by Microsoft (not own builds or builds provided by Linux distributions) might send telemetry via Windows telemetry APIs. This might not be intended by GStreamer users.
Onnx runtime offers a method on Ort::Env to disable telemetry events like this (in gstonnxclient.cpp)
```
env =
Ort::Env (OrtLoggingLevel::ORT_LOGGING_LEVEL_WARNING,
"GstOnnxNamespace");
env.DisableTelemetryEvents();
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3205rtspclientsink has both a LGPL and MIT license2024-01-05T12:47:01ZNiels De Graefnielsdegraef@gmail.comrtspclientsink has both a LGPL and MIT licenseIt looks like rtspclientsink has both LGPL and MIT licenses, so it's a bit unclear what the current legal status is of it's source code.
In talking to some people on IRC/Matrix, we figured out that:
* The licenses were already part of ...It looks like rtspclientsink has both LGPL and MIT licenses, so it's a bit unclear what the current legal status is of it's source code.
In talking to some people on IRC/Matrix, we figured out that:
* The licenses were already part of the initial version (commit f54dd50203)
* @thaytan apparently started the element by copying gstrtspsrc
* @wtay posted the original code for that in commit a365a29c77d, which mentions the dual license
* @slomo noted that a lot of code has been added, which means a lot of it probably falls under LGPL already
So maybe we should remove the MIT license there?https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/477meson build fails2024-01-05T12:25:58ZMorten Olsen Lysgaardmeson build failsTag for reference: @slomo
Steps to reproduce:
clone GStreamer mono repo.
call meson with `-Drs=enable`.
This gives an error:
```
1gst-devtools| Dependency gstreamer-check-1.0 from subproject subprojects/gstreamer found: NO
```
If ...Tag for reference: @slomo
Steps to reproduce:
clone GStreamer mono repo.
call meson with `-Drs=enable`.
This gives an error:
```
1gst-devtools| Dependency gstreamer-check-1.0 from subproject subprojects/gstreamer found: NO
```
If you in addition add `-Dgstreamer:check=enable`, then it works, but this seems like it should be automatically resolved?
Ref, matrix conversation about the issue: https://matrix.to/#/!rFXJkaEjvUdqUHMPew:gstreamer.org/$0s4-Fntiha-82SUWIc-6cXo6tvX18XqwaLVeuS7c-0I?via=gstreamer.org&via=matrix.org&via=gnome.orghttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3204Audio sync problem with alsasink2024-01-05T11:51:32ZPaul GheorgheAudio sync problem with alsasink
Hello, I have this pipeline on my Nvidia Jetson Nano, which uses an HDMI to USB card to capture video and audio. I use gstreamer version 1.14.
gst-launch-1.0 -e v4l2src device=/dev/video0 do-timestamp=true ! queue2 ! image/jpeg,width=1...
Hello, I have this pipeline on my Nvidia Jetson Nano, which uses an HDMI to USB card to capture video and audio. I use gstreamer version 1.14.
gst-launch-1.0 -e v4l2src device=/dev/video0 do-timestamp=true ! queue2 ! image/jpeg,width=1280,height=720,framerate=30/1 ! jpegparse ! jpegdec ! queue2 ! nvoverlaysink sync=false alsasrc device=hw:CARD=MS2109,DEV=0 blocksize=12800 do-timestamp=true ! queue2 ! audio/x-raw,format=S16LE,layout=interleaved,rate=48000,channels=2 ! queue2 ! alsasink device=hw:0,3 sync=false blocksize=12800
Video works without lag, but audio lags behind after a few hours. If I set sync to true, audio stops working.
I see this in debug messages:
WARN audiobasesink gstaudiobasesink.c:1463:gst_audio_base_sink_skew_slaving:<autoaudiosink0-actual-sink-pulse> correct clock skew +0:00:00.029243609 > +0:00:00.020000000
I'm blocked for weeks... any idea what can I try? Thanks!https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/476webrtcsink deadlocks on gst_element_set_state GST_STATE_NULL2024-01-08T10:14:17ZToon Heyrmanwebrtcsink deadlocks on gst_element_set_state GST_STATE_NULL### Describe your issue
I'm encountering deadlocks when I have a gstreamer pipeline with a webrtcsink element in it. Stopping the pipeline by changing the state to NULL makes the change state deadlock in some special cases.
#### Expecte...### Describe your issue
I'm encountering deadlocks when I have a gstreamer pipeline with a webrtcsink element in it. Stopping the pipeline by changing the state to NULL makes the change state deadlock in some special cases.
#### Expected Behavior
That the pipeline is able to handle the state change.
#### Observed Behavior
Actually I see two issues,
1. When the webrtcsink does not receive any frames. For example the appsrc is not pushing any buffers. The webrtcsink is not destructable, as going to the NULL state deadlocks.
2. The webrtssink seems to deadlock in a time window of about 3s after the pipeline receives his first buffer and is started. After that period, the webrtcsink is properly destructable with the change state to NULL.
#### Setup
- **Operating System:** Linux 6.2.0-34-generic #34~22.04.1-Ubuntu x86_64
- **Device:** Computer
- **gst-plugins-rs Version:** gstreamer-1.22.8 and 0.11.3
- **GStreamer Version:** 1.20.3
- **Command line:**
### Steps to reproduce the bug
I'm using the following pipeline (there is probably a simpler one that can reproduce it too):
webrtcsink name=ws congestion-control=disabled signaller::address=ws://127.0.0.1:8443 appsrc name=video-appsrc is-live=true do-timestamp=0 format=time max-buffers=5 leaky-type=2 block=false ! video/x-raw, format=RGB, width=960, height=540 , framerate=25/1 ! videoconvert ! ws. audiotestsrc wave=silence ! audio/x-raw, format=F32LE, rate=48000, channels=2, layout=non-interleaved ! ws.
1. Start a pipeline with the webrtcsink in it and don't push any buffers. Change the pipeline state to NULL.
2. For the second related bug, stop the pipeline immediately after you started the pipeline.
### How reproducible is the bug?
Always
### Solutions you have tried
Switching to multiple versions of the plugins-rs did not solve the issue.
### My current workaround
Currently to work around this issue, I push always a first buffer in the pipeline via the appsrc. When I want to stop the pipeline I check that the pipeline is already running for >3s and then I send execute the gst_element_set_state.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3201Error Building GStreamer 1.22 on Fedora 392024-01-01T20:37:51Z8r4nError Building GStreamer 1.22 on Fedora 39I attempted to build the branch tagged with version 1.22 but was unsuccessful. Details follow..
| binary | version |
| ------ | ------ |
| meson | 1.2.3 |
| ninja | 1.11.1 |
| clang | 17.0.6 |
[meson-setup.log](/uploads/673497e5122047d...I attempted to build the branch tagged with version 1.22 but was unsuccessful. Details follow..
| binary | version |
| ------ | ------ |
| meson | 1.2.3 |
| ninja | 1.11.1 |
| clang | 17.0.6 |
[meson-setup.log](/uploads/673497e5122047d9f5fed690b166dff5/meson-setup.log)
[ninja-build.log](/uploads/ae903e2012acc036b6569f4f0790d9be/ninja-build.log)