GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T14:39:09Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1541error: getting data stream error when using msdkh264enc2021-09-24T14:39:09Zvandanaerror: getting data stream error when using msdkh264enci have installed intel media sdk on my machine and the examples in that run fine. However when i run the below gstreamer pipeline, i get error
Pipeline
```
`gst-launch-1.0 --gst-debug=3 filesrc location=/home/vandana/sample_videos/big_...i have installed intel media sdk on my machine and the examples in that run fine. However when i run the below gstreamer pipeline, i get error
Pipeline
```
`gst-launch-1.0 --gst-debug=3 filesrc location=/home/vandana/sample_videos/big_buck_bunny_720p_2mb.mp4 ! decodebin name=demux demux. ! queue ! audioresample ! audioconvert ! avenc_aac bitrate=192000 ! mux. mpegtsmux bitrate=5000000 alignment=7 name=mux ! filesink location=/home/vandana/sample_videos/sample-mp4-file_lt.ts demux. ! queue ! msdkh264enc hardware=true ! video/x-h264,stream-format=byte-stream,profile=high ! h264parse ! mux.`
Logs
libva info: VA-API version 1.11.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_11
libva info: va_openDriver() returns 0
Setting pipeline to PAUSED ...
libva info: VA-API version 1.11.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_11
libva info: va_openDriver() returns 0
0:00:00.040951282 21893 0x55aca38ebe10 WARN basesrc gstbasesrc.c:3688:gst_base_src_start_complete:<filesrc0> pad not activated yet
Pipeline is PREROLLING ...
Got context from element 'msdkh264enc0': gst.msdk.Context=context, gst.msdk.Context=(GstMsdkContext)"\(GstMsdkContext\)\ msdkcontext1";
0:00:00.046714269 21893 0x7f286c0a2d40 WARN qtdemux qtdemux.c:3101:qtdemux_parse_trex:<qtdemux0> failed to find fragment defaults for stream 1
0:00:00.046766206 21893 0x7f286c0a2d40 WARN qtdemux qtdemux.c:3101:qtdemux_parse_trex:<qtdemux0> failed to find fragment defaults for stream 2
Redistribute latency...
0:00:00.104990328 21893 0x55aca38a1590 WARN videopool gstvideopool.c:194:video_buffer_pool_set_config:<msdkbufferpool0> allocation params alignment 31 is smaller than the max specified video stride alignment 127, fixing
Redistribute latency...
0:00:00.105078458 21893 0x55aca38a1590 WARN videopool gstvideopool.c:194:video_buffer_pool_set_config:<msdkbufferpool1> allocation params alignment 31 is smaller than the max specified video stride alignment 127, fixing
0:00:00.105139905 21893 0x55aca38a1590 WARN videopool gstvideopool.c:194:video_buffer_pool_set_config:<msdkbufferpool2> allocation params alignment 31 is smaller than the max specified video stride alignment 127, fixing
0:00:00.105213075 21893 0x7f2864008630 WARN videopool gstvideopool.c:194:video_buffer_pool_set_config:<msdkbufferpool2> allocation params alignment 31 is smaller than the max specified video stride alignment 127, fixing
0:00:00.105270679 21893 0x7f2864008630 WARN videopool gstvideopool.c:194:video_buffer_pool_set_config:<msdkbufferpool2> allocation params alignment 31 is smaller than the max specified video stride alignment 127, fixing
Redistribute latency...
0:00:00.105394611 21893 0x55aca38a1590 WARN videopool gstvideopool.c:194:video_buffer_pool_set_config:<msdkbufferpool3> allocation params alignment 31 is smaller than the max specified video stride alignment 127, fixing
0:00:00.105454194 21893 0x7f2864008630 WARN videopool gstvideopool.c:194:video_buffer_pool_set_config:<msdkbufferpool3> allocation params alignment 31 is smaller than the max specified video stride alignment 127, fixing
0:00:00.105485546 21893 0x7f2864008630 WARN videopool gstvideopool.c:194:video_buffer_pool_set_config:<msdkbufferpool3> allocation params alignment 31 is smaller than the max specified video stride alignment 127, fixing
0:00:00.126799907 21893 0x55aca38a14a0 FIXME basesink gstbasesink.c:3386:gst_base_sink_default_event:<filesink0> stream-start event without group-id. Consider implementing group-id handling in the upstream elements
0:00:00.127131802 21893 0x55aca38a14a0 FIXME aggregator gstaggregator.c:1365:gst_aggregator_aggregate_func:<mux> Subclass should call gst_aggregator_selected_samples() from its aggregate implementation.
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:01.129732883 21893 0x55aca38a1590 WARN default gstmsdkvideomemory.c:207:gst_video_meta_map_msdk_memory: The surface is not allocated
0:00:01.129788717 21893 0x55aca38a1590 ERROR default video-frame.c:168:gst_video_frame_map_id: failed to map video frame plane 0
0:00:01.129819870 21893 0x55aca38a1590 WARN msdkenc gstmsdkenc.c:1672:gst_msdkenc_handle_frame:<msdkh264enc0> Failed to map frame
0:00:01.470362790 21893 0x55aca38a1540 WARN audioencoder gstaudioencoder.c:981:gst_audio_encoder_finish_frame:<avenc_aac0> Can't copy metadata because input buffer disappeared
Got EOS from element "pipeline0".
Execution ended after 0:00:01.341743595
Setting pipeline to NULL ...
Freeing pipeline ...
```
Also attaching the level 5 logs for a similar pipeline for filesink
`LD_LIBRARY_PATH=/usr/local/lib:/opt/intel/mediasdk/lib gst-launch-1.0 -v --gst-debug-no-color=1 dvbsrc modulation=5 adapter=0 frequency=147000000 delsys=dvb-c-b ! decodebin name=demux demux. ! queue ! audioresample ! audioconvert ! avenc_aac bitrate = 128000 ! queue ! mpegtsmux bitrate=3000000 alignment=7 name=mux ! filesink location=dvb_msdk_out_210308.mp4 demux. ! queue ! msdkh264enc i-frames=60 b-frames=4 bitrate=1200 frame-packing=-1 ! video/x-h264,stream-format=byte-stream,profile=main ! mux.`
[log_dvb_msdk_210308.log](/uploads/7180569c0ad40e65980a6d3b973af3f7/log_dvb_msdk_210308.log)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/877Application linking error for gstreamer variables from gtkwebkit library2022-04-08T11:48:56ZDonia AbrahamApplication linking error for gstreamer variables from gtkwebkit libraryBuild fails because of following error
```
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libwebkit2gtk-4.0.so: undefined reference to GST_CAT_DEFAULT'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64...Build fails because of following error
```
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libwebkit2gtk-4.0.so: undefined reference to GST_CAT_DEFAULT'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libwebkit2gtk-4.0.so: undefined reference to _gst_debug_min'
```
Expected behavior
Build successful.
Other information
Linux version - 20.04
Gstreamer 1.18.3 - built from scratch on the PC using Meson
gtk-webkit - installed by apt get
Trying to build application against Linux 20.04 with latest Gstreamer and GTKWebkit.Downloaded, build and installed gstreamer,apt installed libwebkit2gtk-4.0 and libgtk-4.0-dev
Linker error from gst variables.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1540d3d11 itterating GPUs incorrectly?2021-03-08T07:48:52ZFredrik Pålssond3d11 itterating GPUs incorrectly?I think there is something wrong with the way d3d11 decoders select GPUs. Consider the output from gst-inspect and gst-launch below.
gst-inspect says device1 is Nvidia. When running gst-launch with d3dh264device1dec decoder the .dot pro...I think there is something wrong with the way d3d11 decoders select GPUs. Consider the output from gst-inspect and gst-launch below.
gst-inspect says device1 is Nvidia. When running gst-launch with d3dh264device1dec decoder the .dot produced indicates an Intel card.
> gst-inspect-1.0.exe d3d11
...
Version 1.19.0.1
...
d3d11h264dec: Direct3D11 H.264 Intel(R) HD Graphics 530 Decoder
d3d11h264device1dec: Direct3D11 H.264 NVIDIA Quadro M2000M Decoder
...
> gst-launch-1.0.exe udpsrc auto-multicast=true uri=udp://239.12.182.1:10200 caps=\"application/x-rtp,clock-rate=90000\" ! rtpjitterbuffer latency=50 ! rtph264depay ! h264parse ! d3d11h264device1dec ! queue ! d3d11videosink
gst-launch.PAUSED_PLAYING.dot:
.....
queue0_038C9D58_src_0386BDB8 -> d3d11videosinkbin0_03870048_sink_03900038 [label="video/x-raw(memory:D3D11Memory)\l format: NV12\l width: 1280\l height: 720\l interlace-mode: progressive\l multiview-mode: mono\l multiview-flags: 0:ffffffff:/right-view...\l pixel-aspect-ratio: 1/1\l framerate: 0/1\l"]
subgraph cluster_d3d11h264device1dec0_00BE4768 {
fontname="Bitstream Vera Sans";
fontsize="8";
style="filled,rounded";
color=black;
label="GstD3D11H264Device1Dec\nd3d11h264device1dec0\n[>]\ndevice-id=6427\nvendor-id=32902";
subgraph cluster_d3d11h264device1dec0_00BE4768_sink {
label="";
style="invis";
d3d11h264device1dec0_00BE4768_sink_0386B9B0 [color=black, fillcolor="#aaaaff", label="sink\n[>][bfb]", height="0.2", style="filled,solid"];
}
....
Vendor 32902 = Intelhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1539webrtcbin: dtls close not firing connection-state signal2023-05-19T03:14:48ZAaron Clausonwebrtcbin: dtls close not firing connection-state signalI'm doing some testing with a webrtcbin pipeline and have encountered an issue where the `connection-state` signal does not get fired when the underlying DTLS connection is closed. Possibly related to #758. I am using a single `sendonly`...I'm doing some testing with a webrtcbin pipeline and have encountered an issue where the `connection-state` signal does not get fired when the underlying DTLS connection is closed. Possibly related to #758. I am using a single `sendonly` VP8 video stream from `webrtcbin` to Chrome.
````
"webrtcbin bundle-policy=max-bundle name=sendonly "
"videotestsrc is-live=true pattern=ball ! videoconvert ! queue ! vp8enc deadline=1 ! rtpvp8pay ! "
"queue ! application/x-rtp,media=video,encoding-name=VP8,payload=96 ! sendonly. "
````
The code I use to hook up the signals is:
````
g_signal_connect (webrtcbin, "on-negotiation-needed", G_CALLBACK (on_negotiation_needed), NULL);
g_signal_connect (webrtcbin, "on-ice-candidate", G_CALLBACK (send_ice_candidate_message), NULL);
g_signal_connect (webrtcbin, "on-new-transceiver", G_CALLBACK (on_new_transceiver), NULL);
g_signal_connect (webrtcbin, "notify::on-new-transceiver", G_CALLBACK (on_new_transceiver), NULL);
g_signal_connect (webrtcbin, "notify::ice-gathering-state", G_CALLBACK (on_ice_gathering_state_notify), NULL);
g_signal_connect (webrtcbin, "notify::ice-connection-state", G_CALLBACK (on_ice_connection_state_notify), NULL);
g_signal_connect (webrtcbin, "notify::connection-state", G_CALLBACK (on_connection_state_notify), NULL);
````
And then we I connect to my application using Chrome the abbreviated output is:
````
set_offer.
on_offer_set.
create-answer promise wait over.
on_answer_created.
on_connection_state_notify '2'.
on_ice_gathering_state_notify '1'.
on_ice_connection_state_notify '3'.
on_ice_gathering_state_notify '2'.
on_negotiation_needed
The name of the element is 'sendonly'.
The signaling state of the element is '0'.
Remote description is set.
````
Closing the connection in Chrome does NOT fire any signal that I have been able to detect.
If I add in some debug logging with `GST_DEBUG=2,dtls*:7` I can see the DTLS connection close being detected. But after that the `webrtcbin` pipeline is not closed and continues to send packets to Chrome.
````
0:00:36.928521700 9 0x7f3470001980 LOG dtlssrtpdemux gstdtlssrtpdemux.c:123:sink_chain:<dtlssrtpdemux0> pushing dtls packet
0:00:36.928840100 9 0x7f3470001980 DEBUG dtlsdec gstdtlsdec.c:610:sink_chain:<dtlsdec0> received buffer from rtp_0_1231155112 with length 31
0:00:36.929062100 9 0x7f3470001980 TRACE dtlsconnection gstdtlsconnection.c:618:gst_dtls_connection_process:<GstDtlsConnection@0x7f3470009c50> locking @ process
0:00:36.929237600 9 0x7f3470001980 TRACE dtlsconnection gstdtlsconnection.c:620:gst_dtls_connection_process:<GstDtlsConnection@0x7f3470009c50> locked @ process
0:00:36.929438600 9 0x7f3470001980 LOG dtlsconnection gstdtlsconnection.c:844:log_state:<GstDtlsConnection@0x7f3470009c50> process start: role=client buf=(0x7f346c237210:0/31) 1000001|1 SSL negotiation finished successfully
0:00:36.929646900 9 0x7f3470001980 DEBUG dtlsconnection gstdtlsconnection.c:1222:bio_method_read:<GstDtlsConnection@0x7f3470009c50> reading 31/31 bytes 31 at offset 0, output buff size is 16717
0:00:36.929888000 9 0x7f3470001980 DEBUG dtlsconnection gstdtlsconnection.c:667:gst_dtls_connection_process:<GstDtlsConnection@0x7f3470009c50> read result: 0
0:00:36.930132300 9 0x7f3470001980 LOG dtlsconnection gstdtlsconnection.c:997:handle_error:<GstDtlsConnection@0x7f3470009c50> Connection was closed
0:00:36.930509700 9 0x7f3470001980 DEBUG dtlsdec gstdtlsdec.c:499:process_buffer:<dtlsdec0> Peer closed the connection
````https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/666hls: Player is deadlock when pause/play bipbop video many time2023-04-20T16:09:17ZPhong Tranhls: Player is deadlock when pause/play bipbop video many timeI try with command line: gst-play-1.0 "http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8" Then I press space button to play/pause video many time. The player is freeze for a long time. Just can exit it by force quit. I use ...I try with command line: gst-play-1.0 "http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8" Then I press space button to play/pause video many time. The player is freeze for a long time. Just can exit it by force quit. I use Gstreamer 1.18.3 and two MacOS version: BigSur 11.2.1, Catalina 10.15.7https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/83Missing header on Ubuntu2021-03-05T09:16:43ZFlorian KarydesMissing header on UbuntuWhen compiling in Ubuntu 18.04 I get:
```bash
$ gcc basic-tutorial-1.c -o basic-tutorial-1 `pkg-config --cflags --libs gstreamer-1.0`
Package gstreamer-1.0 was not found in the pkg-config search path.
Perhaps you should add the directory...When compiling in Ubuntu 18.04 I get:
```bash
$ gcc basic-tutorial-1.c -o basic-tutorial-1 `pkg-config --cflags --libs gstreamer-1.0`
Package gstreamer-1.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gstreamer-1.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gstreamer-1.0' found
basic-tutorial-1.c:1:10: fatal error: gst/gst.h: No such file or directory
#include <gst/gst.h>
^~~~~~~~~~~
compilation terminated.
```
Installing `apt install libgstreamer1.0-dev` fixed it but it's mentioned nowhere in the _Installing on Linux_ section.https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/317ubuntu 20.04 build android arm64 use ndk21 meer error2021-10-18T08:40:34Ztestubuntu 20.04 build android arm64 use ndk21 meer errori use this command build arm64
./cerbero-uninstalled -c config/cross-android-arm64.cbc package gstreamer-1.0
meet error in openssl cross compile
Running command 'sh -c 'perl ./Configure --prefix=~/cerbero/build/dist/android_arm64 --li...i use this command build arm64
./cerbero-uninstalled -c config/cross-android-arm64.cbc package gstreamer-1.0
meet error in openssl cross compile
Running command 'sh -c 'perl ./Configure --prefix=~/cerbero/build/dist/android_arm64 --libdir=lib no-makedepend shared android-arm64''
no NDK aarch64-linux-android-gcc on $PATH at (eval 10) line 124.
Configuring OpenSSL version 1.1.1h (0x1010108fL) for android-arm64
Using os-specific seed configurationhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/859matroskademux: buffer overflow in gst_matroska_demux_add_wvpk_header2022-11-11T09:24:35ZNatalie Silvanovichmatroskademux: buffer overflow in gst_matroska_demux_add_wvpk_headerThe attached file causes heap corruption in gst_matroska_demux_add_wvpk_header. This issue occurs with the patch from https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/858 applied, so it is likely a different issue. A st...The attached file causes heap corruption in gst_matroska_demux_add_wvpk_header. This issue occurs with the patch from https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/858 applied, so it is likely a different issue. A stack trace is below:
```
==3502609==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x628000003dcc at pc 0x00000047297c bp 0x7fffeee386c0 sp 0x7fffeee37e80
WRITE of size 6444 at 0x628000003dcc thread T6 (matroskademux0:)
[Detaching after fork from child process 3502618]
#0 0x47297b in memmove (/usr/local/google/home/natashenka/Downloads/video/video+0x47297b)
#1 0x7fffee512f3d in gst_matroska_demux_add_wvpk_header /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-good/gst/matroska/matroska-demux.c:3962:7
#2 0x7fffee517005 in gst_matroska_demux_parse_blockgroup_or_simpleblock.constprop.0 /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-good/gst/matroska/matroska-demux.c:4783:15
#3 0x7fffee51edda in gst_matroska_demux_parse_id /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-good/gst/matroska/matroska-demux.c:5574:17
#4 0x7fffee5244f7 in gst_matroska_demux_loop /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-good/gst/matroska/matroska-demux.c:5763:9
#5 0x7ffff7c6edfe in gst_task_func /usr/local/google/home/natashenka/gst-build/build/../subprojects/gstreamer/gst/gsttask.c:384:5
#6 0x7ffff51ab9a3 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7b9a3)
#7 0x7ffff51ab0bc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7b0bc)
#8 0x7ffff508fea6 in start_thread nptl/pthread_create.c:477:8
#9 0x7ffff4dcbdee in clone misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95
0x628000003dcc is located 25 bytes to the right of 15539-byte region [0x628000000100,0x628000003db3)
allocated by thread T6 (matroskademux0:) here:
#0 0x4d623d in malloc (/usr/local/google/home/natashenka/Downloads/video/video+0x4d623d)
#1 0x7ffff5187d48 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57d48)
Thread T6 (matroskademux0:) created by T4 (typefind:sink) here:
#0 0x4c0e0a in pthread_create (/usr/local/google/home/natashenka/Downloads/video/video+0x4c0e0a)
#1 0x7ffff51d2ff0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0xa2ff0)
Thread T4 (typefind:sink) created by T0 here:
#0 0x4c0e0a in pthread_create (/usr/local/google/home/natashenka/Downloads/video/video+0x4c0e0a)
#1 0x7ffff51d2ff0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0xa2ff0)
SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/local/google/home/natashenka/Downloads/video/video+0x47297b) in memmove
Shadow bytes around the buggy address:
0x0c507fff8760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c507fff8770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c507fff8780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c507fff8790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c507fff87a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c507fff87b0: 00 00 00 00 00 00 03 fa fa[fa]fa fa fa fa fa fa
0x0c507fff87c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c507fff87d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c507fff87e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c507fff87f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c507fff8800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
```
[write.mka](/uploads/6b5135aa6dc1e34457c4a61b294103dc/write.mka)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1538rsvgdec: isn't able to negotiate caps when size is forced downstream2023-10-16T10:32:36ZNazar Mokrynskyirsvgdec: isn't able to negotiate caps when size is forced downstreamThis works:
```
gst-launch-1.0 curlhttpsrc location='https://upload.wikimedia.org/wikipedia/commons/3/30/Vector-based_example.svg' ! \
rsvgdec ! \
videoconvert ! \
imagefreeze ! \
autovideosink
```
This doesn't:
```
gst-launch-1....This works:
```
gst-launch-1.0 curlhttpsrc location='https://upload.wikimedia.org/wikipedia/commons/3/30/Vector-based_example.svg' ! \
rsvgdec ! \
videoconvert ! \
imagefreeze ! \
autovideosink
```
This doesn't:
```
gst-launch-1.0 curlhttpsrc location='https://upload.wikimedia.org/wikipedia/commons/3/30/Vector-based_example.svg' ! \
rsvgdec ! \
video/x-raw,width=1000,height=1000 ! videoconvert ! \
imagefreeze ! \
autovideosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstCurlHttpSrc:curlhttpsrc0: Internal data stream error.
Additional debug info:
../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstCurlHttpSrc:curlhttpsrc0:
streaming stopped, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
```
Happens both with 1.18.0 stable and 1.19.0 from master.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/665gobject-introspection warnings about childproxy docs2022-07-09T22:57:47ZSebastian Drögegobject-introspection warnings about childproxy docs@meh @thiblahute I assume this also applies to hotdoc or does it handle these differently?
```
../subprojects/gstreamer/gst/gstchildproxy.h:57: Error: Gst: identifier not found on the first line:
* #GstChildProxyInterface::get_child_...@meh @thiblahute I assume this also applies to hotdoc or does it handle these differently?
```
../subprojects/gstreamer/gst/gstchildproxy.h:57: Error: Gst: identifier not found on the first line:
* #GstChildProxyInterface::get_child_by_name:
^
../subprojects/gstreamer/gst/gstchildproxy.h:68: Error: Gst: identifier not found on the first line:
* #GstChildProxyInterface::get_child_by_index:
^
../subprojects/gstreamer/gst/gstchildproxy.h:79: Error: Gst: identifier not found on the first line:
* #GstChildProxyInterface::get_children_count:
^
../subprojects/gstreamer/gst/gstchildproxy.h:92: Error: Gst: identifier not found on the first line:
* #GstChildProxyInterface::child_added:
^
../subprojects/gstreamer/gst/gstchildproxy.h:102: Error: Gst: identifier not found on the first line:
* #GstChildProxyInterface::child_removed:
```https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/92Stack overflow in gst_ffmpeg_channel_layout_to_gst2021-06-02T22:22:25ZNatalie SilvanovichStack overflow in gst_ffmpeg_channel_layout_to_gstThe attached file causes a stack buffer overflow in gst_ffmpeg_channel_layout_to_gst when processed with streamer, as the function can be called with nchannels larger than the channel buffer. Due to the limited values that can be written...The attached file causes a stack buffer overflow in gst_ffmpeg_channel_layout_to_gst when processed with streamer, as the function can be called with nchannels larger than the channel buffer. Due to the limited values that can be written to the stack, I think this is probably not exploitable, but filing a confidential bug just in case.
![stack](/uploads/ea6d91b6d4b264bf4ee392e1fd9b2962/stack.mp4)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/876Out-of-bounds read in tag parsing2021-06-02T22:20:48ZNatalie SilvanovichOut-of-bounds read in tag parsingThe attached file causes an out-of-bounds read when played with gstreamer. This bug probably doesn't have serious security consequences, but filing it as a confidential issue just in case. A stack trace is below.
```
==3263091==ERROR: A...The attached file causes an out-of-bounds read when played with gstreamer. This bug probably doesn't have serious security consequences, but filing it as a confidential issue just in case. A stack trace is below.
```
==3263091==ERROR: AddressSanitizer: SEGV on unknown address 0x629000080000 (pc 0x7f51cfd1918c bp 0x7f51c6e338cc sp 0x7f51c6e33860 T6)
==3263091==The signal is caused by a READ memory access.
#0 0x7f51cfd1918c in id3v2_ununsync_data /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-base/gst-libs/gst/tag/id3v2.c:161:11
#1 0x7f51cfd1b177 in id3v2_parse_frame /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-base/gst-libs/gst/tag/id3v2frames.c:137:17
#2 0x7f51cfd19b16 in id3v2_frames_to_tag_list /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-base/gst-libs/gst/tag/id3v2.c:598:11
#3 0x7f51cfd19b16 in gst_tag_list_from_id3v2_tag /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-base/gst-libs/gst/tag/id3v2.c:261:3
#4 0x7f51c8a2a65a in gst_id3demux_parse_tag /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-good/gst/id3demux/gstid3demux.c:181:13
#5 0x7f51cfd13354 in gst_tag_demux_pull_start_tag /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-base/gst-libs/gst/tag/gsttagdemux.c:1266:17
#6 0x7f51cfd13354 in gst_tag_demux_element_find /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-base/gst-libs/gst/tag/gsttagdemux.c:1328:9
#7 0x7f51cfd14464 in gst_tag_demux_element_loop /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-base/gst-libs/gst/tag/gsttagdemux.c:1452:13
#8 0x7f51cfc5edfe in gst_task_func /usr/local/google/home/natashenka/gst-build/build/../subprojects/gstreamer/gst/gsttask.c:384:5
#9 0x7f51cd19b973 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7b973)
#10 0x7f51cd19b08c (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7b08c)
#11 0x7f51cd07fea6 in start_thread nptl/pthread_create.c:477:8
#12 0x7f51ccdbbdee in clone misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-base/gst-libs/gst/tag/id3v2.c:161:11 in id3v2_ununsync_data
Thread T6 (id3demux0:sink) created by T4 (typefind:sink) here:
#0 0x4c0e0a in pthread_create (/usr/local/google/home/natashenka/Downloads/video/video+0x4c0e0a)
#1 0x7f51cd1c2fc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0xa2fc0)
Thread T4 (typefind:sink) created by T0 here:
#0 0x4c0e0a in pthread_create (/usr/local/google/home/natashenka/Downloads/video/video+0x4c0e0a)
#1 0x7f51cd1c2fc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0xa2fc0)
```
![seg](/uploads/086d01c9b66ffe1b9f1cd542708d184a/seg.mp3)Tim-Philipp Müllertim@centricular.comTim-Philipp Müllertim@centricular.comhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/858matroskademux: use-after-free in matroska demuxing2022-11-11T09:24:35ZNatalie Silvanovichmatroskademux: use-after-free in matroska demuxinghe attached file causes a use-after-free when it is played with gstreamer's matroska demuxer, due to a track that has already been freed being reused. To reproduce this issue, play this file with any video player that uses gstreamer, for...he attached file causes a use-after-free when it is played with gstreamer's matroska demuxer, due to a track that has already been freed being reused. To reproduce this issue, play this file with any video player that uses gstreamer, for example:
totem oob_1.mkv
A sample crash dump is as follows:
```
==3228308==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200020bc30 at pc 0x00000046f6d5 bp 0x7fffeee38a80 sp 0x7fffeee38228
READ of size 1 at 0x60200020bc30 thread T6 (matroskademux0:)
[Detaching after fork from child process 3228332]
#0 0x46f6d4 in strcmp (/usr/local/google/home/natashenka/Downloads/video/video+0x46f6d4)
#1 0x7fffee51f123 in gst_matroska_demux_update_tracks /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-good/gst/matroska/matroska-demux.c:3466:13
#2 0x7fffee51f123 in gst_matroska_demux_parse_id /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-good/gst/matroska/matroska-demux.c:5432:19
#3 0x7fffee5244e7 in gst_matroska_demux_loop /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-good/gst/matroska/matroska-demux.c:5761:9
#4 0x7ffff7c6edfe in gst_task_func /usr/local/google/home/natashenka/gst-build/build/../subprojects/gstreamer/gst/gsttask.c:384:5
#5 0x7ffff51ab973 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7b973)
#6 0x7ffff51ab08c (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7b08c)
#7 0x7ffff508fea6 in start_thread nptl/pthread_create.c:477:8
#8 0x7ffff4dcbdee in clone misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95
0x60200020bc30 is located 0 bytes inside of 9-byte region [0x60200020bc30,0x60200020bc39)
freed by thread T6 (matroskademux0:) here:
#0 0x4d5fbd in free (/usr/local/google/home/natashenka/Downloads/video/video+0x4d5fbd)
#1 0x7fffee52da2f in gst_matroska_track_free /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-good/gst/matroska/matroska-ids.c:336:3
previously allocated by thread T6 (matroskademux0:) here:
#0 0x4d623d in malloc (/usr/local/google/home/natashenka/Downloads/video/video+0x4d623d)
#1 0x7ffff5187d18 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57d18)
Thread T6 (matroskademux0:) created by T4 (typefind:sink) here:
#0 0x4c0e0a in pthread_create (/usr/local/google/home/natashenka/Downloads/video/video+0x4c0e0a)
#1 0x7ffff51d2fc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0xa2fc0)
Thread T4 (typefind:sink) created by T0 here:
#0 0x4c0e0a in pthread_create (/usr/local/google/home/natashenka/Downloads/video/video+0x4c0e0a)
#1 0x7ffff51d2fc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0xa2fc0)
SUMMARY: AddressSanitizer: heap-use-after-free (/usr/local/google/home/natashenka/Downloads/video/video+0x46f6d4) in strcmp
Shadow bytes around the buggy address:
0x0c0480039730: fa fa fd fd fa fa fd fa fa fa fd fa fa fa fd fd
0x0c0480039740: fa fa fd fd fa fa fd fa fa fa fd fd fa fa fd fd
0x0c0480039750: fa fa fd fa fa fa fd fd fa fa fd fd fa fa fd fa
0x0c0480039760: fa fa fd fa fa fa fd fd fa fa fd fd fa fa fd fd
0x0c0480039770: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fd
=>0x0c0480039780: fa fa fd fd fa fa[fd]fd fa fa fd fa fa fa 00 00
0x0c0480039790: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x0c04800397a0: fa fa fd fa fa fa 00 fa fa fa fd fd fa fa fd fd
0x0c04800397b0: fa fa 00 01 fa fa 00 01 fa fa 03 fa fa fa fd fa
0x0c04800397c0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x0c04800397d0: fa fa fd fa fa fa fd fa fa fa fd fd fa fa fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==3228308==ABORTING
```
This bug is subject to a 90 day disclosure deadline. After 90 days elapse,
the bug report will become visible to the public. The scheduled disclosure
date is 2021-May-31. Disclosure at an earlier date is possible if
agreed upon by all parties.[oob_1.mkv](/uploads/de2841ff5b27a5091f8bfc075e0b4eaa/oob_1.mkv)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/857rtspsrc: PAUSE reply is sometimes considered as a reply to the subsequent TEA...2021-09-24T13:34:23ZMarc Leemanrtspsrc: PAUSE reply is sometimes considered as a reply to the subsequent TEARDOWNThere seems to be a race condition where the reply to the TEARDOWN that is sent after that. Also, printing the CSeq field in the messages at level TRACE would help debugging....
```
^Chandling interrupt.
Interrupt: Stopping pipeline ......There seems to be a race condition where the reply to the TEARDOWN that is sent after that. Also, printing the CSeq field in the messages at level TRACE would help debugging....
```
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:03.644101094
Setting pipeline to NULL ...
0:00:03.856278865 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:6071:gst_rtspsrc_loop_send_cmd:<rtspsrc0> sending cmd WAIT
0:00:03.856290885 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:6096:gst_rtspsrc_loop_send_cmd:<rtspsrc0> cancel previous request LOOP
0:00:03.856298877 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:6104:gst_rtspsrc_loop_send_cmd:<rtspsrc0> connection flush busy LOOP
0:00:03.856306758 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:5227:gst_rtspsrc_connection_flush:<rtspsrc0> set flushing 1
0:00:03.856313838 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:5230:gst_rtspsrc_connection_flush:<rtspsrc0> connection flush
0:00:03.856389220 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:5811:gst_rtspsrc_loop_udp:<rtspsrc0> got interrupted
0:00:03.856403087 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:6169:gst_rtspsrc_loop:<rtspsrc0> pausing task, reason flushing
0:00:03.856409040 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:6071:gst_rtspsrc_loop_send_cmd:<rtspsrc0> sending cmd WAIT
0:00:03.856414152 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:6104:gst_rtspsrc_loop_send_cmd:<rtspsrc0> connection flush busy LOOP
0:00:03.856419079 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:5227:gst_rtspsrc_connection_flush:<rtspsrc0> set flushing 1
0:00:03.856487204 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:6071:gst_rtspsrc_loop_send_cmd:<rtspsrc0> sending cmd PAUSE
0:00:03.856501474 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:6109:gst_rtspsrc_loop_send_cmd:<rtspsrc0> not interrupting busy cmd WAIT
0:00:03.856553487 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:9062:gst_rtspsrc_thread:<rtspsrc0> got command PAUSE
0:00:03.856566689 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:5227:gst_rtspsrc_connection_flush:<rtspsrc0> set flushing 0
0:00:03.856572367 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:5230:gst_rtspsrc_connection_flush:<rtspsrc0> connection flush
0:00:03.856583195 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:8837:gst_rtspsrc_pause:<rtspsrc0> PAUSE...
0:00:03.856601088 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:530:default_before_send:<rtspsrc0> default handler
0:00:03.856607421 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:530:default_before_send:<rtspsrc0> default handler
0:00:03.856613644 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:6500:gst_rtspsrc_try_send:<rtspsrc0> sending message
0:00:03.856619349 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9709:gst_rtspsrc_print_rtsp_message:<rtspsrc0> --------------------------------------------
0:00:03.856625222 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9712:gst_rtspsrc_print_rtsp_message:<rtspsrc0> RTSP request message 0x7f4aec07cc10
0:00:03.856629642 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9713:gst_rtspsrc_print_rtsp_message:<rtspsrc0> request line:
0:00:03.856635086 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9715:gst_rtspsrc_print_rtsp_message:<rtspsrc0> method: 'PAUSE'
0:00:03.856640097 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9716:gst_rtspsrc_print_rtsp_message:<rtspsrc0> uri: 'rtsp://garage.fritz.box/'
0:00:03.856644996 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9718:gst_rtspsrc_print_rtsp_message:<rtspsrc0> version: '1.0'
0:00:03.856650593 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9719:gst_rtspsrc_print_rtsp_message:<rtspsrc0> headers:
0:00:03.856643234 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:6071:gst_rtspsrc_loop_send_cmd:<rtspsrc0> sending cmd CLOSE
0:00:03.856660118 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9693:dump_key_value:<rtspsrc0> key: 'User-Agent', value: 'GStreamer/1.18.3'
0:00:03.856668032 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:6096:gst_rtspsrc_loop_send_cmd:<rtspsrc0> cancel previous request LOOP
0:00:03.856679435 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:6104:gst_rtspsrc_loop_send_cmd:<rtspsrc0> connection flush busy PAUSE
0:00:03.856671324 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9721:gst_rtspsrc_print_rtsp_message:<rtspsrc0> body:
0:00:03.856699967 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9801:gst_rtspsrc_print_rtsp_message:<rtspsrc0> --------------------------------------------
0:00:03.856689563 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:5227:gst_rtspsrc_connection_flush:<rtspsrc0> set flushing 1
0:00:03.856718069 1719898 0x55e2784cced0 DEBUG rtspsrc gstrtspsrc.c:5230:gst_rtspsrc_connection_flush:<rtspsrc0> connection flush
0:00:03.856757871 1719898 0x55e278591400 WARN rtspsrc gstrtspsrc.c:6455:gst_rtsp_src_receive_response:<rtspsrc0> receive interrupted
0:00:03.856765090 1719898 0x55e278591400 WARN rtspsrc gstrtspsrc.c:6553:gst_rtspsrc_try_send:<rtspsrc0> receive interrupted
0:00:03.856770985 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:6656:gst_rtspsrc_send:<rtspsrc0> got error -3
0:00:03.856776496 1719898 0x55e278591400 WARN rtspsrc gstrtspsrc.c:8950:gst_rtspsrc_pause:<rtspsrc0> PAUSE interrupted
0:00:03.856813329 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:9062:gst_rtspsrc_thread:<rtspsrc0> got command CLOSE
0:00:03.856820049 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:5227:gst_rtspsrc_connection_flush:<rtspsrc0> set flushing 0
0:00:03.856824692 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:5230:gst_rtspsrc_connection_flush:<rtspsrc0> connection flush
0:00:03.856834951 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:8157:gst_rtspsrc_close:<rtspsrc0> TEARDOWN...
0:00:03.858738243 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:8199:gst_rtspsrc_close:<rtspsrc0> Teardown on rtsp://garage.fritz.box/
0:00:03.858764413 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:530:default_before_send:<rtspsrc0> default handler
0:00:03.858770738 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:530:default_before_send:<rtspsrc0> default handler
0:00:03.858775952 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:6500:gst_rtspsrc_try_send:<rtspsrc0> sending message
0:00:03.858781040 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9709:gst_rtspsrc_print_rtsp_message:<rtspsrc0> --------------------------------------------
0:00:03.858786794 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9712:gst_rtspsrc_print_rtsp_message:<rtspsrc0> RTSP request message 0x7f4aec07cc10
0:00:03.858791107 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9713:gst_rtspsrc_print_rtsp_message:<rtspsrc0> request line:
0:00:03.858796019 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9715:gst_rtspsrc_print_rtsp_message:<rtspsrc0> method: 'TEARDOWN'
0:00:03.858800587 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9716:gst_rtspsrc_print_rtsp_message:<rtspsrc0> uri: 'rtsp://garage.fritz.box/'
0:00:03.858805297 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9718:gst_rtspsrc_print_rtsp_message:<rtspsrc0> version: '1.0'
0:00:03.858809267 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9719:gst_rtspsrc_print_rtsp_message:<rtspsrc0> headers:
0:00:03.858814761 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9693:dump_key_value:<rtspsrc0> key: 'User-Agent', value: 'GStreamer/1.18.3'
0:00:03.858818921 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9721:gst_rtspsrc_print_rtsp_message:<rtspsrc0> body:
0:00:03.858823403 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9801:gst_rtspsrc_print_rtsp_message:<rtspsrc0> --------------------------------------------
0:00:03.859368744 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9709:gst_rtspsrc_print_rtsp_message:<rtspsrc0> --------------------------------------------
0:00:03.859379127 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9731:gst_rtspsrc_print_rtsp_message:<rtspsrc0> RTSP response message 0x7f4aec07cc70
0:00:03.859382634 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9732:gst_rtspsrc_print_rtsp_message:<rtspsrc0> status line:
0:00:03.859386218 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9733:gst_rtspsrc_print_rtsp_message:<rtspsrc0> code: '551'
0:00:03.859389753 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9734:gst_rtspsrc_print_rtsp_message:<rtspsrc0> reason: 'Option not supported'
0:00:03.859393468 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9736:gst_rtspsrc_print_rtsp_message:<rtspsrc0> version: '1.0
0:00:03.859396630 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9737:gst_rtspsrc_print_rtsp_message:<rtspsrc0> headers:
0:00:03.859400971 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9693:dump_key_value:<rtspsrc0> key: 'CSeq', value: '6'
0:00:03.859404870 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9693:dump_key_value:<rtspsrc0> key: 'Session', value: '487329988'
0:00:03.859408953 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9693:dump_key_value:<rtspsrc0> key: 'Date', value: 'Tue, Mar 02 2021 20:57:48 GMT'
0:00:03.859414871 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9740:gst_rtspsrc_print_rtsp_message:<rtspsrc0> body: length 0
0:00:03.859419251 1719898 0x55e278591400 LOG rtspsrc gstrtspsrc.c:9801:gst_rtspsrc_print_rtsp_message:<rtspsrc0> --------------------------------------------
0:00:03.859423272 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:6402:gst_rtsp_src_receive_response:<rtspsrc0> received response message
0:00:03.859428372 1719898 0x55e278591400 DEBUG rtspsrc gstrtspsrc.c:6421:gst_rtsp_src_receive_response:<rtspsrc0> got response message 551
0:00:03.859435944 1719898 0x55e278591400 WARN rtspsrc gstrtspsrc.c:6715:gst_rtspsrc_send:<rtspsrc0> error: Unhandled error
0:00:03.859440818 1719898 0x55e278591400 WARN rtspsrc gstrtspsrc.c:6715:gst_rtspsrc_send:<rtspsrc0> error: Option not supported (551)
```https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/issues/6libffi does not honor includedir2021-03-03T18:57:09ZTim Fleschenberglibffi does not honor includedirHi,
I am currently in the process of building glib and discovered that libffi as a subproject does not honor the includedir and always places the header files in an include directory directly below prefix. However, the includedir path i...Hi,
I am currently in the process of building glib and discovered that libffi as a subproject does not honor the includedir and always places the header files in an include directory directly below prefix. However, the includedir path information in the libffi pkgconfig file is correctly pointing to the specified includedir.
This behavior should be corrected with this patch: [patchfile.patch](/uploads/9e5d0c7408989deca426e57c92ce2620/patchfile.patch)
However, I am new to using meson and have no idea whether this patch breaks something in other projects or if there is a superordinate prefix specifically for subprojects that should be used.https://gitlab.freedesktop.org/gstreamer/www/-/issues/32Issue with page "Bindings for Qt": qmlglsink has been moved to gst-plugins-good2021-03-02T10:34:14ZAlexanderIssue with page "Bindings for Qt": qmlglsink has been moved to gst-plugins-goodPage https://gstreamer.freedesktop.org/bindings/qt.html says "For integration with the Qt toolkit there is the qmlglsink element in gst-plugins-bad (soon to be moved to gst-plugins-base or -good) which is a video sink that renders to a Q...Page https://gstreamer.freedesktop.org/bindings/qt.html says "For integration with the Qt toolkit there is the qmlglsink element in gst-plugins-bad (soon to be moved to gst-plugins-base or -good) which is a video sink that renders to a QQuickItem in a QML application."
But it appears to have already been moved to https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/tree/master/ext/qthttps://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/87GStreamer 1.18.4 release tracker2021-03-16T14:37:22ZTim-Philipp Müllertim@centricular.comGStreamer 1.18.4 release tracker# Milestone 1.18.4
- [Milestone 1.18.4 Overview](https://gitlab.freedesktop.org/groups/gstreamer/-/milestones/34)
# Todo
- [x] [Merge Requests with `Needs backport` label](https://gitlab.freedesktop.org/groups/gstreamer/-/merge_reques...# Milestone 1.18.4
- [Milestone 1.18.4 Overview](https://gitlab.freedesktop.org/groups/gstreamer/-/milestones/34)
# Todo
- [x] [Merge Requests with `Needs backport` label](https://gitlab.freedesktop.org/groups/gstreamer/-/merge_requests?scope=all&utf8=%E2%9C%93&state=all&label_name[]=Needs%20backport)
- [x] [Issues with `Needs backport` label](https://gitlab.freedesktop.org/groups/gstreamer/-/issues?scope=all&utf8=%E2%9C%93&state=all&label_name[]=Needs%20backport)
- [x] [Merge Requests with `Maybe backport` label](https://gitlab.freedesktop.org/groups/gstreamer/-/merge_requests?scope=all&utf8=%E2%9C%93&state=all&label_name[]=Maybe%20backport)
- [x] [Merge Requests with `1.18.4` milestone](https://gitlab.freedesktop.org/groups/gstreamer/-/merge_requests?milestone_title=1.18.4)
- [x] [Issues with `1.18.4` milestone](https://gitlab.freedesktop.org/groups/gstreamer/-/issues?milestone_title=1.18.4)
- [x] [Ensure all Merge Requests on the 1.18 branch have a milestone set or are labelled as `No milestone`](https://gitlab.freedesktop.org/groups/gstreamer/-/merge_requests?scope=all&utf8=%E2%9C%93&state=all&target_branch=1.18&milestone_title=None¬[label_name][]=No%20milestone)
- [x] [Issues with `Security` label](https://gitlab.freedesktop.org/groups/gstreamer/-/issues?scope=all&utf8=%E2%9C%93&state=all&label_name[]=Security)
For bonus points:
- [x] [Issues with `next-stable` milestone](https://gitlab.freedesktop.org/groups/gstreamer/-/issues?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=next-stable)
- [x] [Merge Requests with `next-stable` milestone](https://gitlab.freedesktop.org/groups/gstreamer/-/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=next-stable)
- [x] check that there are no closed issues / merged MRs with %"next-stable" milestone
# Prep
- [x] www: add release note entry and add contributors
- [ ] ~~update translations (to make sure we don't forget during release)~~
# Modules
- [x] git commit, tag, upload tarball for each of:
- gstreamer
- gst-plugins-base
- gst-plugins-good
- gst-plugins-ugly
- gst-plugins-bad
- gst-libav
- gst-rtsp-server
- gst-editing-services
- gst-devtools
- gst-python
- gstreamer-vaapi
- gst-omx
- gstreamer-sharp
- [x] GPG sign source tarballs: `for i in */*1.18.4.tar.xz; do gpg --armor --detach-sign $i; done`
# Cerbero
- [x] build 1.18.4 tag - https://gitlab.freedesktop.org/gstreamer/cerbero/-/merge_requests/687
- [x] binaries
- [x] Windows x86 MinGW (@nirbheek)
- [x] Windows x86_64 MinGW (@nirbheek)
- [x] Windows x86 MSVC (@nirbheek)
- [x] Windows x86_64 MSVC (@nirbheek)
- [x] Windows UWP release-crt (@nirbheek)
- [x] Windows UWP debug-crt (@nirbheek)
- [x] Android (@thaytan)
- [x] macOS (@ystreet)
- [x] iOS (@ystreet)
- [x] source bundle (@thaytan)
- [x] check for sha265sums for binaries
- [x] check for GPG signatures for binaries
- [x] tag cerbero (@tpm)
- [x] build 1.18 branch again - https://gitlab.freedesktop.org/gstreamer/cerbero/-/merge_requests/688
- [x] update download section on website
- [x] announce binaries (twitter, gstreamer-devel)
# gst-build
- [x] bump gst-integration-testsuites version
- [x] build 1.18.4 tag - https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/233/
- [x] tag gst-build
- [x] build 1.18 branch again - https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/234
# Announce
- [x] Mailing lists
- [x] Website: news item
- [x] Website: release notes
- [x] Twitter
- [ ] ~~Upload tarballs to GNOME FTP~~
- [x] IRC channel topic1.18.4Tim-Philipp Müllertim@centricular.comTim-Philipp Müllertim@centricular.comhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/875HDR10 CLL metadata is allowed to change2022-06-20T13:13:59ZValZapodHDR10 CLL metadata is allowed to changeContrary to popular belief HDR10 static metadata can change per segment on seamless branching Blu-rays (ripping of which was also very broken due to wrong TrueHD duplicated frames deletion on segment border) and it is also allowed to cha...Contrary to popular belief HDR10 static metadata can change per segment on seamless branching Blu-rays (ripping of which was also very broken due to wrong TrueHD duplicated frames deletion on segment border) and it is also allowed to change in mp4. As ffmpeg mail says (right now [last HDR metadata patches](https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=3373) are being accepted):
https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg108319.html
> in that some formats allow use to set it on frame,
> some on the stream, some on the container
> I notice that color data can be set per frame and per stream already
> and I don’t fully understand how these interact if converting between data in
> frame (e.g HEVC SEI in stream in hev1) or data in header (e.g. MOV mdcv tag or
> HEVC SEI in hvc1 format).
And this is correct. Free CTA-861-G (and now -H) standard mandate that and I quote:
> If the Source supports the transmission of the Dynamic Range and Mastering InfoFrame and if it
> determines that the Sink is capable of receiving that information, the Source shall send the Dynamic
> Range and Mastering InfoFrame **once per Video Field**
What that means is that it is allowed to change and display should be fast enough to change it on the fly.
In fact there is a sample from "In the Heart of the Sea" movie https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/uploads/16c628c535865d7282a48317064345a2/out.mp4 that utilizes that.
It can cause all kind of issues for you. mpv does support it and so does MadVR.https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/316Bootstrap fails on Windows if PERL5LIB contains space2021-03-01T20:58:34ZAaron ClausonBootstrap fails on Windows if PERL5LIB contains spaceAttempting a fresh install of `cerbero` on Windows 10.
`python ./cerbero-uninstalled bootstrap`
Fails with the error below. My guess is that the cause is an existing PERL5LIB environment variable with a space in the path. Removing the ...Attempting a fresh install of `cerbero` on Windows 10.
`python ./cerbero-uninstalled bootstrap`
Fails with the error below. My guess is that the cause is an existing PERL5LIB environment variable with a space in the path. Removing the variable allowed the command to progress.
````
c:\Dev\github\cerbero>python ./cerbero-uninstalled bootstrap
WARNING: Perl not found, you may need to run bootstrap.
Traceback (most recent call last):
File "./cerbero-uninstalled", line 100, in <module>
main()
File "c:\Dev\github\cerbero\cerbero\main.py", line 183, in main
Main(sys.argv[1:])
File "c:\Dev\github\cerbero\cerbero\main.py", line 51, in __init__
self.load_config()
File "c:\Dev\github\cerbero\cerbero\main.py", line 143, in load_config
self.config.load(self.args.config, self.args.variants)
File "c:\Dev\github\cerbero\cerbero\config.py", line 264, in load
self._create_build_tools_config()
File "c:\Dev\github\cerbero\cerbero\config.py", line 664, in _create_build_tools_config
self.build_tools_config.load()
File "c:\Dev\github\cerbero\cerbero\config.py", line 293, in load
self.do_setup_env()
File "c:\Dev\github\cerbero\cerbero\config.py", line 321, in do_setup_env
self.env = self.get_env(self.prefix, libdir, self.py_prefix)
File "c:\Dev\github\cerbero\cerbero\config.py", line 504, in get_env
new_env = self._merge_env(self.config_env, env, override_env=('LDFLAGS', 'PATH'))
File "c:\Dev\github\cerbero\cerbero\config.py", line 361, in _merge_env
"variable '%s' with values '%s' and '%s'" % (k, new_v, old_v))
cerbero.errors.FatalError: Fatal Error: Don't know how to combine the environment variable 'PERL5LIB' with values '/c/Dev/github/cerbero/build/build-tools/lib/perl5:/c/Dev/github/cerbero/build/build-tools/lib/perl5/site_perl/0.0' and 'C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\lib'
````https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/856directsound: AC3/DTS passthrough does not work2023-10-24T10:24:18ZMilenko Mitrovicdirectsound: AC3/DTS passthrough does not workThere are a couple of issues in directsoundsink when trying to passthrough AC3/DTS.
I am not sure whether there is a bug in gst_audio_iec61937_payload itself or the G_BYTE_ORDER parameter added to the gst_audio_iec61937_payload call is ...There are a couple of issues in directsoundsink when trying to passthrough AC3/DTS.
I am not sure whether there is a bug in gst_audio_iec61937_payload itself or the G_BYTE_ORDER parameter added to the gst_audio_iec61937_payload call is wrong. I haven't really looked into it but changing G_BYTE_ORDER to G_BIG_ENDIAN fixed one part of it.
I am also not sure what gst_buffer_copy_into was supposed to do. IMO it was supposed to copy metadata and not copy the buffer and therefore override what has been created by the gst_audio_iec61937_payload call.
The _swab call swapped infobuf.size amount of data ignoring that the gst_audio_iec61937_payload call actually added a header to it. Maybe after the byte order was added as parameter to gst_audio_iec61937_payload this _swab call is not necessary anymore but IMO this could never have worked.
Attached is a patch that fixes the passthrough for me.
[0001-directsound-Fixed-AC3-DTS-passthrough.patch](/uploads/982d3896bbd5d5fb949baa96aa21b015/0001-directsound-Fixed-AC3-DTS-passthrough.patch)