gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2024-03-29T02:40:50Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3358Rust-based plugin initialization hangs on Android with GStreamer 1.24.02024-03-29T02:40:50ZNoTuxNoBuxRust-based plugin initialization hangs on Android with GStreamer 1.24.0### Describe your issue
For Android it is necessary to copy `GStreamer.java` to your project and call its `init` so it can in turn call `nativeInit` that is injected by GStreamer. This worked fine on GStreamer 1.22.6 on a Meta Quest 2 fo...### Describe your issue
For Android it is necessary to copy `GStreamer.java` to your project and call its `init` so it can in turn call `nativeInit` that is injected by GStreamer. This worked fine on GStreamer 1.22.6 on a Meta Quest 2 for me, but with GStreamer 1.24.0 the call seems to get 'stuck' and never returns due to an unknown reason with no other code changes.
(Strictly related to 'application development', but since it worked before this sounds like a regression.)
#### Expected Behavior
The call doesn't get stuck and proceeds as was the case before.
#### Observed Behavior
The call never returns.
#### Setup
- **Operating System:**: Android
- **Device:** Mobile (Meta Quest 2)
- **GStreamer Version:** 1.24.0
- **Command line:** N.a.
### Steps to reproduce the bug
Call `init` from `org.freedesktop.gstreamer.GStreamer` from your Android application on a Meta Quest 2 (might also fail elsewhere on Android, I have no other devices to test with).
### How reproducible is the bug?
Every time.
### Solutions you have tried
Disabling the call, but without it none of the hardware-accelerated video decoders are available, from what I understand.
### Additional Information
Not sure if related to https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4115. I checked the source code to see if there have been any changes to the way the native function is injected or what `GStreamer.java` looks like, but no changes seem to have occurred to those files between 1.22.6 and 1.24.0.amysparkamysparkhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2488gstreamer-plugins-good 1.22.2: test suite is failing in 2 units2024-03-28T20:45:39ZTomasz Kłoczkogstreamer-plugins-good 1.22.2: test suite is failing in 2 unitsLooks like test suite is failing in two units
<details>
```console
+ cd gst-plugins-good-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...Looks like test suite is failing in two units
<details>
```console
+ cd gst-plugins-good-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/gst-plugins-good-1.22.2/x86_64-redhat-linux-gnu'
ninja: no work to do.
1/115 elements_audioamplify OK 0.43s
2/115 elements_audiochebband OK 0.42s
3/115 elements_audiocheblimit OK 0.42s
4/115 elements_audiodynamic OK 0.41s
5/115 elements_audioecho OK 0.41s
6/115 elements_audiofirfilter OK 0.40s
7/115 elements_audioiirfilter OK 0.39s
8/115 elements_audioinvert OK 0.39s
9/115 elements_audiopanorama OK 0.38s
10/115 elements_audiowsincband OK 0.38s
11/115 elements_audiowsinclimit OK 0.37s
12/115 elements_alphacolor OK 0.37s
13/115 elements_alpha OK 0.36s
14/115 elements_avimux OK 0.35s
15/115 elements_avisubtitle OK 0.35s
16/115 elements_capssetter OK 0.34s
17/115 elements_aacparse OK 0.34s
18/115 elements_ac3parse OK 0.33s
19/115 elements_amrparse OK 0.32s
20/115 elements_flacparse OK 0.31s
21/115 elements_mpegaudioparse OK 0.31s
22/115 elements_autodetect OK 0.30s
23/115 elements_dtmf OK 0.28s
24/115 elements_flvdemux OK 0.27s
25/115 elements_mulawdec OK 0.24s
26/115 elements_mulawenc OK 0.23s
27/115 elements_matroskademux OK 0.45s
28/115 elements_id3demux OK 0.50s
29/115 elements_matroskamux OK 0.44s
30/115 elements_hlsdemux_m3u8 OK 0.58s
31/115 elements_level OK 0.50s
32/115 elements_matroskaparse OK 0.47s
33/115 elements_splitmuxsinktimecode OK 0.45s
34/115 elements_multifile OK 0.47s
35/115 elements_imagefreeze OK 0.54s
36/115 elements_icydemux OK 0.56s
37/115 elements_qtdemux OK 0.42s
38/115 elements_rglimiter OK 0.40s
39/115 elements_rgvolume OK 0.39s
40/115 elements_spectrum OK 0.39s
41/115 elements_udpsink OK 0.46s
42/115 elements_udpsrc OK 0.45s
43/115 elements_videobox OK 0.45s
44/115 elements_aspectratiocrop OK 0.40s
45/115 pipelines_wavenc OK 0.45s
46/115 elements_xingmux OK 0.42s
47/115 elements_wavpackparse OK 0.43s
48/115 elements_y4menc OK 0.46s
49/115 elements_wavparse OK 0.49s
50/115 elements_equalizer OK 0.44s
51/115 pipelines_tagschecking OK 0.42s
52/115 elements_rtphdrext_colorspace OK 0.45s
53/115 elements_rtph263 OK 0.44s
54/115 elements_rtph261 OK 0.45s
55/115 elements_rtpopus OK 0.41s
56/115 elements_flvmux OK 0.97s
57/115 elements_videoflip OK 0.65s
58/115 elements_splitmuxsrc OK 0.82s
59/115 elements_rtph265 OK 0.53s
60/115 elements_videofilter OK 0.71s
61/115 elements_rtpcollision OK 0.42s
62/115 elements_rtph264 OK 0.55s
63/115 elements_rtpvp9 OK 0.47s
64/115 elements_rtphdrextclientaudiolevel OK 0.40s
65/115 elements_rtpjpeg OK 0.37s
66/115 elements_rtptimerqueue OK 0.45s
67/115 elements_rtpbin_buffer_list OK 0.55s
68/115 elements_rtpptdemux OK 0.44s
69/115 elements_rganalysis OK 0.94s
70/115 elements_rtpmux OK 0.45s
71/115 elements_rtphdrextsdes OK 0.52s
72/115 elements_rtpvp8 OK 0.65s
73/115 elements_rtpst2022_1_fecenc OK 0.34s
74/115 elements_rtpst2022_1_fecdec OK 0.36s
75/115 elements_rtpred OK 0.43s
76/115 elements_gdkpixbufoverlay FAIL 0.29s exit status 1
>>> MALLOC_PERTURB_=6 GST_STATE_IGNORE_ELEMENTS='aasink autoaudiosrc autoaudiosink autovideosrc
autovideosink cacasink cairotextoverlay gtkglsink gtksink jackaudiosrc
jackaudiosink osssrc osssink osxaudiosink osxaudiosrc osxvideosrc osxvideosink
pulsesink pulsesrc pulsemixer v4l2src' GSETTINGS_BACKEND=memory GST_PLUGIN_PATH_1_0=/home/tkloczko/rpmbuild/BUILD/gst-plugins-good-1.22.2/x86_64-redhat-linux-gnu:/usr/lib64/gstreamer-1.0:/usr/lib64/gstreamer-1.0 CK_DEFAULT_TIMEOUT=20 GST_PLUGIN_SCANNER_1_0=/usr/libexec/gstreamer-1.0/gst-plugin-scanner GST_PLUGIN_LOADING_WHITELIST=gstreamer:gst-plugins-base:timecode:gst-plugins-good@/home/tkloczko/rpmbuild/BUILD/gst-plugins-good-1.22.2/x86_64-redhat-linux-gnu GST_PLUGIN_SYSTEM_PATH_1_0='' GST_REGISTRY=/home/tkloczko/rpmbuild/BUILD/gst-plugins-good-1.22.2/x86_64-redhat-linux-gnu/tests/check/elements_gdkpixbufoverlay.registry /home/tkloczko/rpmbuild/BUILD/gst-plugins-good-1.22.2/x86_64-redhat-linux-gnu/tests/check/elements_gdkpixbufoverlay
――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――
Running suite(s): gdkpixbufoverlay
0%: Checks: 1, Failures: 1, Errors: 0
../tests/check/elements/gdkpixbufoverlay.c:50:F:general:test_simple_overlay:0: 'gst_element_set_state (pipeline, GST_STATE_PLAYING)' (0) is not equal to 'GST_STATE_CHANGE_ASYNC' (2)
Check suite gdkpixbufoverlay ran in 0.007s (tests failed: 1)
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
77/115 generic_states FAIL 0.75s exit status 1
>>> MALLOC_PERTURB_=199 GST_STATE_IGNORE_ELEMENTS='aasink autoaudiosrc autoaudiosink autovideosrc
autovideosink cacasink cairotextoverlay gtkglsink gtksink jackaudiosrc
jackaudiosink osssrc osssink osxaudiosink osxaudiosrc osxvideosrc osxvideosink
pulsesink pulsesrc pulsemixer v4l2src' GSETTINGS_BACKEND=memory GST_PLUGIN_PATH_1_0=/home/tkloczko/rpmbuild/BUILD/gst-plugins-good-1.22.2/x86_64-redhat-linux-gnu:/usr/lib64/gstreamer-1.0:/usr/lib64/gstreamer-1.0 CK_DEFAULT_TIMEOUT=20 GST_REGISTRY=/home/tkloczko/rpmbuild/BUILD/gst-plugins-good-1.22.2/x86_64-redhat-linux-gnu/tests/check/generic_states.registry GST_PLUGIN_SCANNER_1_0=/usr/libexec/gstreamer-1.0/gst-plugin-scanner GST_PLUGIN_LOADING_WHITELIST=gstreamer:gst-plugins-base:timecode:gst-plugins-good@/home/tkloczko/rpmbuild/BUILD/gst-plugins-good-1.22.2/x86_64-redhat-linux-gnu GST_PLUGIN_SYSTEM_PATH_1_0='' /home/tkloczko/rpmbuild/BUILD/gst-plugins-good-1.22.2/x86_64-redhat-linux-gnu/tests/check/generic_states
――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――
Running suite(s): states_good
66%: Checks: 3, Failures: 0, Errors: 1
../tests/check/generic/states.c:180:E:general:test_state_changes_down_seq:0: (after this point) Received signal 11 (Segmentation fault)
Check suite states ran in 0.489s (tests failed: 1)
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
78/115 elements_rtpulpfec OK 0.42s
79/115 elements_jpegenc OK 0.26s
80/115 orc_audiopanorama OK 0.09s
81/115 orc_deinterlace OK 0.08s
82/115 orc_videomixer OK 0.06s
83/115 orc_videobox OK 0.05s
84/115 elements_jpegdec OK 0.30s
85/115 elements_splitmuxsink OK 1.11s
86/115 elements_wavpackenc OK 0.20s
87/115 elements_id3v2mux OK 0.30s
88/115 elements_vp8dec OK 0.26s
89/115 elements_apev2mux OK 0.31s
90/115 pipelines_wavpack OK 0.21s
91/115 elements_gdkpixbufsink OK 0.49s
92/115 elements_vp8enc OK 0.41s
93/115 elements_vp9enc OK 0.44s
94/115 pipelines_flacdec OK 0.62s
95/115 elements_rtpssrcdemux OK 0.73s
96/115 elements_dash_mpd OK 0.72s
97/115 elements_deinterlace OK 1.63s
98/115 elements_wavpackdec OK 0.75s
99/115 elements_rtpfunnel OK 1.28s
100/115 elements_rtpbin OK 1.46s
101/115 pipelines_effectv OK 1.63s
102/115 elements_rtprtx OK 1.40s
103/115 elements_rtp_payloading OK 1.36s
104/115 elements_videomixer OK 1.95s
105/115 elements_rtpsession OK 2.00s
106/115 elements_deinterleave OK 2.92s
107/115 elements_rtpstorage OK 2.32s
108/115 elements_mpg123audiodec OK 3.52s
109/115 elements_souphttpsrc2 OK 4.84s
110/115 elements_videocrop OK 5.96s
111/115 pipelines_simple_launch_lines OK 10.05s
112/115 elements_qtmux OK 10.49s
113/115 elements_interleave OK 11.18s
114/115 elements_shapewipe OK 15.86s
115/115 elements_rtpjitterbuffer OK 19.80s
Summary of Failures:
76/115 elements_gdkpixbufoverlay FAIL 0.29s exit status 1
77/115 generic_states FAIL 0.75s exit status 1
Ok: 113
Expected Fail: 0
Fail: 2
Unexpected Pass: 0
Skipped: 0
Timeout: 0
```
</details>https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/168pad: Offset handling inconsistencies2024-03-28T17:53:31ZBugzilla Migration Userpad: Offset handling inconsistencies## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#765049)](https://bugzilla.gnome.org/show_bug.cgi?id=765049)**
## Description
14:24 `< slomo_>` after probes, always check if sticky events have changed (when handli...## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#765049)](https://bugzilla.gnome.org/show_bug.cgi?id=765049)**
## Description
14:24 `< slomo_>` after probes, always check if sticky events have changed (when handling serialized events/buffers/buffer lists)
14:24 `< slomo_>` after probes, always check if pad offsets have changed (on sinkpads) and apply them if so
Current situation: Apply buffer pad probe on a sinkpad, change the pad offset in the probe => this has no effect.
### See also
* [Bug 795330](https://bugzilla.gnome.org/show_bug.cgi?id=795330)
* [Bug 796898](https://bugzilla.gnome.org/show_bug.cgi?id=796898)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3431Unable to play mkv video using gstreamer2024-03-28T14:22:29ZGuilherme HubnerUnable to play mkv video using gstreamer### Describe your issue
I am unable to play MKV files using gstreamer. I've tried many different ways and none worked for me.
Initially I wrote a program to extract a frame out of the video using `playbin`, it works for most of the vide...### Describe your issue
I am unable to play MKV files using gstreamer. I've tried many different ways and none worked for me.
Initially I wrote a program to extract a frame out of the video using `playbin`, it works for most of the videos I input to it. But for some files when I call `gst_element_get_state(playbin, NULL, NULL, 5*GST_SECOND)` I get `GST_STATE_CHANGE_FAILURE` as return.
Triggered by that I started trying another ways to reproduce the video, for example:
`gst-play-1.0 ~/Downloads/cicd.mkv`
That opens the player but all the frames are black.
I also tried:
`gst-launch-1.0 -v playbin3 uri=file:///home/$USER/Downloads/cicd.mkv`
`gst-launch-1.0 -v playbin uri=file:///home/$USER/Downloads/cicd.mkv`
And again all I got was a black screen.
Using VLC and other players I was able to play the video.
Other MKV videos I have works with all methods listed above.
#### Expected Behavior
I would expect to be able to play the video using gstreamer.
#### Observed Behavior
gstreamer is unable to properly play the video, programatically it gives error and using cli tools it shows only completely black frames.
#### Setup
- Operating System: Ubuntu 22.04.4 LTS x86_64
- Device: Computer
- GStreamer Version: 1.20.3
- gst-play-1.0 version 1.20.1
- gst-launch-1.0 version 1.20.3
### Steps to reproduce the bug
1. Download the video in this issue
2. open terminal
3. type `gst-play-1.0 ~/Downloads/cicd.mkv`
4. You can also try `gst-launch-1.0 -v playbin3 uri=file:///home/$USER/Downloads/cicd.mkv` or `gst-launch-1.0 -v playbin uri=file:///home/$USER/Downloads/cicd.mkv`
### How reproducible is the bug?
We tried in many different machines running linux, so it is not device specific.
### Additional Information
Video that is failing: [cicd.mkv](/uploads/ed66b66141d804ee330e92576a303a4a/cicd.mkv)
Worth to mention that the video above was also encoded using gstreamer.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3432vtdec: Seeking sometimes freezes output and causes kVTVideoDecoderBadDataErr2024-03-28T13:12:23ZPiotr Brzezińskivtdec: Seeking sometimes freezes output and causes kVTVideoDecoderBadDataErrWhen using `gst-play` with some files, in my case a [HDR10 60fps 4K test clip](https://drive.google.com/file/d/1Ic9DZXMSo07EJMqCFaQRKSSrSw6y1mYv/view?usp=sharing) from the [Kodi samples library](https://kodi.wiki/view/Samples), seeking f...When using `gst-play` with some files, in my case a [HDR10 60fps 4K test clip](https://drive.google.com/file/d/1Ic9DZXMSo07EJMqCFaQRKSSrSw6y1mYv/view?usp=sharing) from the [Kodi samples library](https://kodi.wiki/view/Samples), seeking forward (2+ times for this example) causes `vtdec` to get into a bad state where output frames are empty and the output callback signals `kVTVideoDecoderBadDataErr` infinitely. When looking at the output, every few seconds a frame or two will appear, but it's frozen otherwise.
**Note**: This only happens if hardware acceleration is enabled. Software decoding works fine.
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6446 will make things a bit better (should error out at some point instead of just freezing and waiting until input runs out), but the issue still stands.
For the record, when using `avdec_h265` no such issue can be seen.
#### Setup
- **Operating System:** macOS Sonoma 14.4
- **Device:** MacBook Pro (M1 Pro)
- **GStreamer Version:** latest `main`https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3427vavp9enc: some resolutions fails to encode using CQP2024-03-28T00:14:04ZVíctor Manuel Jáquez Lealvavp9enc: some resolutions fails to encode using CQPUsing iHD driver version 24.1.3 (libva 2.21) on Alder Lake
This pipeline fails:
```
gst-launch-1.0 videotestsrc pattern=1 ! video/x-raw, format=NV12, width=640, height=480 ! vavp9lpenc rate-control=cqp ! fakesink
```
with these logs
...Using iHD driver version 24.1.3 (libva 2.21) on Alder Lake
This pipeline fails:
```
gst-launch-1.0 videotestsrc pattern=1 ! video/x-raw, format=NV12, width=640, height=480 ! vavp9lpenc rate-control=cqp ! fakesink
```
with these logs
```
0:00:00.106913809 88845 0x7f9f4c000b90 DEBUG vabaseenc gstvabaseenc.c:371:gst_va_base_enc_copy_output_data:<vavp9lpenc0> Not enough space for coded data
0:00:00.106927139 88845 0x7f9f4c000b90 ERROR vavp9enc gstvavp9enc.c:2544:_vp9_create_super_frame_output_buffer:<vavp9lpenc0> Fails to copy the output data of system_frame_number 1, frame_num: 1
0:00:00.106931294 88845 0x7f9f4c000b90 ERROR vavp9enc gstvavp9enc.c:2660:gst_va_vp9_enc_prepare_output:<vavp9lpenc0> Failed to create output buffer
0:00:00.106933608 88845 0x7f9f4c000b90 ERROR vabaseenc gstvabaseenc.c:466:_push_buffer_to_downstream:<vavp9lpenc0> Failed to prepare output
0:00:00.106954914 88845 0x7f9f4c000b90 DEBUG vabaseenc gstvabaseenc.c:513:_push_out_one_buffer:<vavp9lpenc0> fails to push one buffer, system_frame_number 1: error
```
cc: @He_Junyanhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3426switchbin doesn't negotiate requested resolution from webcam2024-03-27T18:04:49ZSergei Ilinykhswitchbin doesn't negotiate requested resolution from webcam### Describe your issue
I'm a somewhat puzzled on how switchbin element does negotiation.
Below are minimal examples just for the problem demonstration. Real life code will include more paths to switchbin.
# Next 3 work well
gs...### Describe your issue
I'm a somewhat puzzled on how switchbin element does negotiation.
Below are minimal examples just for the problem demonstration. Real life code will include more paths to switchbin.
# Next 3 work well
gst-launch-1.0 -v v4l2src device=/dev/video0 ! switchbin num-paths=1 path0::caps="image/jpeg,with=1280,height=720" ! jpegdec ! videoconvert ! autovideosink
gst-launch-1.0 -v v4l2src device=/dev/video0 ! switchbin num-paths=1 path0::caps="image/jpeg,with=320,height=240" ! jpegdec ! videoconvert ! autovideosink
gst-launch-1.0 -v v4l2src device=/dev/video0 ! switchbin num-paths=1 path0::caps="image/jpeg,with=1280,height=720" path0::element="jpegdec" ! videoconvert ! autovideosink
# but the next one doesn't work
gst-launch-1.0 -v v4l2src device=/dev/video0 ! switchbin num-paths=1 path0::caps="image/jpeg,with=320,height=240" path0::element="jpegdec" ! videoconvert ! autovideosink
I can't explain why. But according to the log the failing sample just took the first available caps from v4l2src, which is `image/jpeg, width=1280, height=720, framerate=30/1` and didn't even try to negotiate with any other, regardless v4l2src also declares `image/jpeg, width=320, height=240, framerate=30/1`.
Looks like a bug.
#### Expected Behavior
Requested resolution is negotiated
#### Observed Behavior
<!-- What actually happened -->
#### Setup
- **Operating System:** Gentoo
- **Device:** Laptop MSI GL75 9SDK
- **GStreamer Version:** 1.22.3
- **Command line:** ? bash/konsole
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open terminal
2. type `gst-launch-1.0 -v v4l2src device=/dev/video0 ! switchbin num-paths=1 path0::caps="image/jpeg,with=320,height=240" path0::element="jpegdec" ! videoconvert ! autovideosink`
### Additional Information
The command above opens a window with single static frame for less than a second and closes immediately.
<!-- Any other information such as logs. Make use of <details> for long output -->
```
0:00:00.674750199 373216 0x7f7428000d10 INFO GST_STATES gstelement.c:2716:_priv_gst_element_state_changed:<pipeline0> notifying about state-changed PAUSED to PLAYING (VOID_PENDING pending)
0:00:00.674894259 373216 0x55ce4cadf330 INFO bin gstbin.c:2767:gst_bin_do_latency_func:<pipeline0> configured latency of 0:00:00.048333333
/GstPipeline:pipeline0/GstV4l2Src:v4l2src0: crop-bounds = < (int)0, (int)0, (int)424, (int)240 >
0:00:00.687233331 373216 0x7f7428000b70 INFO v4l2src gstv4l2src.c:854:gst_v4l2src_negotiate:<v4l2src0> fixated to: image/jpeg, width=(int)1280, height=(int)720, framerate=(fraction)30/1, parsed=(boolean)true, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)2:4:5:1
0:00:00.687266699 373216 0x7f7428000b70 INFO GST_EVENT gstevent.c:918:gst_event_new_caps: creating caps event image/jpeg, width=(int)1280, height=(int)720, framerate=(fraction)30/1, parsed=(boolean)true, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)2:4:5:1
0:00:00.687322122 373216 0x7f7428000b70 WARN GST_CAPS gstpad.c:5787:pre_eventfunc_check:<switchbin0:sink> caps image/jpeg, width=(int)1280, height=(int)720, framerate=(fraction)30/1, parsed=(boolean)true, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)2:4:5:1 not accepted
0:00:00.687337726 373216 0x7f7428000b70 WARN GST_CAPS gstpad.c:5787:pre_eventfunc_check:<switchbin0:sink> caps image/jpeg, width=(int)1280, height=(int)720, framerate=(fraction)30/1, parsed=(boolean)true, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)2:4:5:1 not accepted
0:00:00.687343283 373216 0x7f7428000b70 WARN GST_PADS gstpad.c:4361:gst_pad_peer_query:<v4l2src0:src> could not send sticky events
/GstPipeline:pipeline0/GstV4l2Src:v4l2src0.GstPad:src: caps = image/jpeg, width=(int)1280, height=(int)720, framerate=(fraction)30/1, parsed=(boolean)true, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)2:4:5:1
0:00:00.688144772 373216 0x7f7428000b70 WARN v4l2 gstv4l2object.c:4440:gst_v4l2_object_set_crop:<v4l2src0:src> VIDIOC_S_CROP failed
0:00:00.712830318 373216 0x7f7428000b70 INFO v4l2 gstv4l2object.c:4035:gst_v4l2_object_set_format_full:<v4l2src0:src> Set capture framerate to 30/1
0:00:00.712850244 373216 0x7f7428000b70 WARN v4l2 gstv4l2object.c:3258:gst_v4l2_object_reset_compose_region:<v4l2src0:src> Failed to get default compose rectangle with VIDIOC_G_SELECTION: Недопустимый аргумент
0:00:00.712855689 373216 0x7f7428000b70 INFO v4l2 gstv4l2object.c:3194:gst_v4l2_object_setup_pool:<v4l2src0:src> accessing buffers via mode 4
0:00:00.712924496 373216 0x7f7428000b70 INFO v4l2bufferpool gstv4l2bufferpool.c:586:gst_v4l2_buffer_pool_set_config:<v4l2src0:pool1:src> increasing minimum buffers to 2
0:00:00.712929207 373216 0x7f7428000b70 INFO v4l2bufferpool gstv4l2bufferpool.c:599:gst_v4l2_buffer_pool_set_config:<v4l2src0:pool1:src> reducing maximum buffers to 32
0:00:00.712952484 373216 0x7f7428000b70 INFO v4l2bufferpool gstv4l2bufferpool.c:599:gst_v4l2_buffer_pool_set_config:<v4l2src0:pool1:src> reducing maximum buffers to 32
0:00:00.713605268 373216 0x7f7428000b70 WARN v4l2bufferpool gstv4l2bufferpool.c:848:gst_v4l2_buffer_pool_start:<v4l2src0:pool1:src> Uncertain or not enough buffers, enabling copy threshold
0:00:01.128822853 373216 0x7f7428000b70 WARN GST_CAPS gstpad.c:5787:pre_eventfunc_check:<switchbin0:sink> caps image/jpeg, width=(int)1280, height=(int)720, framerate=(fraction)30/1, parsed=(boolean)true, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)2:4:5:1 not accepted
0:00:01.128907610 373216 0x7f7428000b70 WARN basesrc gstbasesrc.c:3132:gst_base_src_loop:<v4l2src0> error: Internal data stream error.
0:00:01.128928899 373216 0x7f7428000b70 WARN basesrc gstbasesrc.c:3132:gst_base_src_loop:<v4l2src0> error: streaming stopped, reason not-negotiated (-4)
0:00:01.128965241 373216 0x7f7428000b70 INFO GST_ERROR_SYSTEM gstelement.c:2281:gst_element_message_full_with_details:<v4l2src0> posting message: Internal data stream error.
ОШИБКА: из элемента /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data stream error.
Дополнительная отладочная информация:
../gstreamer-1.22.3/libs/gst/base/gstbasesrc.c(3132): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
streaming stopped, reason not-negotiated (-4)
0:00:01.129116749 373216 0x7f7428000b70 INFO GST_ERROR_SYSTEM gstelement.c:2308:gst_element_message_full_with_details:<v4l2src0> posted error message: Internal data stream error.
0:00:01.129170285 373216 0x7f7428000b70 WARN GST_CAPS gstpad.c:5787:pre_eventfunc_check:<switchbin0:sink> caps image/jpeg, width=(int)1280, height=(int)720, framerate=(fraction)30/1, parsed=(boolean)true, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)2:4:5:1 not accepted
0:00:01.129208187 373216 0x7f7428000b70 WARN GST_CAPS gstpad.c:5787:pre_eventfunc_check:<switchbin0:sink> caps image/jpeg, width=(int)1280, height=(int)720, framerate=(fraction)30/1, parsed=(boolean)true, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)2:4:5:1 not accepted
0:00:01.129260135 373216 0x7f7428000b70 WARN GST_CAPS gstpad.c:5787:pre_eventfunc_check:<switchbin0:sink> caps image/jpeg, width=(int)1280, height=(int)720, framerate=(fraction)30/1, parsed=(boolean)truExecution ended after 0:00:00.997273841
e, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)2:4:5:1 not accepted
Установка конвейера в состояние NULL…
0:00:01.129366704 373216 0x55ce4cadf330 INFO GST_STATES gstbin.c:2480:gst_bin_element_set_state:<autovideosink0> current PLAYING pending VOID_PENDING, desired next PAUSED
```
```
name : HD Webcam (V4L2)
class : Video/Source
caps : image/jpeg, width=1280, height=720, framerate=30/1
image/jpeg, width=320, height=180, framerate=30/1
image/jpeg, width=320, height=240, framerate=30/1
image/jpeg, width=352, height=288, framerate=30/1
image/jpeg, width=424, height=240, framerate=30/1
image/jpeg, width=640, height=360, framerate=30/1
image/jpeg, width=640, height=480, framerate=30/1
image/jpeg, width=848, height=480, framerate=30/1
image/jpeg, width=960, height=540, framerate=30/1
video/x-raw, format=YUY2, width=1280, height=720, framerate=10/1
video/x-raw, format=YUY2, width=320, height=180, framerate=30/1
video/x-raw, format=YUY2, width=320, height=240, framerate=30/1
video/x-raw, format=YUY2, width=352, height=288, framerate=30/1
video/x-raw, format=YUY2, width=424, height=240, framerate=30/1
video/x-raw, format=YUY2, width=640, height=360, framerate=30/1
video/x-raw, format=YUY2, width=640, height=480, framerate=30/1
video/x-raw, format=YUY2, width=848, height=480, framerate=20/1
video/x-raw, format=YUY2, width=960, height=540, framerate=15/1
properties:
api.v4l2.cap.bus_info = usb-0000:00:14.0-13
api.v4l2.cap.capabilities = 84a00001
api.v4l2.cap.card = HD Webcam: HD Webcam
api.v4l2.cap.device-caps = 04200001
api.v4l2.cap.driver = uvcvideo
api.v4l2.cap.version = 6.8.1
api.v4l2.path = /dev/video0
device.api = v4l2
device.devids = 20736
device.id = 41
device.product.id = 0x211
device.vendor.id = 0x598
factory.name = api.v4l2.source
media.class = Video/Source
node.description = HD Webcam (V4L2)
node.name = v4l2_input.pci-0000_00_14.0-usb-0_13_1.0
node.nick = HD Webcam
node.pause-on-idle = false
object.path = v4l2:/dev/video0
priority.session = 1000
factory.id = 10
client.id = 34
clock.quantum-limit = 8192
media.role = Camera
node.driver = true
object.id = 45
object.serial = 45
gst-launch-1.0 pipewiresrc target-object=45 ! ...
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3414jpegparse: Constant stream of "Invalid data" warnings when used with v4l2src ...2024-03-26T20:29:54ZRobert Maderjpegparse: Constant stream of "Invalid data" warnings when used with v4l2src / pipewiresrcThe following example pipelines produce a otherwise unproblematic stream of error messages (I guess on every frame) on different common UVC cameras of my Laptop and Desktop:
```
gst-launch-1.0 v4l2src ! image/jpeg,width=1280,height=720 !...The following example pipelines produce a otherwise unproblematic stream of error messages (I guess on every frame) on different common UVC cameras of my Laptop and Desktop:
```
gst-launch-1.0 v4l2src ! image/jpeg,width=1280,height=720 ! decodebin3 ! waylandsink
```
or
```
gst-launch-1.0 pipewiresrc ! image/jpeg,width=1280,height=720 ! decodebin3 ! waylandsink
```
Note that whatever comes behind `decodebin3` does not matter - `fakesink` is also affected.
The warning looks as follows:
```
Additional debug info:
../subprojects/gst-plugins-bad/gst/jpegformat/gstjpegparse.c(939): gst_jpeg_parse_handle_frame (): /GstPipeline:pipeline0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0/GstJpegParse:jpegparse0:
Failed to parse app0 segment
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3376Follow-up from "va: Move PROP_RATE_CONTROL to the end of the array"2024-03-26T17:41:03ZVíctor Manuel Jáquez LealFollow-up from "va: Move PROP_RATE_CONTROL to the end of the array"There are encoder properties that are hardware dependent: if the driver offers them, they are installed in the class. But currently that code is quite fragile: if new properties are added we could fall again in a segmentation fault.
The...There are encoder properties that are hardware dependent: if the driver offers them, they are installed in the class. But currently that code is quite fragile: if new properties are added we could fall again in a segmentation fault.
These hardware dependent properties should be handled in helper or in the VA encoders base class.
The following discussion from !6319 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6319#note_2320031): (+2 comments)
> This sounds like a footgun that will trigger again in a few months when someone adds new properties. Can this be refactored a bit to avoid this?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3425vtdec: Fails to decode some kinds of 10bit HDR footage2024-03-26T14:58:26ZPiotr Brzezińskivtdec: Fails to decode some kinds of 10bit HDR footageWhen testing a [HDR10 60fps 4K test clip](https://drive.google.com/file/d/1Ic9DZXMSo07EJMqCFaQRKSSrSw6y1mYv/view?usp=sharing) from the [Kodi samples library](https://kodi.wiki/view/Samples), `vtdec` fails to play it completely.
The erro...When testing a [HDR10 60fps 4K test clip](https://drive.google.com/file/d/1Ic9DZXMSo07EJMqCFaQRKSSrSw6y1mYv/view?usp=sharing) from the [Kodi samples library](https://kodi.wiki/view/Samples), `vtdec` fails to play it completely.
The error message is as follows:
```
0:00:00.667358334 71926 0x600003f4ad90 ERROR vtdec vtdec.c:1218:gst_vtdec_session_output_callback:<vtdechw0> Error decoding frame -17694
```
which indicates `kVTVideoDecoderReferenceMissingErr`. It's not a critical error, and should ideally be worked around instead of aborting completely. It's of course hard to find any documentation about this error, but VLC for example only [restarts the encoding session](https://code.videolan.org/videolan/vlc/-/blob/master/modules/codec/videotoolbox/decoder.c#L1751) when this error is encountered.
It's not clear why and when this error can be expected, it definitely doesn't happen for all kinds of HDR 10bit footage (a quick recording of similar kind from a relatively modern iPhone has no issues being played back), but that's the only case where I was able to reproduce it.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3424rtspsrc retrieves frames from another multicast stream2024-03-26T12:31:12Zrobin-blanchardrtspsrc retrieves frames from another multicast stream### Describe your issue
<!-- Please provide a clear and concise summary of the bug. -->
I am currently in the process of bumping GStreamer to 1.22.9 in my solution. When using an rtspsrc pipeline to a multicast stream, the frames I recei...### Describe your issue
<!-- Please provide a clear and concise summary of the bug. -->
I am currently in the process of bumping GStreamer to 1.22.9 in my solution. When using an rtspsrc pipeline to a multicast stream, the frames I receive are from another multicast stream. Both streams come from the same media gateway.
<!-- For any GStreamer usage questions or application development support
please head over to our new GStreamer Discourse forum at
https://discourse.gstreamer.org/ instead, or find us on
the GStreamer Matrix room at https://matrix.to/#/#gstreamer:gstreamer.org -->
#### Expected Behavior
<!-- What did you expect to happen -->
I expected both pipelines to retrieve frames from the corresponding stream. The pipelines are:
`/usr/bin/gst-launch-1.0 rtspsrc location=$RTSP latency=20000 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! jpegenc ! multifilesink location="frame%05d.jpg"` with `RTSP` being the RTSP link.
#### Observed Behavior
<!-- What actually happened -->
The pipeline running on `rtsp://A.B.C.D:1234/camera01` corrrectly works.
The pipeline running on `rtsp://A.B.C.D:1234/camera02` retrieves frames from the `camera01` stream.
#### Setup
- **Operating System:** Linux
- **Device:** Docker container <!-- Delete as appropriate !-->
- **GStreamer Version:** 1.22.9
- **Command line:** `/usr/bin/gst-launch-1.0 rtspsrc location=$RTSP latency=20000 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! jpegenc ! multifilesink location="frame%05d.jpg"`
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
Here's the Dockerfile used to build GStreamer:
```
# Taken from https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3202
FROM ubuntu:22.04
# Setting bash as the default shell in this container
SHELL ["/bin/bash", "-c"]
# Environment variable to configure timezone
ENV TZ=Etc/UTC \
GSTREAMER_VERSION=1.22.9
WORKDIR /tmp/workdir
RUN apt update \
&& apt install -y tzdata \
&& rm -rf /var/lib/apt/lists/*
RUN apt update \
&& apt install -y \
autoconf \
build-essential \
cmake \
curl \
dvb-apps \
fonts-open-sans \
g++ \
git \
liba52-0.7.4-dev \
libaom-dev \
libasound2-dev \
libass-dev \
libavc1394-dev \
libavcodec-dev \
libavdevice-dev \
libavformat-dev \
libavutil-dev \
libcdio-cdda-dev \
libcdio-dev \
libcdio-paranoia-dev \
libdrm-dev \
libfaad-dev \
libfdk-aac-dev \
libfreetype6-dev \
libgl1-mesa-dev \
libiec61883-dev \
libjack-dev \
libjpeg62-dev \
libmad0-dev \
libmp3lame-dev \
libogg-dev \
libopenal-dev \
libopencore-amrnb-dev \
libopencore-amrwb-dev \
libopus-dev \
libpng-dev \
libpulse-dev \
libraw1394-dev \
librtmp-dev \
libsdl2-dev \
libsoup2.4-dev \
libsrt-openssl-dev \
libssl-dev \
libswscale-dev \
libtheora-dev \
libtool \
libvorbis-dev \
libvpx-dev \
libwebp-dev \
libx264-dev \
libx265-dev \
libxcb-shape0-dev \
libxcb-shm0-dev \
libxcb-xfixes0-dev \
libxv-dev \
libxvidcore-dev \
mesa-utils \
pkg-config \
scons \
wget \
x11proto-gl-dev \
x11proto-video-dev \
yasm \
zlib1g-dev \
&& rm -rf /var/lib/apt/lists/*
ENV LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64
RUN apt update \
&& apt remove -y \
meson \
&& apt install -y \
python3-pip \
flex \
bison \
&& python3 -m pip install meson ninja tomli \
&& rm -rf /var/lib/apt/lists/*
###################################################################################################
# GStreamer clone
RUN git clone --depth 1 --branch ${GSTREAMER_VERSION} https://github.com/GStreamer/gstreamer.git
# GStreamer build
RUN cd /tmp/workdir/gstreamer \
&& meson setup --wipe \
-Dlibav=enabled \
-Dgood=enabled \
-Dbad=enabled \
-Dugly=enabled \
-Dgpl=enabled \
--buildtype release \
builddir \
&& meson compile -C builddir \
&& cd builddir \
&& meson install \
&& ldconfig \
&& cd /tmp/workdir \
&& rm -rf gstreamer
```
Build the image and run a container with `--network host` to access multicast streams.
Running the gst-launch command on both streams should reproduce the bug.
### How reproducible is the bug?
Always once we're in such a setup
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->
With GStreamer 1.18.4, there is no such problemhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1461webrtc/nice: synchronous disposal of Nice agent triggers g_warnings when "TUR...2024-03-26T11:27:28ZMathieu Duponchellewebrtc/nice: synchronous disposal of Nice agent triggers g_warnings when "TURN refreshes" are pending.Since https://gitlab.freedesktop.org/libnice/libnice/-/merge_requests/179/diffs?commit_id=bbf7f2d7beb24c7d620e62c2030701e6961a29d4 NiceAgent will log a g_warning when trying to dispose a Nice agent with "alive reservations" on a TURN ser...Since https://gitlab.freedesktop.org/libnice/libnice/-/merge_requests/179/diffs?commit_id=bbf7f2d7beb24c7d620e62c2030701e6961a29d4 NiceAgent will log a g_warning when trying to dispose a Nice agent with "alive reservations" on a TURN server.
Currently, webrtcbin disposes of the agent synchronously when its state is going down, which can trigger the warnings without the user having any control over that.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3420macos: Transparent PNG into glimagesink doesn't display correctly2024-03-25T20:41:29ZPiotr Brzezińskimacos: Transparent PNG into glimagesink doesn't display correctlyA pipeline like `filesrc ! pngdec ! imagefreeze ! glimagesink`, when decoding a PNG file with an alpha channel, does not seem to render correctly (only on macOS, to my knownledge). The image only appears for 1 frame after a forced re-ren...A pipeline like `filesrc ! pngdec ! imagefreeze ! glimagesink`, when decoding a PNG file with an alpha channel, does not seem to render correctly (only on macOS, to my knownledge). The image only appears for 1 frame after a forced re-render, through resizing the window for example. Displays fine with `! osxvideosink`. It's identical to https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1548 with how it manifests. Haven't investigated any further yet.
Here's a quick recording when attempting to show the [GStreamer logo png](/uploads/05df15420ac0e49969836d6ccc8da223/gstreamer-logo.png):
![Screen_Recording_2024-03-25_at_21.39.12](/uploads/4aef37e90f6d33397581b6744f051dc2/Screen_Recording_2024-03-25_at_21.39.12.mov)
#### Setup
- **Operating System:** macOS Sonoma 14.4
- **Device:** MacBook Pro w/ M1 Pro
- **GStreamer Version:** latest `main`https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1614qmlglsink: Memory leak2024-03-25T13:25:43ZJulien FRqmlglsink: Memory leak### Describe your issue
There is a memory leak using qmlglsink.
Reproduced with `gst-plugins-good/tests/examples/qt/qmlsink-multisink`.
https://github.com/carusojfr/gstreamer/tree/qmlglsink-memory-leaks/subprojects/gst-plugins-good/test...### Describe your issue
There is a memory leak using qmlglsink.
Reproduced with `gst-plugins-good/tests/examples/qt/qmlsink-multisink`.
https://github.com/carusojfr/gstreamer/tree/qmlglsink-memory-leaks/subprojects/gst-plugins-good/tests/examples/qt/qmlsink-multisink
#### Expected Behavior
There should be no more live objects in memory when application closed.
#### Observed Behavior
When `videoitem` is destroyed there are both GstCaps/GstPad live object.
There is an extra GstCaps at each stop/start of the pipeline.
If `videoitem` is not destroyed, there are GstCaps,GstContext,GstGLContextGLX,GstGLDisplayX11,GstGLDisplayX11,GstGLWindowX11,GstGLWrappedContext,GstPad,GstQtSink
#### Setup
- Debian 9/11
- VM/Computer
- 1.10/1.16/1.18/Last
- **Command line:**
<pre><code>
cmake -Hsubprojects/gst-plugins-good/tests/examples/qt/qmlsink-multisink/ -Bbuild
cmake --build build/
</pre></code>
### Steps to reproduce the bug
1. open terminal
2. type `./build/qmlsink-multisink`
1. click Quit
2. read on the console all lives objects (see appendices)
3. type `./build/qmlsink-multisink`
1. click on index to unset source
2. read on the console all lives objects (see appendices)
4. type `./build/qmlsink-multisink`
1. click on video to start/stop
2. read on the console all lives objects (see appendices)
### How reproducible is the bug?
systematic
### Solutions you have tried
I try to remove glsink increment in `void VideoItem::componentComplete()`, then there is only GstCaps/GstPad live when application Quit (if videoitem is destroyed)
The RenderJob (::AfterSwapStage) to unref sink is called only when video-item is destroyed (disable loader) before Quit.
### Additional Information
<p>
<details>
<summary>Memory leaks traces</summary>
Traces when application Quit.
<pre><code>
0:00:05.015097802 13732 0x56027a27ea40 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstCaps, address=(gpointer)0x7ffab0002ad0, description=(string)video/x-raw(memory:GLMemory), format=(string)RGBA, width=(int)320, height=(int)240, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, texture-target=(string)2D, ref-count=(uint)4, trace=(string);
0:00:05.015145702 13732 0x56027a27ea40 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstContext, address=(gpointer)0x56027a412460, description=(string)context 'gst.gl.GLDisplay'='context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0";', ref-count=(uint)1, trace=(string);
0:00:05.015158802 13732 0x56027a27ea40 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstGLContextGLX, address=(gpointer)0x7ffab00080f0, description=(string)<glcontextglx1>, ref-count=(uint)1, trace=(string);
0:00:05.015171502 13732 0x56027a27ea40 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstGLDisplayX11, address=(gpointer)0x56027a4681e0, description=(string)<gldisplayx11-1>, ref-count=(uint)4, trace=(string);
0:00:05.015201001 13732 0x56027a27ea40 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstGLDisplayX11, address=(gpointer)0x56027a4680e0, description=(string)<gldisplayx11-0>, ref-count=(uint)1, trace=(string);
0:00:05.015220401 13732 0x56027a27ea40 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstGLWindowX11, address=(gpointer)0x56027a4586a0, description=(string)<glwindowx11-1>, ref-count=(uint)1, trace=(string);
0:00:05.015241701 13732 0x56027a27ea40 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstGLWrappedContext, address=(gpointer)0x56027a475190, description=(string)<glwrappedcontext0>, ref-count=(uint)1, trace=(string);
0:00:05.015266501 13732 0x56027a27ea40 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstPad, address=(gpointer)0x56027a2ff530, description=(string)<sink:sink>, ref-count=(uint)2, trace=(string);
0:00:05.015290301 13732 0x56027a27ea40 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstQtSink, address=(gpointer)0x56027a412f20, description=(string)<sink>, ref-count=(uint)1, trace=(string);
</code></pre>
Traces when application Quit and video-item is destroyed.
<pre><code>
0:00:05.068313771 14779 0x55c28fd6fa40 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstCaps, address=(gpointer)0x7f7158002ad0, description=(string)video/x-raw(memory:GLMemory), format=(string)RGBA, width=(int)320, height=(int)240, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, texture-target=(string)2D, ref-count=(uint)4, trace=(string);
0:00:05.068375471 14779 0x55c28fd6fa40 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstPad, address=(gpointer)0x55c28fdef530, description=(string)<'':sink>, ref-count=(uint)1, trace=(string);
</code></pre>
Traces when pipeline is start/stop 3 times
<pre><code>
0:00:06.235596402 26980 0x55c1f471ba40 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstCaps, address=(gpointer)0x7f85a00028f0, description=(string)video/x-raw(memory:GLMemory), format=(string)RGBA, width=(int)320, height=(int)240, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, texture-target=(string)2D, ref-count=(uint)2, trace=(string);
0:00:06.235828202 26980 0x55c1f471ba40 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstCaps, address=(gpointer)0x7f85a0002ad0, description=(string)video/x-raw(memory:GLMemory), format=(string)RGBA, width=(int)320, height=(int)240, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, texture-target=(string)2D, ref-count=(uint)4, trace=(string);
0:00:06.235854002 26980 0x55c1f471ba40 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstCaps, address=(gpointer)0x7f85a0002940, description=(string)video/x-raw(memory:GLMemory), format=(string)RGBA, width=(int)320, height=(int)240, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, texture-target=(string)2D, ref-count=(uint)2, trace=(string);
0:00:06.235874002 26980 0x55c1f471ba40 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstCaps, address=(gpointer)0x7f85a0002b20, description=(string)video/x-raw(memory:GLMemory), format=(string)RGBA, width=(int)320, height=(int)240, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, texture-target=(string)2D, ref-count=(uint)2, trace=(string);
0:00:06.235898702 26980 0x55c1f471ba40 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstPad, address=(gpointer)0x55c1f479b530, description=(string)<'':sink>, ref-count=(uint)1, trace=(string);
</code></pre>
</details>
</p>https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3105qmlglsink: QtGLVideoItem destructor breaks Qt rendering with "QEGLPlatformCon...2024-03-25T13:25:40ZVincas Dargisqmlglsink: QtGLVideoItem destructor breaks Qt rendering with "QEGLPlatformContext: eglSwapBuffers failed: 3001" error if GstGLVideoItem is never used in pipeline on IMX8MM Vivante EGLIssue originally discovered in 1.22.1, but reproduced with 1.22.6 too. Using Qt 5.15.15.
This is what happens when QML scene changes (items destroyed via `StackView.replace()` etc), in result destroying `GstGLVideoItem`:
(`GST_DEBUG="*...Issue originally discovered in 1.22.1, but reproduced with 1.22.6 too. Using Qt 5.15.15.
This is what happens when QML scene changes (items destroyed via `StackView.replace()` etc), in result destroying `GstGLVideoItem`:
(`GST_DEBUG="*:3,gl*:7,qt*:7"` output)
```
Nov 09 09:39:21 imx8mmevk envInitScript.sh[1648]: 0:03:08.195660703 1648 0xaaaae23f9600 INFO qtglwidget qtitem.cc:144:~QtGLVideoItem: 0xaaaae2dcd580 Destroying QtGLVideoItem and invalidating the proxy 0xaaaae2e3e240
Nov 09 09:39:21 imx8mmevk envInitScript.sh[1648]: 0:03:08.195935191 1648 0xaaaae23f9600 DEBUG glcontext gstglcontext.c:746:gst_gl_context_finalize:<glwrappedcontext0> End of finalize
Nov 09 09:39:21 imx8mmevk envInitScript.sh[1648]: 0:03:08.196394171 1648 0xaaaae23f9600 TRACE gldisplay gstgldisplay.c:251:gst_gl_display_finalize:<gldisplayvivfb0> finalizing
Nov 09 09:39:21 imx8mmevk envInitScript.sh[1648]: 0:03:08.212644957 1648 0xaaaae23f9600 TRACE gldisplay gstgldisplay.c:251:gst_gl_display_finalize:<gldisplayegl0> finalizing
Nov 09 09:39:21 imx8mmevk envInitScript.sh[1648]: QEGLPlatformContext: eglSwapBuffers failed: 3001
Nov 09 09:39:21 imx8mmevk envInitScript.sh[1648]: QEGLPlatformContext: eglSwapBuffers failed: 3001
Nov 09 09:39:21 imx8mmevk envInitScript.sh[1648]: QEGLPlatformContext: eglSwapBuffers failed: 3001
Nov 09 09:39:21 imx8mmevk envInitScript.sh[1648]: QEGLPlatformContext: eglSwapBuffers failed: 3001
Nov 09 09:39:21 imx8mmevk envInitScript.sh[1648]: QEGLPlatformContext: eglSwapBuffers failed: 3001
Nov 09 09:39:21 imx8mmevk envInitScript.sh[1648]: QEGLPlatformContext: eglSwapBuffers failed: 3001
Nov 09 09:39:21 imx8mmevk envInitScript.sh[1648]: QEGLPlatformContext: eglSwapBuffers failed: 3001
Nov 09 09:39:21 imx8mmevk envInitScript.sh[1648]: QEGLPlatformContext: eglSwapBuffers failed: 3001
Nov 09 09:39:21 imx8mmevk envInitScript.sh[1648]: QEGLPlatformContext: eglSwapBuffers failed: 3001
...
```
Qt application UI hangs, output is being spammed with `QEGLPlatformContext: eglSwapBuffers failed: 3001`, and does not recover.
This reproduces _only_ when `g_object_set(m_sink, "widget", m_item, nullptr);` is never called, i.e. GstGLVideoItem item exists but is never used in `qmlglsink`, and so far _only_ in IMX8MM ARM device with Vivante EGL backend. On X11 Linux amd64 machines there's no such issue.
Qt application is launched like this:
```
export QT_QPA_PLATFORM=eglfs
export QT_QPA_EGLFS_INTEGRATION=eglfs_viv
export QT_QPA_EGLFS_FB=/dev/fb0
export QT_QPA_EGLFS_FORCE888=32
export QT_QPA_EGLFS_FORCEVSYNC=1
export QT_QPA_EGLFS_KMS_CONFIG="/etc/kms.conf"
export QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS=/dev/input/event1
export QT_QPA_EVDEV_MOUSE_PARAMETERS=/dev/input/event1
export QT_QPA_FB_HIDECURSOR=1
./MyApp -platform eglfs
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3119gst-examples: webrtc java version does not find gstreamer lib on Windows (and...2024-03-24T23:25:51Zvdeconinckgst-examples: webrtc java version does not find gstreamer lib on Windows (and then more)The java sendrecv sample fails with the following error (although I correctly launch it with `java -Djna.library.path=<path_to_gstreamer_bin>`):
```plaintext
java.lang.UnsatisfiedLinkError: Could not load library gstreamer
```
After a ...The java sendrecv sample fails with the following error (although I correctly launch it with `java -Djna.library.path=<path_to_gstreamer_bin>`):
```plaintext
java.lang.UnsatisfiedLinkError: Could not load library gstreamer
```
After a bit of fiddling, I think I found the cause and solution(s):
The name of the gstreamer lib in the current Windows distribution has changed from `gstreamer.1.0.dll` to `gstreamer.1.0-0.dll` (note the additional `-0`) but the build.gradle compile dependency still points to `gst1-java-core:0.9.4` which does not support that naming.
Upgrading to the latest core release (1.4.0) fixes that issue:
```plaintext
compile "org.freedesktop.gstreamer:gst1-java-core:1.4.0"
```
But then other issues arise due to the API change. Namely:
- the webrtc imports must be updated due to the package change, as follows:
```plaintext
import org.freedesktop.gstreamer.webrtc.*;
import org.freedesktop.gstreamer.webrtc.WebRTCBin.CREATE_OFFER;
import org.freedesktop.gstreamer.webrtc.WebRTCBin.ON_ICE_CANDIDATE;
import org.freedesktop.gstreamer.webrtc.WebRTCBin.ON_NEGOTIATION_NEEDED;
```
- the call to `Gst.init()` must specify a requested version (1.14) otherwise it assumes 1.8 and a version check fails later on (this one was hard to find, although it is documented in https://github.com/gstreamer-java/gst1-java-core/blob/master/README.md ) :
```plaintext
Gst.init(new Version(1,14));
```
- the call to `pad.getCaps()` must be updated to `pad.getAllowedCaps()` as follows:
```plaintext
Structure caps = pad.getAllowedCaps().getStructure(0);
```
I hope it will be patched in a future version. In the meantime it is documented here for others encountering the same issue :-)
Keep on the good work.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3413vaav1dec fails to decode av1 contents on Alder lake2024-03-22T09:07:04ZStéphane Cerveauscerveau@igalia.comvaav1dec fails to decode av1 contents on Alder lake### Describe your issue
Playing with some medias such as [BigBuckBunny mp4](https://lafibre.info/tv-numerique-hd-3d/comparer-h-264-vp9-av1/msg980640/#msg980640), the decoder fails to decode frames saying
```
0:00:00.033643671 645970 0...### Describe your issue
Playing with some medias such as [BigBuckBunny mp4](https://lafibre.info/tv-numerique-hd-3d/comparer-h-264-vp9-av1/msg980640/#msg980640), the decoder fails to decode frames saying
```
0:00:00.033643671 645970 0x63ac6da97ea0 WARN vadecoder gstvadecoder.c:662:gst_va_decoder_decode_with_aux_surface:<vadecoder0> vaEndPicture: internal decoding error
0:00:00.033651037 645970 0x63ac6da97ea0 WARN av1decoder gstav1decoder.c:739:gst_av1_decoder_handle_frame:<vaav1dec0> end picture error
0:00:00.033660416 645970 0x63ac6da97ea0 WARN videodecoder gstvideodecoder.c:4787:_gst_video_decoder_error:<vaav1dec0> error: Failed to handle the frame 1543372222
0:00:00.033733013 645970 0x63ac6da97ea0 WARN vadecoder gstvadecoder.c:662:gst_va_decoder_decode_with_aux_surface:<vadecoder0> vaEndPicture: internal decoding error
0:00:00.033735564 645970 0x63ac6da97ea0 WARN av1decoder gstav1decoder.c:739:gst_av1_decoder_handle_frame:<vaav1dec0> end picture error
0:00:00.033739535 645970 0x63ac6da97ea0 WARN videodecoder gstvideodecoder.c:4787:_gst_video_decoder_error:<vaav1dec0> error: Failed to handle the frame 1543372222
0:00:00.033755050 645970 0x63ac6da97ea0 WARN vadecoder gstvadecoder.c:662:gst_va_decoder_decode_with_aux_surface:<vadecoder0> vaEndPicture: internal decoding error
0:00:00.033757085 645970 0x63ac6da97ea0 WARN av1decoder gstav1decoder.c:739:gst_av1_decoder_handle_frame:<vaav1dec0> end picture error
0:00:00.033760540 645970 0x63ac6da97ea0 WARN videodecoder gstvideodecoder.c:4787:_gst_video_decoder_error:<vaav1dec0> error: Failed to handle the frame 1543372222
0:00:00.033769051 645970 0x63ac6da97ea0 WARN codecparsers_av1 gstav1parser.c:4235:gst_av1_parse_uncompressed_frame_header: parse uncompressed frame header error 3
0:00:00.033771246 645970 0x63ac6da97ea0 WARN av1decoder gstav1decoder.c:582:gst_av1_decoder_process_frame:<vaav1dec0> Parsing frame failed.
0:00:00.033773319 645970 0x63ac6da97ea0 WARN av1decoder gstav1decoder.c:640:gst_av1_decoder_decode_one_obu:<vaav1dec0> Failed to handle frame OBU
...
```
#### Expected Behavior
To play properly the media
#### Observed Behavior
the element does not succeed to display any of the frames
#### Setup
- **Operating System:** Linux
- **Device:** Computer
- **GStreamer Version:** 1.24
- **Command line:**
`gst-launch-1.0 filesrc location=201411_blender_big_buck_bunny_24fps_720p_av1.mp4 ! qtdemux ! av1parse ! vaav1dec ! autovideosink`
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open terminal
2. type `command`
### How reproducible is the bug?
Always
### Screenshots if relevant
### Solutions you have tried
Play other medias
### Related non-duplicate issues
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3415GStreamer 1.24.2 stable bug-fix release tracker2024-03-22T01:28:29ZTim-Philipp Müllertim@centricular.comGStreamer 1.24.2 stable bug-fix release tracker# Milestone 1.24.2
- Milestone 1.24.2 Overview: %1.24.2
- ETA: 01-07 April 2024 (maybe sooner if anything comes up)
# Todo
- [ ] [Merge Requests with `Needs backport` label](https://gitlab.freedesktop.org/groups/gstreamer/-/merge_requ...# Milestone 1.24.2
- Milestone 1.24.2 Overview: %1.24.2
- ETA: 01-07 April 2024 (maybe sooner if anything comes up)
# Todo
- [ ] [Merge Requests with `Needs backport` label](https://gitlab.freedesktop.org/groups/gstreamer/-/merge_requests?scope=all&state=merged&label_name%5B%5D=Needs%20backport¬%5Blabel_name%5D%5B%5D=Backported%20into%201.24)
- [ ] [Issues with `Needs backport` label](https://gitlab.freedesktop.org/groups/gstreamer/-/issues?scope=all&utf8=%E2%9C%93&state=all&label_name%5B%5D=Needs%20backport)
- [ ] [Merge Requests with `Maybe backport` label](https://gitlab.freedesktop.org/groups/gstreamer/-/merge_requests?scope=all&utf8=%E2%9C%93&state=all&label_name%5B%5D=Maybe%20backport)
- [ ] [Merge Requests with `1.24.2` milestone](https://gitlab.freedesktop.org/groups/gstreamer/-/merge_requests?milestone_title=1.24.2)
- [ ] [Issues with `1.24.2` milestone](https://gitlab.freedesktop.org/groups/gstreamer/-/issues?milestone_title=1.24.2)
- [ ] [Issues with `Security` label](https://gitlab.freedesktop.org/groups/gstreamer/-/issues?scope=all&utf8=%E2%9C%93&state=all&label_name%5B%5D=Security)
- [ ] Blockers / Todo
- nothing so far
# Prep
- [ ] gst-plugins-rs
- [ ] make sure 0.12 branch is up-to-date with regards to backports ( @slomo)
- [ ] update `Cargo.lock` in 0.12 branch (if needed)
- [ ] double-check meson.build version matches Cargo.toml version
- [ ] add `gstreamer-1.24.2` tag pointing to tip of 0.12 branch
- [ ] www: add release note entry and add contributors
- [ ] including gst-plugin-rs fixes perhaps
- [ ] update translations, maybe (also in main, then backport)
# GStreamer
- [ ] MR / commit for release
- [ ] tag release
- [ ] upload tarballs (plus checksums and GPG signatures)
- [ ] back to dev in 1.24 branch
# Cerbero
- [ ] pending merge requests: https://gitlab.freedesktop.org/gstreamer/cerbero/-/merge_requests?scope=all&state=opened&target_branch=1.24
- [ ] [cerbero issues with 1.24.2 milestone](https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/?sort=created_date&state=opened&milestone_title=1.24.2&first_page_size=100)
- [ ] build 1.24.2 tag
- [ ] binaries
- [ ] Windows x86 MinGW + MSVC ( @nirbheek)
- [ ] Windows x86_64 MinGW + MSVC ( @nirbheek)
- [ ] Android
- [ ] macOS ( @ystreet)
- [ ] iOS ( @ystreet)
- [ ] source bundle
- [ ] check for sha265sums for binaries
- [ ] check for GPG signatures for binaries
- [ ] tag cerbero ( @tpm)
- [ ] build 1.24 branch again
- [ ] update download section on website
- [ ] announce binaries (twitter, discourse, gstreamer-devel)
# Announce
- [ ] Discourse
- [ ] Website: news item + release notes
- [ ] Twitter ( @tpm)
- [ ] Mastodon ( @slomo)
- [ ] IRC channel topic
- [ ] Mailing lists
# Post release
- [ ] Add 1.24.3 milestone
- [ ] Add 1.24.3 tracker issue1.24.2Tim-Philipp Müllertim@centricular.comTim-Philipp Müllertim@centricular.com2024-04-02https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3411udpsrc: Surprising effects of reuse property being default true2024-03-21T12:37:55ZJonas Danielssonudpsrc: Surprising effects of reuse property being default true### Describe your issue
When having an application with many (\~100) `udpsrc` elements all allocating their ports automatically (port = 0) we tracked down some very confusing behavior to the root cause of two different `udpsrc` allocati...### Describe your issue
When having an application with many (\~100) `udpsrc` elements all allocating their ports automatically (port = 0) we tracked down some very confusing behavior to the root cause of two different `udpsrc` allocating the same port.
#### Expected Behavior
The expected behavior was for none of the `udpsrc` to allocate a port already bound by another `udpsrc`
### Additional Information
This is on Linux:
```shell
$ uname -a
Linux fedora 6.7.7-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 1 16:53:59 UTC 2024 x86_64 GNU/Linux
```
After setting the `reuse` property of `udpsrc` to false this behavior went away. I constructed a small test to check the likelihood of port conflicts using `udpsrc`:
```Rust
#[tracing_test::traced_test]
#[test]
fn test_port_conflict() {
gst::init().unwrap();
let mut map = std::collections::HashMap::new();
loop {
let udpsrc = spiideo_gst_utils::make_element("udpsrc", None).unwrap();
udpsrc.set_property("port", 0);
udpsrc.set_state(gst::State::Ready).unwrap();
let port = udpsrc.property::<i32>("port");
tracing::info!("port: {port}");
if map.contains_key(&port) {
tracing::error!("Port conflict on {port} after {} iterations", map.len());
udpsrc.set_state(gst::State::Null).unwrap();
break;
}
map.insert(port, udpsrc);
}
map.values().into_iter().for_each(|element| { element.set_state(gst::State::Null).unwrap(); });
}
```
This resulted in it being quite likely (due to the Birthday paradox, there are many pairs that can conflict):
```shell
running 1 test
INFO test_port_conflict: shibuya::ingestion_jack::test: port: 42937
INFO test_port_conflict: shibuya::ingestion_jack::test: port: 39148
INFO test_port_conflict: shibuya::ingestion_jack::test: port: 57579
INFO test_port_conflict: shibuya::ingestion_jack::test: port: 59762
[...]
INFO test_port_conflict: shibuya::ingestion_jack::test: port: 54535
INFO test_port_conflict: shibuya::ingestion_jack::test: port: 39319
INFO test_port_conflict: shibuya::ingestion_jack::test: port: 58404
ERROR test_port_conflict: shibuya::ingestion_jack::test: Port conflict on 58404 after 249 iterations
test ingestion_jack::test::test_port_conflict ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 19 filtered out; finished in 0.08s
```
The issue here is the unexpected effect of `SO_REUSEADDR` for UDP sockets (at least on Linux!):
From the [`socket(7)`](http://man7.org/linux/man-pages/man7/socket.7.html) man page:
```
SO_REUSEADDR
Indicates that the rules used in validating addresses supplied
in a bind(2) call should allow reuse of local addresses. For
AF_INET sockets this means that a socket may bind, except when
there is an active listening socket bound to the address.
```
UDP does not do listen though ...
From blog post: https://gavv.net/articles/ephemeral-port-reuse/
> Hence, when an ephemeral port is allocated, `SO_REUSEADDR` enables the kernel to reuse any other non-listening ephemeral port.
>
> The important point here is that the kernel doesn’t check whether there is an opened socket for an ephemeral port, it only checks whether there is a socket in the listening state for that port.
Given all this, is revisiting `reuse` default `true` for `udpsrc` an option?1.26-dev-cyclehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3354va: radeonsi: DRM RGB formats doesn't look correctly mapped to VA formats2024-03-21T11:46:48ZVíctor Manuel Jáquez Lealva: radeonsi: DRM RGB formats doesn't look correctly mapped to VA formatsFrom the matrix channel:
> robert.mader
>
> Hm, is it just me or does vapostproc on AMD really only support RGB formats that the same Mesa driver does not support for texturing (it supports e.g. DRM BA24 while EGL only supports AB24)? H...From the matrix channel:
> robert.mader
>
> Hm, is it just me or does vapostproc on AMD really only support RGB formats that the same Mesa driver does not support for texturing (it supports e.g. DRM BA24 while EGL only supports AB24)? Has > anyone recall such issues with va on AMD?1.24.2