GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-11-04T18:48:44Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3020Memory leak when parsing WAV files that includes "JUNK"2023-11-04T18:48:44ZjohanadamnilssonMemory leak when parsing WAV files that includes "JUNK"### Memory leak when parsing WAV files that includes "JUNK"
So I have found that running the included WAV file I am finding a memory leak ([chime_initiated_call](/uploads/0342eb7a28f96eb7c7ea6595540fc59a/chime_initiated_call.wav)). I ha...### Memory leak when parsing WAV files that includes "JUNK"
So I have found that running the included WAV file I am finding a memory leak ([chime_initiated_call](/uploads/0342eb7a28f96eb7c7ea6595540fc59a/chime_initiated_call.wav)). I have tried narrowing it down as much as possible however I have problem following why the code is taking the path it is taking, also understanding the WAV format is not clear, but lets discuss what I have found.
First the stack trace of the memory leak:
```
Indirect leak of 10080 byte(s) in 36 object(s) allocated from:
#0 0x7f88747dbc in \__interceptor_malloc r0/libsanitizer/asan/asan_malloc_linux.cpp:69 (discriminator 2)
#1 0x7f8859b3b4 in g_malloc r0/glib/gmem.c:130
#2 0x7f885b4874 in g_slice_alloc r0/glib/gslice.c:1074
#3 0x7f8811af84 in gst_buffer_new r0/gst/gstbuffer.c:863
#4 0x7f8811ce70 in gst_buffer_new_allocate r0/gst/gstbuffer.c:908
#5 0x7f875617dc in gst_base_src_default_alloc r0/libs/gst/base/gstbasesrc.c:1546
#6 0x7f8755f954 in gst_base_src_default_create r0/libs/gst/base/gstbasesrc.c:1592
#7 0x7f8755cc60 in gst_base_src_get_range r0/libs/gst/base/gstbasesrc.c:2592 (discriminator 7)
#8 0x7f8755f738 in gst_base_src_getrange r0/libs/gst/base/gstbasesrc.c:2793
#9 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#10 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#11 0x7f8816976c in gst_proxy_pad_getrange_default r0/gst/gstghostpad.c:185 (discriminator 2)
#12 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#13 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#14 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#15 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#16 0x7f85b1756c in gst_wavparse_stream_headers r0/gst/wavparse/gstwavparse.c:1555
#17 0x7f85b1a61c in gst_wavparse_loop r0/gst/wavparse/gstwavparse.c:2252 (discriminator 7)
#18 0x7f88201678 in gst_task_func r0/gst/gsttask.c:384
#19 0x7f885c1b44 in g_thread_pool_thread_proxy r0/glib/gthreadpool.c:352
#20 0x7f885c0eb4 in g_thread_proxy r0/glib/gthread.c:831
#21 0x7f87d7eea0 in start_thread r1/nptl/pthread_create.c:444
#22 0x7f87de59d8 in thread_start r1/misc/../sysdeps/unix/sysv/linux/aarch64/clone.S:79
Indirect leak of 7308 byte(s) in 36 object(s) allocated from:
#0 0x7f88747dbc in \__interceptor_malloc r0/libsanitizer/asan/asan_malloc_linux.cpp:69 (discriminator 2)
#1 0x7f8859b3b4 in g_malloc r0/glib/gmem.c:130
#2 0x7f885b4874 in g_slice_alloc r0/glib/gslice.c:1074
#3 0x7f88107f5c in \_sysmem_new_block r0/gst/gstallocator.c:437
#4 0x7f8811ce64 in gst_buffer_new_allocate r0/gst/gstbuffer.c:901
#5 0x7f875617dc in gst_base_src_default_alloc r0/libs/gst/base/gstbasesrc.c:1546
#6 0x7f8755f954 in gst_base_src_default_create r0/libs/gst/base/gstbasesrc.c:1592
#7 0x7f8755cc60 in gst_base_src_get_range r0/libs/gst/base/gstbasesrc.c:2592 (discriminator 7)
#8 0x7f8755f738 in gst_base_src_getrange r0/libs/gst/base/gstbasesrc.c:2793
#9 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#10 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#11 0x7f8816976c in gst_proxy_pad_getrange_default r0/gst/gstghostpad.c:185 (discriminator 2)
#12 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#13 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#14 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#15 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#16 0x7f85b1756c in gst_wavparse_stream_headers r0/gst/wavparse/gstwavparse.c:1555
#17 0x7f85b1a61c in gst_wavparse_loop r0/gst/wavparse/gstwavparse.c:2252 (discriminator 7)
#18 0x7f88201678 in gst_task_func r0/gst/gsttask.c:384
#19 0x7f885c1b44 in g_thread_pool_thread_proxy r0/glib/gthreadpool.c:352
#20 0x7f885c0eb4 in g_thread_proxy r0/glib/gthread.c:831
#21 0x7f87d7eea0 in start_thread r1/nptl/pthread_create.c:444
#22 0x7f87de59d8 in thread_start r1/misc/../sysdeps/unix/sysv/linux/aarch64/clone.S:79```
```
This should be possible to get when running `gst-launch-1.0 -v playbin uri=file://<file>`. I have tried with using valgrind, address sanitizer or GST_TRACERS, all are showing the memory leak.
Running `xxd <file> | less` command on a file that is not leaking looks like:
```
00000000: 5249 4646 a488 0300 5741 5645 666d 7420 RIFF....WAVEfmt
00000010: 1000 0000 0100 0200 401f 0000 007d 0000 ........@....}..
00000020: 0400 1000 6461 7461 8088 0300 0000 0000 ....data........
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
```
This makes sense for me when looking at the [WAV file format](https://docs.fileformat.com/audio/wav/)
Now looking on a file that causes a leak:
```
00000000: 5249 4646 e001 0c00 5741 5645 4a55 4e4b RIFF....WAVEJUNK
00000010: 4000 0000 e001 0c00 0000 0000 e8fc 0b00 @...............
00000020: 0000 0000 7cff 0100 0000 0000 0000 0000 ....|...........
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000050: 0000 0000 666d 7420 1000 0000 0100 0200 ....fmt ........
00000060: 44ac 0000 9809 0400 0600 1800 6461 7461 D...........data
00000070: e8fc 0b00 0000 0000 0000 0000 0000 0000 ................
```
Now there is "JUNK" after WAVE field. To my understanding this is not wrong.... [according to Wikipedia](https://en.wikipedia.org/wiki/WAV#CITEREFIBMMicrosoft1991).
Knowing all this I am very confused as in the "gst_wavparse_stream_headers" function the memory leak is made in a switch statement that I don't believe it should be in. In the first case statement it matches on [GST_RIFF_TAG_LIST](https://github.com/GStreamer/gstreamer/blob/main/subprojects/gst-plugins-good/gst/wavparse/gstwavparse.c#L1470 "https://github.com/gstreamer/gstreamer/blob/main/subprojects/gst-plugins-good/gst/wavparse/gstwavparse.c#l1470") and inside it matches on the GST_RIFF_LIST_adtl, both I feel should not be a match as I don't see it in "xxd" commands output. Have not worked much with parsers so can be missing something, however I am grateful for any help and explanation that you can provide.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/1030Memory leak when parsing WAV files that includes "JUNK"2023-10-06T13:24:34ZjohanadamnilssonMemory leak when parsing WAV files that includes "JUNK"### Memory leak when parsing WAV files that includes "JUNK"
So I have found that running the included WAV file I am finding a memory leak ([chime_initiated_call.wav](/uploads/b059a20c45692e4282bfa443ad9fef2d/chime_initiated_call.wav)). ...### Memory leak when parsing WAV files that includes "JUNK"
So I have found that running the included WAV file I am finding a memory leak ([chime_initiated_call.wav](/uploads/b059a20c45692e4282bfa443ad9fef2d/chime_initiated_call.wav)). I have tried narrowing it down as much as possible however I have problem following why the code is taking the path it is taking, also understanding the WAV format is not clear, but lets discuss what I have found.
First the stack trace of the memory leak:
---
Indirect leak of 10080 byte(s) in 36 object(s) allocated from:
#0 0x7f88747dbc in \__interceptor_malloc r0/libsanitizer/asan/asan_malloc_linux.cpp:69 (discriminator 2)
#1 0x7f8859b3b4 in g_malloc r0/glib/gmem.c:130
#2 0x7f885b4874 in g_slice_alloc r0/glib/gslice.c:1074
#3 0x7f8811af84 in gst_buffer_new r0/gst/gstbuffer.c:863
#4 0x7f8811ce70 in gst_buffer_new_allocate r0/gst/gstbuffer.c:908
#5 0x7f875617dc in gst_base_src_default_alloc r0/libs/gst/base/gstbasesrc.c:1546
#6 0x7f8755f954 in gst_base_src_default_create r0/libs/gst/base/gstbasesrc.c:1592
#7 0x7f8755cc60 in gst_base_src_get_range r0/libs/gst/base/gstbasesrc.c:2592 (discriminator 7)
#8 0x7f8755f738 in gst_base_src_getrange r0/libs/gst/base/gstbasesrc.c:2793
#9 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#10 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#11 0x7f8816976c in gst_proxy_pad_getrange_default r0/gst/gstghostpad.c:185 (discriminator 2)
#12 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#13 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#14 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#15 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#16 0x7f85b1756c in gst_wavparse_stream_headers r0/gst/wavparse/gstwavparse.c:1555
#17 0x7f85b1a61c in gst_wavparse_loop r0/gst/wavparse/gstwavparse.c:2252 (discriminator 7)
#18 0x7f88201678 in gst_task_func r0/gst/gsttask.c:384
#19 0x7f885c1b44 in g_thread_pool_thread_proxy r0/glib/gthreadpool.c:352
#20 0x7f885c0eb4 in g_thread_proxy r0/glib/gthread.c:831
#21 0x7f87d7eea0 in start_thread r1/nptl/pthread_create.c:444
#22 0x7f87de59d8 in thread_start r1/misc/../sysdeps/unix/sysv/linux/aarch64/clone.S:79
Indirect leak of 7308 byte(s) in 36 object(s) allocated from:
#0 0x7f88747dbc in \__interceptor_malloc r0/libsanitizer/asan/asan_malloc_linux.cpp:69 (discriminator 2)
#1 0x7f8859b3b4 in g_malloc r0/glib/gmem.c:130
#2 0x7f885b4874 in g_slice_alloc r0/glib/gslice.c:1074
#3 0x7f88107f5c in \_sysmem_new_block r0/gst/gstallocator.c:437
#4 0x7f8811ce64 in gst_buffer_new_allocate r0/gst/gstbuffer.c:901
#5 0x7f875617dc in gst_base_src_default_alloc r0/libs/gst/base/gstbasesrc.c:1546
#6 0x7f8755f954 in gst_base_src_default_create r0/libs/gst/base/gstbasesrc.c:1592
#7 0x7f8755cc60 in gst_base_src_get_range r0/libs/gst/base/gstbasesrc.c:2592 (discriminator 7)
#8 0x7f8755f738 in gst_base_src_getrange r0/libs/gst/base/gstbasesrc.c:2793
#9 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#10 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#11 0x7f8816976c in gst_proxy_pad_getrange_default r0/gst/gstghostpad.c:185 (discriminator 2)
#12 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#13 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#14 0x7f88197214 in gst_pad_get_range_unchecked r0/gst/gstpad.c:4948 (discriminator 7)
#15 0x7f881a5e0c in gst_pad_pull_range r0/gst/gstpad.c:5193
#16 0x7f85b1756c in gst_wavparse_stream_headers r0/gst/wavparse/gstwavparse.c:1555
#17 0x7f85b1a61c in gst_wavparse_loop r0/gst/wavparse/gstwavparse.c:2252 (discriminator 7)
#18 0x7f88201678 in gst_task_func r0/gst/gsttask.c:384
#19 0x7f885c1b44 in g_thread_pool_thread_proxy r0/glib/gthreadpool.c:352
#20 0x7f885c0eb4 in g_thread_proxy r0/glib/gthread.c:831
#21 0x7f87d7eea0 in start_thread r1/nptl/pthread_create.c:444
#22 0x7f87de59d8 in thread_start r1/misc/../sysdeps/unix/sysv/linux/aarch64/clone.S:79
---
This should be possible to get when running "gst-launch-1.0 -v playbin uri=file://\<file\>". I have tried with using valgrind, address sanitizer or GST_TRACERS, all are showing the memory leak.
Running "xxd \<file\> | less" command on a file that is not leaking looks like:
---
00000000: 5249 4646 a488 0300 5741 5645 666d 7420 RIFF....WAVEfmt
00000010: 1000 0000 0100 0200 401f 0000 007d 0000 ........@....}..
00000020: 0400 1000 6461 7461 8088 0300 0000 0000 ....data........
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
---
This makes sense for me when looking at the [WAV file format](https://docs.fileformat.com/audio/wav/)
Now looking on a file that causes a leak:
---
00000000: 5249 4646 e001 0c00 5741 5645 4a55 4e4b RIFF....WAVEJUNK
00000010: 4000 0000 e001 0c00 0000 0000 e8fc 0b00 @...............
00000020: 0000 0000 7cff 0100 0000 0000 0000 0000 ....|...........
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000050: 0000 0000 666d 7420 1000 0000 0100 0200 ....fmt ........
00000060: 44ac 0000 9809 0400 0600 1800 6461 7461 D...........data
00000070: e8fc 0b00 0000 0000 0000 0000 0000 0000 ................
---
Now there is "JUNK" after WAVE field. To my understanding this is not wrong.... [according to Wikipedia](https://en.wikipedia.org/wiki/WAV#CITEREFIBMMicrosoft1991).
Knowing all this I am very confused as in the "gst_wavparse_stream_headers" function the memory leak is made in a switch statement that I don't believe it should be in. In the first case statement it matches on [GST_RIFF_TAG_LIST](https://github.com/GStreamer/gstreamer/blob/main/subprojects/gst-plugins-good/gst/wavparse/gstwavparse.c#L1470 "https://github.com/gstreamer/gstreamer/blob/main/subprojects/gst-plugins-good/gst/wavparse/gstwavparse.c#l1470") and inside it matches on the GST_RIFF_LIST_adtl, both I feel should not be a match as I don't see it in "xxd" commands output. Have not worked much with parsers so can be missing something, however I am grateful for any help and explanation that you can provide.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/444NDI: Support more than 8 channels of raw audio2023-10-12T06:33:14ZLieven PaulissenNDI: Support more than 8 channels of raw audioIt seems that `ndisrc` uses the fallback channel-mask from `gst_audio_channel_get_fallback_mask` to configure the audio channel positions (see https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/blob/main/net/ndi/src/ndisrc/receive...It seems that `ndisrc` uses the fallback channel-mask from `gst_audio_channel_get_fallback_mask` to configure the audio channel positions (see https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/blob/main/net/ndi/src/ndisrc/receiver.rs, inside `create_audio_info`). This fallback only supports up to 8 audio channels. When there are more than 8 audio channels, `gst_audio_channel_get_fallback_mask` returns a channel-mask of 0. This will crash Gstreamer when `gst_audio_channel_positions_from_mask` is called later on.
When ingesting an NDI stream containing more (in my case, up to 16) raw audio channels, Gstreamer needs to be able to select channels or apply a custom channel-mask, since audio encoders such as `fdkaacenc` may only support up to 8 audio channels.
```
$ gst-launch-1.0 ndisrc ndi-name="GC-DEV2 (OBS)" ! ndisrcdemux name=demux demux.audio ! queue ! audioconvert ! audio/x-raw,channels=2 ! fdkaacenc ! fakesink
```
I've included a [small patch](https://pastebin.com/XYK5mrhV) that sets the positions of the first 8 audio channels to match the fallback channel-mask, and uses the 13th and higher channel-mask bits to map any remaining channels (so theoretically, this supports up to 52 channels). This way, the first 8 audio channels will always be positioned as valid 8.1 audio and the remaining channels will not be assigned an interfering position.
I realize that this might not be an ideal solution. Gstreamer itself seems to assign up to 28 valid audio channel positions using its `default_channel_order`. Alternatively, you could require `ndisrc` to be configured with a channel-mask property when you want to ingest an NDI stream with more than 8 raw audio channels.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3019How to extract the timestamp or frame number from rtsp server2023-10-05T09:19:47ZAnil kumarHow to extract the timestamp or frame number from rtsp serverI have tried to extract with following code but its not matching with server timestamp please suggest if there are any particular elements to use for this[test4.py](/uploads/b0e9060cee276c07f494df9588cc87be/test4.py)I have tried to extract with following code but its not matching with server timestamp please suggest if there are any particular elements to use for this[test4.py](/uploads/b0e9060cee276c07f494df9588cc87be/test4.py)https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/443livekitwebrtcsink: Signalling error: Error: Server disconnected2023-11-13T19:23:22ZEfim Kozhemyakinlivekitwebrtcsink: Signalling error: Error: Server disconnected### Description
After 15-20 seconds of the Gstreamer pipeline running, an error occurs.
Sink: **livekitwebrtcsink**
#### Below are the debug logs for GST_DEBUG=webrtcsink:6.
`gst-launch-1.0 videotestsrc ! videoconvert ! video/x-raw,widt...### Description
After 15-20 seconds of the Gstreamer pipeline running, an error occurs.
Sink: **livekitwebrtcsink**
#### Below are the debug logs for GST_DEBUG=webrtcsink:6.
`gst-launch-1.0 videotestsrc ! videoconvert ! video/x-raw,width=640,height=480 ! x264enc ! queue ! livekitwebrtcsink signaller::ws-url=<livekit_url> signaller::auth-token=<access_token>`
```
Use Windows high-resolution clock, precision: 1 ms
Setting pipeline to PAUSED ...
0:00:00.072884000 17220 0000025A978807B0 DEBUG webrtcsink net\webrtc\src\webrtcsink\imp.rs:1483:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::prepare:<livekitwebrtcsink0> preparing
Pipeline is live and does not need PREROLL ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
0:00:00.272534000 17220 0000025A978443C0 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:3132:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::sink_event:<livekitwebrtcsink0:video_0> Received caps event Caps { seqnum: Seqnum(63), running-time-offset: 0, structure: Some(GstEventCaps { caps: (GstCaps) video/x-h264, codec_data=(buffer)01f4001effe1001e67f4001e90d9b281407b602d41818190000003001000000303c8f162d96001000568ebec4480, stream-format=(string)avc, alignment=(string)au, level=(string)3, profile=(string)high-4:4:4, width=(int)640, height=(int)480, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)bt601, chroma-site=(string)jpeg, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono }), caps: Caps(video/x-h264(memory:SystemMemory) { codec_data: (GstBuffer) ((GstBuffer*) 0000025A978FB480), stream-format: (gchararray) "avc", alignment: (gchararray) "au", level: (gchararray) "3", profile: (gchararray) "high-4:4:4", width: (gint) 640, height: (gint) 480, pixel-aspect-ratio: (GstFraction) 1/1, framerate: (GstFraction) 30/1, interlace-mode: (gchararray) "progressive", colorimetry: (gchararray) "bt601", chroma-site: (gchararray) "jpeg", multiview-mode: (gchararray) "mono", multiview-flags: (GstVideoMultiviewFlagsSet) 0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono }) }
0:00:00.309443000 17220 0000025A97D17B40 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:3018:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::lookup_caps::{{closure}}:<livekitwebrtcsink0> Stream is already encoded with codec H264, still need to payload it
Redistribute latency...
0:00:00.314359000 17220 0000025A97D17B40 DEBUG webrtcsink net\webrtc\src\webrtcsink\imp.rs:2855:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::run_discovery_pipeline::{{closure}}:<livekitwebrtcsink0> Running discovery pipeline for input caps video/x-h264, stream-format=(string)avc, alignment=(string)au, level=(string)3, profile=(string)high-4:4:4, width=(int)640, height=(int)480, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)bt601, chroma-site=(string)jpeg, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono and output caps ANY with codec Codec { name: "H264", caps: Caps(video/x-h264(memory:SystemMemory)), stream_type: StreamType(VIDEO), payload_type: Some(97), decoding_info: Some(DecodingInfo { has_decoder: true }), encoding_info: Some(EncodingInfo { encoder: ElementFactory { inner: TypedObjectRef { inner: 0x25a9769b000, type: GstElementFactory } }, payloader: ElementFactory { inner: TypedObjectRef { inner: 0x25a976a77e0, type: GstElementFactory } }, output_filter: None }) }
0:00:00.337052000 17220 0000025A97D17B40 DEBUG webrtcsink net\webrtc\src\webrtcsink\imp.rs:2861:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::run_discovery_pipeline::{{closure}}:<livekitwebrtcsink0> Running discovery pipeline
0:00:00.349079000 17220 0000025A97D17B40 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:2966:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::run_discovery_pipeline::{{closure}}: Discovery pipeline got caps Caps(application/x-rtp(memory:SystemMemory) { media: (gchararray) "video", clock-rate: (gint) 90000, encoding-name: (gchararray) "H264", packetization-mode: (gchararray) "1", sprop-parameter-sets: (gchararray) "Z/QAHpDZsoFAe2AtQYGBkAAAAwAQAAADA8jxYtlg,aOvsRIA=", profile-level-id: (gchararray) "f4001e", profile: (gchararray) "high-4:4:4", payload: (gint) 97, ssrc: (guint) 1147621430, timestamp-offset: (guint) 2814551685, seqnum-offset: (guint) 5229, a-framerate: (gchararray) "30", extmap-1: (gchararray) "http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01" })
0:00:00.363514000 17220 0000025A97D17B40 DEBUG webrtcsink net\webrtc\src\webrtcsink\imp.rs:2982:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::run_discovery_pipeline::{{closure}}:<livekitwebrtcsink0> Codec discovery pipeline for caps video/x-h264, stream-format=(string)avc, alignment=(string)au, level=(string)3, profile=(string)high-4:4:4, width=(int)640, height=(int)480, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)bt601, chroma-site=(string)jpeg, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono with codec Codec { name: "H264", caps: Caps(video/x-h264(memory:SystemMemory)), stream_type: StreamType(VIDEO), payload_type: Some(97), decoding_info: Some(DecodingInfo { has_decoder: true }), encoding_info: Some(EncodingInfo { encoder: ElementFactory { inner: TypedObjectRef { inner: 0x25a9769b000, type: GstElementFactory } }, payloader: ElementFactory { inner: TypedObjectRef { inner: 0x25a976a77e0, type: GstElementFactory } }, output_filter: None }) } succeeded: application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)f4001e, profile=(string)high-4:4:4, payload=(int)97, extmap-1=(string)http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01;
0:00:03.009183000 17220 0000025A97D17B40 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:2040:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session:<livekitwebrtcsink0> Adding session: unique for peer: unique
0:00:03.021579000 17220 0000025A97D17B40 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:1438:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::request_webrtcbin_pad::{{closure}}:<livekitwebrtcsink0> Requesting WebRTC pad with caps application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)f4001e, profile=(string)high-4:4:4, payload=(int)97, extmap-1=(string)http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01, ssrc=(uint)2865118788
0:00:03.033926000 17220 0000025A97D17B40 DEBUG webrtcsink net\webrtc\src\webrtcsink\imp.rs:1917:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::negotiate:<livekitwebrtcsink0> Negotiating for session unique
0:00:03.040745000 17220 0000025A97D17B40 DEBUG webrtcsink net\webrtc\src\webrtcsink\imp.rs:1940:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::negotiate: Creating offer for session unique
0:00:03.045533000 17220 0000025A97D17B40 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:2347:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}:<session-pipeline-unique> Recalculating latency
0:00:03.050052000 17220 0000025A97D17B40 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:2347:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}:<session-pipeline-unique> Recalculating latency
0:00:03.061416000 17220 0000025A97D17B40 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:2347:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}:<session-pipeline-unique> Recalculating latency
0:00:03.062370000 17220 0000025AA0797040 DEBUG webrtcsink net\webrtc\src\webrtcsink\imp.rs:1943:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::negotiate::{{closure}}: Created offer for session unique
0:00:03.143521000 17220 0000025AA0797040 LOG webrtcsink net\webrtc\src\webrtcsink\imp.rs:2243:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}:<livekitwebrtcsink0> Ice gathering state in session unique (peer unique) changed: Gathering
0:00:03.391019000 17220 0000025AA0797040 WARN webrtcsink net\webrtc\src\webrtcsink\imp.rs:2120:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}::{{closure}}: rtprtxsend doesn't have a `stuffing-kbps` property, stuffing disabled
0:00:03.399641000 17220 0000025AA0797040 DEBUG webrtcsink net\webrtc\src\webrtcsink\imp.rs:2814:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::handle_sdp_answer::{{closure}}: received reply Ok(None)
0:00:03.404223000 17220 0000025AA0797040 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:1076:gstrswebrtc::webrtcsink::imp::Session::connect_input_stream:<livekitwebrtcsink0> Connecting input stream video_0 for consumer unique and media 0
0:00:03.411455000 17220 0000025AA0797040 DEBUG webrtcsink net\webrtc\src\webrtcsink\imp.rs:1097:gstrswebrtc::webrtcsink::imp::Session::connect_input_stream:<livekitwebrtcsink0> Picking codec from local offer
0:00:03.416467000 17220 0000025A97D17B40 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:2347:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}:<session-pipeline-unique> Recalculating latency
0:00:03.435270000 17220 0000025AA0797040 LOG webrtcsink net\webrtc\src\webrtcsink\imp.rs:2243:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}:<livekitwebrtcsink0> Ice gathering state in session unique (peer unique) changed: Complete
0:00:03.435662000 17220 0000025A97D17B40 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:2347:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}:<session-pipeline-unique> Recalculating latency
0:00:03.441829000 17220 0000025AA0797040 LOG webrtcsink net\webrtc\src\webrtcsink\imp.rs:2206:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}:<livekitwebrtcsink0> Ice connection state in session unique (peer unique) changed: Checking
0:00:03.451193000 17220 0000025AA0797040 LOG webrtcsink net\webrtc\src\webrtcsink\imp.rs:2172:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}:<livekitwebrtcsink0> Connection state in session unique (peer unique) changed: Connecting
0:00:03.728601000 17220 0000025AA0797040 LOG webrtcsink net\webrtc\src\webrtcsink\imp.rs:2206:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}:<livekitwebrtcsink0> Ice connection state in session unique (peer unique) changed: Completed
0:00:03.733924000 17220 0000025A97D17B40 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:2347:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}:<session-pipeline-unique> Recalculating latency
0:00:03.954061000 17220 0000025AA0797040 LOG webrtcsink net\webrtc\src\webrtcsink\imp.rs:2172:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}:<livekitwebrtcsink0> Connection state in session unique (peer unique) changed: Connected
0:00:04.202197000 17220 0000025A97D17B40 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:2347:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}:<session-pipeline-unique> Recalculating latency
0:00:04.214001000 17220 0000025A97D17B40 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:2347:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}:<session-pipeline-unique> Recalculating latency
0:00:05.002929000 17220 0000025A97D17B40 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:2347:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}:<session-pipeline-unique> Recalculating latency
0:00:05.013715000 17220 0000025A97D17B40 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:2347:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::start_session::{{closure}}:<session-pipeline-unique> Recalculating latency
ERROR: from element /GstPipeline:pipeline0/GstLiveKitWebRTCSink:livekitwebrtcsink0: GStreamer encountered a general stream error.
Additional debug info:
net\webrtc\src\webrtcsink\imp.rs(1573): gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::connect_signaller::{{closure}}::{{closure}} (): /GstPipeline:pipeline0/GstLiveKitWebRTCSink:livekitwebrtcsink0:
Signalling error: Error: Server disconnected
Execution ended after 0:00:17.967301000
Setting pipeline to NULL ...
0:00:18.050845000 17220 0000025A978807B0 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:1498:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::unprepare:<livekitwebrtcsink0> unpreparing
0:00:18.054825000 17220 0000025A978807B0 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:930:gstrswebrtc::webrtcsink::imp::State::finalize_session: Ending session unique
0:00:18.058572000 17220 0000025A978807B0 DEBUG webrtcsink net\webrtc\src\webrtcsink\imp.rs:1522:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::unprepare:<livekitwebrtcsink0> Waiting for codec discoveries to finish
0:00:18.063490000 17220 0000025A978807B0 DEBUG webrtcsink net\webrtc\src\webrtcsink\imp.rs:1529:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::unprepare:<livekitwebrtcsink0> No codec discovery is running anymore
0:00:18.067467000 17220 0000025A978807B0 DEBUG webrtcsink net\webrtc\src\webrtcsink\imp.rs:1540:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::unprepare:<livekitwebrtcsink0> Ending sessions
0:00:18.071122000 17220 0000025AA082FCC0 DEBUG webrtcsink net\webrtc\src\webrtcsink\imp.rs:962:gstrswebrtc::webrtcsink::imp::State::finalize_session::{{closure}}: Session unique ended
0:00:18.072244000 17220 0000025A978807B0 DEBUG webrtcsink net\webrtc\src\webrtcsink\imp.rs:1544:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::unprepare:<livekitwebrtcsink0> All sessions have started finalizing
0:00:18.079282000 17220 0000025A978807B0 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:1547:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::unprepare:<livekitwebrtcsink0> Stopping signaller
0:00:18.083450000 17220 0000025A978807B0 INFO webrtcsink net\webrtc\src\webrtcsink\imp.rs:1549:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::unprepare:<livekitwebrtcsink0> Stopped signaller
0:00:18.087033000 17220 0000025A978807B0 DEBUG webrtcsink net\webrtc\src\webrtcsink\imp.rs:1560:gstrswebrtc::webrtcsink::imp::BaseWebRTCSink::unprepare:<livekitwebrtcsink0> All sessions are done finalizing
Freeing pipeline ...
```
#### Setup
- **Operating System:** Windows 11
- **Device:** Computer
- **gst-plugins-rs Version:** 0.11
- **GStreamer Version:** GStreamer 1.22.6 (gst-launch-1.0 version 1.22.6)
- **Command line:** `gst-launch-1.0 videotestsrc ! videoconvert ! video/x-raw,width=640,height=480 ! x264enc ! queue ! livekitwebrtcsink signaller::ws-url=<livekit_url> signaller::auth-token=<access_token>`
### Steps to reproduce the bug
1. build webrtc plugin according: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs
2. create livekit access token: `livekit-cli create-token --api-key <api_key> --api-secret <api_secret> --join --room <room> --create --identity <user_id> --valid-for 24h`
3. run pipeline: `gst-launch-1.0 videotestsrc ! videoconvert ! video/x-raw,width=640,height=480 ! x264enc ! queue ! livekitwebrtcsink signaller::ws-url=<livekit_url> signaller::auth-token=<access_token>`
### Additional Information
Pipeline with livekit api key and api secret works fine:
`gst-launch-1.0 -e videotestsrc ! videoconvert ! video/x-raw,width=640,height=480 ! x264enc ! queue ! livekitwebrtcsink signaller::ws-url=<livekit_url> signaller::api-key=<api_key> signaller::secret-key=<api_secret> signaller::room-name=<room>`https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/442webrtcsink ignores encoder plugin ranks2023-10-05T07:29:15ZJan Schmidtwebrtcsink ignores encoder plugin ranksWhen selecting encoders, `webrtcsink` ignores plugin ranks completely, and will plug encoders with rank `None` - making it impossible to disable (for example) broken Nvidia hw encoder elements by overriding the plugin rankWhen selecting encoders, `webrtcsink` ignores plugin ranks completely, and will plug encoders with rank `None` - making it impossible to disable (for example) broken Nvidia hw encoder elements by overriding the plugin rankhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3016d3d11videosink: full screen video on second display reduces video size2023-10-12T00:25:15ZSophie Otletd3d11videosink: full screen video on second display reduces video size### Describe your issue
d3d11videosink: streaming a video on a second display, with the window maximized and then entering fullscreen mode (with ALT+ENTER) reduces the video size.
#### Expected Behavior
The video is shown in full screen...### Describe your issue
d3d11videosink: streaming a video on a second display, with the window maximized and then entering fullscreen mode (with ALT+ENTER) reduces the video size.
#### Expected Behavior
The video is shown in full screen.
#### Observed Behavior
The video is really small or inexistant.
#### Setup
- **Operating System:** Windows 11
- **Device:** Computer, 2 screens
- **GStreamer Version:** 1.22
- **Command line:** `gst-launch-1.0.exe videotestsrc ! queue ! d3d11videosink fullscreen-toggle-mode=0x02`
### Steps to reproduce the bug
1. open terminal
2. type `gst-launch-1.0.exe videotestsrc ! queue ! d3d11videosink fullscreen-toggle-mode=0x02`
3. slide the stream window on the second screen
4. maximize the stream window
5. press ALT+ENTER
### How reproducible is the bug?
The fullscreen always reduce, 100% reproducible.
### Screenshots if relevant
![image](/uploads/2ac5d7f9d03b823389e3de05b945da5f/image.png)
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
This issue also appears with the version 1.21 of Gstreamerhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1787appsrc with webrtc streaming issues.2023-10-03T14:36:30ZSuresh Kumarappsrc with webrtc streaming issues.Hi,
Our requirement is to stream video over Webrtc. I have a camera source with ISP(Image signal processing) based filter processing, the filtered streamed
is pushed to a Gstreamer appsrc object. This object is further used as source t...Hi,
Our requirement is to stream video over Webrtc. I have a camera source with ISP(Image signal processing) based filter processing, the filtered streamed
is pushed to a Gstreamer appsrc object. This object is further used as source to Gstreamer Webrtc pipeline.
Our code is working with standlone VideotestSrc,but when I use the appsrc object as source, after offer send, no further response/video streaming . appsrc object when used to stream using Gstreamer RTP pipeline, its working fine.
**Our observation is at other end client, no transceiver information is shown in logs. **
Screen shots:
Pipeline
![pipline](/uploads/ea806e8d62495717a2187dc3151bdb27/pipline.png)
Transceiver
![transreciver](/uploads/f1fe532a8a284a5bcd988c9a59032f85/transreciver.png)
Offer
![offer](/uploads/4f461a4d805fc7ea785cb78c7fd11739/offer.png)
Transceiver error at other client
![client_end_error](/uploads/035bfde3997336cb635db3ce91a12b72/client_end_error.png)
Thanks.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3010Slow memory leak over time with mp3/mp2 files2023-10-04T08:09:12ZWilhelm BartelSlow memory leak over time with mp3/mp2 files### 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/ -->
while creating a simple gstreamer pipeline with the [go-gst bindings](https://github.com/go-gst/go-gst) I experienced a [small memory leak](https://github.com/go-gst/go-gst/issues/49)
#### Observed Behavior
<!-- What actually happened -->
The gstreamer pipeline seems to leak memory over time while playing. I threw [valgrind and heaptrack at the built golang binary](https://github.com/go-gst/go-gst/issues/49#issuecomment-1740095586) and found out that the issue may (not only) be in the bindings
#### Setup
- **Operating System:** Archlinux, Debian 12
- **Device:** Computer / Docker Container <!-- Delete as appropriate !-->
- **GStreamer Version:** 1.22.6 / 1.22.4
### Steps to reproduce the bug
I provided a [minimal golang app](https://github.com/go-gst/go-gst/blob/memleak_reproduction/examples/memleak_reproduction/main.go) in a branch of the repository. Although after some investigation the leak even happens with [our port of the playbin example](https://github.com/go-gst/go-gst/blob/memleak_reproduction/examples/playbin/main.go)
To run it do the follwing:
```bash
go build -o bin ./examples/memleak_reproduction
# valgrind:
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --show-leak-kinds=all --num-callers=40 --log-file=valgrind.log ./bin file:///path/to/your/file
# heaptrack:
heaptrack ./bin file:///path/to/your/file
```
### How reproducible is the bug?
Always
### Screenshots if relevant
see [original issue](https://github.com/go-gst/go-gst/issues/49)
### Solutions you have tried
will try 1.24 / main gstreamer branch
### Related non-duplicate issues
May be related:
* https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2707 but in Python bindings, and an older gstreamer version (1.20 instead of 1.22.6)
* https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1721 but in C#https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/122libva does not respect the meson pkgconfig variable set in cross file2023-09-28T13:09:03ZMaciej Andrzejewskilibva does not respect the meson pkgconfig variable set in cross fileTested on `main` branch of the gstreamer.
Run the meson with this pkg-config setup:
```
(...)
[binaries]
c = ['arm-buildroot-linux-gnueabi-gcc']
cpp = ['arm-buildroot-linux-gnueabi-g++']
ar = ['arm-buildroot-linux-gnueabi-ar']
pkgconfig...Tested on `main` branch of the gstreamer.
Run the meson with this pkg-config setup:
```
(...)
[binaries]
c = ['arm-buildroot-linux-gnueabi-gcc']
cpp = ['arm-buildroot-linux-gnueabi-g++']
ar = ['arm-buildroot-linux-gnueabi-ar']
pkgconfig = '/tmp/project/pkg-config-wrapper.sh'
strip = ['arm-buildroot-linux-gnueabi-strip']
cmake = ['false']
```
File `/tmp/project/pkg-config-wrapper.sh`:
```
#!/bin/bash
export PKG_CONFIG_SYSROOT_DIR=/tmp/sysroot/target-arm-buildroot-linux-gnueabi_glibc
exec pkg-config "$@"
```
The messon log:
```
(...)
gstreamer| Found pkg-config: /tmp/project/pkg-config-wrapper.sh (0.29.2)
(...)
libva| Found pkg-config: /usr/bin/pkg-config (0.29.2)
```
It detected correct pkg-config for the gstreamer but take default path to pkg-config in the libva which render the cross-compilation useless.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/440gst-plugin-version-helper: cargo intentionally provides bogus mtime on files ...2023-10-04T16:20:54ZSebastian Drögegst-plugin-version-helper: cargo intentionally provides bogus mtime on files so can't use it as release dateSee https://github.com/rust-lang/cargo/issues/10285
For releases we'll have to provide another mechanism than looking at the `Cargo.toml`'s mtime. The most obvious approach would be to add a release date directly to `Cargo.toml` as a cu...See https://github.com/rust-lang/cargo/issues/10285
For releases we'll have to provide another mechanism than looking at the `Cargo.toml`'s mtime. The most obvious approach would be to add a release date directly to `Cargo.toml` as a custom
```toml
[package.metadata.gstreamer]
release_date = "2023-07-20"
```
This would then have to be always updated in sync together with the version numbers.Sebastian DrögeSebastian Drögehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3006GstEvent (GST_EVENT_STREAM_START) trapped in a loop2023-10-27T04:06:35ZRobert AyrapetyanGstEvent (GST_EVENT_STREAM_START) trapped in a loopThere is a pipeline with `GstDtlsEnc` connected to the `GstNiceSink`.
`GstDtlsEnc` is sending a `GST_EVENT_STREAM_START` event once:
```
dtlsenc gstdtlsenc.c:490:src_task_loop:<dtlsenc0> gstdlsenc start event s_id dtlsenc-219bba68
```
ni...There is a pipeline with `GstDtlsEnc` connected to the `GstNiceSink`.
`GstDtlsEnc` is sending a `GST_EVENT_STREAM_START` event once:
```
dtlsenc gstdtlsenc.c:490:src_task_loop:<dtlsenc0> gstdlsenc start event s_id dtlsenc-219bba68
```
nicesink receives this event first time:
```
0:00:05.756910574 25 0x7f2134005cc0 ERROR basesink gstbasesink.c:3389:gst_base_sink_default_event:<nicesink0> Now posting STREAM_START (seqnum:497)
0:00:05.756917967 25 0x7f2134005cc0 ERROR basesink gstbasesink.c:3391:gst_base_sink_default_event:<nicesink0> Processing event stream-start event: 0x7f2118001a20, time 99:99:99.999999999, seq-num 497, GstEventStreamStart, stream-id=(string)dtlsenc-219bba68, flags=(GstStreamFlags)GST_STREAM_FLAG_NONE;
```
And then again and again, infinitely:
```
0:00:10.217010119 25 0x7f2134005cc0 ERROR basesink gstbasesink.c:3389:gst_base_sink_default_event:<nicesink0> Now posting STREAM_START (seqnum:497)
0:00:10.217023121 25 0x7f2134005cc0 ERROR basesink gstbasesink.c:3391:gst_base_sink_default_event:<nicesink0> Processing event stream-start event: 0x7f2118001a20, time 99:99:99.999999999, seq-num 497, GstEventStreamStart, stream-id=(string)dtlsenc-219bba68, flags=(GstStreamFlags)GST_STREAM_FLAG_NONE;
```
Any thoughts why this may happen? How some event may be trapped like that?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3005How To Set Max Thread Creation2023-09-30T09:16:38Zkeivan moazamiHow To Set Max Thread CreationI Want to decode 200 ip cameras that have 1 fps. when I run pipeline for decoding with cpu, each pipeline create about 23 threads, and when create pipeline for gpu decoding gstreamer create about 8 threads internally. for 200 cameras abo...I Want to decode 200 ip cameras that have 1 fps. when I run pipeline for decoding with cpu, each pipeline create about 23 threads, and when create pipeline for gpu decoding gstreamer create about 8 threads internally. for 200 cameras about 4500 threads needed that cause os crash.
I search documentation and test some ways but didn't worked, for example Initiate GstSharedTaskPool and call gst_shared_task_pool_set_max_threads() and then when a GST_STREAM_STATUS_TYPE_CREATE message come in bus, set task pool with gst_task_set_pool() but didn't work. I see ts-udpsrc plugin but I want to force gstreamer to use one thread per pipeline. Is there a way to do this?
Thanks
Gstreamer version : 1.22
os : win 10https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/439WebRTCSink and Apple Safari2023-10-30T17:28:41ZGallery SiennaWebRTCSink and Apple SafariHas anyone had success using webrtcsink with the gst-webrtc-signalling-server and the gstwebrtc-api example HTML via webpack ?
Sending a simple test stream from GStreamer into this environment picks up fine and plays the stream in Chrom...Has anyone had success using webrtcsink with the gst-webrtc-signalling-server and the gstwebrtc-api example HTML via webpack ?
Sending a simple test stream from GStreamer into this environment picks up fine and plays the stream in Chrome, but in Apple Safari it throws ICE candidate errors.
Replication:
signalling server on ubuntu 22.04
webpack / gstwebapi hosted on ubuntu 22.04
Gstreamer on ubuntu 22.04 : gst-launch-1.0 webrtcsink name=ws congestion-control=homegrown meta=“meta,name=gst-stream” videotestsrc ! ws. audiotestsrc ! ws.
Connect to index.html served by webpack
Compare playback of GStreamer webrtcsink source using Safari and Chrome on a recent macOS, or try on safari from iOS
Would be great to hear from anyone able to replicate this one way or the other.
On inspection, the SDP and ICE negotiations appear to be similar between Chrome and Safari with no obvious error, so the issue must be a little more esoteric.
I have attached[Webrtcice.pdf](/uploads/1c0bc79f6c3bc9a92588289a8e41d27b/Webrtcice.pdf) a full log for each of the component parts in the jigsaw here:[Webrtcice.rtfd.zip](/uploads/04161cb81db03e272cbb2398c72224bf/Webrtcice.rtfd.zip)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3004d3d11: cache compiled shaders in a sake of faster startup2023-10-11T19:35:00ZAlexander Slobodeniukd3d11: cache compiled shaders in a sake of faster startupIt's not really a problem, but some room for improvement, that seems to be feasible. I think I can do the PR, but also would like to know your opinion, so let's open a discussion.
**Idea**
The thing is that in the log of some apps I ca...It's not really a problem, but some room for improvement, that seems to be feasible. I think I can do the PR, but also would like to know your opinion, so let's open a discussion.
**Idea**
The thing is that in the log of some apps I can see that it can compile many times the same d3d11 shaders, and it seems that sometimes the compilation can take up to ~5ms depending on the case.
Following the code and the logs it seems that d3d11 elements just compile shaders every time they start.
My idea is to improve gstd3d11compile.cpp in a way that it would be caching the compiled shader, and checking/accessing the already compiled one by a tuple device/code.
If I understand correctly, the things that can determine each shader are it's code, the ID3D11Device handle and the compilation flags, macros, parameters, etc.
Looking on compiled shader as just a compiled binary that will run on a certain GPU. Please correct me if I'm wrong.
**What would improve**
There're many cases when the same shader gets compiled several times for the same device.
The simplest example is when the application opens and closes many pipelines, so each time the shaders will be compiled again.
So all the sturtups starting from the second one would be ~5ms faster.
But also depending on the pipeline it can be more. If there're also more elements, such as d3d11convert, etc.
**How I think it could be done**
The crucial change would happen in the gst_d3d11_compile() function in gstd3d11compile.cpp.
There would be a GHashTable stored in a static memory (variable).
Before executing GstD3DCompileFunc, the code of gst_d3d11_compile would build a hash of the parameters of that function (code, flags, includes, everything). The algorhythm is a really small piece of code that can be copied from [g_bytes_hash](https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gbytes.c?ref_type=heads#L385).
So, once we have this hash, we search in our "static" GHashTable, and so either we find the pointer to already compiled shader and return it, either we don't find it and therefore execute GstD3DCompileFunc, store the shader in our hash table and return it.
Everything under a static lock.
Apart from that change the patch would also manage not to release the shader objects (because now we store them in the hash table forever). Such as `ID3D11PixelShader *ps[CONVERTER_MAX_QUADS];` of `struct _GstD3D11ConverterPrivate`.
CC pinging @seungha.yang as an author of the code.https://gitlab.freedesktop.org/gstreamer/www/-/issues/47configure.ac:7: error: required file 'htdocs/bugs/Makefile.in' not found2023-09-27T10:21:42ZMichiel Westerbeekconfigure.ac:7: error: required file 'htdocs/bugs/Makefile.in' not foundTrying to run ./src/autogen.sh but getting the following error:
```
configure.ac:7: error: required file 'htdocs/bugs/Makefile.in' not found
```
Is this file missing from the repo?Trying to run ./src/autogen.sh but getting the following error:
```
configure.ac:7: error: required file 'htdocs/bugs/Makefile.in' not found
```
Is this file missing from the repo?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3003glimagsink: Incorrect video/x-raw BGR10A2_LE output2023-09-27T11:48:14ZVincent Cheahglimagsink: Incorrect video/x-raw BGR10A2_LE output### Describe your issue
When using video/x-raw BGR10A2_LE on glimagesink would results incorrect output (black and white). gst-launch-1.0 videotestsrc num-buffers=10000 ! "video/x-raw,format=BGR10A2_LE" ! glimagesink.
#### Expected Beh...### Describe your issue
When using video/x-raw BGR10A2_LE on glimagesink would results incorrect output (black and white). gst-launch-1.0 videotestsrc num-buffers=10000 ! "video/x-raw,format=BGR10A2_LE" ! glimagesink.
#### Expected Behavior
The glimagesink BGR10A2_LE video/x-raw output correctly.
#### Observed Behavior
The glimagesink BGR10A2_LE video/x-raw results in black and white output.
![image](/uploads/f9960aacf10835a0161e80f648784760/image.png)
#### Setup
* Platform: Intel MTL
* Operating System: Linux
* GStreamer Version:1.23.0.1
* Command line: gst-launch-1.0 videotestsrc num-buffers=10000 ! "video/x-raw,format=BGR10A2_LE" ! glimagesink
### Steps to reproduce the bug
The issue can be reproduced with these commands
- gst-launch-1.0 videotestsrc num-buffers=10000 ! "video/x-raw,format=BGR10A2_LE" ! glimagesink
- gst-launch-1.0 videotestsrc num-buffers=10000 ! videoconvert ! "video/x-raw,format=BGR10A2_LE" ! glimagesink
- gst-launch-1.0 videotestsrc num-buffers=10000 ! vapostproc ! "video/x-raw,format=BGR10A2_LE" ! glimagesink
- gst-launch-1.0 videotestsrc num-buffers=10000 ! msdkvpp ! "video/x-raw,format=BGR10A2_LE" ! glimagesink
### How reproducible is the bug?
The reproducibility of the bug is always (100%) when using video/x-raw BGR10A2_LE on glimagesink.
### Solutions you have tried
The output is correct when not going through glimagesink.
- gst-launch-1.0 videotestsrc num-buffers=10000 ! "video/x-raw,format=BGR10A2_LE" ! msdkh265enc ! filesink location=test.h265.
- gst-launch-1.0 videotestsrc num-buffers=10000 ! "video/x-raw,format=BGR10A2_LE" ! filesink location=test.yuv
Had also bisected glimagesink. It seems https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5109 resulted the BGR10A2_LE to render black and white output.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/438License question2023-09-26T16:52:09ZMatt LarsenLicense questionI am considering using webrtcsink for a work project. I am concerned that since webrtcsink uses webrtcbin (GLP 2.0), I will be unable to use this in our product. Do I need to be concerned about the GPL 2.0 license in the dependency?I am considering using webrtcsink for a work project. I am concerned that since webrtcsink uses webrtcbin (GLP 2.0), I will be unable to use this in our product. Do I need to be concerned about the GPL 2.0 license in the dependency?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3001Fails to build with mpg123 1.32.x2023-09-28T17:28:32ZSoulHarsh007Fails to build with mpg123 1.32.xI am using ArchLinux PKGBUILDs (Link to PKGBUILD: [ArchLinux GitLab - GStreamer at 0f037a92](https://gitlab.archlinux.org/archlinux/packaging/packages/gstreamer/-/blob/0f037a929f5a28d9f5c23fedc302f386553fc033/PKGBUILD)) to build GStreame...I am using ArchLinux PKGBUILDs (Link to PKGBUILD: [ArchLinux GitLab - GStreamer at 0f037a92](https://gitlab.archlinux.org/archlinux/packaging/packages/gstreamer/-/blob/0f037a929f5a28d9f5c23fedc302f386553fc033/PKGBUILD)) to build GStreamer 1.22.6 with mpg123 1.32.1 and the build seems to fail, here is the relevant snippet from build failure log:
```log
[1883/4160] Linking target subprojects/gst-plugins-good/ext/dv/libgstdv.so
[1884/4160] Generating 'subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/moc_qtglrenderer.cpp'
[1885/4160] Compiling C object subprojects/gst-plugins-good/ext/raw1394/libgst1394.so.p/gstdv1394src.c.o
[1886/4160] Linking target subprojects/gst-plugins-good/ext/mpg123/libgstmpg123.so
FAILED: subprojects/gst-plugins-good/ext/mpg123/libgstmpg123.so
cc -o subprojects/gst-plugins-good/ext/mpg123/libgstmpg123.so subprojects/gst-plugins-good/ext/mpg123/libgstmpg123.so.p/gstmpg123audiodec.c.o -flto -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libgstmpg123.so -Wl,-Bsymbolic-functions -Wl,-z,nodelete -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=auto -march=haswell -mtune=haswell -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -flto=auto '-Wl,-rpath,$ORIGIN/../../../gst-plugins-base/gst-libs/gst/audio:$ORIGIN/../../../gstreamer/libs/gst/base:$ORIGIN/../../../gstreamer/gst:$ORIGIN/../../../gst-plugins-base/gst-libs/gst/tag' -Wl,-rpath-link,/build/gstreamer/src/build/subprojects/gst-plugins-base/gst-libs/gst/audio -Wl,-rpath-link,/build/gstreamer/src/build/subprojects/gstreamer/libs/gst/base -Wl,-rpath-link,/build/gstreamer/src/build/subprojects/gstreamer/gst -Wl,-rpath-link,/build/gstreamer/src/build/subprojects/gst-plugins-base/gst-libs/gst/tag subprojects/gst-plugins-base/gst-libs/gst/audio/libgstaudio-1.0.so.0.2206.0 subprojects/gst-plugins-base/gst-libs/gst/tag/libgsttag-1.0.so.0.2206.0 subprojects/gstreamer/libs/gst/base/libgstbase-1.0.so.0.2206.0 subprojects/gstreamer/gst/libgstreamer-1.0.so.0.2206.0 /usr/lib/libglib-2.0.so /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so -pthread -lm /usr/lib/libz.so /usr/lib/liborc-0.4.so /usr/lib/libmpg123.so -Wl,--end-group
/usr/bin/ld: /tmp/ccTOoO1C.ltrans0.ltrans.o: in function `gst_mpg123_audio_dec_handle_frame':
<artificial>:(.text+0x2068): undefined reference to `mpg123_decode_frame_64'
collect2: error: ld returned 1 exit status
[1887/4160] Compiling C object subprojects/gst-plugins-good/ext/raw1394/libgst1394.so.p/gsthdv1394src.c.o
[1888/4160] Linking target subprojects/gst-plugins-good/ext/libpng/libgstpng.so
[1889/4160] Compiling C++ object subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/meson-generated_moc_gstqsgtexture.cpp.o
[1890/4160] Compiling C++ object subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/meson-generated_moc_qtitem.cpp.o
[1891/4160] Compiling C++ object subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/meson-generated_moc_qtwindow.cpp.o
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/437webrtcsink: is 60 Hz possible?2023-09-25T17:45:12ZjamlabsPSwebrtcsink: is 60 Hz possible?Hello,
I'm using the example from https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/tree/main/net/webrtc to test webrtcsink.
I change the source from videotestsrc to v4l2src and it works fine, except that i cannot get 60HZ refre...Hello,
I'm using the example from https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/tree/main/net/webrtc to test webrtcsink.
I change the source from videotestsrc to v4l2src and it works fine, except that i cannot get 60HZ refresh rate.
My video on v4l2src is an HDMI port with 1080p60 live input. My refresh rate for the remote stream in the browser window is about 30Hz.
Is it possible to obtain 60Hz with this webrtcsink method, or is it an inherent delay of the solution and cannot be improved?
thank you