GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-11-03T16:42:15Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1537glimagesink is not a great pick for autovideosink2022-11-03T16:42:15ZGuillaume Desmottesglimagesink is not a great pick for autovideosink`glimagesink` is automatically picked by `autovideosink` when available:
```
gst-launch-1.0 videotestsrc ! autovideosink -v
Setting pipeline to PAUSED ...
0:00:00.019496855 581347 0x1c24610 DEBUG autodetect gstautodetec...`glimagesink` is automatically picked by `autovideosink` when available:
```
gst-launch-1.0 videotestsrc ! autovideosink -v
Setting pipeline to PAUSED ...
0:00:00.019496855 581347 0x1c24610 DEBUG autodetect gstautodetect.c:367:gst_auto_detect_detect:<autovideosink0> Creating new kid
0:00:00.019809556 581347 0x1c24610 LOG autodetect gstautodetect.c:273:gst_auto_detect_find_best:<autovideosink0> Trying to find usable video elements ...
0:00:00.033455152 581347 0x1c24610 DEBUG autodetect gstautodetect.c:283:gst_auto_detect_find_best:<autovideosink0> Testing glimagesink
0:00:00.034114590 581347 0x1c24610 DEBUG autodetect gstautodetect.c:291:gst_auto_detect_find_best:<autovideosink0> Checking caps: video/x-raw vs. video/x-raw(memory:GLMemory, meta:GstVideoOverlayComposition), format=(string)RGBA, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ], texture-target=(string){ 2D, external-oes }; video/x-raw(memory:GLMemory), format=(string)RGBA, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ], texture-target=(string){ 2D, external-oes }; video/x-raw(memory:GLMemory, meta:GstVideoOverlayComposition), format=(string)RGBA, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ], texture-target=(string){ 2D, rectangle, external-oes }; video/x-raw(memory:GLMemory, meta:GstVideoOverlayComposition), format=(string){ RGBA, RGB, RGBx, BGR, BGRx, BGRA, xRGB, xBGR, ARGB, ABGR, GRAY8, GRAY16_LE, GRAY16_BE, AYUV, VUYA, YUY2, UYVY, GBRA, GBR, RGBP, BGRP, Y444, I420, YV12, Y42B, Y41B, NV12, NV21, NV16, NV61, A420, AV12, ARGB64, RGB16, BGR16, BGR10A2_LE, RGB10A2_LE, Y410, P010_10LE, P012_LE, P016_LE, Y210, Y212_LE, Y412_LE, NV12_16L32S, NV12_4L4 }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ], texture-target=(string){ 2D, rectangle, external-oes }; video/x-raw(memory:GLMemory), format=(string)RGBA, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ], texture-target=(string){ 2D, rectangle, external-oes }; video/x-raw(memory:GLMemory), format=(string){ RGBA, RGB, RGBx, BGR, BGRx, BGRA, xRGB, xBGR, ARGB, ABGR, GRAY8, GRAY16_LE, GRAY16_BE, AYUV, VUYA, YUY2, UYVY, GBRA, GBR, RGBP, BGRP, Y444, I420, YV12, Y42B, Y41B, NV12, NV21, NV16, NV61, A420, AV12, ARGB64, RGB16, BGR16, BGR10A2_LE, RGB10A2_LE, Y410, P010_10LE, P012_LE, P016_LE, Y210, Y212_LE, Y412_LE, NV12_16L32S, NV12_4L4 }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ], texture-target=(string){ 2D, rectangle, external-oes }; video/x-raw(memory:GLMemory, meta:GstVideoOverlayComposition), format=(string)RGBA, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw(memory:GLMemory), format=(string)RGBA, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw(memory:GLMemory, meta:GstVideoOverlayComposition), format=(string){ RGBA, RGB, RGBx, BGR, BGRx, BGRA, xRGB, xBGR, ARGB, ABGR, GRAY8, GRAY16_LE, GRAY16_BE, AYUV, VUYA, YUY2, UYVY, GBRA, GBR, RGBP, BGRP, Y444, I420, YV12, Y42B, Y41B, NV12, NV21, NV16, NV61, A420, AV12, ARGB64, RGB16, BGR16, BGR10A2_LE, RGB10A2_LE, Y410, P010_10LE, P012_LE, P016_LE, Y210, Y212_LE, Y412_LE, NV12_16L32S, NV12_4L4 }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw(memory:GLMemory), format=(string){ RGBA, RGB, RGBx, BGR, BGRx, BGRA, xRGB, xBGR, ARGB, ABGR, GRAY8, GRAY16_LE, GRAY16_BE, AYUV, VUYA, YUY2, UYVY, GBRA, GBR, RGBP, BGRP, Y444, I420, YV12, Y42B, Y41B, NV12, NV21, NV16, NV61, A420, AV12, ARGB64, RGB16, BGR16, BGR10A2_LE, RGB10A2_LE, Y410, P010_10LE, P012_LE, P016_LE, Y210, Y212_LE, Y412_LE, NV12_16L32S, NV12_4L4 }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw(memory:DMABuf, meta:GstVideoOverlayComposition), format=(string)RGBA, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw(memory:DMABuf), format=(string)RGBA, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw(memory:DMABuf, meta:GstVideoOverlayComposition), format=(string){ RGBA, RGB, RGBx, BGR, BGRx, BGRA, xRGB, xBGR, ARGB, ABGR, GRAY8, GRAY16_LE, GRAY16_BE, AYUV, VUYA, YUY2, UYVY, GBRA, GBR, RGBP, BGRP, Y444, I420, YV12, Y42B, Y41B, NV12, NV21, NV16, NV61, A420, AV12, ARGB64, RGB16, BGR16, BGR10A2_LE, RGB10A2_LE, Y410, P010_10LE, P012_LE, P016_LE, Y210, Y212_LE, Y412_LE, NV12_16L32S, NV12_4L4 }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw(memory:DMABuf), format=(string){ RGBA, RGB, RGBx, BGR, BGRx, BGRA, xRGB, xBGR, ARGB, ABGR, GRAY8, GRAY16_LE, GRAY16_BE, AYUV, VUYA, YUY2, UYVY, GBRA, GBR, RGBP, BGRP, Y444, I420, YV12, Y42B, Y41B, NV12, NV21, NV16, NV61, A420, AV12, ARGB64, RGB16, BGR16, BGR10A2_LE, RGB10A2_LE, Y410, P010_10LE, P012_LE, P016_LE, Y210, Y212_LE, Y412_LE, NV12_16L32S, NV12_4L4 }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw(meta:GstVideoGLTextureUploadMeta, meta:GstVideoOverlayComposition), format=(string)RGBA, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw(meta:GstVideoGLTextureUploadMeta), format=(string)RGBA, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw(memory:SystemMemory, meta:GstVideoOverlayComposition), format=(string)RGBA, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw, format=(string)RGBA, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw(memory:SystemMemory, meta:GstVideoOverlayComposition), format=(string){ RGBA, RGB, RGBx, BGR, BGRx, BGRA, xRGB, xBGR, ARGB, ABGR, GRAY8, GRAY16_LE, GRAY16_BE, AYUV, VUYA, YUY2, UYVY, GBRA, GBR, RGBP, BGRP, Y444, I420, YV12, Y42B, Y41B, NV12, NV21, NV16, NV61, A420, AV12, ARGB64, RGB16, BGR16, BGR10A2_LE, RGB10A2_LE, Y410, P010_10LE, P012_LE, P016_LE, Y210, Y212_LE, Y412_LE, NV12_16L32S, NV12_4L4 }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; video/x-raw, format=(string){ RGBA, RGB, RGBx, BGR, BGRx, BGRA, xRGB, xBGR, ARGB, ABGR, GRAY8, GRAY16_LE, GRAY16_BE, AYUV, VUYA, YUY2, UYVY, GBRA, GBR, RGBP, BGRP, Y444, I420, YV12, Y42B, Y41B, NV12, NV21, NV16, NV61, A420, AV12, ARGB64, RGB16, BGR16, BGR10A2_LE, RGB10A2_LE, Y410, P010_10LE, P012_LE, P016_LE, Y210, Y212_LE, Y412_LE, NV12_16L32S, NV12_4L4 }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]
0:00:00.034153875 581347 0x1c24610 DEBUG autodetect gstautodetect.c:302:gst_auto_detect_find_best:<autovideosink0> Found compatible caps
0:00:00.071485071 581347 0x1c24610 DEBUG autodetect gstautodetect.c:309:gst_auto_detect_find_best:<autovideosink0> This worked!
0:00:00.072172900 581347 0x1c24610 DEBUG autodetect gstautodetect.c:326:gst_auto_detect_find_best:<autovideosink0> done trying
```
It's not ideal as it does not provide any window management support preventing the video to be resized or moved around.
`gtksink` and `gtkglsink` for example would be better choices for most use cases.
Is there any reason why `glimagesink` has `GST_RANK_SECONDARY` while the GTK sinks have `GST_RANK_NONE`?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1535vah264dec + videoconvert is slow2022-11-15T13:35:00ZEric Knappvah264dec + videoconvert is slowConverting the output of vah264dec to anything with videoconvert is very slow. When resolution and framerate are high enough (e.g. 720p30), the conversion speed is less than realtime. Single core CPU usage hits 100%. The same pipeline wi...Converting the output of vah264dec to anything with videoconvert is very slow. When resolution and framerate are high enough (e.g. 720p30), the conversion speed is less than realtime. Single core CPU usage hits 100%. The same pipeline with vaapih264dec or vapostproc is much faster. I tried converting to multiple formats and they were all slow when vah264dec was paired with videoconvert. Logs do not show any issues.
#### Setup
- **Operating System:** Ubuntu 20.04.5
- **CPU:** i7-6700
- **GStreamer Version:** Main branch
SLOW:
`gst-launch-1.0 videotestsrc ! 'video/x-raw,width=1280,height=720,framerate=30/1' ! vah264enc ! queue ! h264parse ! vah264dec ! 'video/x-raw,format=NV12' ! videoconvert ! 'video/x-raw,format=UYVY' ! fakesink`
FAST (vaapih264dec):
`gst-launch-1.0 videotestsrc ! 'video/x-raw,width=1280,height=720,framerate=30/1' ! vah264enc ! queue ! h264parse ! vaapih264dec ! 'video/x-raw,format=NV12' ! videoconvert ! 'video/x-raw,format=UYVY' ! fakesink`
FAST (vapostproc):
`gst-launch-1.0 videotestsrc ! 'video/x-raw,width=1280,height=720,framerate=30/1' ! vah264enc ! queue ! h264parse ! vah264dec ! 'video/x-raw,format=NV12' ! vapostproc ! 'video/x-raw,format=UYVY' ! fakesink`https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1533wpe: crash in gst_wpe_video_src_create2022-11-02T13:12:24ZGuillaume Desmotteswpe: crash in gst_wpe_video_src_createRunning this pipeline raises a crash after a few seconds:
`gst-launch-1.0 -v wpevideosrc location="https://onestream.live" ! queue ! gtksink`
Note that the website is never rendered either.
```
Thread 12 "wpevideosrc0:sr" received sig...Running this pipeline raises a crash after a few seconds:
`gst-launch-1.0 -v wpevideosrc location="https://onestream.live" ! queue ! gtksink`
Note that the website is never rendered either.
```
Thread 12 "wpevideosrc0:sr" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdd91b640 (LWP 360882)]
__memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:273
273 VMOVU (%rsi), %VEC(0)
(gdb) bt
#0 __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:273
#1 0x00007ffff7eae657 in _sysmem_copy (mem=0x7fffc40045a0, offset=<optimized out>, size=8294400) at ../subprojects/gstreamer/gst/gstallocator.c:485
#2 0x00007ffff7eba08e in gst_buffer_copy_into (dest=0x74a480, src=src@entry=0x74a6c0, flags=flags@entry=(GST_BUFFER_COPY_FLAGS | GST_BUFFER_COPY_TIMESTAMPS | GST_BUFFER_COPY_META | GST_BUFFER_COPY_MEMORY | GST_BUFFER_COPY_DEEP), offset=offset@entry=0, size=8294400, size@entry=18446744073709551615) at ../subprojects/gstreamer/gst/gstbuffer.c:638
#3 0x00007ffff7ebca70 in gst_buffer_copy_with_flags (buffer=0x74a6c0, flags=(GST_BUFFER_COPY_FLAGS | GST_BUFFER_COPY_TIMESTAMPS | GST_BUFFER_COPY_META | GST_BUFFER_COPY_MEMORY | GST_BUFFER_COPY_DEEP)) at ../subprojects/gstreamer/gst/gstbuffer.c:727
#4 0x00007ffff7e66cdd in gst_wpe_video_src_create(GstBaseSrc*, guint64, guint, GstBuffer**) (bsrc=0x6c8c60, offset=18446744073709551615, length=4096, buf=0x7fffdd91ac60) at ../subprojects/gst-plugins-bad/ext/wpe/gstwpevideosrc.cpp:195
#5 0x00007ffff7689576 in gst_base_src_get_range (src=src@entry=0x6c8c60, offset=offset@entry=18446744073709551615, length=<optimized out>, buf=buf@entry=0x7fffdd91ad48) at ../subprojects/gstreamer/libs/gst/base/gstbasesrc.c:2587
#6 0x00007ffff768da6d in gst_base_src_loop (pad=0x6ca140) at ../subprojects/gstreamer/libs/gst/base/gstbasesrc.c:2911
#7 0x00007ffff7f2bc71 in gst_task_func (task=0x74a3b0) at ../subprojects/gstreamer/gst/gsttask.c:384
#8 0x00007ffff7da0d02 in g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/gthreadpool.c:354
#9 0x00007ffff7d9e302 in g_thread_proxy (data=0x9804c0) at ../glib/gthread.c:827
#10 0x00007ffff7a8cded in start_thread (arg=<optimized out>) at pthread_create.c:442
#11 0x00007ffff7b12370 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1531vah264enc: [radeon]: failure at using a 640x482 size2022-11-01T19:31:39ZVíctor Manuel Jáquez Lealvah264enc: [radeon]: failure at using a 640x482 sizeWhile this pipeline works (gstreamer-vaapi):
```
gst-launch-1.0 videotestsrc num-buffers=1 ! video/x-raw, format=NV12, width=640, height=482 ! vaapih264enc ! video/x-h264, profile=high ! fakesink
```
This does not (gstva):
```
gst-la...While this pipeline works (gstreamer-vaapi):
```
gst-launch-1.0 videotestsrc num-buffers=1 ! video/x-raw, format=NV12, width=640, height=482 ! vaapih264enc ! video/x-h264, profile=high ! fakesink
```
This does not (gstva):
```
gst-launch-1.0 videotestsrc num-buffers=1 ! video/x-raw, format=NV12, width=640, height=482 ! vah264enc ! video/x-h264, profile=high ! fakesink
```
Not all frame sizes fail, just only those where height is 482, 486, 490, ... perhaps all those that aren't `height % 4 = 0`
Nonetheless, vapostproc can upload frames with this size. So it's specific to encoder profile.
It's not ruled out that it might be a driver bug under gstva configuration, which is different of gstreamer-vaapi.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1529dashdemux2: support thumbnail_tile representations2022-10-30T20:06:56Zdiegonietodashdemux2: support thumbnail_tile representationsCurrently in dashdemux2 does not recognize MPDs with thumbnail tiles representationCurrently in dashdemux2 does not recognize MPDs with thumbnail tiles representationhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1528ID3 tags are not read when streaming HLS streams2022-11-01T11:33:44ZMichael LugmairID3 tags are not read when streaming HLS streams### Describe your issue
When listening to the Soma.fm HLS streams through Sayonara, the tags are not updated.
`GST_MESSAGE_TAG` is received, but only bitrate and codec related stuff is visible there. I also tested with `gst-launch-1.0...### Describe your issue
When listening to the Soma.fm HLS streams through Sayonara, the tags are not updated.
`GST_MESSAGE_TAG` is received, but only bitrate and codec related stuff is visible there. I also tested with `gst-launch-1.0` and the behavior is identical. So I guess it's not a problem of Sayonara.
It seems the tags are not evaluated or id3 tags are ignored for FLAC mp4 files.
#### Expected Behavior
id3 tags are continuously updated during streaming.
#### Observed Behavior
Received tags:
```
taglist=(taglist)"taglist, \
nominal-bitrate=(uint)1155201, \
audio-codec=(string)"Free Lossless Audio Codec (FLAC)", \
minimum-bitrate=(uint)1183218, maximum-bitrate=(uint)1263749, \
bitrate=(uint)1203054;";
```
#### Setup
- **Operating System:** Linux. Tested on Ubuntu and Manjaro
- **Device:** Notebook
- **GStreamer Version:** 1.20.3
- **Command line:** `GST_DEBUG=6 gst-launch-1.0 -vv souphttpsrc location=https://hls.somafm.com/hls/groovesalad/FLAC/program.m3u8 ! hlsdemux ! decodebin ! audioconvert name=converter-1 ! autoaudiosink sync=false`
### Steps to reproduce the bug
* Open terminal
```
* GST_DEBUG=6 gst-launch-1.0 -vv souphttpsrc location=https://hls.somafm.com/hls/groovesalad/FLAC/program.m3u8 ! hlsdemux ! decodebin ! audioconvert name=converter-1 ! autoaudiosink sync=false 2>&1 | grep -i tag
```
* No indication that tags are evaluated
### How reproducible is the bug?
100%
### Screenshots if relevant
### Solutions you have tried
I had a look at https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/ext/hls/gsthlsdemux-util.c#L267 in the gstreamer bad plugins. There's code available for reading the id3 tags.
I manually downloaded 1 minute of the stream. The tags are visible when inspecting the resulting file with a hex editor. See the following script [download-soma-radio-hls.sh](/uploads/d307cf52c5f27fda0979a88861d9e1ab/download-soma-radio-hls.sh)
### Related non-duplicate issues
None found.
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/263aws: does not support custom region (regression from the rusoto plugin)2023-05-31T14:05:33ZGuillaume Desmottesaws: does not support custom region (regression from the rusoto plugin)The new `aws` plugin does not seem to handle custom regions as the `rusoto` plugin did.
Compare the `Settings::to_uri()` implementation of [aws](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/blob/main/net/aws/src/s3sink/imp....The new `aws` plugin does not seem to handle custom regions as the `rusoto` plugin did.
Compare the `Settings::to_uri()` implementation of [aws](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/blob/main/net/aws/src/s3sink/imp.rs#L117) and the [rusoto plugin](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/blob/0.8/net/rusoto/src/s3sink/imp.rs#L118).
The old plugin had code to handle custom regions and encode them properly.
I'm not an AWS expert so I may have missed something but it seems that custom regions will no longer work because of this.
cc @arunhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1524gl: Segfault in gst_gl_window_cocoa_queue_resize() on macOS 13/M12023-09-27T15:50:35ZBoris Vinogradovgl: Segfault in gst_gl_window_cocoa_queue_resize() on macOS 13/M1I run basic tutorial code number 5 (gstreamer playbin + gtk overlay) on Mac OS 12.6/13 (Apple M1 CPU) and have segmentation fault after start demo.
After investigate I found line creates crash - if I comment this line demo works without ...I run basic tutorial code number 5 (gstreamer playbin + gtk overlay) on Mac OS 12.6/13 (Apple M1 CPU) and have segmentation fault after start demo.
After investigate I found line creates crash - if I comment this line demo works without crash:
```rust
video_overlay.set_window_handle(window as usize);
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/262Static gstbuild fails in scheduled pipelines Job Failed #304582312023-05-31T13:42:35ZJordan PetridіsStatic gstbuild fails in scheduled pipelines Job Failed #30458231Job [#30458231](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/jobs/30458231) failed for 4c7dfceb9ae61a48d8634b13766fa9ca1b6b08a1:
Not exactly sure when this started happening, but basically the job in now hanging when trying...Job [#30458231](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/jobs/30458231) failed for 4c7dfceb9ae61a48d8634b13766fa9ca1b6b08a1:
Not exactly sure when this started happening, but basically the job in now hanging when trying to generate `Gst.gir`.
Here are the logs when reproduced locally.
```
root@96b8dece257d:/gstreamer# export G_DEBUG=fatal-criticals
root@96b8dece257d:/gstreamer# ninja -C build-gst-full/ -v
ninja: Entering directory `build-gst-full/'
[1/2] /usr/local/bin/meson --internal exe --unpickle /gstreamer/build-gst-full/meson-private/meson_exe_g-ir-scanner_7b19a526e4c404adbce253c56436d20001144e62.dat
FAILED: Gst-1.0.gir
/usr/local/bin/meson --internal exe --unpickle /gstreamer/build-gst-full/meson-private/meson_exe_g-ir-scanner_7b19a526e4c404adbce253c56436d20001144e62.dat
while executing ['/usr/bin/g-ir-scanner', '--no-libtool', '--namespace=Gst', '--nsversion=1.0', '--warn-all', '--output', 'Gst-1.0.gir', '--add-init-section=extern void gst_init(gint*,gchar**);g_setenv("GST_REGISTRY_DISABLE", "yes", TRUE);g_setenv("GST_REGISTRY_1.0", "/no/way/this/exists.reg", TRUE);g_setenv("GST_PLUGIN_PATH_1_0", "", TRUE);g_setenv("GST_PLUGIN_SYSTEM_PATH_1_0", "", TRUE);gst_init(NULL,NULL);', '--quiet', '--c-include=gst/gst.h', '--cflags-begin', '-I/gstreamer/subprojects/gstreamer/gst/..', '-I/gstreamer/build-gst-full/subprojects/gstreamer/gst/..', '-DGST_DISABLE_MINIOBJECT_INLINE_FUNCTIONS', '--cflags-end', '--add-include-path=/gstreamer/build-gst-full', '-I/gstreamer/', '-I/gstreamer/build-gst-full/', '-I/gstreamer/subprojects/gstreamer/.', '-I/gstreamer/build-gst-full/subprojects/gstreamer/.', '-I/gstreamer/subprojects/gstreamer/.', '-I/gstreamer/build-gst-full/subprojects/gstreamer/.', '-I/gstreamer/subprojects/gst-plugins-base/gst-libs', '-I/gstreamer/build-gst-full/subprojects/gst-plugins-base/gst-libs', '-I/gstreamer/subprojects/gst-plugins-base/gst-libs', '-I/gstreamer/build-gst-full/subprojects/gst-plugins-base/gst-libs', '-I/gstreamer/subprojects/gstreamer/libs', '-I/gstreamer/build-gst-full/subprojects/gstreamer/libs', '-I/gstreamer/subprojects/gstreamer/.', '-I/gstreamer/build-gst-full/subprojects/gstreamer/.', '-I/gstreamer/subprojects/gstreamer/.', '-I/gstreamer/build-gst-full/subprojects/gstreamer/.', '-I/gstreamer/subprojects/orc/.', '-I/gstreamer/build-gst-full/subprojects/orc/.', '-I/gstreamer/subprojects/gst-plugins-base/gst-libs', '-I/gstreamer/build-gst-full/subprojects/gst-plugins-base/gst-libs', '-I/gstreamer/subprojects/gst-plugins-base/gst-libs', '-I/gstreamer/build-gst-full/subprojects/gst-plugins-base/gst-libs', '-I/gstreamer/subprojects/gst-plugins-base/gst-libs', '-I/gstreamer/build-gst-full/subprojects/gst-plugins-base/gst-libs', '-I/gstreamer/subprojects/gst-plugins-base/gst-libs', '-I/gstreamer/build-gst-full/subprojects/gst-plugins-base/gst-libs', '--filelist=/gstreamer/build-gst-full/libgstreamer-full-1.0.so.p/Gst_1.0_gir_filelist', '--include=GLib-2.0', '--include=GObject-2.0', '--include=GModule-2.0', '--symbol-prefix=gst', '--identifier-prefix=Gst', '--pkg-export=gstreamer-1.0', '--cflags-begin', '-I/gstreamer/subprojects/gstreamer/.', '-I/gstreamer/build-gst-full/subprojects/gstreamer/.', '-I/gstreamer/subprojects/gst-plugins-base/gst-libs', '-I/gstreamer/build-gst-full/subprojects/gst-plugins-base/gst-libs', '-I/gstreamer/subprojects/gstreamer/libs', '-I/gstreamer/build-gst-full/subprojects/gstreamer/libs', '-I/gstreamer/subprojects/orc/.', '-I/gstreamer/build-gst-full/subprojects/orc/.', '-I/usr/include/glib-2.0', '-I/usr/lib/x86_64-linux-gnu/glib-2.0/include', '-DGST_STATIC_COMPILATION', '-DORC_STATIC_COMPILATION', '-I/usr/local/include/pango-1.0', '-I/usr/include/harfbuzz', '-I/usr/include/libmount', '-I/usr/include/blkid', '-I/usr/include/fribidi', '-I/usr/include/cairo', '-I/usr/include/pixman-1', '-I/usr/include/uuid', '-I/usr/include/freetype2', '-I/usr/include/libpng16', '-I/usr/local/include/gstreamer-1.0', '-I/usr/local/include/orc-0.4', '-I/usr/local/include', '-I/usr/local/include/gtk-4.0', '-I/usr/include/gdk-pixbuf-2.0', '-I/usr/include/graphene-1.0', '-I/usr/lib/x86_64-linux-gnu/graphene-1.0/include', '-I/usr/include/gobject-introspection-1.0', '--cflags-end', '--add-include-path=/usr/local/share/gir-1.0', '--add-include-path=/usr/share/gir-1.0', '-L/gstreamer/build-gst-full/', '--library', 'gstreamer-full-1.0', '-L/gstreamer/build-gst-full/subprojects/gst-plugins-rs', '-L/usr/local/lib/x86_64-linux-gnu', '--extra-library=glib-2.0', '--extra-library=gobject-2.0', '--extra-library=gmodule-2.0', '--extra-library=m', '--extra-library=z', '--extra-library=ssl', '--extra-library=crypto', '-L/usr/local/lib/x86_64-linux-gnu', '--extra-library=pangocairo-1.0', '--extra-library=pango-1.0', '--extra-library=harfbuzz', '--extra-library=cairo', '--extra-library=gstwebrtc-1.0', '--extra-library=gstbase-1.0', '--extra-library=gstreamer-1.0', '--extra-library=gio-2.0', '--extra-library=gstapp-1.0', '--extra-library=gstsdp-1.0', '--extra-library=gstrtp-1.0', '--extra-library=gstvideo-1.0', '--extra-library=webpdemux', '--extra-library=webp', '--extra-library=cairo-gobject', '--extra-library=dav1d', '--extra-library=sodium', '--extra-library=gtk-4', '--extra-library=gdk_pixbuf-2.0', '--extra-library=graphene-1.0', '--extra-library=girepository-1.0', '--sources-top-dirs', '/gstreamer/subprojects/', '--sources-top-dirs', '/gstreamer/build-gst-full/subprojects/']
--- stdout ---
--- stderr ---
(Gst-1.0:42980): GLib-GObject-WARNING **: 17:16:13.670: cannot register existing type 'GstRTPHeaderExtension'
(Gst-1.0:42980): GLib-GObject-WARNING **: 17:16:13.670: cannot add private field to invalid (non-instantiatable) type '<invalid>'
(Gst-1.0:42980): GLib-CRITICAL **: 17:16:13.670: g_once_init_leave: assertion 'result != 0' failed
Command '['/gstreamer/build-gst-full/tmp-introspectc7w54wlp/Gst-1.0', '--introspect-dump=/gstreamer/build-gst-full/tmp-introspectc7w54wlp/functions.txt,/gstreamer/build-gst-full/tmp-introspectc7w54wlp/dump.xml']' died with <Signals.SIGTRAP: 5>.
ninja: build stopped: subcommand failed.
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1519SSRCs from a RTCP FB FIR packet is not propagated upstream2022-10-28T11:51:39ZJohan SternerupSSRCs from a RTCP FB FIR packet is not propagated upstreamWhen an RTCP FB FIR is handled in rtp_session_process_fir() it will generate a GstForceKeyUnit event with the property "ssrc" set to the contents of "media source" within the RTCP FB packet. However, as described in RFC5104 (section 4.3....When an RTCP FB FIR is handled in rtp_session_process_fir() it will generate a GstForceKeyUnit event with the property "ssrc" set to the contents of "media source" within the RTCP FB packet. However, as described in RFC5104 (section 4.3.1.2) the "media source" field is not used and SHALL be set to 0 and that's exactly what is done in session_fir() on the sender side. Instead of using "media source" as SSRC the SSRCs of the media senders are added in the fci data and there may be several.
The GstForceKeyUnit event is propagated from rtpbin upstream until it reaches rtpfunnel. rtpfunnel tries to match the ssrc that is 0 with one its pads but the lookup fails because there is no pad that matches ssrc=0. Consequently the event never reaches its upstream producer elements.
Somehow we have to pass on the SSRCs we get from the RTCP FB fci data into one or several GstForceKeyUnit event so that events are passed to all senders matching one of the SSRCs. If I look at just this specfic setup I think the ideal thing would be to pass an array of SSRCs within the GstKeyForceUnit (omitting that I don't have a clue how to pass an array in a GstStructure). As long as there is logic in rtpfunnel to handle the SSRCs and match them to the correct upstream branch this should work. However, there may be other setups where there is no rtpfunnel or the corresponding required logic.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1518matroskademux fails to demux video from valid .webm2024-02-19T10:24:21ZDaniel Limiamatroskademux fails to demux video from valid .webm### Describe your issue
The following valid .webm video (See attachments) recorded using Google Chrome MediaRecord API fails to be demuxed using matroskademux. Video returns empty while audio works properly.
#### Expected Behavior
Video...### Describe your issue
The following valid .webm video (See attachments) recorded using Google Chrome MediaRecord API fails to be demuxed using matroskademux. Video returns empty while audio works properly.
#### Expected Behavior
Video should be properly demuxed from a valid .webm file recorded with Google Chrome using MediaRecord API
#### Observed Behavior
Using matroskademux fails to demux video from a valid .webm file recorded with Google Chrome using MediaRecord API
#### Setup
- **Operating System:** MacOS 12.5 Monterrey
- **Device:** Computer
- **GStreamer Version:** latest
- **Command line:** `gst-launch-1.0 filesrc location=./video.webm ! matroskademux ! fakesink`
### Steps to reproduce the bug
1. open terminal
2. type ` GST_DEBUG_DUMP_DOT_DIR=~/ gst-launch-1.0 filesrc location=./video.webm ! matroskademux ! fakesink`. video.webm is the attached file
3. Use `ls -1 ~/gst_dot_files/*.dot | xargs -I{} dot -Tpng {} -o{}.png` to transform dot files to png. You will see how the audio track is actually demuxed, but the video track is not.
### How reproducible is the bug?
Always
### Screenshots if relevant
### Solutions you have tried
I first tried to use decodebin and decodebin3 which resulted in the same problem. I tried to reproduce what decodebin does with the video and then I found out the video track was not being demuxed.
### Related non-duplicate issues
### Additional Information
The video:![video](/uploads/dff809b2535d1e1ebf24779dec8aa7f5/video.webm)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1517inputselector and clocksync should proactively query upstream latency2022-10-24T14:40:30ZVivia Nikolaidouinputselector and clocksync should proactively query upstream latencyThe following discussion from !3256 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3256#note_1604462): (+1 comment)
> If no upstream latency was queried...The following discussion from !3256 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3256#note_1604462): (+1 comment)
> If no upstream latency was queried yet then this should probably do that now, like `clocksync` does for example
And it turns out `clocksync` also doesn't.
Also check `identity`.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/260webrtcsink: allow passing over any GStreamer upstream events over the `input`...2022-10-24T10:55:57ZMathieu Duponchellewebrtcsink: allow passing over any GStreamer upstream events over the `input` data channelAt the moment `webrtcsink` creates a data-channel labeled `input`, and tries to deserialize (from JSON) any data it receives there as navigation events. This should be extended to any upstream events, which would allow for seek events. I...At the moment `webrtcsink` creates a data-channel labeled `input`, and tries to deserialize (from JSON) any data it receives there as navigation events. This should be extended to any upstream events, which would allow for seek events. In addition, a reverse data channel could be established to acknowledge results of asynchronous events.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1516Add SVT-AV1 encoder/decoder element2023-01-31T14:46:12ZSebastian DrögeAdd SVT-AV1 encoder/decoder elementhttps://gitlab.com/AOMediaCodec/SVT-AV1https://gitlab.com/AOMediaCodec/SVT-AV1https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/259webrtcsink: improve encoder selection mechanism2022-10-24T14:24:11ZMathieu Duponchellewebrtcsink: improve encoder selection mechanismAt the moment, encoder selection in webrtcsink happens as follows:
* `webrtcsink` waits for caps from input stream
* It then looks up encoders for the caps provided by the user, and runs "discovery pipelines" with them, stopping at the ...At the moment, encoder selection in webrtcsink happens as follows:
* `webrtcsink` waits for caps from input stream
* It then looks up encoders for the caps provided by the user, and runs "discovery pipelines" with them, stopping at the first functional one for each structure in the caps.
* Once a consumer connects, it is then offered all the codecs we found a functional encoder for
* The consumer then rules out any formats it wants, and we select the format at the top of the SDP, using whatever first functional encoder we found during the delivery phase.
This process works decently but has a critical flaw: some encoders may only allow for a limited number of concurrent instances before erroring out.
I think we should address the issue as follows:
* During the discovery stage, don't stop at the first functional encoder for a format, but instead construct a sorted list of functional encoders (we can still look up the SDP attributes at that point, I don't see a reason why those would change for a given encoder as long as the input caps don't).
* When a consumer connects, *reserve* an instance of a functional encoder for each format, by trying to set it to READY. If this fails, move to the next functional encoder for the format, if no functional encoder is available don't propose the format at all.
* Once the consumer has replied (or has been otherwise removed), release all resources we no longer need, keeping only one functional encoder if needed, bring the consumer pipeline to READY, add the encoder, move state up
The advantage of that solution is that it should work even when another process is trying to make use of "limited use" encoders.
Question: Can we consider that all "limited use" encoders can be reserved by simply setting them to READY, or will we have to possibly send caps / bring their state up to PAUSED to have them reserve resources?
Original issue: https://github.com/centricular/webrtcsink/issues/82https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/257webrtcsink: implement WHIP signaller2022-10-24T09:15:26ZMathieu Duponchellewebrtcsink: implement WHIP signallerOriginal issue: https://github.com/centricular/webrtcsink/issues/40Original issue: https://github.com/centricular/webrtcsink/issues/40https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1515Base parse fails to infer the correct PTS when splitting one video frame int...2022-11-24T04:44:02ZHe JunyanBase parse fails to infer the correct PTS when splitting one video frame into several sub buffers.### Describe your issue
<!-- a clear and concise summary of the bug. -->
Base parse fails to infer the correct PTS when splitting one video frame into several sub buffers.
<!-- For any GStreamer usage question, please contact the commun...### Describe your issue
<!-- a clear and concise summary of the bug. -->
Base parse fails to infer the correct PTS when splitting one video frame into several sub buffers.
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstreamer.freedesktop.org/lists/ -->
#### Observed Behavior
<!-- What did you expect to happen -->
There are requests that we need to split one video frame into several sub buffers. For example, if we want to split the MKV stream([multi_slice_h264.mkv](/uploads/987119b6b81a63463ec341b6fd5e3f06/multi_slice_h264.mkv)) into h264 NALs, using command line:
```
gst-launch-1.0 -vf filesrc location=multi_slice_h264.mkv ! matroskademux name=de de.video_0 ! h264parse ! video/x-h264,alignment=nal ! fakesin
k silent=false
```
The output is:
```
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (34 bytes, dts: none, pts: 0:00:00.000000000, duration: 0:00:00.000000000, offset: -1, offset_end: -1, flags: 00006440 discont header delta-unit tag-memory , meta: none) 0x7f3df001f120
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (8 bytes, dts: none, pts: none, duration: 0:00:00.000000000, offset: -1, offset_end: -1, flags: 00006440 discont header delta-unit tag-memory , meta: none) 0x7f3df001f480
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (288 bytes, dts: none, pts: none, duration: 0:00:00.033333333, offset: -1, offset_end: -1, flags: 00004040 dis
cont tag-memory , meta: none) 0x7f3df001f120
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (289 bytes, dts: none, pts: none, duration: 0:00:00.000000000, offset: -1, offset_end: -1, flags: 00004040 dis
cont tag-memory , meta: none) 0x560e960ccb40
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (4832 bytes, dts: none, pts: none, duration: 0:00:00.000000000, offset: -1, offset_end: -1, flags: 00004040 di
scont tag-memory , meta: none) 0x7f3df001f120
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (73 bytes, dts: none, pts: 0:00:00.033000000, duration: 0:00:00.033333333, offset: -1, offset_end: -1, flags:
00006000 delta-unit tag-memory , meta: none) 0x560e960cc6c0
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (74 bytes, dts: none, pts: none, duration: 0:00:00.000000000, offset: -1, offset_end: -1, flags: 00006000 delt
a-unit tag-memory , meta: none) 0x7f3df001f480
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (3480 bytes, dts: none, pts: none, duration: 0:00:00.000000000, offset: -1, offset_end: -1, flags: 00006000 de
lta-unit tag-memory , meta: none) 0x560e960cc6c0
```
We notice that only the first split output buffer of one input frame has PTS and others are none.
#### Expected Behavior
Each buffer should have correct PTS. Here, each sub buffers should have the same PTS as the input frame buffer.
### Solutions you have tried
The same kind of issue also exists in VP9 and AV1 parse(maybe more). The base parse https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gstreamer/libs/gst/base/gstbaseparse.c#L2407 will always wipe out the PTS and DTS and infer a new one for us, which is not correct.
### Related non-duplicate issues
We already have a lot of discuss at:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3182#note_1591585https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/392Can't install MSI into Program Files folder2022-11-17T06:36:56ZmirhCan't install MSI into Program Files folderThere's even a FIXME for that.
https://gitlab.freedesktop.org/gstreamer/cerbero/-/blob/1.21.1/cerbero/packages/wix.py#L504
When you are browsing for a directory in the custom setup window, everything is all nice and dandy.. but when yo...There's even a FIXME for that.
https://gitlab.freedesktop.org/gstreamer/cerbero/-/blob/1.21.1/cerbero/packages/wix.py#L504
When you are browsing for a directory in the custom setup window, everything is all nice and dandy.. but when you press OK, "location" gets filled with the equivalent "Program Files (x86)" path.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1514rtpsession: Detects TWCC packets that are actually none2022-10-20T12:00:34ZSebastian Drögertpsession: Detects TWCC packets that are actually noneI have an RTSP stream here where every RTP packet the following line is printed:
```
0:00:00.589206114 �[31m1110402�[00m 0x563da35fd2a0 �[37mDEBUG �[00m �[00m rtpsession rtptwcc.c:304:rtp_twcc_manager_get_recv_twcc_seqnum:�[00...I have an RTSP stream here where every RTP packet the following line is printed:
```
0:00:00.589206114 �[31m1110402�[00m 0x563da35fd2a0 �[37mDEBUG �[00m �[00m rtpsession rtptwcc.c:304:rtp_twcc_manager_get_recv_twcc_seqnum:�[00m Received TWCC packet, but no extension registered; ignoring
```
The stream does not contain any TWCC.
CC @hgrhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1513qtdemux: odd corruption in push mode2023-02-09T13:08:40ZIhor Ranchynskyiqtdemux: odd corruption in push mode### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstream...### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstreamer.freedesktop.org/lists/ -->
I'm making a program that remuxes videos, I got a bug report that one of them came out corrupted. The program uses gstreamer and push-mode appsrc internally.
#### Expected Behavior
<!-- What did you expect to happen -->
Output is identical to the input.
#### Observed Behavior
<!-- What actually happened -->
Output is corrupted, like there's a missing keyframe or something.
#### Setup
- **Operating System:** Windows 10
- **Device:** Computer
- **GStreamer Version:** 1.20.4 MSVC 64-bit
- **Command line:** `gst-launch-1.0 pushfilesrc location=issue.mp4 ! qtdemux ! mp4mux faststart=true ! filesink location="out.mp4"`
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. download [issue.mp4](/uploads/fb2694810acd80cdba965af95da39721/issue.mp4) (originally from https://www.youtube.com/watch?v=hVq6eD6-U00)
2. type `gst-launch-1.0 pushfilesrc location=issue.mp4 ! qtdemux ! mp4mux faststart=true ! filesink location="out.mp4"`
### How reproducible is the bug?
Always
### Screenshots if relevant
![BF3T7nx](/uploads/bf3982e9c12bb9293c5eb42237bfce4b/BF3T7nx.png)
![0pOzhuX](/uploads/b31340b9e2d0b5f978786bd362678368/0pOzhuX.png)
### Solutions you have tried
Regular pull-mode `gst-launch-1.0 filesrc location=issue.mp4 ! qtdemux ! mp4mux faststart=true ! filesink location="out.mp4"` works just fine
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->
`GST_DEBUG=4 gst-launch-1.0 pushfilesrc location=issue.mp4 ! qtdemux ! mp4mux faststart=true ! f
ilesink location="out.mp4" > log.txt 2>&1`
[log.txt](/uploads/f85ff725be4d1c13f83f21b6d997a5ec/log.txt)