GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-09-25T15:51:38Zhttps://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/453Adapt .pc files for android (IOS?) builds, to use libgstreamer_android.so ins...2023-09-25T15:51:38ZPeter BeresfordAdapt .pc files for android (IOS?) builds, to use libgstreamer_android.so instead of discrete dependenciesPlease see here for context, including comments from @slomo
[GStreamer #2999](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2999)
[gtk-rs-code #1196](https://github.com/gtk-rs/gtk-rs-core/issues/1196)
When building for and...Please see here for context, including comments from @slomo
[GStreamer #2999](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2999)
[gtk-rs-code #1196](https://github.com/gtk-rs/gtk-rs-core/issues/1196)
When building for android (IOS?) the recommended deployment is a single shared lib (typically called libgstreamer_android.so)
In the build .pc files, for android builds (IOS?), these discrete dependencies should be replaced with the mono-lib libgstreamer_android.sohttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/436webrtcdsp example2023-09-25T15:52:11ZFabien Danieauwebrtcdsp exampleHi,
Is it possible to use the webrtc echo cancellation feature? (https://gstreamer.freedesktop.org/documentation/webrtcdsp/webrtcdsp.html)
Can it be added to a pipeline like
`gst-launch-1.0 webrtcsink name=ws meta="meta,name=gst-stream...Hi,
Is it possible to use the webrtc echo cancellation feature? (https://gstreamer.freedesktop.org/documentation/webrtcdsp/webrtcdsp.html)
Can it be added to a pipeline like
`gst-launch-1.0 webrtcsink name=ws meta="meta,name=gst-stream" pulsesrc ! opusenc ! audio/x-opus, rate=48000, channels=2 ! ws.` ?
Assuming that I also receive and playback someone else sound. So pulsesrc is capturing this sound, creating the echo.
Thankshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/435NDI Video is stopping at exact 30min, is there a limitaion?2023-09-29T15:55:54ZChristian HattenbergerNDI Video is stopping at exact 30min, is there a limitaion?```
gst-launch-1.0 rtspclientsink name=rsink location=rtsp://localhost:8554/test ndisrc url-address=10.0.0.95:5961 color-format=compressed-v5-with-audio ! ndisrcdemux name=demux demux.video ! queue ! rsink.sink_0 demux.audio ! queue ! de...```
gst-launch-1.0 rtspclientsink name=rsink location=rtsp://localhost:8554/test ndisrc url-address=10.0.0.95:5961 color-format=compressed-v5-with-audio ! ndisrcdemux name=demux demux.video ! queue ! rsink.sink_0 demux.audio ! queue ! decodebin ! audioconvert ! opusenc bitrate=128000 ! rsink.sink_1
```
I tried for me every possible pipeline with rtsp and udp, but video is always stopping at 30min and audio is still running.
- GStreamer 1.20.7
- NewTek NDI Source 0.12.0-alpha.1-8bbfb10c (tried older one too)
Can someone give me a hint?
[gst.log](/uploads/e23f31f3d8b440c4a36c448acc80dce5/gst.log)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3000bad: netsim test failing: Got data flow before stream-start event2023-09-25T19:44:24ZJeremy Bichabad: netsim test failing: Got data flow before stream-start eventgst-plugin-bad1.0's elements_netsim build test has been failing in Debian Unstable for a while. This started happening sometime after July 6 (when 1.22.4 was uploaded) but before August 15 when I started working on packaging 1.22.5. The ...gst-plugin-bad1.0's elements_netsim build test has been failing in Debian Unstable for a while. This started happening sometime after July 6 (when 1.22.4 was uploaded) but before August 15 when I started working on packaging 1.22.5. The test fails with 1.22.4: this is not a regression in gst-plugins-bad but was triggered by a change in the dependencies.
This issue also affects Ubuntu 23.10 which makes sense because Ubuntu was automatically syncing packages from Debian Unstable in July and early August.
Build log excerpt
------------------
```
=================================== 91/109 ===================================
test: elements_netsim
start time: 12:04:11
duration: 1.31s
result: exit status 2
command: GST_PLUGIN_LOADING_WHITELIST=gstreamer:gst-plugins-base:gst-plugins-good:
gst-plugins-ugly:gst-libav:libnice:gst-plugins-bad@/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu
GST_PLUGIN_PATH_1_0=/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/gstreamer-1.0:
/usr/lib/x86_64-linux-gnu/gstreamer-1.0
GST_PLUGIN_SCANNER_1_0=/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner
GST_STATE_IGNORE_ELEMENTS='' CK_DEFAULT_TIMEOUT=20
GST_REGISTRY=/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tests/check/elements_netsim.registry
MALLOC_PERTURB_=119 GST_PLUGIN_SYSTEM_PATH_1_0=''
LD_LIBRARY_PATH=/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/gst-libs/gst/basecamerabinsrc:
/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/gst-libs/gst/uridownloader:
/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/gst-libs/gst/interfaces:
/usr/lib/libeatmydata /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tests/check/elements_netsim
----------------------------------- stdout -----------------------------------
Running suite(s): netsim
Unexpected critical/warning: ../gst/gstpad.c:4427:gst_pad_chain_data_unchecked:<netsim0:sink> Got data flow before stream-start event
Stack trace:
gst_debug_get_stack_trace (/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2205.0:0x7f94f8b3e6db)
?? (/usr/lib/x86_64-linux-gnu/libgstcheck-1.0.so.0.2205.0:0x7f94f8961a9f)
g_logv (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.0:0x7f94f89ddc0c)
g_log (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.0:0x7f94f89ddebf)
?? (/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2205.0:0x7f94f8b4a072)
?? (/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2205.0:0x7f94f8b4c2c2)
gst_pad_push (/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2205.0:0x7f94f8b53b44)
?? (/usr/lib/x86_64-linux-gnu/libgstcheck-1.0.so.0.2205.0:0x7f94f8967b62)
?? (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.0:0x7f94f8a029dd)
?? (/usr/lib/x86_64-linux-gnu/libc.so.6:0x7f94f87fa3e8)
?? (/usr/lib/x86_64-linux-gnu/libc.so.6:0x7f94f887aa28)
Unexpected critical/warning: ../gst/gstpad.c:4427:gst_pad_chain_data_unchecked:
<bin0:sink> Got data flow before stream-start event
Stack trace:
gst_debug_get_stack_trace (/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2205.0:0x7f94f8b3e6db)
?? (/usr/lib/x86_64-linux-gnu/libgstcheck-1.0.so.0.2205.0:0x7f94f8961a9f)
g_logv (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.0:0x7f94f89ddc0c)
g_log (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.0:0x7f94f89ddebf)
?? (/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2205.0:0x7f94f8b4a072)
?? (/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2205.0:0x7f94f8b4c2c2)
gst_pad_push (/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2205.0:0x7f94f8b53b44)
?? (/usr/lib/x86_64-linux-gnu/libgstcheck-1.0.so.0.2205.0:0x7f94f8967b62)
?? (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7800.0:0x7f94f8a029dd)
?? (/usr/lib/x86_64-linux-gnu/libc.so.6:0x7f94f87fa3e8)
?? (/usr/lib/x86_64-linux-gnu/libc.so.6:0x7f94f887aa28)
0%: Checks: 2, Failures: 2, Errors: 0
../libs/gst/check/gstcheck.c:286:F:general:netsim_stress:0: Unexpected critical/warning:
../gst/gstpad.c:4427:gst_pad_chain_data_unchecked:<netsim0:sink> Got data flow before stream-start event
../libs/gst/check/gstcheck.c:286:F:general:netsim_stress_delayed:0: Unexpected critical/warning:
../gst/gstpad.c:4427:gst_pad_chain_data_unchecked:<bin0:sink> Got data flow before stream-start event
Check suite netsim ran in 0.240s (tests failed: 2)
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2999GStreamer Rust on Android Fails to dlopen gobject-2.0 (and other libs) - For ...2023-09-25T15:57:46ZPeter BeresfordGStreamer Rust on Android Fails to dlopen gobject-2.0 (and other libs) - For Android these are all contained in the libgstreamer_android.so mono-libUsing the rust bindings/libraries on Android is causing issues due to the fact that the rust bindings make reference to the discrete (shared) libraries instead of the android libgstreamer_android.so mono-library.
I have the libgstreamer...Using the rust bindings/libraries on Android is causing issues due to the fact that the rust bindings make reference to the discrete (shared) libraries instead of the android libgstreamer_android.so mono-library.
I have the libgstreamer_android.so library in the APK and am running GStreamer code using the Android JNI, however when running code from rust, the rust bindings libraries refer to the discrete/separate gstreamer libraries, resulting in shared library loading errors, e.g.:
```
dlopen failed: library "libgobject-2.0.so" not found
```
Is there a way to tell the rust build system (for Android) that it should map these discrete libraries back to the libgstreamer_android.so mono-lib?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2998find_cuda_context doesn't find CUDA context2023-09-24T01:27:37Zintractabilisfind_cuda_context doesn't find CUDA contextI am writing a CUDA kernel that processes video frames coming as OpenGL textures from `glcolorconvert`. I understand that I must share CUDA context with GStreamer to achieve this goal. At least otherwise, a naive call to `cudaGraphicsRes...I am writing a CUDA kernel that processes video frames coming as OpenGL textures from `glcolorconvert`. I understand that I must share CUDA context with GStreamer to achieve this goal. At least otherwise, a naive call to `cudaGraphicsResourceGetMappedPointer` causes a seg fault.
I intercepted `GST_MESSAGE_NEED_CONTEXT` posted on the bus and provided the context. However, I don't think it has any effect. When I look at `find_cuda_context` from `gstcudautils.cpp` it is supposed to use the context provided by the message handler, but I don't think it is correctly written. In particular,
```c
find_cuda_context (GstElement * element, GstCudaContext ** cuda_ctx)
```
The found context is supposed to be returned in `cuda_ctx`, but it's easy to see that `*cuda_ctx` is not assigned any value in this function. Moreover, after posting the message, the code doesn't check if the context was assigned to `GstElement`.
@seungha.yanghttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2997GStreamer with OpenGL creates an empty "OpenGL Renderer" window on Wayland2023-12-14T22:05:51ZGeorges Basile Stavracas NetoGStreamer with OpenGL creates an empty "OpenGL Renderer" window on Wayland### Describe your issue
GStreamer with OpenGL creates an empty "OpenGL Renderer" window on Wayland. This can be seen with GNOME Shell's built-in screen recorder. We have worked around it with commit https://gitlab.gnome.org/GNOME/gnome-...### Describe your issue
GStreamer with OpenGL creates an empty "OpenGL Renderer" window on Wayland. This can be seen with GNOME Shell's built-in screen recorder. We have worked around it with commit https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/575ba13b9b4efa40f07d57d87d50d8f0466f2e16, so for accurate testing this commit needs to be reverted locally.
#### Expected Behavior
GStreamer creates an offscreen surface for rendering.
#### Observed Behavior
GStreamer creates an empty, onscreen surface for rendering.
#### Setup
- **Operating System:** Arch Linux (reproducible on any Wayland system)
- **Device:** Computer
- **GStreamer Version:** 1.20 & 1.22
### Steps to reproduce the bug
1. On a Wayland system, open a terminal
2. Type `gst-launch-1.0 gltestsrc ! gldownload ! waylandsink`
3. Notice the extra "OpenGL Renderer" window
### How reproducible is the bug?
Always reproduciblehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2996Crash when setting playbin state to NULL with a 16-bit PNG image2024-03-19T22:40:15ZIvan MolodetskikhCrash when setting playbin state to NULL with a 16-bit PNG image### 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/ -->
GStreamer crashes when setting playbin state to NULL when playing a 16-bit PNG image.
#### Expected Behavior
<!-- What did you expect to happen -->
No crash.
#### Observed Behavior
<!-- What actually happened -->
```
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007ffff78bb8a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007ffff78698ee in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007ffff78518ff in __GI_abort () at abort.c:79
#4 0x00007ffff78527d0 in __libc_message (fmt=fmt@entry=0x7ffff79cf56a "%s\n") at ../sysdeps/posix/libc_fatal.c:150
#5 0x00007ffff78c5795 in malloc_printerr (str=str@entry=0x7ffff79d1de8 "munmap_chunk(): invalid pointer") at malloc.c:5765
#6 0x00007ffff78c5a2c in munmap_chunk (p=p@entry=0x7fffa37ff000) at malloc.c:3035
#7 0x00007ffff78ca41a in __GI___libc_free (mem=mem@entry=0x7fffa37ff010) at malloc.c:3381
#8 0x00007ffff7b4c805 in g_free (mem=0x7fffa37ff010) at ../glib/gmem.c:238
#9 0x00007fffdbf432f9 in _mem_free (allocator=<optimized out>, memory=0x7fffe00b2310 [None]) at ../gst-libs/gst/gl/gstglbasememory.c:484
#10 0x00007ffff7d25e45 in _gst_memory_free (mem=0x7fffe00b2310 [None]) at ../gst/gstmemory.c:98
#11 0x00007ffff7ce975a in _gst_buffer_free (buffer=0x5555556e6bd0 [None]) at ../gst/gstbuffer.c:816
#12 0x00007ffff7ceeb03 in default_stop (pool=0x7fffa800bec0 [GstBufferPool|glbufferpool2]) at ../gst/gstbufferpool.c:422
#13 0x00007ffff7ce7ba3 in do_stop (pool=pool@entry=0x7fffa800bec0 [GstBufferPool|glbufferpool2]) at ../gst/gstbufferpool.c:440
#14 0x00007ffff7cef660 in gst_buffer_pool_set_active (pool=0x7fffa800bec0 [GstBufferPool|glbufferpool2], active=active@entry=0) at ../gst/gstbufferpool.c:548
#15 0x00007ffff7eec852 in gst_video_decoder_reset (decoder=decoder@entry=0x7fffe0047a20 [GstVideoDecoder|pngdec0], full=full@entry=1, flush_hard=flush_hard@entry=1) at ../gst-libs/gst/video/gstvideodecoder.c:2389
#16 0x00007ffff7eec9df in gst_video_decoder_change_state (element=0x7fffe0047a20 [GstElement|pngdec0], transition=<optimized out>) at ../gst-libs/gst/video/gstvideodecoder.c:2880
#17 0x00007ffff7d0ba14 in gst_element_change_state (element=element@entry=0x7fffe0047a20 [GstElement|pngdec0], transition=transition@entry=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstelement.c:3093
#18 0x00007ffff7d0c2c9 in gst_element_set_state_func (element=0x7fffe0047a20 [GstElement|pngdec0], state=GST_STATE_READY) at ../gst/gstelement.c:3047
#19 0x00007ffff7ce3488 in gst_bin_element_set_state (next=<optimized out>, current=<optimized out>, start_time=0 [0:00:00.000000000], base_time=38213693980291 [10:36:53.693980291], element=0x7fffe0047a20 [GstElement|pngdec0], bin=<optimized out>) at ../gst/gstbin.c:2582
#20 gst_bin_change_state_func (element=0x5555556e1080 [GstElement|decodebin0], transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstbin.c:2931
#21 0x00007fffe9dd5999 in gst_decode_bin_change_state (element=0x5555556e1080 [GstElement|decodebin0], transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/playback/gstdecodebin2.c:5468
#22 0x00007ffff7d0ba14 in gst_element_change_state (element=element@entry=0x5555556e1080 [GstElement|decodebin0], transition=transition@entry=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstelement.c:3093
#23 0x00007ffff7d0c2c9 in gst_element_set_state_func (element=0x5555556e1080 [GstElement|decodebin0], state=GST_STATE_READY) at ../gst/gstelement.c:3047
#24 0x00007ffff7ce3488 in gst_bin_element_set_state (next=<optimized out>, current=<optimized out>, start_time=0 [0:00:00.000000000], base_time=38213693980291 [10:36:53.693980291], element=0x5555556e1080 [GstElement|decodebin0], bin=<optimized out>) at ../gst/gstbin.c:2582
#25 gst_bin_change_state_func (element=0x5555556c6e70 [GstElement|uridecodebin0], transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstbin.c:2931
#26 0x00007fffe9dee070 in gst_uri_decode_bin_change_state (element=0x5555556c6e70 [GstElement|uridecodebin0], transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/playback/gsturidecodebin.c:2913
#27 0x00007ffff7d0ba14 in gst_element_change_state (element=element@entry=0x5555556c6e70 [GstElement|uridecodebin0], transition=transition@entry=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstelement.c:3093
#28 0x00007ffff7d0c2c9 in gst_element_set_state_func (element=0x5555556c6e70 [GstElement|uridecodebin0], state=GST_STATE_READY) at ../gst/gstelement.c:3047
#29 0x00007ffff7ce3488 in gst_bin_element_set_state (next=<optimized out>, current=<optimized out>, start_time=0 [0:00:00.000000000], base_time=38213693980291 [10:36:53.693980291], element=0x5555556c6e70 [GstElement|uridecodebin0], bin=<optimized out>) at ../gst/gstbin.c:2582
#30 gst_bin_change_state_func (element=0x5555556ceac0 [GstElement|playbin], transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstbin.c:2931
#31 0x00007fffe9e04f12 in gst_play_bin_change_state (element=0x5555556ceac0 [GstElement|playbin], transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/playback/gstplaybin2.c:5838
#32 0x00007ffff7d0ba14 in gst_element_change_state (element=element@entry=0x5555556ceac0 [GstElement|playbin], transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstelement.c:3093
#33 0x00007ffff7d0bf81 in gst_element_continue_state (element=element@entry=0x5555556ceac0 [GstElement|playbin], ret=ret@entry=GST_STATE_CHANGE_SUCCESS) at ../gst/gstelement.c:2801
#34 0x00007ffff7d0ba58 in gst_element_change_state (element=element@entry=0x5555556ceac0 [GstElement|playbin], transition=transition@entry=GST_STATE_CHANGE_PLAYING_TO_PAUSED) at ../gst/gstelement.c:3132
#35 0x00007ffff7d0c2c9 in gst_element_set_state_func (element=0x5555556ceac0 [GstElement|playbin], state=GST_STATE_NULL) at ../gst/gstelement.c:3047
#36 0x000055555555b6f5 in play_free (play=0x5555556c40b0) at ../tools/gst-play.c:298
#37 real_main (argc=<optimized out>, argv=<optimized out>) at ../tools/gst-play.c:1844
#38 0x00007ffff785314a in __libc_start_call_main (main=main@entry=0x555555559270 <main>, argc=argc@entry=2, argv=argv@entry=0x7fffffffe198) at ../sysdeps/nptl/libc_start_call_main.h:58
#39 0x00007ffff785320b in __libc_start_main_impl (main=0x555555559270 <main>, argc=2, argv=0x7fffffffe198, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe188) at ../csu/libc-start.c:360
#40 0x00005555555592a5 in _start ()
```
#### Setup
- **Operating System:** Fedora 39 in a toolbox
- **Device:** Computer
- **GStreamer Version:** some combination of 1.22.6 and 1.22.5, apparently. Ask Fedora I guess, but it also happens in the current org.gnome.Platform//45
- **Command line:** gst-play-1.0
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. gst-play-1.0 [16-bit.png](/uploads/6bf739d9547640f7a7c16f7b16997970/16-bit.png)
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Always
### 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/2995Follow-up from "video,d3d11,cuda: Add 16bits GBR format support and add HEVC ...2023-11-21T18:58:41ZSeungha Yangseungha@centricular.comFollow-up from "video,d3d11,cuda: Add 16bits GBR format support and add HEVC GBR en/decoding to nvcodec"The following discussion from !5375 should be addressed:
- [ ] @seungha.yang started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5375#note_2096052): (+3 comments)
> cc @vjaquez @He_Junyan `va...The following discussion from !5375 should be addressed:
- [ ] @seungha.yang started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5375#note_2096052): (+3 comments)
> cc @vjaquez @He_Junyan `vah265dec` may need to handle this case as well if it supports main-444 or high-bitdepth profileshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2994vah264dec should (have ability to) drop corrupted frames2023-09-26T16:48:19ZVincas Dargisvah264dec should (have ability to) drop corrupted framesSome IP cameras produces corrupted (green with va, gray with avdec) frames in the beginning of the RTSP stream unless `wait-for-keyframe=1` is set for `rtph264depay`.
If we save this corrupted stream using `mp4mux` and `filesink`, and t...Some IP cameras produces corrupted (green with va, gray with avdec) frames in the beginning of the RTSP stream unless `wait-for-keyframe=1` is set for `rtph264depay`.
If we save this corrupted stream using `mp4mux` and `filesink`, and then play that file using `vah264dec` we get green frames, but NOT with older/deprecated vaapih264dec.
`avdec_h264` can avoid corrupted frames by setting `output-corrupted=0`, but there's no such option in new `vah264dec`, nor it does that by default as `vaapih264dec`does.
Here's sample video with corrupted RTSP stream.
![video_no_wait_for_keyframe](/uploads/b85a328176fcdd9eae4abc9460992f2d/video_no_wait_for_keyframe.mp4)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2993When the RTSP URL contains a password with an '@' symbol, the host parsing ma...2023-09-21T08:17:57ZAlice ZhangWhen the RTSP URL contains a password with an '@' symbol, the host parsing may be incorrect.When I test the pipeline with the command "gst-launch-1.0 --gst-debug=rtspsrc:5 rtspsrc location='rtsp://ain:1z@WSX@192.168.1.223:554/cam/realmonitor?channel=1&subtype=0' ! decodebin ! fakesink sync=0", an error occurs and the error mess...When I test the pipeline with the command "gst-launch-1.0 --gst-debug=rtspsrc:5 rtspsrc location='rtsp://ain:1z@WSX@192.168.1.223:554/cam/realmonitor?channel=1&subtype=0' ! decodebin ! fakesink sync=0", an error occurs and the error message suggests the following:
[hint.txt](/uploads/8eeed59a493464d3d984127ca2e05d83/hint.txt)
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>When I remove the '@' symbol, the aforementioned issue disappears.</div>
</div>
</div>
<div>
</div>
</div>
</div>
</div>
<div>
</div>
</div>
</div>
<div>
<div>
</div>
<div>
</div>
<div>
<div>
<div>
<div>
</div>
</div>
</div>
</div>
</div>https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2992RTPbin property ts-offset-smoothing-factor has incorrect formula for averaging2023-10-10T06:17:26ZCharlie LaubRTPbin property ts-offset-smoothing-factor has incorrect formula for averagingI was reading the documentation for element rtpbin for version 1.22 and I think I noticed an error, at least there seems to be one in the documentation. I describe this below, and then give a suggestion on how ts-averaging could be made ...I was reading the documentation for element rtpbin for version 1.22 and I think I noticed an error, at least there seems to be one in the documentation. I describe this below, and then give a suggestion on how ts-averaging could be made more useful when longer term averaging of the ts-offset is desired.
The potential bug is found within the property "ts-offset-smoothing-factor". The documentation says:
Controls the weighting between previous and current timestamp offsets in a running moving average (RMA): ts_offset_average(n) = ((ts-offset-smoothing-factor - 1) * ts_offset_average(n - 1) + ts_offset(n)) / ts-offset-smoothing-factor
The forumla seems wrong to me. This is a simple linear combination of two quantities via a weighting factor:
A = quantity one
B = quantity two
X = weighting factor
C = weighted average of A and B
The averaging formula should be written:
C = A*X + (1-X)*B
or you could also write:
C = A*(1-X) + B*X
However, the formula shown in the documentation is in the form:
C = A*(X-1) + B*X
The difference is in the (X-1) factor in the first term. That's incorrect. C should lie between A and B, but if X=0 we get C=A*(0-1)+B*0, or C=-A.
More specifically to the averaging of ts-offset, in the first part:
ts_offset_average(n) = ((ts-offset-smoothing-factor - 1)...
The factor
(ts-offset-smoothing-factor - 1)
is backwards and should be
(1-ts-offset-smoothing-factor)
given that
0 <= ts-offset-smoothing-factor <= 1.
I cannot see the actual code in which the ts-offset-smoothing-factor is implemented, so this may just be a documentation error, but the formula in the documentation will definitely cause problems if used.
SUGGESTED IMPROVEMENT FOR LONG-TERM AVERAGING OF TS-OFFSET
If this formula is evaluated each frame there may be many, many evaluations per second. The cumulative effect over some time period is:
X^n
where X is the weighting factor and n is the number of evaluations that have passed in the time period of interest. Let's say we are handing audio at 48kHz in 1024 sample chunks. This means there are on the order of 40 frames per second. If X is 0.99 then in one second the moving average can change by 0.99^40 which equals about 0.67. In ten seconds this drops to 0.018. But the ts-offset is likely changing much, much slower than that. The problem is that the weighting factor is already almost at the slowest possible value limit of X=1-delta.
For slower averaging the user could be allowed to specify how many seconds the ts-offset should be averaged over, so that even in the smallest interval of 1 second (assuming parameter values less than 1 are reserved for the current moving average formula) there are 40 equally weighted ts-offset values. At the beginning of each frame, 1/40th of a second later, there is one new value added to the average and the oldest one dropped. You need to keep N values in memory to perform this sort of moving average, but the result will be MUCH smoother. Increasing the averaging interval to 10 or 100 seconds would allow much slower averaging that is possible with the current formula and might better correspond to the real-world rate of change of the ts-offset due to various sources of drift in the system.
Both the existing and my proposed averaging schemes could be implemented at the same time. The current moving average could be used when ts-offset-smoothing-factor < 1 and my proposed per-second averaging used when ts-offset-smoothing-factor >= 1https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/1008When the RTSP URL contains a password with an '@' symbol, the host parsing ma...2023-09-21T08:10:18ZAlice ZhangWhen the RTSP URL contains a password with an '@' symbol, the host parsing may be incorrect.When I test the pipeline with the command "gst-launch-1.0 --gst-debug=rtspsrc:5 rtspsrc location='rtsp://ain:1z@WSX@192.168.1.223:554/cam/realmonitor?channel=1&subtype=0' ! decodebin ! fakesink sync=0", an error occurs and the error mess...When I test the pipeline with the command "gst-launch-1.0 --gst-debug=rtspsrc:5 rtspsrc location='rtsp://ain:1z@WSX@192.168.1.223:554/cam/realmonitor?channel=1&subtype=0' ! decodebin ! fakesink sync=0", an error occurs and the error message suggests the following:
[hint.txt](/uploads/6a38f1c28b7f4c34b65168c591e8dfc6/hint.txt)
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>When I remove the '@' symbol, the aforementioned issue disappears.</div>
</div>
</div>
<div>
</div>
</div>
</div>
</div>
<div>
</div>
</div>
</div>
<div>
<div>
</div>
<div>
</div>
<div>
<div>
<div>
<div>
</div>
</div>
</div>
</div>
</div>https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2991glcolorconvert incorrectly converts RGB planar video2023-11-01T07:41:21Zintractabilisglcolorconvert incorrectly converts RGB planar videoI am writing an application that connects to an RTSP server and receives a video stream encoded with H.265 with RGB, full-range planar colors. According to the H.265 standard, planar RGB is signaled by setting **chroma_format_idc** to 4:...I am writing an application that connects to an RTSP server and receives a video stream encoded with H.265 with RGB, full-range planar colors. According to the H.265 standard, planar RGB is signaled by setting **chroma_format_idc** to 4:4:4 and setting **matrix_coeffs** to GBR (referred to as RGB). See Rec. ITU-T H.265 v8, Table E.5.
`GstH265Parse` correctly recognizes this format and sets `chroma-format: 4:4:4` and `colorimetry: 1:1:16:4` (the first 1 in the colorimetry string means an RGB matrix).
However, `validate_colorimetry` from `video-info.c` thinks an RGB matrix is invalid for Y444.
```
if ((GST_VIDEO_FORMAT_INFO_IS_YUV (finfo)
|| GST_VIDEO_FORMAT_INFO_IS_GRAY (finfo))
&& info->colorimetry.matrix == GST_VIDEO_COLOR_MATRIX_RGB) {
GST_WARNING
("color matrix RGB is only supported with RGB format, %s is not",
finfo->name);
return FALSE;
}
```
As a result, `gst_video_info_from_caps` changes the RGB matrix to BT601. Moreover, it overwrites the 0...255 range with 16...235. Consequently, `glcolorconvert` treats GBR values as luma and two chroma components, producing incorrect colors.
The full graph is attached.
@marotc @ndufresne @ystreet
[pipeline.pdf](/uploads/76ea04225eb066e66eb49d81002a38df/pipeline.pdf)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/1007glcolorconvert incorrectly converts RGB planar video2023-09-21T02:49:42Zintractabilisglcolorconvert incorrectly converts RGB planar videoI am writing an application that connects to an RTSP server and receives a video stream encoded with H.265 with RGB, full-range planar colors. According to the H.265 standard, planar RGB is signaled by setting **chroma_format_idc** to 4:...I am writing an application that connects to an RTSP server and receives a video stream encoded with H.265 with RGB, full-range planar colors. According to the H.265 standard, planar RGB is signaled by setting **chroma_format_idc** to 4:4:4 and setting **matrix_coeffs** to GBR (referred to as RGB). See Rec. ITU-T H.265 v8, Table E.5.
`GstH265Parse` correctly recognizes this format and sets `chroma-format: 4:4:4` and `colorimetry: 1:1:16:4` (the first 1 in the colorimetry string means an RGB matrix).
However, `validate_colorimetry` from `video-info.c` thinks an RGB matrix is invalid for Y444.
```
if ((GST_VIDEO_FORMAT_INFO_IS_YUV (finfo)
|| GST_VIDEO_FORMAT_INFO_IS_GRAY (finfo))
&& info->colorimetry.matrix == GST_VIDEO_COLOR_MATRIX_RGB) {
GST_WARNING
("color matrix RGB is only supported with RGB format, %s is not",
finfo->name);
return FALSE;
}
```
As a result, `gst_video_info_from_caps` changes the RGB matrix to BT601. Moreover, it overwrites the 0...255 range with 16...235. Consequently, `glcolorconvert` treats GBR values as luma and two chroma components, producing incorrect colors.
The full graph is attached.
@marotc @ndufresne @ystreet
[pipeline.pdf](/uploads/852d782d646c11fee074a498f45b1f9e/pipeline.pdf)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/1029RTPbin property ts-offset-smoothing-factor has incorrect formula for averaging2023-09-21T08:09:44ZCharlie LaubRTPbin property ts-offset-smoothing-factor has incorrect formula for averagingI was reading the documentation for element rtpbin for version 1.22 and I think I noticed an error, at least there seems to be one in the documentation. I describe this below, and then give a suggestion on how ts-averaging could be made ...I was reading the documentation for element rtpbin for version 1.22 and I think I noticed an error, at least there seems to be one in the documentation. I describe this below, and then give a suggestion on how ts-averaging could be made more useful when longer term averaging of the ts-offset is desired.
The potential bug is found within the property "ts-offset-smoothing-factor". The documentation says:
Controls the weighting between previous and current timestamp offsets in a running moving average (RMA): ts_offset_average(n) = ((ts-offset-smoothing-factor - 1) * ts_offset_average(n - 1) + ts_offset(n)) / ts-offset-smoothing-factor
The forumla seems wrong to me. This is a simple linear combination of two quantities via a weighting factor:
A = quantity one
B = quantity two
X = weighting factor
C = weighted average of A and B
The averaging formula should be written:
C = A*X + (1-X)*B
or you could also write:
C = A*(1-X) + B*X
However, the formula shown in the documentation is in the form:
C = A*(X-1) + B*X
The difference is in the (X-1) factor in the first term. That's incorrect. C should lie between A and B, but if X=0 we get C=A*(0-1)+B*0, or C=-A.
More specifically to the averaging of ts-offset, in the first part:
ts_offset_average(n) = ((ts-offset-smoothing-factor - 1)...
The factor
(ts-offset-smoothing-factor - 1)
is backwards and should be
(1-ts-offset-smoothing-factor)
given that
0 <= ts-offset-smoothing-factor <= 1.
I cannot see the actual code in which the ts-offset-smoothing-factor is implemented, so this may just be a documentation error, but the formula in the documentation will definitely cause problems if used.
SUGGESTED IMPROVEMENT FOR LONG-TERM AVERAGING OF TS-OFFSET
If this formula is evaluated each frame there may be many, many evaluations per second. The cumulative effect over some time period is:
X^n
where X is the weighting factor and n is the number of evaluations that have passed in the time period of interest. Let's say we are handing audio at 48kHz in 1024 sample chunks. This means there are on the order of 40 frames per second. If X is 0.99 then in one second the moving average can change by 0.99^40 which equals about 0.67. In ten seconds this drops to 0.018. But the ts-offset is likely changing much, much slower than that. The problem is that the weighting factor is already almost at the slowest possible value limit of X=1-delta.
For slower averaging the user could be allowed to specify how many seconds the ts-offset should be averaged over, so that even in the smallest interval of 1 second (assuming parameter values less than 1 are reserved for the current moving average formula) there are 40 equally weighted ts-offset values. At the beginning of each frame, 1/40th of a second later, there is one new value added to the average and the oldest one dropped. You need to keep N values in memory to perform this sort of moving average, but the result will be MUCH smoother. Increasing the averaging interval to 10 or 100 seconds would allow much slower averaging that is possible with the current formula and might better correspond to the real-world rate of change of the ts-offset due to various sources of drift in the system.
Both the existing and my proposed averaging schemes could be implemented at the same time. The current moving average could be used when ts-offset-smoothing-factor < 1 and my proposed per-second averaging used when ts-offset-smoothing-factor >= 1https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2990log spam: "can't find exact taps"2023-09-21T08:26:17ZDavid Inglog spam: "can't find exact taps"I have been seeing a lot of logspam from a couple of warnings in the code-base: `GST_WARNING ("can't find exact taps");`
One is in `audio-resampler.c`
One is in `video-scaler.c`.
According to @slomo these are "harmless and shouldn't r...I have been seeing a lot of logspam from a couple of warnings in the code-base: `GST_WARNING ("can't find exact taps");`
One is in `audio-resampler.c`
One is in `video-scaler.c`.
According to @slomo these are "harmless and shouldn't really be a warning". I'm not sure what the correct log level should be because I don't really understand what a "tap" is.
Another issue is that the documentation doesn't really define what a "tap" is, and perhaps the only way to figure it out is a deep dive into the code (which I have not done). (I took a quick glance and it wasn't clear.)
Someone should define "tap" in the documentation (code comments). Here are the relevant entities in the code.
* GST_AUDIO_RESAMPLER_OPT_N_TAPS
* GST_VIDEO_RESAMPLER_OPT_MAX_TAPS
* GstVideoResampler.n_taps
* GstVideoResampler.taps
* GST_VIDEO_RESAMPLER_FLAG_HALF_TAPS
* gst_video_scaler_get_max_taps(...)
* gst_video_scaler_new(..., n_taps, ...)
* GST_VIDEO_CONVERTER_OPT_RESAMPLER_TAPShttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2988Trailing space on RTSP WWW-Authenticate header breaks parsing2023-09-19T18:21:10ZEric ChandrasekharTrailing space on RTSP WWW-Authenticate header breaks parsingWe use an `rtspsrc` element to connect to camera streams, and we’ve recently come across a camera which sends a trailing extra space at the end of the WWW-Authenticate header within the OPTIONS command, like so:
`WWW-Authenticate: Dige...We use an `rtspsrc` element to connect to camera streams, and we’ve recently come across a camera which sends a trailing extra space at the end of the WWW-Authenticate header within the OPTIONS command, like so:
`WWW-Authenticate: Digest realm="FII_NS_CPD", nonce="990d51c37b1f651153afcb5f619f891b" `
The pipeline ends up erroring out with a 401 unauthorized message, and when looking at wireshark, the rtspsrc element never actually sends an Authorization header after receiving the 401 (despite passing in the correct credentials with user-id and user-pw).
Digging a little deeper into the rtspconnection code, it looks like the trailing extra space is causing `nonce="990d51c37b1f651153afcb5f619f891b"` to be split into a separate header, making it no longer tied to the Digest auth header. This is breaking authentication since this nonce value is required for Digest auth.
It seems like gstreamer should be more resilient against whitespace at the end of this header, with a change like this:
```
diff -rupN gst-plugins-base-1.22.4/gst-libs/gst/rtsp/gstrtspconnection.c gst-plugins-base-1.22.4-updated/gst-libs/gst/rtsp/gstrtspconnection.c
--- gst-plugins-base-1.22.4/gst-libs/gst/rtsp/gstrtspconnection.c 2023-06-20 12:42:25.000000000 -0400
+++ gst-plugins-base-1.22.4-updated/gst-libs/gst/rtsp/gstrtspconnection.c 2023-09-19 11:13:01.262427969 -0400
@@ -2375,8 +2375,15 @@ parse_line (guint8 * buffer, GstRTSPMess
comma = next_value;
} else if (*next_value == ' ' && next_value[1] != ',' &&
next_value[1] != '=' && comma != NULL) {
- next_value = comma;
- comma = NULL;
+ /* only process this as a separate challenge/header if there is more than just
+ * trailing whitespace after this */
+ for (gchar* curr_char = next_value; *curr_char != '\0'; curr_char++) {
+ if (!g_ascii_isspace (*curr_char)) {
+ next_value = comma;
+ comma = NULL;
+ break;
+ }
+ }
break;
}
} else if (*next_value == ',')
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2987mpegpsdemux seeking stop position handling is wrong2023-09-19T09:55:10ZAlcarompegpsdemux seeking stop position handling is wrong### Describe your issue
Telling a mpegpsdemux element to seek to start=0 stop=duration will emit a segment event of start=(first PTS) stop=duration, which will subsequently discard various amounts of data.
#### Expected Behavior
Either ...### Describe your issue
Telling a mpegpsdemux element to seek to start=0 stop=duration will emit a segment event of start=(first PTS) stop=duration, which will subsequently discard various amounts of data.
#### Expected Behavior
Either start=(first PTS) stop=(first PTS)+duration, or start=0 stop=duration
#### Observed Behavior
start=(first PTS) stop=duration
#### Setup
- **Operating System:** Debian 12
- **Device:** Computer / Tablet / Mobile / Virtual Machine <!-- Delete as appropriate !-->
- **GStreamer Version:** 1.22.0
- **Command line:** Not applicable
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. Acquire an mpeg file whose first PTS is greater than the file's duration, for example https://gitlab.winehq.org/wine/wine/-/raw/a240d38085631d282aa218618aaab28c25b95e73/dlls/quartz/tests/test.mpg
2. Compile and run [this program](/uploads/f55d2d40e39d3faadc8cb2ae8f518b04/a.c) with GST_DEBUG=1 or higher
```
0:00:00.015903585 1077832 0x561cc240f6a0 ERROR default a.c:42:main: initial play
0:00:00.016485410 1077832 0x561cc225cb60 ERROR default a.c:18:fakesink_buffer_handler: fakesink 1214
0:00:00.016677124 1077832 0x561cc240f6a0 ERROR default a.c:50:main: time segment start=0:00:00.540000000, offset=0:00:00.000000000, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.540000000, base=0:00:00.000000000, position 0:00:00.540000000, duration 0:00:00.119700000
0:00:00.016688884 1077832 0x561cc240f6a0 ERROR default a.c:52:main: seek with end=inf
0:00:00.017000327 1077832 0x561cc225cb60 ERROR default a.c:18:fakesink_buffer_handler: fakesink 1214
0:00:00.017118745 1077832 0x561cc240f6a0 ERROR default a.c:56:main: time segment start=0:00:00.540000000, offset=0:00:00.000000000, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x01, time=0:00:00.540000000, base=0:00:00.000000000, position 0:00:00.540000000, duration 0:00:00.119700000
0:00:00.017129751 1077832 0x561cc240f6a0 ERROR default a.c:58:main: seek with end=duration
0:00:00.017431621 1077832 0x561cc240f6a0 ERROR default a.c:64:main: time segment start=0:00:00.540000000, offset=0:00:00.000000000, stop=0:00:00.119700000, rate=1.000000, applied_rate=1.000000, flags=0x01, time=0:00:00.540000000, base=0:00:00.000000000, position 0:00:00.540000000, duration 0:00:00.119700000
```
Note how start plus duration is not stop in the last one. In fact, start is after stop. Note also how the fakesink reports no input for that one.
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Always
### 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/2986avenc_g726 queuing problem2023-09-25T05:37:26ZElif Biliravenc_g726 queuing problemHey, I want to encode the audio data I received from the alsasrc element in different bitrate settings with the avenc_g726 element, and send it via udp by adding stanag 7023 format to this audio data I have encoded. For example, if the e...Hey, I want to encode the audio data I received from the alsasrc element in different bitrate settings with the avenc_g726 element, and send it via udp by adding stanag 7023 format to this audio data I have encoded. For example, if the encoder bitrate is set to 16 bits, I want 100 bytes of audio data, 24-\>150 ,32-\>200 and 40-\>250.
Although I set the audio data I received from alsasrc to the desired size with the "blocksize" parameter, the avenc_g726 element performs a queuing operation, which causes a latency. So, even if I set the data to be maximum 258 bytes in alsasrc, the avenc_g726 element outputs larger bytes. 16 -\> 1024 24 -\> 1026 32 -\> 1024 40 -\> 1025
how can I fix this queuing and delay process? how can I get data of the specified size from the avenc_g726 element? (i tried the frame-size, bufsize, and max-samples parameters for the avenc_g726 element, it doesn't work.)