GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-05-31T14:15:59Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1254GST 1.20.2 (and main) on Ubuntu 20.04 `-Dintrospection=enabled` fails because...2022-05-31T14:15:59ZThomas GoodwinGST 1.20.2 (and main) on Ubuntu 20.04 `-Dintrospection=enabled` fails because 'master' is not the branch### Describe your issue
Unable to compile GStreamer 1.20.2 on Ubuntu 20.04 if the `introspection` option is enabled or if `gobject-introspection` is available (but incompatible?) in the operating system.
#### Expected Behavior
In this...### Describe your issue
Unable to compile GStreamer 1.20.2 on Ubuntu 20.04 if the `introspection` option is enabled or if `gobject-introspection` is available (but incompatible?) in the operating system.
#### Expected Behavior
In this case it appears there are attempts to let meson download and install the compatible/required version, however the processes are broken on Ubuntu 20.04. I would expect the processes to work.
#### Observed Behavior
Meson attempts to fall back to the `pango.wrap`, which points to a tagged version with its own `gobject-introspection.wrap`, that points at a non-existent `master` branch (now `main`). Patching the `pango.wrap` to an updated version that would fix this issue results in another build failure for `subprojects/gstreamer` and `subprojects/gst-plugins-base` because the `-Dintrospection=enabled` option causes the configuration to abort because `g-ir-scanner` is not found (a program provided by `gobject-introspection`). Patching the `meson.build` files in this case allows the configuration to proceed, which then pulls pango and builds `gobject-introspection` from that updated wrap.
#### Setup
- **Operating System: Ubuntu 20.04**
- **Device:** Computer
- **GStreamer Version: 1.20.2**
- **Command line: bash**
### Steps to reproduce the bug
I installed `gobject-introspection` via `apt` and then tried configuring the gstreamer build, tag 1.20.2:
```
meson -Dgpl=enabled builddir
```
The configuration failed because though `meson` found the dependency via `pkgconfig`, it fell back to using the `.wrap` version of the dependency instead, which it found by way of pango. Meson then failed when attempting to clone the `master` branch of `gobject-introspection`.
I then ran `apt remove gobject-introspection` and tried letting meson handle the dependency on its own by setting the build option:
```
rm -rf builddir
meson -Dgpl=enabled -Dintrospection=enabled builddir
```
The error was essentially the same but clarified that it arrived at this dependency because of Pango. The `pango.wrap` version is [1.48.7](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/681068a59dd4853019df60a3dd5bf93438c1057d). That version of Pango contains a the `gobject-introspection.wrap` that points at the `master` branch which was renamed to `main` [on this commit](https://gitlab.gnome.org/GNOME/pango/-/commit/00815c8b7f6baf5bd86c3b8314edef33a053ffd9). The fix version of Pango is 1.50.6.
I then performed a fresh clone of the `1.20.2` GStreamer tag, patched the `pango.wrap` to use the 1.50.6 tag, and re-attempted build configuration with the command above. However, it did not fix the issue. Now it does not try pulling Pango to get the dependency (there is no directory for it in `subprojects` after the configuration attempt fails). Rather, the error is it cannot find `g-ir-scanner`, which is part of `gobject-introspection`, so I think there is a dependency tree issue for `gstreamer` in the `meson.build`:
```
gstreamer| Project name: gstreamer
gstreamer| Project version: 1.20.2
gstreamer| C compiler for the host machine: cc (gcc 9.4.0 "cc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0")
gstreamer| C linker for the host machine: cc ld.bfd 2.34
gstreamer| Compiler for C supports link arguments -Wl,-Bsymbolic-functions: YES (cached)
gstreamer| Compiler for C supports arguments -fvisibility=hidden: YES (cached)
gstreamer| Compiler for C supports arguments -fno-strict-aliasing: YES
gstreamer| Message: Disabling GLib cast checks
gstreamer| Has header "dlfcn.h" : YES
gstreamer| Has header "inttypes.h" : YES
gstreamer| Has header "memory.h" : YES
gstreamer| Has header "poll.h" : YES
gstreamer| Has header "stdint.h" : YES
gstreamer| Has header "stdio_ext.h" : YES
gstreamer| Has header "strings.h" : YES
gstreamer| Has header "string.h" : YES
gstreamer| Has header "sys/param.h" : YES
gstreamer| Has header "sys/poll.h" : YES
gstreamer| Has header "sys/prctl.h" : YES
gstreamer| Has header "sys/socket.h" : YES
gstreamer| Has header "sys/stat.h" : YES
gstreamer| Has header "sys/times.h" : YES
gstreamer| Has header "sys/time.h" : YES (cached)
gstreamer| Has header "sys/types.h" : YES
gstreamer| Has header "sys/utsname.h" : YES
gstreamer| Has header "sys/wait.h" : YES
gstreamer| Has header "ucontext.h" : YES
gstreamer| Has header "unistd.h" : YES (cached)
gstreamer| Has header "sys/resource.h" : YES
gstreamer| Has header "sys/uio.h" : YES
gstreamer| Checking whether type "struct tm" has member "tm_gmtoff" : YES
gstreamer| Checking for function "gmtime_r" : YES
gstreamer| Checking for function "sigaction" : YES
gstreamer| Checking for function "getrusage" : YES
gstreamer| Checking for function "fseeko" : YES
gstreamer| Checking for function "ftello" : YES
gstreamer| Checking for function "poll" : YES
gstreamer| Checking for function "ppoll" : YES
gstreamer| Checking for function "pselect" : YES
gstreamer| Checking for function "getpagesize" : YES
gstreamer| Checking for function "clock_gettime" : YES (cached)
gstreamer| Checking for function "clock_nanosleep" : YES
gstreamer| Checking for function "strnlen" : YES
gstreamer| Checking for function "getline" : YES
gstreamer| Checking for function "mkstemp" : YES
gstreamer| Checking for function "alarm" : YES
gstreamer| Checking for function "gettimeofday" : YES (cached)
gstreamer| Checking for function "localtime_r" : YES
gstreamer| Checking if "pthread_setname_np(const char*)" : links: NO
gstreamer| Header <pthread.h> has symbol "pthread_condattr_setclock" : YES
gstreamer| Header <pthread.h> has symbol "pthread_cond_timedwait_relative_np" : NO
gstreamer| Checking if "futex(2) system call" : links: YES
gstreamer| Checking if "posix timers from time.h" compiles: YES
gstreamer| Checking if "monotonic clock from time.h" compiles: YES
gstreamer| Checking if "__uint128_t available" compiles: YES
gstreamer| Checking for function "getpid" : YES
gstreamer| Checking for function "strdup" : YES
gstreamer| Checking for function "strsignal" : YES
gstreamer| Checking for type "clockid_t" : YES
gstreamer| Checking for type "timer_t" : YES
gstreamer| Checking whether type "struct timespec" has members "tv_sec", "tv_nsec" : YES
gstreamer| Checking whether type "struct itimerspec" has members "it_interval", "it_value" : YES
gstreamer| Found pkg-config: /usr/bin/pkg-config (0.29.1)
gstreamer| Did not find CMake 'cmake'
gstreamer| Found CMake: NO
gstreamer| Run-time dependency libunwind found: NO (tried pkgconfig and cmake)
gstreamer| Run-time dependency libdw found: NO (tried pkgconfig and cmake)
gstreamer| Has header "dbghelp.h" : NO
gstreamer| Checking for function "backtrace" : YES
gstreamer| Message: Minimal support for stack traces, no source info.
gstreamer| Has header "execinfo.h" : YES
gstreamer| Checking for function "backtrace" : YES
gstreamer| Compiler for C supports arguments -Wmissing-declarations: YES
gstreamer| Compiler for C supports arguments -Wmissing-prototypes: YES
gstreamer| Compiler for C supports arguments -Wredundant-decls: YES
gstreamer| Compiler for C supports arguments -Wundef: YES
gstreamer| Compiler for C supports arguments -Wwrite-strings: YES
gstreamer| Compiler for C supports arguments -Wformat: YES
gstreamer| Compiler for C supports arguments -Wformat-nonliteral: YES
gstreamer| Compiler for C supports arguments -Wformat-security: YES
gstreamer| Compiler for C supports arguments -Wold-style-definition: YES
gstreamer| Compiler for C supports arguments -Winit-self: YES
gstreamer| Compiler for C supports arguments -Wmissing-include-dirs: YES
gstreamer| Compiler for C supports arguments -Waddress: YES
gstreamer| Compiler for C supports arguments -Waggregate-return: YES
gstreamer| Compiler for C supports arguments -Wno-multichar: YES
gstreamer| Compiler for C supports arguments -Wdeclaration-after-statement: YES
gstreamer| Compiler for C supports arguments -Wvla: YES
gstreamer| Compiler for C supports arguments -Wpointer-arith: YES
gstreamer| Library gmp found: NO
gstreamer| Library gsl found: NO
gstreamer| Library gslcblas found: NO
gstreamer| Library dl found: YES
gstreamer| Checking for function "dladdr" with dependency -ldl: YES
gstreamer| Run-time dependency glib-2.0 found: YES 2.64.6
gstreamer| Run-time dependency gobject-2.0 found: YES 2.64.6
gstreamer| Run-time dependency gmodule-2.0 found: YES 2.64.6
gstreamer| Run-time dependency gio-2.0 found: YES 2.64.6
gstreamer| Run-time dependency gio-unix-2.0 found: YES 2.64.6
gstreamer| Library m found: YES
gstreamer| Library rt found: YES
gstreamer| Program g-ir-scanner found: NO
subprojects/gstreamer/meson.build:509:0: ERROR: Program 'g-ir-scanner' not found or not executable
```
I modified that line as well as the same line found in `gst-plugins-base` to be `required: false` rather than being tied to enabling the option, since the following `build_gir` variable (line 512 in the `subprojects/gstreamer/meson.build` case) seems to be intended to flag whether it's necessary to pull and build the package from source. Re-running the `meson ... builddir` configuration step from above succeeded this time in pulling `pango` and building the `gobject-introspection` dependency.
### How reproducible is the bug?
Always
### Screenshots if relevant
### Solutions you have tried
See _Steps to Reproduce_ above; the patches are in-line below. I do not think these are entirely the correct solution, however. The pango wrap version should probably be bumped but the `meson.build` patches are probably not right given there is a top-level `meson.build` check for this option that perhaps should be dealing with this missing / unmet dependency in a more resilient manner.
```diff
diff --git a/subprojects/gst-plugins-base/meson.build b/subprojects/gst-plugins-base/meson.build
index 6d64762aae..68d6037e06 100644
--- a/subprojects/gst-plugins-base/meson.build
+++ b/subprojects/gst-plugins-base/meson.build
@@ -428,7 +428,7 @@ if cc.has_member('struct tcp_info', 'tcpi_reordering', prefix: '#include <netine
core_conf.set('HAVE_LINUX_TCP_INFO', true)
endif
-gir = find_program('g-ir-scanner', required : get_option('introspection'))
+gir = find_program('g-ir-scanner', required : false)
gnome = import('gnome')
build_gir = gir.found() and (not meson.is_cross_build() or get_option('introspection').enabled())
gir_init_section = [ '--add-init-section=extern void gst_init(gint*,gchar**);' + \
diff --git a/subprojects/gstreamer/meson.build b/subprojects/gstreamer/meson.build
index 62cefa19e9..1988e21c39 100644
--- a/subprojects/gstreamer/meson.build
+++ b/subprojects/gstreamer/meson.build
@@ -506,7 +506,7 @@ mathlib = cc.find_library('m', required : false)
# Also provides clock_gettime in glibc < 2.17
rt_lib = cc.find_library('rt', required : false)
-gir = find_program('g-ir-scanner', required : get_option('introspection'))
+gir = find_program('g-ir-scanner', required : false)
gnome = import('gnome')
build_gir = gir.found() and (not meson.is_cross_build() or get_option('introspection').enabled())
diff --git a/subprojects/pango.wrap b/subprojects/pango.wrap
index 7da354c912..dd27c4a1b0 100644
--- a/subprojects/pango.wrap
+++ b/subprojects/pango.wrap
@@ -1,4 +1,4 @@
[wrap-git]
url=https://gitlab.gnome.org/GNOME/pango.git
push-url=git@gitlab.gnome.org:GNOME/pango.git
-revision=1.48.7
+revision=1.50.6
```
### 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-project/-/issues/96g_source_remove method call is getting stuck (leading corresponding thread to...2022-09-05T08:43:16ZHemanthg_source_remove method call is getting stuck (leading corresponding thread to get stuck)Hello,
We have a Media Server integrated with GStreamer for transcoding. Our application is running absolutely fine in production system.
Recently, we have noticed an abnormal behavior where g_source_remove method call is stuck leading ...Hello,
We have a Media Server integrated with GStreamer for transcoding. Our application is running absolutely fine in production system.
Recently, we have noticed an abnormal behavior where g_source_remove method call is stuck leading to application issue.
if (source_id)
{
g_source_remove(source_id);
source_id = 0;
}
As mentioned in the code above, we are validating the source_id before invoking g_source_remove method call. Also, we have tried printing source_id,
the value is not corrupted (valid).
From the link, https://docs.gtk.org/glib/type_func.Source.remove.html it is mentioned that,
It is a programmer error to attempt to remove a non-existent source.
As detailed in this ticket, the problem is not observed frequently in the production system (Handling millions of calls). However,
there is a corner scenario where this issue is occurring.
Could you please help us to better implement g_source_remove to avoid this abnormal behavior.
We tried running stress test(high volume), the issue is recreated in our lab.
We are running GStreamer version 1.12 and let us know if any subsequent version address g_source_remove issue.
Thanks in advance.
Hemanthhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/978ERROR:../sys/v4l2/gstv4l2bufferpool.c:1193:gst_v4l2_buffer_pool_qbuf: asserti...2023-07-08T09:26:24ZOllie CharlesERROR:../sys/v4l2/gstv4l2bufferpool.c:1193:gst_v4l2_buffer_pool_qbuf: assertion failed: ("Value of time " "timestamp" " is out of timeval's range" && ((timestamp) / GST_SECOND) < G_MAXLONG)I'm trying to run the following pipeline with `gst-launch`:
```
gst-launch-1.0 libcamerasrc ! video/x-raw,width=1280,height=720,format=NV12 ! v4l2convert ! videoflip method=rotate-180 ! clockoverlay ! v4l2h264enc extra-controls="control...I'm trying to run the following pipeline with `gst-launch`:
```
gst-launch-1.0 libcamerasrc ! video/x-raw,width=1280,height=720,format=NV12 ! v4l2convert ! videoflip method=rotate-180 ! clockoverlay ! v4l2h264enc extra-controls="controls,repeat_sequence_header=1" ! 'video/x-h264,level=(string)4' ! tee name=t ! h264parse ! hlssink2 max-files=5 location=hls/segment%05d.ts playlist-location=hls/playlist.m3u8 playlist-root=/hls target-duration=2 playlist-length=3 t. ! h264parse ! splitmuxsink location=Videos/ollie/test%04d.mov max-size-time=60000000000 max-files=1440
```
Generally this works well. However, at random times this pipeline will crash with:
```
Setting pipeline to PAUSED ...
[74:10:19.137045188] [14766] INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3544-22656360
[74:10:19.153599841] [14767] WARN CameraSensorProperties camera_sensor_properties.cpp:163 No static properties available for 'imx477'
[74:10:19.153645267] [14767] WARN CameraSensorProperties camera_sensor_properties.cpp:165 Please consider updating the camera sensor properties database
[74:10:19.153702415] [14767] ERROR CameraSensor camera_sensor.cpp:591 'imx477 10-001a': Camera sensor does not support test pattern modes.
[74:10:19.170311642] [14767] INFO RPI raspberrypi.cpp:1356 Registered camera /base/soc/i2c0mux/i2c@1/imx477@1a to Unicam device /dev/media2 and ISP device /dev/media0
Pipeline is live and does not need PREROLL ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
[74:10:19.187479625] [14774] INFO Camera camera.cpp:1029 configuring streams: (0) 1280x720-NV12
[74:10:19.188335751] [14767] INFO RPI raspberrypi.cpp:760 Sensor: /base/soc/i2c0mux/i2c@1/imx477@1a - Selected sensor format: 2028x1080-SBGGR12_1X12 - Selected unicam format: 2028x1080-pBCC
**:50:57. / 99:99:99.
ERROR:../sys/v4l2/gstv4l2bufferpool.c:1193:gst_v4l2_buffer_pool_qbuf: assertion failed: ("Value of time " "timestamp" " is out of timeval's range" && ((timestamp) / GST_SECOND) < G_MAXLONG)
Bail out! ERROR:../sys/v4l2/gstv4l2bufferpool.c:1193:gst_v4l2_buffer_pool_qbuf: assertion failed: ("Value of time " "timestamp" " is out of timeval's range" && ((timestamp) / GST_SECOND) < G_MAXLONG)
Aborted
```
I'm not sure what's going on here, and the crash seems to happen after different durations.
Happy to provide any more information that will help.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1253glvideomixer: gst-inspect does not document GstGLVideoMixerPad2022-12-14T14:09:07ZGuillaume Desmottesglvideomixer: gst-inspect does not document GstGLVideoMixerPadSee the pad template of `glvideomixer`:
```
Pad Templates:
SINK template: 'sink_%u'
Availability: On request
Capabilities:
video/x-raw(memory:GLMemory, meta:GstVideoOverlayComposition)
format: { (string)...See the pad template of `glvideomixer`:
```
Pad Templates:
SINK template: 'sink_%u'
Availability: On request
Capabilities:
video/x-raw(memory:GLMemory, meta:GstVideoOverlayComposition)
format: { (string)RGBA, (string)BGRA, (string)RGBx, (string)BGRx, (string)ARGB, (string)ABGR, (string)xRGB, (string)xBGR, (string)GBRA, (string)GBR, (string)RGBP, (string)BGRP, (string)RGB, (string)BGR, (string)RGB16, (string)BGR16, (string)AYUV, (string)VUYA, (string)Y410, (string)I420, (string)YV12, (string)NV12, (string)NV21, (string)NV16, (string)NV61, (string)YUY2, (string)UYVY, (string)Y210, (string)Y4
1B, (string)Y42B, (string)Y444, (string)GRAY8, (string)GRAY16_LE, (string)GRAY16_BE, (string)ARGB64, (string)A420, (string)AV12, (string)NV12_16L32S, (string)NV12_4L4, (string)BGR10A2_LE, (string)RGB10A2_LE, (string)P010_10LE, (string)P012_LE, (string)P016_LE, (string)Y212_LE, (string)Y412_LE }
width: [ 1, 2147483647 ]
height: [ 1, 2147483647 ]
framerate: [ 0/1, 2147483647/1 ]
video/x-raw(memory:DMABuf, meta:GstVideoOverlayComposition)
format: { (string)RGBA, (string)BGRA, (string)RGBx, (string)BGRx, (string)ARGB, (string)ABGR, (string)xRGB, (string)xBGR, (string)GBRA, (string)GBR, (string)RGBP, (string)BGRP, (string)RGB, (string)BGR, (string)RGB16, (string)BGR16, (string)AYUV, (string)VUYA, (string)Y410, (string)I420, (string)YV12, (string)NV12, (string)NV21, (string)NV16, (string)NV61, (string)YUY2, (string)UYVY, (string)Y210, (string)Y4
1B, (string)Y42B, (string)Y444, (string)GRAY8, (string)GRAY16_LE, (string)GRAY16_BE, (string)ARGB64, (string)A420, (string)AV12, (string)NV12_16L32S, (string)NV12_4L4, (string)BGR10A2_LE, (string)RGB10A2_LE, (string)P010_10LE, (string)P012_LE, (string)P016_LE, (string)Y212_LE, (string)Y412_LE }
width: [ 1, 2147483647 ]
height: [ 1, 2147483647 ]
framerate: [ 0/1, 2147483647/1 ]
video/x-raw(memory:SystemMemory, meta:GstVideoOverlayComposition)
format: { (string)RGBA, (string)BGRA, (string)RGBx, (string)BGRx, (string)ARGB, (string)ABGR, (string)xRGB, (string)xBGR, (string)GBRA, (string)GBR, (string)RGBP, (string)BGRP, (string)RGB, (string)BGR, (string)RGB16, (string)BGR16, (string)AYUV, (string)VUYA, (string)Y410, (string)I420, (string)YV12, (string)NV12, (string)NV21, (string)NV16, (string)NV61, (string)YUY2, (string)UYVY, (string)Y210, (string)Y4
1B, (string)Y42B, (string)Y444, (string)GRAY8, (string)GRAY16_LE, (string)GRAY16_BE, (string)ARGB64, (string)A420, (string)AV12, (string)NV12_16L32S, (string)NV12_4L4, (string)BGR10A2_LE, (string)RGB10A2_LE, (string)P010_10LE, (string)P012_LE, (string)P016_LE, (string)Y212_LE, (string)Y412_LE }
width: [ 1, 2147483647 ]
height: [ 1, 2147483647 ]
framerate: [ 0/1, 2147483647/1 ]
video/x-raw(meta:GstVideoGLTextureUploadMeta, meta:GstVideoOverlayComposition)
format: RGBA
width: [ 1, 2147483647 ]
height: [ 1, 2147483647 ]
framerate: [ 0/1, 2147483647/1 ]
video/x-raw(memory:GLMemory)
format: { (string)RGBA, (string)BGRA, (string)RGBx, (string)BGRx, (string)ARGB, (string)ABGR, (string)xRGB, (string)xBGR, (string)GBRA, (string)GBR, (string)RGBP, (string)BGRP, (string)RGB, (string)BGR, (string)RGB16, (string)BGR16, (string)AYUV, (string)VUYA, (string)Y410, (string)I420, (string)YV12, (string)NV12, (string)NV21, (string)NV16, (string)NV61, (string)YUY2, (string)UYVY, (string)Y210, (string)Y4
1B, (string)Y42B, (string)Y444, (string)GRAY8, (string)GRAY16_LE, (string)GRAY16_BE, (string)ARGB64, (string)A420, (string)AV12, (string)NV12_16L32S, (string)NV12_4L4, (string)BGR10A2_LE, (string)RGB10A2_LE, (string)P010_10LE, (string)P012_LE, (string)P016_LE, (string)Y212_LE, (string)Y412_LE }
width: [ 1, 2147483647 ]
height: [ 1, 2147483647 ]
framerate: [ 0/1, 2147483647/1 ]
video/x-raw(memory:DMABuf)
format: { (string)RGBA, (string)BGRA, (string)RGBx, (string)BGRx, (string)ARGB, (string)ABGR, (string)xRGB, (string)xBGR, (string)GBRA, (string)GBR, (string)RGBP, (string)BGRP, (string)RGB, (string)BGR, (string)RGB16, (string)BGR16, (string)AYUV, (string)VUYA, (string)Y410, (string)I420, (string)YV12, (string)NV12, (string)NV21, (string)NV16, (string)NV61, (string)YUY2, (string)UYVY, (string)Y210, (string)Y4
1B, (string)Y42B, (string)Y444, (string)GRAY8, (string)GRAY16_LE, (string)GRAY16_BE, (string)ARGB64, (string)A420, (string)AV12, (string)NV12_16L32S, (string)NV12_4L4, (string)BGR10A2_LE, (string)RGB10A2_LE, (string)P010_10LE, (string)P012_LE, (string)P016_LE, (string)Y212_LE, (string)Y412_LE }
width: [ 1, 2147483647 ]
height: [ 1, 2147483647 ]
framerate: [ 0/1, 2147483647/1 ]
video/x-raw
format: { (string)RGBA, (string)BGRA, (string)RGBx, (string)BGRx, (string)ARGB, (string)ABGR, (string)xRGB, (string)xBGR, (string)GBRA, (string)GBR, (string)RGBP, (string)BGRP, (string)RGB, (string)BGR, (string)RGB16, (string)BGR16, (string)AYUV, (string)VUYA, (string)Y410, (string)I420, (string)YV12, (string)NV12, (string)NV21, (string)NV16, (string)NV61, (string)YUY2, (string)UYVY, (string)Y210, (string)Y41B, (string)Y42B, (string)Y444, (string)GRAY8, (string)GRAY16_LE, (string)GRAY16_BE, (string)ARGB64, (string)A420, (string)AV12, (string)NV12_16L32S, (string)NV12_4L4, (string)BGR10A2_LE, (string)RGB10A2_LE, (string)P010_10LE, (string)P012_LE, (string)P016_LE, (string)Y212_LE, (string)Y412_LE }
width: [ 1, 2147483647 ]
height: [ 1, 2147483647 ]
framerate: [ 0/1, 2147483647/1 ]
video/x-raw(meta:GstVideoGLTextureUploadMeta)
format: RGBA
width: [ 1, 2147483647 ]
height: [ 1, 2147483647 ]
framerate: [ 0/1, 2147483647/1 ]
SRC template: 'src'
Availability: Always
Capabilities:
video/x-raw(ANY)
```
`GstGLVideoMixerPad` is not documented for the sink pads while its equivalent is for `compositor`:
```
Pad Templates:
SINK template: 'sink_%u'
Availability: On request
Capabilities:
video/x-raw
format: { (string)ABGR64_LE, (string)BGRA64_LE, (string)AYUV64, (string)ARGB64_LE, (string)ARGB64, (string)RGBA64_LE, (string)ABGR64_BE, (string)BGRA64_BE, (string)ARGB64_BE, (string)RGBA64_BE, (string)GBRA_12LE, (string)GBRA_12BE, (string)Y412_LE, (string)Y412_BE, (string)A444_10LE, (string)GBRA_10LE, (string)A444_10BE, (string)GBRA_10BE, (string)A422_10LE, (string)A422_10BE, (string)A420_10LE, (string)A420
_10BE, (string)RGB10A2_LE, (string)BGR10A2_LE, (string)Y410, (string)GBRA, (string)ABGR, (string)VUYA, (string)BGRA, (string)AYUV, (string)ARGB, (string)RGBA, (string)A420, (string)AV12, (string)Y444_16LE, (string)Y444_16BE, (string)v216, (string)P016_LE, (string)P016_BE, (string)Y444_12LE, (string)GBR_12LE, (string)Y444_12BE, (string)GBR_12BE, (string)I422_12LE, (string)I422_12BE, (string)Y212_LE, (string)Y212_BE, (string)I
420_12LE, (string)I420_12BE, (string)P012_LE, (string)P012_BE, (string)Y444_10LE, (string)GBR_10LE, (string)Y444_10BE, (string)GBR_10BE, (string)r210, (string)I422_10LE, (string)I422_10BE, (string)NV16_10LE32, (string)Y210, (string)v210, (string)UYVP, (string)I420_10LE, (string)I420_10BE, (string)P010_10LE, (string)NV12_10LE32, (string)NV12_10LE40, (string)P010_10BE, (string)NV12_10BE_8L128, (string)Y444, (string)RGBP, (stri
ng)GBR, (string)BGRP, (string)NV24, (string)xBGR, (string)BGRx, (string)xRGB, (string)RGBx, (string)BGR, (string)IYU2, (string)v308, (string)RGB, (string)Y42B, (string)NV61, (string)NV16, (string)VYUY, (string)UYVY, (string)YVYU, (string)YUY2, (string)I420, (string)YV12, (string)NV21, (string)NV12, (string)NV12_8L128, (string)NV12_64Z32, (string)NV12_4L4, (string)NV12_32L32, (string)NV12_16L32S, (string)Y41B, (string)IYU1, (
string)YVU9, (string)YUV9, (string)RGB16, (string)BGR16, (string)RGB15, (string)BGR15, (string)RGB8P, (string)GRAY16_LE, (string)GRAY16_BE, (string)GRAY10_LE32, (string)GRAY8 }
width: [ 1, 2147483647 ]
height: [ 1, 2147483647 ]
framerate: [ 0/1, 2147483647/1 ]
Type: GstCompositorPad
Pad Properties:
alpha : Alpha of the picture
flags: readable, writable, controllable
Double. Range: 0 - 1 Default: 1
converter-config : A GstStructure describing the configuration that should be used when scaling and converting this pad's video frames
flags: readable, writable
Boxed pointer of type "GstStructure"
emit-signals : Send signals to signal data consumption
flags: readable, writable
Boolean. Default: false
height : Height of the picture
flags: readable, writable, controllable
Integer. Range: -2147483648 - 2147483647 Default: -1
max-last-buffer-repeat: Repeat last buffer for time (in ns, -1=until EOS), behaviour on EOS is not affected
flags: readable, writable, changeable in NULL, READY, PAUSED or PLAYING state
Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 18446744073709551615
operator : Blending operator to use for blending this pad over the previous ones
flags: readable, writable, controllable
Enum "GstCompositorOperator" Default: 1, "over"
(0): source - Source
(1): over - Over
(2): add - Add
repeat-after-eos : Repeat the last frame after EOS until all pads are EOS
flags: readable, writable, controllable
Boolean. Default: false
sizing-policy : Sizing policy to use for image scaling
flags: readable, writable, controllable
Enum "GstCompositorSizingPolicy" Default: 0, "none"
(0): none - None: Image is scaled to fill configured destination rectangle without padding or keeping the aspect ratio
(1): keep-aspect-ratio - Keep Aspect Ratio: Image is scaled to fit destination rectangle specified by GstCompositorPad:{xpos, ypos, width, height} with preserved aspect ratio. Resulting image will be centered in the destination rectangle with padding if necessary
width : Width of the picture
flags: readable, writable, controllable
Integer. Range: -2147483648 - 2147483647 Default: -1
xpos : X Position of the picture
flags: readable, writable, controllable
Integer. Range: -2147483648 - 2147483647 Default: 0
ypos : Y Position of the picture
flags: readable, writable, controllable
Integer. Range: -2147483648 - 2147483647 Default: 0
zorder : Z Order of the picture
flags: readable, writable, controllable
Unsigned Integer. Range: 0 - 4294967295 Default: 0
SRC template: 'src'
Availability: Always
Capabilities:
video/x-raw
format: { (string)AYUV, (string)VUYA, (string)BGRA, (string)ARGB, (string)RGBA, (string)ABGR, (string)Y444, (string)Y42B, (string)YUY2, (string)UYVY, (string)YVYU, (string)I420, (string)YV12, (string)NV12, (string)NV21, (string)Y41B, (string)RGB, (string)BGR, (string)xRGB, (string)xBGR, (string)RGBx, (string)BGRx }
width: [ 1, 2147483647 ]
height: [ 1, 2147483647 ]
framerate: [ 0/1, 2147483647/1 ]
Type: GstAggregatorPad
Pad Properties:
emit-signals : Send signals to signal data consumption
flags: readable, writable
Boolean. Default: false
```
I'm not sure what's going wrong as both [are using `gst_element_class_add_static_pad_template_with_gtype`](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/ext/gl/gstglvideomixer.c#L921).https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/95iOS App crashes when calling g_tls_file_database_new2022-06-04T03:21:45Zsamanta-ramijaniOS App crashes when calling g_tls_file_database_newHi!
I want to update the GStreamer version of my iOS App from 1.16.3 to 1.18.6.
What I did:
I downloaded the installer from here: https://gstreamer.freedesktop.org/data/pkg/ios/1.18.6/gstreamer-1.0-devel-1.18.6-ios-universal.pkg I upd...Hi!
I want to update the GStreamer version of my iOS App from 1.16.3 to 1.18.6.
What I did:
I downloaded the installer from here: https://gstreamer.freedesktop.org/data/pkg/ios/1.18.6/gstreamer-1.0-devel-1.18.6-ios-universal.pkg I updated the gst_ios_init.h file to use openssl instead of gnutls, by replacing the `#define GST_IOS_GIO_MODULE_GNUTLS` line with `#define GST_IOS_GIO_MODULE_OPENSSL`
The App is now crashing (iOS 15.4.1) when calling the `g_tls_file_database_new (ca_certificates, NULL)` on the `gst_ios_init.m` file. I am getting a `EXC_BAD_ACCESS` exception, which is weird because I didn't change the certificate location.
This is a snippet of the code where the App is crashing, it only crashes if there is a file where `ca_certificates` points to. If there isn't then the `gst_ios_init` call runs properly, but then I cannot use encryption, which I really need to!!
```
const gchar *resources_dir = [resources UTF8String];
const gchar *tmp_dir = [tmp UTF8String];
const gchar *cache_dir = [cache UTF8String];
const gchar *docs_dir = [docs UTF8String];
const gchar *library_dir = [libraryString UTF8String];
gchar *ca_certificates;
g_setenv ("TMP", tmp_dir, TRUE);
g_setenv ("TEMP", tmp_dir, TRUE);
g_setenv ("TMPDIR", tmp_dir, TRUE);
g_setenv ("XDG_RUNTIME_DIR", resources_dir, TRUE);
g_setenv ("XDG_CACHE_HOME", cache_dir, TRUE);
g_setenv ("HOME", docs_dir, TRUE);
g_setenv ("XDG_DATA_DIRS", resources_dir, TRUE);
g_setenv ("XDG_CONFIG_DIRS", resources_dir, TRUE);
g_setenv ("XDG_CONFIG_HOME", cache_dir, TRUE);
g_setenv ("XDG_DATA_HOME", resources_dir, TRUE);
g_setenv ("FONTCONFIG_PATH", resources_dir, TRUE);
ca_certificates = g_build_filename (library_dir, "ca.pem", NULL);
g_setenv ("CA_CERTIFICATES", ca_certificates, TRUE);
#if defined(GST_IOS_GIO_MODULE_OPENSSL)
GST_G_IO_MODULE_LOAD(openssl);
#endif
if (ca_certificates) {
GTlsBackend *backend = g_tls_backend_get_default ();
if (backend) {
GTlsDatabase *db = g_tls_file_database_new (ca_certificates, NULL);
if (db)
g_tls_backend_set_default_database (backend, db);
}
}
g_free (ca_certificates);
gst_init (NULL, NULL);
```
Here's also an screenshot of the crash.
![Screen_Shot_2022-05-27_at_2.05.07_PM](/uploads/00667d212f59854a9bbb9aa066389825/Screen_Shot_2022-05-27_at_2.05.07_PM.png)
Thank you!https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/206spotifyaudiosrc: ERROR: from element /GstPipeline:pipeline0/GstOggDemux:oggde...2022-06-14T21:56:24ZJonas Kvingespotifyaudiosrc: ERROR: from element /GstPipeline:pipeline0/GstOggDemux:oggdemux0: Could not demultiplex stream.Command:
`gst-launch-1.0 spotifyaudiosrc username= password= track=spotify:track:3i3P1mGpV9eRlfKccjDjwi ! oggdemux ! vorbisdec ! audioconvert ! alsasink device=hw:1,0`
Output:
```
Setting pipeline to PAUSED ...
0:00:00.019426428 26647...Command:
`gst-launch-1.0 spotifyaudiosrc username= password= track=spotify:track:3i3P1mGpV9eRlfKccjDjwi ! oggdemux ! vorbisdec ! audioconvert ! alsasink device=hw:1,0`
Output:
```
Setting pipeline to PAUSED ...
0:00:00.019426428 26647 0x55eb35b9f2c0 DEBUG spotifyaudiosrc audio/spotify/src/spotifyaudiosrc/imp.rs:337:gstspotify::spotifyaudiosrc::imp:<spotifyaudiosrc0> credentials not in cache
0:00:00.268827807 26647 0x55eb35b9f2c0 DEBUG spotifyaudiosrc audio/spotify/src/spotifyaudiosrc/imp.rs:262:gstspotify::spotifyaudiosrc::imp:<spotifyaudiosrc0> stopping
0:00:00.269021822 26647 0x55eb35b9f2c0 DEBUG spotifyaudiosrc audio/spotify/src/spotifyaudiosrc/imp.rs:337:gstspotify::spotifyaudiosrc::imp:<spotifyaudiosrc0> credentials not in cache
Pipeline is PREROLLING ...
0:00:00.627294228 26647 0x55eb35ba6460 DEBUG spotifyaudiosrc audio/spotify/src/spotifyaudiosrc/imp.rs:288:gstspotify::spotifyaudiosrc::imp:<spotifyaudiosrc0> eos
ERROR: from element /GstPipeline:pipeline0/GstOggDemux:oggdemux0: Could not demultiplex stream.
Additional debug info:
../ext/ogg/gstoggdemux.c(4767): gst_ogg_demux_send_event (): /GstPipeline:pipeline0/GstOggDemux:oggdemux0:
EOS before finding a chain
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
0:00:00.627672221 26647 0x55eb35b9f2c0 DEBUG spotifyaudiosrc audio/spotify/src/spotifyaudiosrc/imp.rs:262:gstspotify::spotifyaudiosrc::imp:<spotifyaudiosrc0> stopping
Freeing pipeline ...
```
Running:
`gst-launch-1.0 spotifyaudiosrc username= password= track=spotify:track:3i3P1mGpV9eRlfKccjDjwi ! filesink location=spotify.out`
Results in an empty file.
Output:
```
Setting pipeline to PAUSED ...
0:00:00.009023652 4277 0x55beb7311270 DEBUG spotifyaudiosrc audio/spotify/src/spotifyaudiosrc/imp.rs:337:gstspotify::spotifyaudiosrc::imp:<spotifyaudiosrc0> credentials not in cache
Pipeline is PREROLLING ...
0:00:00.372066451 4277 0x55beb7585c00 DEBUG spotifyaudiosrc audio/spotify/src/spotifyaudiosrc/imp.rs:288:gstspotify::spotifyaudiosrc::imp:<spotifyaudiosrc0> eos
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Redistribute latency...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.000111788
Setting pipeline to NULL ...
0:00:00.372305014 4277 0x55beb7311270 DEBUG spotifyaudiosrc audio/spotify/src/spotifyaudiosrc/imp.rs:262:gstspotify::spotifyaudiosrc::imp:<spotifyaudiosrc0> stopping
Freeing pipeline ...
```Guillaume DesmottesGuillaume Desmotteshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1252codecs: h264decoder: Gap in field picture is not handled2022-05-30T18:32:47ZSeungha Yangseungha@centricular.comcodecs: h264decoder: Gap in field picture is not handledDecoder should be robust against incomplete field pair
(need to address https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/gst-libs/gst/codecs/gsth264decoder.c#L1219)
Test file: [field_gap.mkv](/...Decoder should be robust against incomplete field pair
(need to address https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/gst-libs/gst/codecs/gsth264decoder.c#L1219)
Test file: [field_gap.mkv](/uploads/22320607309bf565ebc05bb1b1d5fdeb/field_gap.mkv)
```
gst-launch-1.0 videotestsrc num-buffers=100 ! video/x-raw,format=NV12,framerate=30/1 ! interlace field-pattern=1 ! video/x-raw,interlace-mode=interleaved ! qsvh264enc ! video/x-h264,stream-format=byte-stream ! h264parse ! matroskamux ! filesink location=field_gap.mkv
```
Note that h264parse will split interlaced frame into two AUs (per field) and then the second field will be dropped by muxer because of unknown PTS.https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/162Request GstForceKeyUnit whenever a new clients connects on shared mount points2023-10-17T17:16:46ZOmer TalRequest GstForceKeyUnit whenever a new clients connects on shared mount pointsHello there,
I'm building an app which has some RTSP servers up and running.
I wish that each clients that connects (and re-uses an existing `GstRTSPMedia`) will send an upstream event to force a new key frame.
I couldn't, however, figu...Hello there,
I'm building an app which has some RTSP servers up and running.
I wish that each clients that connects (and re-uses an existing `GstRTSPMedia`) will send an upstream event to force a new key frame.
I couldn't, however, figure out how to get the `GstRTSPMedia` object from the `GstRTSPClient` object after a connection was made (by using the `client-connected` signal).
I would greatly appreciate any help.
Thank you,
Omerhttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/389Add gstreamer-vulkan2023-12-14T09:53:31ZPhilippe RenonAdd gstreamer-vulkanWould it make sense to add `gstreamer-vulkan` ? There is a `gstreamer-gl` so, I guess, yes it would.
Anyways, I had a first try and hit a roadblock when generating `gstreamer-vulkan-sys` :
```
error[E0433]: failed to resolve: use of und...Would it make sense to add `gstreamer-vulkan` ? There is a `gstreamer-gl` so, I guess, yes it would.
Anyways, I had a first try and hit a roadblock when generating `gstreamer-vulkan-sys` :
```
error[E0433]: failed to resolve: use of undeclared crate or module `vulkan`
--> gstreamer-vulkan\sys\src\lib.rs:767:79
|
767 | unsafe extern "C" fn(*mut GstVulkanWindow, *mut *mut glib::GError) -> vulkan::VkSurfaceKHR,
| ^^^^^^ use of undeclared crate or module `vulkan`
```
The Vulkan objects are not generated.
The Vulkan gir file is quite terse: https://github.com/gtk-rs/gir-files/blob/master/Vulkan-1.0.gir.
I am missing something ?Marijn SuijtenMarijn Suijtenhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1250Follow-up from "va: vpp: add compositor"2022-10-10T11:05:22ZVíctor Manuel Jáquez LealFollow-up from "va: vpp: add compositor"The following discussion from !2332 should be addressed:
- [ ] @He_Junyan started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2332#note_1403622):
> @vjaquez , I think we need to enable this p...The following discussion from !2332 should be addressed:
- [ ] @He_Junyan started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2332#note_1403622):
> @vjaquez , I think we need to enable this property in vapostproc element. It does not make sense that the vacompositor can do this while the vapostproc can not.U. Artie EoffU. Artie Eoffhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1249vulkan: GstVulkan-1.0.gir is missing VulkanUpload, VulkanDownload, VulkanSink...2022-05-29T11:45:05ZPhilippe Renonvulkan: GstVulkan-1.0.gir is missing VulkanUpload, VulkanDownload, VulkanSink (when building with MSYS2/Mingw)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1720vulkan: GstVulkan-1.0.gir is missing VulkanUpload, VulkanDownload, VulkanSink...2022-05-28T16:40:50ZPhilippe Renonvulkan: GstVulkan-1.0.gir is missing VulkanUpload, VulkanDownload, VulkanSink (when building with MSYS2/Mingw)When building with MSYS2/Mingw the resulting GstVulkan-1.0.gir file is not defining VulkanUpload, VulkanDownload, VulkanSink elements.\
Not sure this is a MSYS2/Mingw specific issue.
[GstVulkan-1.0.gir](/uploads/de2568fa2ee7d707293f4da0...When building with MSYS2/Mingw the resulting GstVulkan-1.0.gir file is not defining VulkanUpload, VulkanDownload, VulkanSink elements.\
Not sure this is a MSYS2/Mingw specific issue.
[GstVulkan-1.0.gir](/uploads/de2568fa2ee7d707293f4da003e40d1a/GstVulkan-1.0.gir)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1719Large latency with webrtcbin2022-10-25T02:53:39ZJean-Michaël CelerierLarge latency with webrtcbinHello,
I'm trying to understand where the latency / failures come from with webrtcbin. It takes anything between 2-30 seconds to come up on local host on a web browser (firefox, linux).
When it comes up, video starts to stream immediatel...Hello,
I'm trying to understand where the latency / failures come from with webrtcbin. It takes anything between 2-30 seconds to come up on local host on a web browser (firefox, linux).
When it comes up, video starts to stream immediately, but sound lags for a few more seconds (sometimes up to 20), unless I use autoaudiosrc. audiotestsrc exhibits the same lag.
Code is basically just the webrtc h264 streaming example merged with the appsrc tutorial, with all the things I tried to make it not lag and that can be seen in the comments:
- pushing audio buffers explicitly instead of waiting for them to be pulled
- disabling a/v sync (at least I tried, by toggling the various sync / async fields on rtpbin)
- playing with the latency, frame-size, etc settings of opusenc, webrtcbin and friends
- playing with the audio / video priority
but nothing made any difference (at current HEAD of gstreamer as well as 1.20.2-1.1 as packaged by archlinux)
For simplicity here is the pipeline:
webrtcbin latency=10 name=webrtcbin stun-server=stun://stun.l.google.com:19302
videotestsrc is-live=1 pattern=snow
! videorate ! videoscale
! video/x-raw,width=64,height=64,framerate=60/1
! videoconvert
! queue max-size-buffers=1
! x264enc bitrate=600 speed-preset=ultrafast tune=zerolatency key-int-max=15
! video/x-h264,profile=constrained-baseline
! queue max-size-time=100
! h264parse
! rtph264pay config-interval=-1 name=payloader aggregate-mode=zero-latency
! application/x-rtp,media=video,encoding-name=H264,payload=96
! webrtcbin.
appsrc is-live=1 name=mysound
! audioconvert ! audioresample
! opusenc audio-type=restricted-lowdelay bandwidth=fullband bitrate=128000 frame-size=2.5
! rtpopuspay pt=97 ! webrtcbin.
Files:
[webrtc.cpp](/uploads/45942f9341613ba48c28289d91ba6f80/webrtc.cpp)
[webrtc.html](/uploads/ff5d7dba268cea8c276aa57110271cd5/webrtc.html)
Video of what I'm seeing: in the video, in the third try that finally loads at 00:35, sounds comes up quite a bit after the video (when the "Start feeding" messages appear in the log) - the HTML <audio> and <video> element are synced on the same stream and both start outputting sound at the exact same time.
![bug-gst](/uploads/306cb2635a9eb94ddc47bb0e442986eb/bug-gst.mp4)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1248Make CI tolerant to external infra failures like GNOME2022-05-31T03:04:30ZNirbheek Chauhannirbheek.chauhan@gmail.comMake CI tolerant to external infra failures like GNOMEThe following discussion from !2509 should be addressed:
- [ ] @nirbheek started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2509#note_1402601): (+2 comments)
> > @nirbheek: We should actually ma...The following discussion from !2509 should be addressed:
- [ ] @nirbheek started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2509#note_1402601): (+2 comments)
> > @nirbheek: We should actually make the update non-fatal when the HEAD is on the right revision already, so that we're less dependent on failures from other infra, like GNOME gitlab.
>
> @xclaesse: Sounds like something that would be easier to implement in Meson. As this been an issue in the past?
>
> @xclaesse We could also use more release tarballs instead of git, that would avoid relying on network completely. I had the idea in the past to allow having both [wrap-git] and [wrap-file] sections and Meson would prefer wrap-file but use git if you do --wrap-mode=git which devs probably want but not CI. Something like that.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1247gstreamer-vaapi: elements_vaapipostproc test failing2024-02-19T06:11:56ZJeremy Bichagstreamer-vaapi: elements_vaapipostproc test failing#### Setup
- Debian Unstable or Ubuntu 22.04 LTS
- **GStreamer Version:** 1.20.2
### Steps to reproduce the bug
From **gstreamer-vappi**:
1. `meson test`
### Additional Information
I'd like to run the build tests at build time. Any id...#### Setup
- Debian Unstable or Ubuntu 22.04 LTS
- **GStreamer Version:** 1.20.2
### Steps to reproduce the bug
From **gstreamer-vappi**:
1. `meson test`
### Additional Information
I'd like to run the build tests at build time. Any idea why the test is failing in the minimal Debian/Ubuntu build environment?
https://buildd.debian.org/status/logs.php?pkg=gstreamer-vaapi1.0&arch=amd64
```
1/2 elements_vaapipostproc FAIL 0.33s exit status 3
08:40:28 GST_REGISTRY=/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tests/check/elements_vaapipostproc.registry
GST_PLUGIN_SYSTEM_PATH_1_0=''
GST_PLUGIN_PATH_1_0=/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/gstreamer-1.0
CK_DEFAULT_TIMEOUT=20 MALLOC_PERTURB_=215 /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tests/check/elements_vaapipostproc
----------------------------------- output -----------------------------------
Running suite(s): vaapipostproc
0%: Checks: 3, Failures: 3, Errors: 0
../tests/check/elements/vaapipostproc.c:57:F:general:test_make:0: Failed to create vaapipostproc element
../tests/check/elements/vaapipostproc.c:79:F:general:test_crop_mouse_events:0: Failed to create vaapipostproc element
../tests/check/elements/vaapipostproc.c:79:F:general:test_orientation_mouse_events:0: Failed to create vaapipostproc element
Check suite vaapipostproc ran in 0.010s (tests failed: 3)
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1246gstreamer-editing-services: nleoperation test timeout too low2022-05-27T18:01:37ZJeremy Bichagstreamer-editing-services: nleoperation test timeout too low#### Setup
- Debian Unstable or Ubuntu 22.04 LTS
- **GStreamer Version:** 1.20.2
### Steps to reproduce the bug
From **gstreamer-editing-services**:
1. `meson test`
### Additional Information
https://buildd.debian.org/status/logs.php?...#### Setup
- Debian Unstable or Ubuntu 22.04 LTS
- **GStreamer Version:** 1.20.2
### Steps to reproduce the bug
From **gstreamer-editing-services**:
1. `meson test`
### Additional Information
https://buildd.debian.org/status/logs.php?pkg=gstreamer-editing-services1.0&arch=amd64
You could just copy the [timeout increase](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-editing-services/tests/check/nle/tempochange.c#L644-647) lines from the tempochange test.
```
23/23 nle_nleoperation FAIL 67.85s exit status 1
17:42:17 GST_PLUGIN_PATH_1_0=/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/gstreamer-1.0:
/usr/lib/x86_64-linux-gnu/gstreamer-1.0:/usr/lib/x86_64-linux-gnu/gstreamer-1.0 CK_DEFAULT_TIMEOUT=20
GST_PLUGIN_SYSTEM_PATH_1_0='' MALLOC_PERTURB_=115
GST_REGISTRY=/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tests/check/nle_nleoperation.registry
GST_STATE_IGNORE_ELEMENTS='' /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tests/check/nle_nleoperation
----------------------------------- output -----------------------------------
Running suite(s): nleoperation
83%: Checks: 6, Failures: 0, Errors: 1
../tests/check/nle/common.c:163:E:nleoperation:test_pyramid_operations:0: (after this point) Test timeout expired
Check suite gnonlin ran in 66.517s (tests failed: 1)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/205Build error: shutil.move(...) in cargo_wrapper.py results in AttributeError2022-08-30T06:13:28ZKlaas Jan RusscherBuild error: shutil.move(...) in cargo_wrapper.py results in AttributeErrorThe last line of cargo_wrapper.py is `shutil.move(f, uninstalled)`. For Python3.8 this results in the error:
```
Traceback (most recent call last):
File "/home/user/temp/gstreamer/subprojects/gst-plugins-rs/cargo_wrapper.py", line 140,...The last line of cargo_wrapper.py is `shutil.move(f, uninstalled)`. For Python3.8 this results in the error:
```
Traceback (most recent call last):
File "/home/user/temp/gstreamer/subprojects/gst-plugins-rs/cargo_wrapper.py", line 140, in <module>
shutil.move(f, uninstalled)
File "/usr/lib/python3.8/shutil.py", line 787, in move
real_dst = os.path.join(dst, _basename(src))
File "/usr/lib/python3.8/shutil.py", line 750, in _basename
return os.path.basename(path.rstrip(sep))
AttributeError: 'PosixPath' object has no attribute 'rstrip'
```
The reason in that `shutil.move(...)` supports path copies from Python 3.9 on, and I am using Python3.8 for which `shutil.move(..)` only supports string arguments (see [shutil.move(...) documentation](https://docs.python.org/3/library/shutil.html#shutil.move)).
I will upload a commit shortly that checks the python version and that uses `shutil.move(str(f), str(uninstalled))` for Python3.8 and older.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1245gst-libav: generic_plugin_test fails2022-09-22T07:03:02ZJeremy Bichagst-libav: generic_plugin_test fails#### Setup
- Debian Unstable or Ubuntu 22.04 LTS
- **GStreamer Version:** 1.20.2
### Steps to reproduce the bug
From **gst-libav**:
1. `meson test`
### Additional Information
https://buildd.debian.org/status/logs.php?pkg=gst-libav1.0&...#### Setup
- Debian Unstable or Ubuntu 22.04 LTS
- **GStreamer Version:** 1.20.2
### Steps to reproduce the bug
From **gst-libav**:
1. `meson test`
### Additional Information
https://buildd.debian.org/status/logs.php?pkg=gst-libav1.0&arch=amd64
```
5/6 generic_plugin_test FAIL 0.49s exit status 1
08:50:52 GST_PLUGIN_SYSTEM_PATH_1_0='' GST_PLUGIN_LOADING_WHITELIST=gstreamer:gst-plugins-base:gst-libav@/
<<PKGBUILDDIR>>/obj-x86_64-linux-gnu MALLOC_PERTURB_=19 GST_PLUGIN_PATH_1_0=/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu:
/usr/lib/x86_64-linux-gnu/gstreamer-1.0:/usr/lib/x86_64-linux-gnu/gstreamer-1.0
GST_REGISTRY=/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tests/check/generic_plugin_test.registry
GST_PLUGIN_SCANNER_1_0=/usr/libexec/gstreamer-1.0/gst-plugin-scanner CK_DEFAULT_TIMEOUT=20 GSETTINGS_BACKEND=memory
/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tests/check/generic_plugin_test
----------------------------------- output -----------------------------------
stdout:
Running suite(s): Plugin
Unexpected critical/warning: External plugin loader failed. This most likely means that the plugin
loader helper binary was not found or could not be run. You might need to set the GST_PLUGIN_SCANNER
environment variable if your setup is unusual. This should normally not be required though.
Stack trace:
gst_debug_get_stack_trace (/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2001.0:0x7f5123a2380b)
?? (/usr/lib/x86_64-linux-gnu/libgstcheck-1.0.so.0.2001.0:0x7f5123856aa7)
g_logv (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.1:0x7f51238cc989)
g_log (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.1:0x7f51238ccc6b)
?? (/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2001.0:0x7f5123a4f9b6)
?? (/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2001.0:0x7f5123a50a2d)
?? (/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2001.0:0x7f5123a50bac)
gst_update_registry (/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2001.0:0x7f5123a521c0)
test_libav_update_reg (plugin-test.c:61)
srunner_run_tagged (/usr/lib/x86_64-linux-gnu/libgstcheck-1.0.so.0.2001.0:0x7f51238642e5)
gst_check_run_suite (/usr/lib/x86_64-linux-gnu/libgstcheck-1.0.so.0.2001.0:0x7f5123857f8b)
main (plugin-test.c:98)
__libc_start_main (/lib/x86_64-linux-gnu/libc-2.33.so:0x7f51236957f9)
_start (/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/tests/check/generic_plugin_test:0x56105143f2a6)
50%: Checks: 2, Failures: 1, Errors: 0
../libs/gst/check/gstcheck.c:286:F:existence:test_libav_update_reg:0: Unexpected critical/warning:
External plugin loader failed. This most likely means that the plugin loader helper binary was not
found or could not be run. You might need to set the GST_PLUGIN_SCANNER environment variable if your
setup is unusual. This should normally not be required though.
Check suite plugin_test ran in 0.059s (tests failed: 1)
stderr:
(generic_plugin_test): GStreamer-WARNING **: External plugin loader failed.
This most likely means that the plugin loader helper binary was not found
or could not be run. You might need to set the GST_PLUGIN_SCANNER environment
variable if your setup is unusual. This should normally not be required though.
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1244flaky camerabin test in bad plugins2022-05-26T21:14:08ZJeremy Bichaflaky camerabin test in bad plugins#### Setup
- Debian Unstable or Ubuntu 22.10 Development or Ubuntu 22.04 LTS
- **GStreamer Version:** 1.20.2
### Steps to reproduce the bug
From **gst-plugins-bad**:
1. `meson test`
### Additional Information
The test passes sometimes...#### Setup
- Debian Unstable or Ubuntu 22.10 Development or Ubuntu 22.04 LTS
- **GStreamer Version:** 1.20.2
### Steps to reproduce the bug
From **gst-plugins-bad**:
1. `meson test`
### Additional Information
The test passes sometimes but often fails. Here's an example on arm64:
https://launchpadlibrarian.net/603454185/buildlog_ubuntu-kinetic-arm64.gst-plugins-bad1.0_1.20.2-1ubuntu1_BUILDING.txt.gz
```
77/77 elements_camerabin FAIL 61.66s exit status 1
20:09:24 CK_DEFAULT_TIMEOUT=20 GST_PLUGIN_SCANNER_1_0=/usr/libexec/gstreamer-1.0/gst-plugin-scanner
GST_PLUGIN_PATH_1_0=/<<PKGBUILDDIR>>/obj-aarch64-linux-gnu:/usr/lib/aarch64-linux-gnu/gstreamer-1.0:
/usr/lib/aarch64-linux-gnu/gstreamer-1.0 GST_PLUGIN_SYSTEM_PATH_1_0=''
GST_REGISTRY=/<<PKGBUILDDIR>>/obj-aarch64-linux-gnu/tests/check/elements_camerabin.registry
GST_PLUGIN_LOADING_WHITELIST=gstreamer:gst-plugins-base:gst-plugins-good:gst-plugins-ugly:
gst-libav:libnice:gst-plugins-bad@/<<PKGBUILDDIR>>/obj-aarch64-linux-gnu
GST_STATE_IGNORE_ELEMENTS='' MALLOC_PERTURB_=192 /<<PKGBUILDDIR>>/obj-aarch64-linux-gnu/tests/check/elements_camerabin
----------------------------------- output -----------------------------------
stdout:
Running suite(s): camerabin
Unexpected critical/warning:
Trying to dispose element audiotestsrc0, but it is in READY (locked) instead of the NULL state.
You need to explicitly set elements to the NULL state before
dropping the final reference, to allow them to clean up.
This problem may also be caused by a refcounting bug in the
application or some element.
Stack trace:
gst_debug_get_stack_trace (/usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0.2002.0:0xffff8886a55c)
?? (/usr/lib/aarch64-linux-gnu/libgstcheck-1.0.so.0.2002.0:0xffff88432988)
g_logv (/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0.7200.1:0xffff8867ddb0)
g_log (/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0.7200.1:0xffff8867e048)
g_object_unref (/usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0.7200.1:0xffff887939e0)
?? (/usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0.2002.0:0xffff888382c8)
gst_bin_remove (/usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0.2002.0:0xffff88833698)
?? (/usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0.2002.0:0xffff88833e30)
g_object_unref (/usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0.7200.1:0xffff887939e0)
teardown (camerabin.c:750)
?? (/usr/lib/aarch64-linux-gnu/libgstcheck-1.0.so.0.2002.0:0xffff88438508)
srunner_run_tagged (/usr/lib/aarch64-linux-gnu/libgstcheck-1.0.so.0.2002.0:0xffff88439214)
gst_check_run_suite (/usr/lib/aarch64-linux-gnu/libgstcheck-1.0.so.0.2002.0:0xffff88435d68)
main (camerabin.c:2002)
?? (/usr/lib/aarch64-linux-gnu/libc.so.6:0xffff882973f8)
__libc_start_main (/usr/lib/aarch64-linux-gnu/libc.so.6:0xffff882974c8)
_start (/<<PKGBUILDDIR>>/obj-aarch64-linux-gnu/tests/check/elements_camerabin:0xaaaac68f186c)
94%: Checks: 17, Failures: 1, Errors: 0
../libs/gst/check/gstcheck.c:286:S:wrappercamerabinsrc:test_multiple_video_recordings:0: Unexpected critical/warning:
Trying to dispose element audiotestsrc0, but it is in READY (locked) instead of the NULL state.
You need to explicitly set elements to the NULL state before
dropping the final reference, to allow them to clean up.
This problem may also be caused by a refcounting bug in the
application or some element.
Check suite camerabin ran in 60.679s (tests failed: 1)
stderr:
(elements_camerabin): GStreamer-WARNING **: External plugin loader failed.
This most likely means that the plugin loader helper binary was not found
or could not be run. You might need to set the GST_PLUGIN_SCANNER environment
variable if your setup is unusual. This should normally not be required though.
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1242Unable to specify non-standard strides in video meta2022-05-27T21:18:36ZMichael Grünermichael.gruner@ridgerun.comUnable to specify non-standard strides in video meta### 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 experiencing a regression after what appears to be [this commit](https://github.com/GStreamer/gst-plugins-base/commit/75680e5d34ac0d2d67d3ca1064798ece8860000d) by @gdesmott. I'm developing a source element for a camera that may produce images with odd widths. If I'm not mistaken, GStreamer will [automatically assume a 4-byte aligned stride](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/blob/1.18.4/gst-libs/gst/video/video-info.c#L817). My camera won't add this stride, so I indicate the actual stride in my buffer's video meta. For a 321x240 RGB image, the actual stride my camera gives is 963 (321*3) instead of the 964 GStreamer assumes, for example.
This used to work fine, however, on GStreamer 1.20 if I run the following pipeline:
```
GST_DEBUG=2 gst-launch-1.0 oddsrc ! video/x-raw,format=BGR,width=321,height=240 ! videoconvert ! autovideosink
```
I get the following per-buffer warning and nothing gets displayed:
```
0:00:00.582173000 92829 0x107016f00 WARN videometa gstvideometa.c:416:gst_video_meta_validate_alignment: Stride of plane 0 defined in meta (963) is different from the one computed from the alignment (964)
```
Note that I cannot test this with videotestsrc, because unlike videotestsrc, my camera doesn't actually add any padding. Here's a [mock source element that reproduces this same issue](https://gist.github.com/michaelgruner/b1c2d138ed76c49244cb8172e0e35b3d).
Studying the source code, I noticed [the following check](https://gitlab.com/gstreamer/gst-plugins-base/-/blob/master/gst-libs/gst/video/gstvideometa.c#L413):
```c
if (GST_VIDEO_INFO_PLANE_STRIDE (&info, i) != meta->stride[i]) {
GST_WARNING
("Stride of plane %d defined in meta (%d) is different from the one computed from the alignment (%d)",
i, meta->stride[i], GST_VIDEO_INFO_PLANE_STRIDE (&info, i));
return FALSE;
}
```
which seems off to me. I understand my use case is rare, but this would also forbid sources from ever using different strides from the GStreamer computed ones.
Am I missing something? I'd be happy to collaborate with a fix if you consider this to be unwanted behavior.
#### Expected Behavior
My source element creates buffers with non-standard strides and it indicates these strides using `gst_buffer_add_video_meta_full`. The following pipeline used to work fine:
```
GST_DEBUG=2 gst-launch-1.0 oddsrc ! video/x-raw,format=BGR,width=321,height=240 ! videoconvert ! autovideosink
```
#### Observed Behavior
I get these per-buffer warnings:
```
0:00:00.582173000 92829 0x107016f00 WARN videometa gstvideometa.c:416:gst_video_meta_validate_alignment: Stride of plane 0 defined in meta (963) is different from the one computed from the alignment (964)
```
#### Setup
- **Operating System:** MacOS Monterrey 12.3.1
- **Device:** Computer
- **GStreamer Version:** 1.20.1
- **Command line:** `GST_DEBUG=2 gst-launch-1.0 oddsrc ! videoconvert ! autovideosink`
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open terminal
2. copy the contents of [gstoddsrc.c](https://gist.github.com/michaelgruner/b1c2d138ed76c49244cb8172e0e35b3d) into a file with the same name.
3. build the plug-in with `gcc gstoddsrc.c $(pkg-config --cflags --libs gstreamer-1.0 gstreamer-base-1.0 gstreamer-video-1.0) -shared -o gstoddsrc.so`
4. export the current location as a plugin-path: `export GST_PLUGIN_PATH=$(pwd)`
5. run the following pipeline: `GST_DEBUG=2 gst-launch-1.0 oddsrc ! videoconvert ! autovideosink`
### How reproducible is the bug?
The reproducibility of the bug is Always after doing a very specific set of steps
### Screenshots if relevant
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
I can help with the fix if you consider this to be real!