GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-04-23T07:38:07Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/342gl: Propagation of GL display/context not working correctly if using GL eleme...2023-04-23T07:38:07Zmarcbullgl: Propagation of GL display/context not working correctly if using GL elements outside and inside playsinkThe following pipeline does not work with 1.22 / git main (and deadlocks for other reasons with 1.20):
```shell
$ gst-launch-1.0 videotestsrc ! glvideomixer ! sink.video_sink playsink name=sink video-sink="glimagesink"
```
What happe...The following pipeline does not work with 1.22 / git main (and deadlocks for other reasons with 1.20):
```shell
$ gst-launch-1.0 videotestsrc ! glvideomixer ! sink.video_sink playsink name=sink video-sink="glimagesink"
```
What happens here is that outside and inside playsink a different GL display and context are used, and both contexts are not sharing with each other.
This then causes no window to show up, rendering to fail and for each frame errors as follows to be printed
```
0:00:00.103075402 3920565 0x7f0664002180 ERROR gldebug gstgldebug.c:306:_gst_gl_debug_callback:<glcontextegl1> high: GL error from API id:2, GL_INVALID_FRAMEBUFFER_OPERATION in glClear(incomplete framebuffer)
0:00:00.103086683 3920565 0x7f0664002180 ERROR gldebug gstgldebug.c:306:_gst_gl_debug_callback:<glcontextegl1> high: GL error from API id:2, GL_INVALID_FRAMEBUFFER_OPERATION in glDrawElements
0:00:00.136571386 3920565 0x7f0664002180 ERROR gldebug gstgldebug.c:306:_gst_gl_debug_callback:<glcontextegl1> high: GL error from API id:2, GL_INVALID_FRAMEBUFFER_OPERATION in glClear(incomplete framebuffer)
0:00:00.136615900 3920565 0x7f0664002180 ERROR gldebug gstgldebug.c:306:_gst_gl_debug_callback:<glcontextegl1> high: GL error from API id:2, GL_INVALID_FRAMEBUFFER_OPERATION in glDrawElements
0:00:00.169940583 3920565 0x7f0664002180 ERROR gldebug gstgldebug.c:306:_gst_gl_debug_callback:<glcontextegl1> high: GL error from API id:2, GL_INVALID_FRAMEBUFFER_OPERATION in glClear(incomplete framebuffer)
```
Original issue description below
----
I have a problem with the gtk4paintablesink and OpenGL playback, when using a video-stream-combiner with gst_play. I used a modified Glide to produce this problem. You can find it here: https://github.com/marcbull/glide/tree/video-compositor
The repository contains two Dot files of the pipeline and logs for both cases.
Without a video-stream-combiner property set, the gtk4paintablesink shows the expected video frames. If I assign a glvideomixer to the video-stream-combiner property, the view stays black, but you can hear audio playback.
I experienced this on Linux and on macOS.
Glide was started like this:
```
GST_DEBUG_DUMP_DOT_DIR=/tmp/gst GST_DEBUG="gtk4paintablesink:7" cargo r -- -i -c SampleVideo_1280x720_1mb.mp4 &| tee /tmp/glide.log
```
I added an command line argument to enable the use of the glvideomixer:
```
-c, --compositor Use glvideomixer as video-stream-combiner in the pipeline
```
The issue also occurs with the playbin3 element. It can be enabled with the following command line argument:
```
-p, --playbin3 Use playbin3 instead of playbin2
```
Is this a problem in the gtk4paintablesink or another component?
Thanks for your help.https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/115insstalling/on-linux fedora instructions incorrect2023-04-15T14:36:12ZJeroen Stoutinsstalling/on-linux fedora instructions incorrect`dnf install gstreamer1-devel gstreamer1-plugins-base-tools gstreamer1-doc gstreamer1-plugins-base-devel gstreamer1-plugins-good gstreamer1-plugins-good-extras gstreamer1-plugins-ugly gstreamer1-plugins-bad-free gstreamer1-plugins-bad-fr...`dnf install gstreamer1-devel gstreamer1-plugins-base-tools gstreamer1-doc gstreamer1-plugins-base-devel gstreamer1-plugins-good gstreamer1-plugins-good-extras gstreamer1-plugins-ugly gstreamer1-plugins-bad-free gstreamer1-plugins-bad-free-devel gstreamer1-plugins-bad-free-extras`
Should be
`dnf install gstreamer1-devel gstreamer1-plugins-base-tools gstreamer1-doc gstreamer1-plugins-base-devel gstreamer1-plugins-good gstreamer1-plugins-good-extras gstreamer1-plugins-ugly-free gstreamer1-plugins-bad-free gstreamer1-plugins-bad-free-devel gstreamer1-plugins-bad-free-extras`
"gstreamer1-plugins-ugly" is now "gstreamer1-plugins-ugly-free", gstreamer1-plugins-ugly could not be found.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/1011gstrtpst2022-1-fecenc with appsink resulting not-linked errors2023-04-17T15:51:41Zyamen saraijigstrtpst2022-1-fecenc with appsink resulting not-linked errorsI am attempting to use FEC encoding to stream some data over the network, however whenever I use appsrc to feed the data to the pipeline, I get errors related to FEC not-linked, and no data would appear on the FEC sinks `rtp.send_fec_src...I am attempting to use FEC encoding to stream some data over the network, however whenever I use appsrc to feed the data to the pipeline, I get errors related to FEC not-linked, and no data would appear on the FEC sinks `rtp.send_fec_src_0_0` & `rtp.send_fec_src_0_1`. However, the x264 encoder is outputing data into sink `rtp.send_rtp_src_0`.
Is it an issue in the caps, or appsrc is incompatible with FEC encoding?
An example of the used pipeline:
```
rtpbin name=rtp do-retransmission=true do-lost=true fec-encoders="fec,0=\"rtpst2022-1-fecenc\ rows=5\ columns=5\";"
appsrc format=3 is-live=true name=vs0 ! capsfilter name=vs0_caps caps=video/x-raw,width=1280,height=720,format=I420,pixel-aspect-ratio=1/1,framerate=30/1,interlace-mode=progressive ! videoconvert ! queue ! x264enc name=vs0_enc sliced-threads=true bitrate=1000 key-int-max=10 pass=0 speed-preset=superfast tune=zerolatency ! video/x-h264,profile=constrained-baseline ! rtph264pay mtu=1200 config-interval=1 ssrc=0 ! application/x-rtp,payload=103 ! rtprtxqueue ! rtp.send_rtp_sink_0
rtp.send_rtp_src_0 ! udpsink name=rtp_vs0 host=127.0.0.1 port=3300
rtp.send_fec_src_0_0 ! udpsink name=rtcp_fec0_vs0 host=127.0.0.1 port=3303 async=false
rtp.send_fec_src_0_1 ! udpsink name=rtcp_fec1_vs0 host=127.0.0.1 port=3304 async=false
```
Resulting error log:
```rtpst2022-1-fecenc gstrtpst2022-1-fecenc.c:363:queue_fec_packet:<rtpst_2022_1_fecenc0:fec_1>�[00m Failed to push row FEC packet: not-linked
rtpst2022-1-fecenc gstrtpst2022-1-fecenc.c:363:queue_fec_packet:<rtpst_2022_1_fecenc0:fec_1>�[00m Failed to push row FEC packet: not-linked
rtpst2022-1-fecenc gstrtpst2022-1-fecenc.c:363:queue_fec_packet:<rtpst_2022_1_fecenc0:fec_1>�[00m Failed to push row FEC packet: not-linked
rtpst2022-1-fecenc gstrtpst2022-1-fecenc.c:363:queue_fec_packet:<rtpst_2022_1_fecenc0:fec_1>�[00m Failed to push row FEC packet: not-linked
rtpst2022-1-fecenc gstrtpst2022-1-fecenc.c:363:queue_fec_packet:<rtpst_2022_1_fecenc0:fec_1>�[00m Failed to push row FEC packet: not-linked
rtpst2022-1-fecenc gstrtpst2022-1-fecenc.c:398:gst_2d_fec_push_item_unlocked:<rtpst_2022_1_fecenc0:fec_0>�[00m Failed to push column FEC packet: not-linked
rtpst2022-1-fecenc gstrtpst2022-1-fecenc.c:363:queue_fec_packet:<rtpst_2022_1_fecenc0:fec_1>�[00m Failed to push row FEC packet: not-linked
rtpst2022-1-fecenc gstrtpst2022-1-fecenc.c:398:gst_2d_fec_push_item_unlocked:<rtpst_2022_1_fecenc0:fec_0>�[00m Failed to push column FEC packet: not-linked
rtpst2022-1-fecenc gstrtpst2022-1-fecenc.c:363:queue_fec_packet:<rtpst_2022_1_fecenc0:fec_1>�[00m Failed to push row FEC packet: not-linked
rtpst2022-1-fecenc gstrtpst2022-1-fecenc.c:398:gst_2d_fec_push_item_unlocked:<rtpst_2022_1_fecenc0:fec_0>�[00m Failed to push column FEC packet: not-linked
```https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/171Not able to play the audio streamed with gstreamer (OPUS codec) on VLC player2023-04-18T07:49:58Zanonymous_V xyzNot able to play the audio streamed with gstreamer (OPUS codec) on VLC playerI want to stream live audio with gstreamer using 'opus' codec. At the transmitter end I am using the following script:
Transmitter:
" gst-launch-1.0 autoaudiosrc ! audioconvert ! audioresample ! opusenc bitrate=48000 max-payload-size=...I want to stream live audio with gstreamer using 'opus' codec. At the transmitter end I am using the following script:
Transmitter:
" gst-launch-1.0 autoaudiosrc ! audioconvert ! audioresample ! opusenc bitrate=48000 max-payload-size=101 packet-loss-percentage=0 frame-size=20 bandwidth=fullband audio-type=generic hard-resync=false inband-fec=true complexity=10 bitrate-type=constrained-vbr ! rtpopuspay ! udpsink host=224.0.0.161 port=5001 "
Receiver: At receiver I am trying to receive the stream with VLC player using the following script:
"vlc stream.sdp"
SDP file content: stream.sdp
m=audio 5001 RTP/AVP 101
c=IN IP4 224.0.0.161
a=rtpmap:101 opus/48000/1
a=fmtp:101 maxplaybackrate=16000;
sprop-maxcapturerate=16000;
maxaveragebitrate=20000;
stereo=1;
useinbandfec=1;
usedtx=0
But when I execute the VLC script with SDP file, nothing happens. The player remains paused.
I verified the transmitter script with 'gstreamer' receiver and it works fine.
I am not getting if there is something wrong in SDP file or some configuration issue is there.
I hope I'll find some help here.
thanks.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/341webrtcsink: panic when creating data channel2023-04-14T16:02:28ZAlec Gurmanwebrtcsink: panic when creating data channelJetson Xavier NX Ubuntu 18.04.4, JP4.4, DS5.0, GStreamer 1.22.2, Cargo 1.68.2.
Getting a panic when trying to create the data channel in webrtcsink, see below, any thoughts?
`
** (python:15727): CRITICAL **: 10:14:00.957: gst_webrtc_bi...Jetson Xavier NX Ubuntu 18.04.4, JP4.4, DS5.0, GStreamer 1.22.2, Cargo 1.68.2.
Getting a panic when trying to create the data channel in webrtcsink, see below, any thoughts?
`
** (python:15727): CRITICAL **: 10:14:00.957: gst_webrtc_bin_create_data_channel: assertion 'webrtc->priv->is_closed != TRUE' failed thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: BoolError { message: "Invalid return value: expected GstWebRTCDataChannel, got GstWebRTCDataChannel", filename: "/home/aaeon/.cargo/git/checkouts/gtk-rs-core-7be42ca38bd6361c/4510666/glib/src/closure.rs", function: "<_ as glib::closure::TryFromClosureReturnValue>::try_from_closure_return_value::{{closure}}::{{closure}}", line: 384 }', net/webrtc/src/webrtcsink/imp.rs:2232:37
`https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2491gstreamer-vaapi 1.22.2: test suite is failing: failed to create vaapipostproc...2024-02-16T15:22:33ZTomasz Kłoczkogstreamer-vaapi 1.22.2: test suite is failing: failed to create vaapipostproc elementTest suite is failing in on unit
<details>
```console
+ cd gstreamer-vaapi-1.22.2
+ /usr/bin/meson test -C x86_64-redhat-linux-gnu --num-processes 48 --print-errorlogs
ninja: no work to do.
ninja: Entering directory `/home/tkloczko/rpmb...Test suite is failing in on unit
<details>
```console
+ cd gstreamer-vaapi-1.22.2
+ /usr/bin/meson test -C x86_64-redhat-linux-gnu --num-processes 48 --print-errorlogs
ninja: no work to do.
ninja: Entering directory `/home/tkloczko/rpmbuild/BUILD/gstreamer-vaapi-1.22.2/x86_64-redhat-linux-gnu'
ninja: no work to do.
1/2 elements_vaapioverlay OK 0.14s
2/2 elements_vaapipostproc FAIL 0.15s exit status 3
>>> GST_PLUGIN_SYSTEM_PATH_1_0='' CK_DEFAULT_TIMEOUT=20 MALLOC_PERTURB_=83 GST_REGISTRY=/home/tkloczko/rpmbuild/BUILD/gstreamer-vaapi-1.22.2/x86_64-redhat-linux-gnu/tests/check/elements_vaapipostproc.registry GST_PLUGIN_PATH_1_0=/home/tkloczko/rpmbuild/BUILD/gstreamer-vaapi-1.22.2/x86_64-redhat-linux-gnu:/usr/lib64/gstreamer-1.0 /home/tkloczko/rpmbuild/BUILD/gstreamer-vaapi-1.22.2/x86_64-redhat-linux-gnu/tests/check/elements_vaapipostproc
――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――
Running suite(s): vaapipostproc
0%: Checks: 3, Failures: 3, Errors: 0
../tests/check/elements/vaapipostproc.c:57:F:general:test_make:0: Failed to create vaapipostproc element
../tests/check/elements/vaapipostproc.c:79:F:general:test_crop_mouse_events:0: Failed to create vaapipostproc element
../tests/check/elements/vaapipostproc.c:79:F:general:test_orientation_mouse_events:0: Failed to create vaapipostproc element
Check suite vaapipostproc ran in 0.008s (tests failed: 3)
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
Summary of Failures:
2/2 elements_vaapipostproc FAIL 0.15s exit status 3
Ok: 1
Expected Fail: 0
Fail: 1
Unexpected Pass: 0
Skipped: 0
Timeout: 0
```
</details>https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2485rtspclientsink: MP4A-LATM vs MPEG4-GENERIC2023-04-18T07:44:07ZMaurizio Buratortspclientsink: MP4A-LATM vs MPEG4-GENERICos:windows
gstreamer 1.22.1
i use MediaMtx server https://github.com/aler9/mediamtx (Alias rtsp simple server) and when using this test pipeline:
gst-launch-1.0.exe -e videotestsrc ! mfh264enc bitrate=1024 ! video/x-h264 ! rtspclient...os:windows
gstreamer 1.22.1
i use MediaMtx server https://github.com/aler9/mediamtx (Alias rtsp simple server) and when using this test pipeline:
gst-launch-1.0.exe -e videotestsrc ! mfh264enc bitrate=1024 ! video/x-h264 ! rtspclientsink name=mux location=rtsp://192.168.1.201:8554/live audiotestsrc ! audioconvert ! audioresample ! audio/x-raw, rate=48000 ! mfaacenc bitrate=128000 ! audio/mpeg ! mux.
the hls served by mediamtx is without audio.
when streaming with ffmpeg with this test pipeline:
ffmpeg -f lavfi -i smptebars -t 30 -f lavfi -i "sine=frequency=1000:duration=50000" -ac 2 -c:v libx264 -preset ultrafast -b:v 600k -max_muxing_queue_size 1024 -c:a aac -b:a 128k -f rtsp rtsp://localhost:8554/fflive
everything works fine.
the difference is in the audio format
**gstreamer announce**
2023/04/12 16:13:01 DEB [RTSP] [conn 192.168.1.202:50101] [c->s] ANNOUNCE rtsp://192.168.1.201:8554/live RTSP/1.0
CSeq: 2
Content-Length: 628
Content-Type: application/sdp
Date: Wed, 12 Apr 2023 14:13:14 GMT
User-Agent: GStreamer/1.22.1.1
v=0
o=- 3736019951 1 IN IP4 192.168.1.202
s=Session streamed with GStreamer
i=rtspclientsink
t=0 0
a=tool:GStreamer
m=audio 0 RTP/AVP 96
c=IN IP4 0.0.0.0
**a=rtpmap:96 MP4A-LATM/48000**
a=fmtp:96 cpresent=0;config=40002310
a=control:stream=1
a=ts-refclk:local
a=mediaclk:sender
a=ssrc:3350472162 cname:user3404783220@host-19bf6e68
m=video 0 RTP/AVP 99
c=IN IP4 0.0.0.0
a=rtpmap:99 H264/90000
a=framerate:30
a=fmtp:99 packetization-mode=1;sprop-parameter-sets=Z2QAFKwrYKD9gIgAAB9AAAdTAHjhFw==,aO48sA==
a=control:stream=0
a=ts-refclk:local
a=mediaclk:sender
a=ssrc:4171762370 cname:user3404783220@host-19bf6e68
2023/04/12 16:13:03 INF [RTSP] [session 91addd57] is publishing to path 'live', with UDP, 2 tracks (Generic, H264)
2023/04/12 16:13:03 DEB [RTSP] [conn 192.168.1.202:50101] [s->c] RTSP/1.0 200 OK
**ffmpeg announce**
2023/04/13 11:43:19 DEB [RTSP] [conn [::1]:61892] [c->s] ANNOUNCE rtsp://localhost:8554/fflive RTSP/1.0
CSeq: 2
Content-Length: 494
Content-Type: application/sdp
User-Agent: Lavf59.27.100
v=0
o=- 0 0 IN IP6 ::1
s=No Name
c=IN IP6 ::1
t=0 0
a=tool:libavformat LIBAVFORMAT_VERSION
m=video 0 RTP/AVP 96
b=AS:600
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z0LAFNoFB+wEQAAAAwBAAAAMg8UKqA==,aM48gA==; profile-level-id=42C014
a=control:streamid=0
m=audio 0 RTP/AVP 97
b=AS:128
**a=rtpmap:97 MPEG4-GENERIC/44100/2**
a=fmtp:97 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3; config=121056E500
a=control:streamid=1
**the difference with gstreamer is**
**ffmpeg = a=rtpmap:97 MPEG4-GENERIC/44100/2**
**gstreamer = a=rtpmap:96 MP4A-LATM/48000**
would it be possible for gstreamer to send MPEG4-GENERIC instead of MP4A-LATM ?
and can someone explain me the differences between them?
thank youhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/340awskvswebrtcsink: Gstreamer encountered a general stream error.2023-04-17T02:34:40ZAlec Gurmanawskvswebrtcsink: Gstreamer encountered a general stream error.Jetson Xavier NX Ubuntu 18.04.4, JP4.4, DS5.0, GStreamer 1.20.6, Cargo 1.68.2.
Have custom built GStreamer 1.20.6 to attempt to use webrtcsink, currently using the default 1.14 compiled nvidia plugins (L4T, DeepStream), my pipeline con...Jetson Xavier NX Ubuntu 18.04.4, JP4.4, DS5.0, GStreamer 1.20.6, Cargo 1.68.2.
Have custom built GStreamer 1.20.6 to attempt to use webrtcsink, currently using the default 1.14 compiled nvidia plugins (L4T, DeepStream), my pipeline consists of the following:
RTSP Camera/s -> uridecodebin -> nvstreammux -> nvstreamdemux -> nvvideoconvert -> capsfilter (video/x-raw(memory:NVMM),format=I420) -> awskvswebrtcsink
The above pipeline works well with kvssink but am not getting any output from awskvswebrtcsink
Codec pipeline discovery seems to work for H264 / H265 / VP9, shortly after discovery the below logs appear (with GST_DEBUG=4):
`
0:00:06.133806050 6914 0x7f6002f6d0 INFO GST_EVENT gstevent.c:892:gst_event_new_caps: creating caps event application/x-rtcp
0:00:06.134103492 6914 0x7f6002f6d0 INFO GST_EVENT gstevent.c:973:gst_event_new_segment: creating segment event time segment start=0:00:00.000000000, offset=0:00:00.000000000, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000, duration 99:99:99.999999999
0:00:06.154375736 6914 0x7f28009950 INFO GST_ERROR_SYSTEM gstelement.c:2274:gst_element_message_full_with_details:<webrtc-sink--0> posting message: GStreamer encountered a general stream error.
0:00:06.154632730 6914 0x7f28009950 INFO GST_ERROR_SYSTEM gstelement.c:2301:gst_element_message_full_with_details:<webrtc-sink--0> posted error message: GStreamer encountered a general stream error.
`
with GST_DEBUG=1, this is the output:
`Opening in BLOCKING MODE NvMMLiteOpen : Block : BlockType = 261 NVMEDIA: Reading vendor.tegra.display-size : status: 6 NvMMLiteBlockCreate : Block : BlockType = 261 Stream format not found, dropping the frame Stream format not found, dropping the frame Stream format not found, dropping the frame Opening in BLOCKING MODE Opening in BLOCKING MODE Opening in BLOCKING MODE NvMMLiteOpen : Block : BlockType = 4 ===== NVMEDIA: NVENC ===== NvMMLiteBlockCreate : Block : BlockType = 4 Opening in BLOCKING MODE NvMMLiteOpen : Block : BlockType = 9 ===== NVMEDIA: NVENC ===== NvMMLiteBlockCreate : Block : BlockType = 9 H264: Profile = 66, Level = 0 NvMMLiteOpen : Block : BlockType = 8 ===== NVMEDIA: NVENC ===== NvMMLiteBlockCreate : Block : BlockType = 8 NVMEDIA: H265 : Profile : 1`
The webrtcsink seems to become unresponsive, is there any way to get more information about this issue?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2483multifile elements should ensure path is set2023-04-12T19:46:32ZJan Alexander Steffensmultifile elements should ensure path is setThe following discussion from !4109 should be addressed:
- [ ] @tpm started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4109#note_1804911): (+1 comment)
> > Noticed this because the `generic_...The following discussion from !4109 should be addressed:
- [ ] @tpm started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4109#note_1804911): (+1 comment)
> > Noticed this because the `generic_states` test kept segfaulting at random. GLibC 2.37 can crash when `NULL` is supplied as a format string.
>
> Where does it crash? In 495 `gchar *filename = g_strdup_printf (self->path, i);`?
>
> Feels like there should in addition be a check for NULL somewhere in the start function that throws an error if it's not set perhaps?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2482ges: ges_project build test failing with glibc 2.372023-08-15T14:28:15ZJeremy Bichages: ges_project build test failing with glibc 2.37- Ubuntu 23.04
- glib 2.76.1
- gstreamer-editing-services 1.22.1 (and 1.22.0)
The nle_tempochange build test has recently begun failing in Ubuntu 23.04. I was able to duplicate this build failure if I installed glibc 2.37 on Debian 12 (...- Ubuntu 23.04
- glib 2.76.1
- gstreamer-editing-services 1.22.1 (and 1.22.0)
The nle_tempochange build test has recently begun failing in Ubuntu 23.04. I was able to duplicate this build failure if I installed glibc 2.37 on Debian 12 (instead of 2.36).
Build log excerpt
------------------
```
=================================== 12/23 ====================================
test: ges_project
start time: 21:59:31
duration: 0.49s
result: exit status 1
command: <removed for brevity>
----------------------------------- stdout -----------------------------------
Running suite(s): ges-project
83%: Checks: 6, Failures: 1, Errors: 0
../tests/check/ges/project.c:335:F:project:test_project_add_properties:0: Assertion 'binding != tmp_binding' failed
Check suite ges ran in 0.271s (tests failed: 1)
```
Full build log
--------------
Click amd64 or arm64 at https://launchpad.net/ubuntu/+source/gstreamer-editing-services1.0/1.22.1-1
Those are the only two architectures where we fail the build for failing build tests.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2480base: libs_allocators test fails with glib 2.76.12023-06-11T14:37:51ZJeremy Bichabase: libs_allocators test fails with glib 2.76.1- Ubuntu 23.04
- glib 2.76.1
- gst-plugins-base 1.22.1
The libs_allocators build test is failing on Ubuntu 23.04. I was able to duplicate this issue on Debian 12 if I installed glib 2.76.1 there.
I suspect that this was triggered by gl...- Ubuntu 23.04
- glib 2.76.1
- gst-plugins-base 1.22.1
The libs_allocators build test is failing on Ubuntu 23.04. I was able to duplicate this issue on Debian 12 if I installed glib 2.76.1 there.
I suspect that this was triggered by glib's removal of the slice allocator which has uncovered use-after-free issues in several projects.
Build log excerpt
-----------------
```
=================================== 55/127 ===================================
test: libs_allocators
start time: 02:01:35
duration: 0.04s
result: exit status 1
command: <dropped for brevity>
----------------------------------- stdout -----------------------------------
Running suite(s): allocators
Unexpected critical/warning: g_close(fd:4) failed with EBADF. The tracking of file descriptors got messed up
Stack trace:
gst_debug_get_stack_trace (/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2201.0:0x7f58044c93af)
?? (/usr/lib/x86_64-linux-gnu/libgstcheck-1.0.so.0.2201.0:0x7f580429640f)
g_logv (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1:0x7f58043084be)
g_log (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1:0x7f580430879f)
g_close (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1:0x7f580432716c)
test_fdmem (allocators.c:98)
srunner_run_tagged (/usr/lib/x86_64-linux-gnu/libgstcheck-1.0.so.0.2201.0:0x7f580429cfdb)
gst_check_run_suite (/usr/lib/x86_64-linux-gnu/libgstcheck-1.0.so.0.2201.0:0x7f580429a1be)
main (allocators.c:117)
?? (/usr/lib/x86_64-linux-gnu/libc.so.6:0x7f58040a0a8c)
__libc_start_main (/usr/lib/x86_64-linux-gnu/libc.so.6:0x7f58040a0b45)
_start (/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tests/check/libs_allocators:0x5560e5c96531)
50%: Checks: 2, Failures: 1, Errors: 0
../libs/gst/check/gstcheck.c:286:F:general:test_fdmem:0: Unexpected critical/warning: g_close(fd:4) failed with EBADF.
The tracking of file descriptors got messed up
Check suite allocators ran in 0.003s (tests failed: 1)
```
Full build log
--------------
Click amd64 at https://launchpad.net/ubuntu/+source/gst-plugins-base1.0/1.22.1-1
We only fail the build for test failures on amd64 and arm64. Somehow the build test passes on arm64.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2479clockoverlay: how to overlay a d3d11 surface?2023-06-15T15:19:39ZMaurizio Buratoclockoverlay: how to overlay a d3d11 surface?i need to overlay date and time text on d3d11 surfaces
i tried:
gst-launch-1.0.exe -v d3d11testsrc ! video/x-raw(memory:D3D11Memory) ! clockoverlay halignment=2 valignment=1 time-format="%e %b %Y %H:%M:%S" ! nvd3d11h264enc ! h264parse ...i need to overlay date and time text on d3d11 surfaces
i tried:
gst-launch-1.0.exe -v d3d11testsrc ! video/x-raw(memory:D3D11Memory) ! clockoverlay halignment=2 valignment=1 time-format="%e %b %Y %H:%M:%S" ! nvd3d11h264enc ! h264parse ! fakesink
but i get
WARNING: erroneous pipeline: could not link clockoverlay0 to nvd3d11h264enc0
is there another method?
thankshttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/461Example: How to access child properties via GstChildProxy2023-04-11T16:11:25ZTimExample: How to access child properties via GstChildProxyI've been struggling to understand how to set child properties. Specifically I'm using the [Basler](https://github.com/basler/gst-plugin-pylon) `pylonsrc` plugin which has a `cam` property that contains a number of child properties.
```...I've been struggling to understand how to set child properties. Specifically I'm using the [Basler](https://github.com/basler/gst-plugin-pylon) `pylonsrc` plugin which has a `cam` property that contains a number of child properties.
```
GObject
+----GInitiallyUnowned
+----GstObject
+----GstElement
+----GstBaseSrc
+----GstPushSrc
+----GstPylonSrc
Implemented Interfaces:
GstChildProxy
Pad Templates:
SRC template: 'src'
Availability: Always
Capabilities:
video/x-raw
format: { (string)GRAY8, (string)RGB, (string)BGR, (string)YUY2, (string)UYVY }
width: [ 1, 2147483647 ]
height: [ 1, 2147483647 ]
framerate: [ 0/1, 2147483647/1 ]
video/x-bayer
format: { (string)rggb, (string)bggr, (string)gbgr, (string)grgb }
width: [ 1, 2147483647 ]
height: [ 1, 2147483647 ]
framerate: [ 0/1, 2147483647/1 ]
Element has no clocking capabilities.
Element has no URI handling capabilities.
Pads:
SRC: 'src'
Pad Template: 'src'
Element Properties:
blocksize : Size in bytes to read per buffer (-1 = default)
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967295 Default: 4096
cam : The camera to use.
According to the selected camera different properties will be available.
These properties can be accessed using the "cam::<property>" syntax.
The following list details the properties for each camera.
RAP-CAM-1 (40029669) Camera:
name : The name of the object
flags: readable, writable
String. Default: "(null)"
parent : The parent of the object
flags: readable, writable
(null)
GainAuto : Sets the operation mode of the gain auto function.
flags: readable, writable, changeable in NULL, READY, PAU
SED or PLAYING state
...
ReverseX : Enables horizontal flipping of the image.
flags: readable, writable, changeable in NULL, READY, PAU
SED or PLAYING state
```
I'm able to setup and run a pipeline by pre-configuring the camera, but I'm not able to set child parameters in code. This is what I was expecting to work, but doesn't.
```rust
let src = gst::ElementFactory::make("pylonsrc")
.name("source")
.property("device-serial-number", "40029669")
.build()
.expect("Could not create pylonsrc element");
println!("Has cam property: {}", src.has_property("cam", None));
println!("Has cam::ReverseX: {}", src.has_property("cam::ReverseX", None));
src.set_property("cam::ReverseX", 1);
```
This results in the following when I run it:
```
Has cam property: true
Has cam::ReverseX: false
thread 'main' panicked at 'property 'cam::ReverseX' of type 'GstPylonSrc' not found', /home/rapta/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.17.5/src/object.rs:2230:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
I've tried various other methods to try to get access, but I just don't understand the library well enough yet to get anything to work.
In Python I can do this successfully, so I know that it should be possible at least:
```python
pylonsrc = Gst.ElementFactory.make("pylonsrc", "pylonsrc"
Gst.ChildProxy.set_property(pylonsrc, 'cam::ReverseX', 1)
Gst.ChildProxy.set_property(pylonsrc, 'cam::ReverseY', 1)
```
I would greatly appreciate an example of how this can/should be done in Rust.
(Thanks so much for making Gstreamer available in Rust!)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2476hlsdemux2: raise CRITICAL when trying to load local manifest2023-04-12T07:36:48ZGuillaume Desmotteshlsdemux2: raise CRITICAL when trying to load local manifest`$ gst-play-1.0 --use-playbin3 file:///.../manifest.m3u8` raises a critical through libsoup:
```
(gst-play-1.0:48827): libsoup-CRITICAL **: 11:40:51.555: soup_message_new_from_uri: assertion 'SOUP_URI_IS_VALID (uri)' failed
0 0x00007f...`$ gst-play-1.0 --use-playbin3 file:///.../manifest.m3u8` raises a critical through libsoup:
```
(gst-play-1.0:48827): libsoup-CRITICAL **: 11:40:51.555: soup_message_new_from_uri: assertion 'SOUP_URI_IS_VALID (uri)' failed
0 0x00007ffff7ba6e71 in g_logv () at /lib64/libglib-2.0.so.0
#1 0x00007ffff7ba70f3 in g_log () at /lib64/libglib-2.0.so.0
#2 0x00007fffe9024602 in soup_message_new_from_uri () at /lib64/libsoup-3.0.so.0
#3 0x00007fffe90246b6 in soup_message_new () at /lib64/libsoup-3.0.so.0
#4 0x00007fffe927d943 in downloadhelper_submit_request (dh=0x7fffe404fe40, referer=referer@entry=0x0, flags=flags@entry=(DOWNLOAD_FLAG_COMPRESS | DOWNLOAD_FLAG_FORCE_REFRESH), request=0x7fffdc001470, err=err@entry=0x0) at ../subprojects/gst-plugins-good/ext/adaptivedemux2/downloadhelper.c:845
#5 0x00007fffe92ae1b8 in start_playlist_download (pl=pl@entry=0x7fffe40373e0, priv=priv@entry=0x7fffe4037360) at ../subprojects/gst-plugins-good/ext/adaptivedemux2/hls/gsthlsdemux-playlist-loader.c:769
#6 0x00007fffe92ae532 in gst_hls_demux_playlist_loader_update (pl=0x7fffe40373e0) at ../subprojects/gst-plugins-good/ext/adaptivedemux2/hls/gsthlsdemux-playlist-loader.c:814
#7 0x00007ffff7b9dc72 in g_idle_dispatch () at /lib64/libglib-2.0.so.0
#8 0x00007ffff7b9ec7f in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#9 0x00007ffff7bf5118 in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0
#10 0x00007ffff7b9e24f in g_main_loop_run () at /lib64/libglib-2.0.so.0
#11 0x00007fffe926f552 in _gst_adaptive_demux_loop_thread (loop=0x7fffe40552e0) at ../subprojects/gst-plugins-good/ext/adaptivedemux2/gstadaptivedemuxutils.c:204
#12 0x00007ffff7bc8982 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#13 0x00007ffff78b612d in start_thread () at /lib64/libc.so.6
#14 0x00007ffff7937bc0 in clone3 () at /lib64/libc.so.6
```
It works fine when using `playbin` and `hlsdemux`.
Is there any way `hlsdemux2` could support `file://`? If not we should probably reject the URI earlier to prevent the critical.https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/119libav: avmux + avdeinterlace destructor functions do not work2023-04-10T12:40:48ZLeo Liulibav: avmux + avdeinterlace destructor functions do not workThe destructor function of element avmux_* and avdeinterlace does not work when test using gst-launch-1.0, that is, the destructor function of element like finalize/dispose function not be called at the end phase of the application. The ...The destructor function of element avmux_* and avdeinterlace does not work when test using gst-launch-1.0, that is, the destructor function of element like finalize/dispose function not be called at the end phase of the application. The issue will cause some resource leak.
Test case:
`gst-launch-1.0 filesrc location=/home/test/xxx.264 ! h264parse ! avdec_h264 ! avdeinterlace ! x264enc ! h264parse ! avmux_mp4 ! filesink location=xxxx.mp4`
When application will go to exit, the instance of avmux_mp4 and avdeinterlace have not been released.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2472Add a new audio plugin for LC3 codec2023-04-10T12:11:54ZTaruntej KanakamallaAdd a new audio plugin for LC3 codecSpecification : https://www.bluetooth.com/specifications/specs/low-complexity-communication-codec-1-0/
The plugin shall have an encoder and decoder elements to convert the raw audio into LC3 and vice-versa respectively.Specification : https://www.bluetooth.com/specifications/specs/low-complexity-communication-codec-1-0/
The plugin shall have an encoder and decoder elements to convert the raw audio into LC3 and vice-versa respectively.https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/425android: Failed to link the library with Qt5 android project2023-06-07T09:03:24ZReza Alizadeh Majdandroid: Failed to link the library with Qt5 android projectwe built the GStreamer library including the Qt bindings with cerbero by following the [official document](https://gstreamer.freedesktop.org/documentation/installing/building-from-source-using-cerbero.html?gi-language=c#enabling-optional...we built the GStreamer library including the Qt bindings with cerbero by following the [official document](https://gstreamer.freedesktop.org/documentation/installing/building-from-source-using-cerbero.html?gi-language=c#enabling-optional-features-with-variants). and the QT5 plugin became available in the provided bundle.
now when we try to build the `libgstreamer_android.so` using the NDK, when we add the `GSTREAMER_PLUGINS_QT5` plugin to the `Android.mk` we receive a series of undefined reference linker issues about missing the Qt libraries.
```
...
/opt/Qt-android-5.15.8-lts-lgpl/include/QtCore/qstring.h:686: error: undefined reference to 'QString::toUtf8_helper(QString const&)'
/opt/Qt-android-5.15.8-lts-lgpl/include/QtCore/qvariant.h:371: error: undefined reference to 'QVariant::QVariant(int, void const*, unsigned int)'
/opt/Qt-android-5.15.8-lts-lgpl/include/QtCore/qvariant.h:371: error: undefined reference to 'QVariant::QVariant(int, void const*, unsigned int)'
/opt/Qt-android-5.15.8-lts-lgpl/include/QtCore/qbytearray.h:521: error: undefined reference to 'QByteArray::reallocData(unsigned int, QFlags<QArrayData::AllocationOption>)'
/opt/Qt-android-5.15.8-lts-lgpl/include/QtCore/qmetatype.h:1894: error: undefined reference to 'QMetaObject::normalizedType(char const*)'
/opt/Qt-android-5.15.8-lts-lgpl/include/QtCore/qmetatype.h:1866: error: undefined reference to 'QMetaType::registerNormalizedType(QByteArray const&, void (*)(void*), void* (*)(void*, void const*), int, QFlags<QMetaType::TypeFlag>, QMetaObject const*)'
...
```
it seems that the Qt libraries can't be detected while we want to link the Qt libraries to create the `libstreamer_android.so`. does any one could provide any hints about this issue?
The references we tested against:
- GStreamer version: `1.22.1`
- Qt version: `5.15.8`
- the demo Docker environment we prepared to reproduce this issue https://git.pantherx.org/franz/gstreamer-qt-dockerhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2471gstglupload dma glx opengl is rejected2024-01-16T18:54:33Zdiegonietogstglupload dma glx opengl is rejectedI went through the commit 63cf6b42033aa8f3fb0b007517a6dd02a81690a4 and I am not totally sure whether it fixes the root issue.
Correct me if I am wrong, but with X11 systems the default `GST_GL_PLATFORM=glx`, while for wayland systems wi...I went through the commit 63cf6b42033aa8f3fb0b007517a6dd02a81690a4 and I am not totally sure whether it fixes the root issue.
Correct me if I am wrong, but with X11 systems the default `GST_GL_PLATFORM=glx`, while for wayland systems will be `GST_GL_PLATFORM=egl`.
So, unless that env is explicitely set, in X11 it is not possible to run the following pipeline:
```plaintext
GST_GL_API=opengl GST_GL_PLATFORM=glx LIBVA_DRIVER_NAME=iHD gst-launch-1.0 -v filesrc location= <file.mkv> ! matroskademux ! "video/x-h264" ! vah264dec ! "video/x-raw(memory:DMABuf)" ! vapostproc ! "video/x-raw(memory:DMABuf),format=RGBA" ! glimagesink
```
The error is:
```plaintext
ERROR: del elemento /GstPipeline:pipeline0/GstMatroskaDemux:matroskademux0: Internal data stream error.
Información adicional de depuración:
../../../../home/dnieto/workspace/gstreamer/subprojects/gst-plugins-good/gst/matroska/matroska-demux.c(6095): gst_matroska_demux_loop (): /GstPipeline:pipeline0/GstMatroskaDemux:matroskademux0:
streaming stopped, reason not-linked (-1)
ERROR: el conducto no quiere prepararse.
Estableciendo el conducto a NULL …
Liberando el conducto…
```
It's not linked. Which is what you would expect since `glx` it's not supported with DMA. That now sounds ok for me. What is strange is that with the proposed MR, that avoids to reject `glx`, gstglupload finally ends up working with `_raw_data_upload_perform()` . It's like when checking DMA, it avoids to work RAW because of that check. I guess that _reject_ is correct because in the caps we are specifying DMA, right?
If I don't specify that DMA in the caps the pipeline works by raw data.
```plaintext
GST_GL_API=opengl GST_GL_PLATFORM=glx LIBVA_DRIVER_NAME=iHD gst-launch-1.0 -v filesrc location= /opt/medias/jellyfish-3-mbps-hd-h264.mkv ! matroskademux ! "video/x-h264" ! vah264dec ! "video/x-raw(memory:DMABuf)" ! vapostproc ! "video/x-raw,format=RGBA" ! glimagesink
```
On the other side I found that with NV12 format I got bad rendering, while with RGBA it works fine:
```plaintext
GST_GL_API=gles2 GST_GL_PLATFORM=egl LIBVA_DRIVER_NAME=iHD gst-launch-1.0 -v filesrc location= /opt/medias/jellyfish-3-mbps-hd-h264.mkv ! matroskademux ! "video/x-h264" ! vah264dec ! "video/x-raw(memory:DMABuf)" ! vapostproc ! "video/x-raw(memory:DMABuf),format=NV12" ! glimagesink
```
![imagen.png](/uploads/928edee684567d5e74b5a78a27e592ad/imagen.png)
```plaintext
GST_GL_API=gles2 GST_GL_PLATFORM=egl LIBVA_DRIVER_NAME=iHD gst-launch-1.0 -v filesrc location= /opt/medias/jellyfish-3-mbps-hd-h264.mkv ! matroskademux ! "video/x-h264" ! vah264dec ! "video/x-raw(memory:DMABuf)" ! vapostproc ! "video/x-raw(memory:DMABuf),format=RGBA" ! glimagesink
```
![imagen.png](/uploads/3f6e546a629c1616e44cd09b2a78946c/imagen.png)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2470va: va allocator close filedescriptor2023-04-14T10:23:35Zdiegonietova: va allocator close filedescriptorAs stated in _va_drmcommon.h_, "Backend driver will not close the file descriptor. Application should handle the release of the fd"
I saw these file descriptor properly closed in both:
* subprojects/gstreamer-vaapi/gst-libs/gst/vaapi/gs...As stated in _va_drmcommon.h_, "Backend driver will not close the file descriptor. Application should handle the release of the fd"
I saw these file descriptor properly closed in both:
* subprojects/gstreamer-vaapi/gst-libs/gst/vaapi/gstvaapiwindow_wayland.c:766
* subprojects/FFmpeg/libavutil/hwcontext_vaapi.c:1146
However, I don't see that in VAhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/338webrtcsrc: Usage sample command2023-04-13T23:57:30Zkenji tanakawebrtcsrc: Usage sample commandWindows 10: 21H2 (OS Build 19044.2728)
gst-launch-1.0: 1.22.1
cargo: 1.68.2 (6feb7c9cf 2023-03-26)
1. gstreamer install by gstreamer-1.0-msvc-x86_64-1.22.1.msi
2. Clone from git@gitlab.freedesktop.org:gstreamer/gst-plugins-rs.git
3. `ca...Windows 10: 21H2 (OS Build 19044.2728)
gst-launch-1.0: 1.22.1
cargo: 1.68.2 (6feb7c9cf 2023-03-26)
1. gstreamer install by gstreamer-1.0-msvc-x86_64-1.22.1.msi
2. Clone from git@gitlab.freedesktop.org:gstreamer/gst-plugins-rs.git
3. `cargo run --bin gst-webrtc-signalling-server`
4. `cd gstwebrtc-api
npm install
npm start
`
5. Click on the "Start Capture" (automatically opened at https://localhost:9090)
6. `gst-launch-1.0 playbin uri=gstwebrtc://127.0.0.1:8443?peer-id=[Client ID]` (ClientId copy from web page)
I have error message.
```
Signalling error: Unknown message from server: {"type":"welcome","peerId":"79e8b345-34a0-4047-a4b4-614efdd9fc92"}
```
How can I resolve this issue?