GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-06-04T03:21:45Zhttps://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/gstreamer/-/issues/1257gst-plugins-base: (examples) qt-videooverlay not functional2022-06-03T09:37:02ZMarc Leemangst-plugins-base: (examples) qt-videooverlay not functionalAdding it here as a bug for follow up while we look for a solution (discussed on IRC with @tpm
gst-plugins-base has a number of examples to illustrate the integration of GStreamer within different frameworks (e.g. Qt en Gtk).
When cha...Adding it here as a bug for follow up while we look for a solution (discussed on IRC with @tpm
gst-plugins-base has a number of examples to illustrate the integration of GStreamer within different frameworks (e.g. Qt en Gtk).
When changing the application qt-videooverlay.cpp to use the following pipeline:
```sh
rfbsrc uri=rfb://:testme@10.40.216/126 ! videoconvert ! autovideosink
```
instead of
```sh
videotestsrc ! autovideosink
```
This should allow to connect to a VNC server and use it with keyboard/mouse interaction.
However, only the keyboard events are traveling upstream to the VNC server (tightvncserver).
Much to my surprise, the gtk-videooverlay.c application did work. However, I noticed that the rendered window was not the GTK window, but a different window.
This lead me to the fact that the GTK code did not return the window handle (`embed_xid = GDK_WINDOW_XID (video_window_xwindow);`) and '0' was passed to `gst_video_overlay_set_window_handle (GST_VIDEO_OVERLAY (sink), embed_xid);`.
This resulted in the different window.
In the QT application; a correct handle was passed.
The difference is that in
`./subprojects/gst-plugins-base/sys/xvimage/xvimagesink.c`, an internal window is generated instead using the existing one.
Finally, I traced down the rabbit hole and changed the following in `./subprojects/gst-plugins-base/sys/xvimage/xvcontext.c`
```diff
diff --git a/subprojects/gst-plugins-base/sys/xvimage/xvcontext.c b/subprojects/gst-plugins-base/sys/xvimage/xvcontext.c
index a67194c21c..61413eb573 100644
--- a/subprojects/gst-plugins-base/sys/xvimage/xvcontext.c
+++ b/subprojects/gst-plugins-base/sys/xvimage/xvcontext.c
@@ -1057,7 +1057,10 @@ gst_xvcontext_create_xwindow_from_xid (GstXvContext * context, XID xid)
window = g_slice_new0 (GstXWindow);
- window->win = xid;
+ /*window->win = xid;*/
+ window->win = XCreateSimpleWindow (context->disp,
+ context->root, 0, 0, 360, 260, 0, 0, context->black);
+
window->context = gst_xvcontext_ref (context);
/* Set the event we want to receive and create a GC */
```
This resulted in getting the mouse move events passed upstream (so create a new X window instead of using the window passed to us). Since the changes are only X related; I don't think that this is really a GStreamer issue (tm); but it might be helpful to trace the issue in order to fix the example code.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/144input-selector element generates wrong DTS timestamps with sync-mode=0 and mu...2022-06-03T00:10:06ZBugzilla Migration Userinput-selector element generates wrong DTS timestamps with sync-mode=0 and multiple rtspsrc (same video format/framerates)## Submitted by Tapas Kumar Kundu
**[Link to original bug (#759470)](https://bugzilla.gnome.org/show_bug.cgi?id=759470)**
## Description
input-selector: it switches to active live video stream (rtspsrc) without checking for keyframe...## Submitted by Tapas Kumar Kundu
**[Link to original bug (#759470)](https://bugzilla.gnome.org/show_bug.cgi?id=759470)**
## Description
input-selector: it switches to active live video stream (rtspsrc) without checking for keyframes.
This causes input-selector to miss keyframe from rtspsrc and this causes additional delay (video is paused for 1second) during camera switching using input-selector.
Test case:
I have 5 ip cameras (all are rtspsrc element) and one audio src (rtspsrc)
All 5 ip cameras are connected with input-selector element and it switched from one camera to another camera.
My code works perfectly fine [1] : http://hastebin.com/raw/adatujewes
But there is one flaw in streaming. I am seeing a pause for 1 second whenever input-selector is switching between camera.
Look at timestamp 1min 12sec on my streaming video url which is using my binary generated from code [1]:
[2] https://www.youtube.com/watch?v=NPlN_3YhmrM
You will see cameras are switched every 5 seconds after 1:12 on that url [2] However, there is a pause of 1 second when camera switching happens,
I tried with changing delay of queue/ replacing queue with queue2/ making rtspsec latency=0 .
But nothing helps me .
Proposed Solution:
Fix input-selector element so that it can wait for keyframes before switching to live stream. This will give gapless video switching from input-selector element.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1255Loading soup plugin causes critical warning2022-06-02T13:24:24ZJan Alexander SteffensLoading soup plugin causes critical warningThis is new in the 1.20 branch, presumably a regression from !2491 (!2349 in main).
```rust
#0 g_logv (log_domain=0x7f21a8a1ab46 "GStreamer", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=<optimized out>) at ../glib/glib...This is new in the 1.20 branch, presumably a regression from !2491 (!2349 in main).
```rust
#0 g_logv (log_domain=0x7f21a8a1ab46 "GStreamer", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=<optimized out>) at ../glib/glib/gmessages.c:1418
#1 0x00007f21a978bad4 in g_log (log_domain=log_domain@entry=0x7f21a8a1ab46 "GStreamer", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7f21a97e7d57 "%s: assertion '%s' failed") at ../glib/glib/gmessages.c:1456
#2 0x00007f21a978d73e in g_return_if_fail_warning (log_domain=log_domain@entry=0x7f21a8a1ab46 "GStreamer", pretty_function=pretty_function@entry=0x7f21a8a2a730 <__func__.16> "gst_debug_log_valist", expression=expression@entry=0x7f21a8a29a8c "category != NULL") at ../glib/glib/gmessages.c:2942
#3 0x00007f21a899a73b in gst_debug_log_valist (category=0x0, level=GST_LEVEL_DEBUG, file=0x7f21a8915690 "../../../gst/main/subprojects/gst-plugins-good/ext/soup/gstsouploader.c", function=0x7f21a89166b0 <__func__.37> "gst_soup_load_library", line=163, object=0x0, format=0x7f21a89153b8 "Trying all libsoups", args=0x7fffd1e38a30) at ../../../gst/main/subprojects/gstreamer/gst/gstinfo.c:553
#4 0x00007f21a899a8c9 in gst_debug_log (category=<optimized out>, level=level@entry=GST_LEVEL_DEBUG, file=file@entry=0x7f21a8915690 "../../../gst/main/subprojects/gst-plugins-good/ext/soup/gstsouploader.c", function=function@entry=0x7f21a89166b0 <__func__.37> "gst_soup_load_library", line=line@entry=163, object=object@entry=0x0, format=0x7f21a89153b8 "Trying all libsoups") at ../../../gst/main/subprojects/gstreamer/gst/gstinfo.c:502
#5 0x00007f21a89104a9 in gst_soup_load_library () at ../../../gst/main/subprojects/gst-plugins-good/ext/soup/gstsouploader.c:163
#6 0x00007f21a8906f80 in soup_element_init (plugin=plugin@entry=0x557f19905ac0 [GstPlugin]) at ../../../gst/main/subprojects/gst-plugins-good/ext/soup/gstsoupelement.c:59
#7 0x00007f21a891022a in souphttpsrc_element_init (plugin=plugin@entry=0x557f19905ac0 [GstPlugin]) at ../../../gst/main/subprojects/gst-plugins-good/ext/soup/gstsouphttpsrc.c:2641
#8 0x00007f21a8910281 in gst_element_register_souphttpsrc (plugin=plugin@entry=0x557f19905ac0 [GstPlugin]) at ../../../gst/main/subprojects/gst-plugins-good/ext/soup/gstsouphttpsrc.c:277
#9 0x00007f21a8906ef8 in plugin_init (plugin=0x557f19905ac0 [GstPlugin]) at ../../../gst/main/subprojects/gst-plugins-good/ext/soup/gstsoup.c:34
#10 0x00007f21a89bd69a in gst_plugin_register_func (plugin=plugin@entry=0x557f19905ac0 [GstPlugin], desc=desc@entry=0x7f21a8919ce0 <gst_plugin_desc>, user_data=user_data@entry=0x0) at ../../../gst/main/subprojects/gstreamer/gst/gstplugin.c:532
#11 0x00007f21a89bfe06 in _priv_gst_plugin_load_file_for_registry (filename=0x557f19916300 "/home/jan/.cache/gst-build/main/subprojects/gst-plugins-good/ext/soup/libgstsoup.so", registry=0x557f1984a930 [GstRegistry], registry@entry=0x0, error=error@entry=0x7fffd1e38d60) at ../../../gst/main/subprojects/gstreamer/gst/gstplugin.c:971
#12 0x00007f21a89c080f in gst_plugin_load_file (filename=<optimized out>, error=error@entry=0x7fffd1e38d60) at ../../../gst/main/subprojects/gstreamer/gst/gstplugin.c:689
#13 0x00007f21a89c0c93 in gst_plugin_load_by_name (name=0x557f199156a5 "soup") at ../../../gst/main/subprojects/gstreamer/gst/gstplugin.c:1411
#14 0x00007f21a89c1857 in gst_plugin_feature_load (feature=feature@entry=0x557f199141c0 [GstElementFactory]) at ../../../gst/main/subprojects/gstreamer/gst/gstpluginfeature.c:112
#15 0x00007f21a898cd05 in gst_element_factory_create_with_properties (factory=factory@entry=0x557f199141c0 [GstElementFactory], n=n@entry=0, names=names@entry=0x0, values=values@entry=0x0) at ../../../gst/main/subprojects/gstreamer/gst/gstelementfactory.c:481
#16 0x00007f21a898d3f4 in gst_element_factory_make_with_properties (factoryname=0x557f197d2100 "souphttpsrc", n=n@entry=0, names=names@entry=0x0, values=values@entry=0x0) at ../../../gst/main/subprojects/gstreamer/gst/gstelementfactory.c:689
#17 0x00007f21a898d92d in gst_element_factory_make (factoryname=<optimized out>, name=<optimized out>) at ../../../gst/main/subprojects/gstreamer/gst/gstelementfactory.c:814
```https://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/gst-rtsp-server/-/issues/134Not clear how to implement custom SET_PARAMETER request handling2022-05-31T09:21:08ZJames HenstridgeNot clear how to implement custom SET_PARAMETER request handlingI wanted to add support for a custom SET_PARAMETER request to my RTSP server. The documentation makes it look like it should be possible, documenting a `GstRTSPClient::set-parameter-request` signal, and I found the following mailing lis...I wanted to add support for a custom SET_PARAMETER request to my RTSP server. The documentation makes it look like it should be possible, documenting a `GstRTSPClient::set-parameter-request` signal, and I found the following mailing list post with some pointers:
https://lists.freedesktop.org/archives/gstreamer-devel/2019-September/072856.html
I managed to cobble something together by connecting to the `GstRTSPServer::client-created` signal, then connecting to each client's `set-parameter-request` signal. I could now see the requests coming in, but they always result in an error response:
```
$ telnet localhost 8554
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SET_PARAMETER rtsp://localhost:8554/test RTSP/2.0
CSeq: 42
Connection: close
Content-Type: text/parameters
Content-Length: 7
foo=bar
RTSP/2.0 451 Parameter Not Understood
CSeq: 42
Server: GStreamer RTSP server
Date: Wed, 17 Mar 2021 03:27:38 GMT
```
Looking at the `handle_set_param_request` source code, it looks like it generates the response before emitting the signal. Reading through that function, I see it calls a `params_set` virtual method to handle the request. That sent me down a second implementation attempt:
1. create a GstRTSPClient subclass that overrides params_set to handle my parameters.
2. create a GstRTSPServer subclass that overrides create_client to return my GstRTSPClient subclass.
(2) turned out to be a problem, as the default implementation of `create_client` does substantially more than just create a new client instance. And the additional setup it performs makes use of private GstRTSPServer API not available outside of the library.
So how is this supposed to work? Would it be possible to provide an example demonstrating how the API should be used?https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/310gst_ios_init.m implementation contains error2022-05-31T06:36:36Zjuricagst_ios_init.m implementation contains errorHi,
I had the issue that our iOS App started crashing when playing files via https.
The code/pipeline was working but then suddenly the error occured. Most likely it's caused by the update to iOS 14.2, but I wasn't able to find out why....Hi,
I had the issue that our iOS App started crashing when playing files via https.
The code/pipeline was working but then suddenly the error occured. Most likely it's caused by the update to iOS 14.2, but I wasn't able to find out why.
As we're using the binary distribution of GStreamer and the whole application stack is rather complex I wasn't able to find out more from the stacktrace than that the crash happend in "_get_portable_X509_cert_file" (called from souphttpsrc).
As I digged into the problem I found out that the way [gst_ios_init.m](https://gitlab.freedesktop.org/gstreamer/cerbero/-/blob/master/data/xcode/templates/ios/GStreamer%20Base.xctemplate/gst_ios_init.m) is implemented is wrong and thus most likely on iOS no certificate database is configured at all.
`g_tls_file_database_new` needs an existing file to be passed as "anchors", it does not create the file itself. In addition it has to contain at least one certificate in PEM encoded format.
My guess is that from iOS 14.2 on some related internals changed that now lead to the crash when no certificate database was set up for GTls.
I shipped around the problem by writing a random certificate to the file given to `g_tls_file_database_new` as "anchors", this is ok as we work with self signed certificates and don't do validation. On other setups a proper certificate store has to be used.
I'm opening this issue as it was quite hard to find the cause of the problem. Perhaps it's worth adding a comment to the implementation as a reference or even improve the code a bit, i.e. add an check if the file exists or so.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/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/112Initial stream corruption on second+ stream2022-05-30T06:59:03ZMatthew Watersmatthew@centricular.comInitial stream corruption on second+ streamRunning one of the the simplest rtsp-server commands:
`gst-rtsp-server/examples/test-launch 'videotestsrc ! x264enc tune=zerolatency ! rtph264pay name=pay0'`
and playback with gst-play-1.0 (note the second gst-play-1.0 is the one that ...Running one of the the simplest rtsp-server commands:
`gst-rtsp-server/examples/test-launch 'videotestsrc ! x264enc tune=zerolatency ! rtph264pay name=pay0'`
and playback with gst-play-1.0 (note the second gst-play-1.0 is the one that has the corruption):
`gst-play-1.0 rtsp://127.0.0.1:8554/test`
`gst-play-1.0 rtsp://127.0.0.1:8554/test`
Shows initial stream corruption of a classic gray image with the libav decoder.
Reverting to before both https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/147 and https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/merge_requests/135 still results in initial corruption so it has not been fixed by recent related fixes.https://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/gstreamer-rs/-/issues/261[Question] Creating a struct implementing MetaAPI2022-05-28T00:15:42ZDaniel Suess[Question] Creating a struct implementing MetaAPIFirst of all thanks for maintaining these bindings, I am new to Rust, but worked with GStreamer a bit in the past. The ease of use and confidence I get in what I am writing is miles ahead of C code I used to write. Also, apologies if thi...First of all thanks for maintaining these bindings, I am new to Rust, but worked with GStreamer a bit in the past. The ease of use and confidence I get in what I am writing is miles ahead of C code I used to write. Also, apologies if this is not the right place to ask this.
I am trying to implement a struct with the `MetaAPI` trait. However, I can't figure what is the `GstType`? Below is a minimal example:
```
struct StreamIdMeta {
stream_id: u32,
}
unsafe impl MetaAPI for StreamIdMeta {
type GstType = ???
fn get_meta_api() -> glib::Type {
glib::types::Type::U32
}
}
```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!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-bad/-/issues/913Add AES-GCM Authenticated Encryption (RFC 7714) support2022-05-27T10:00:25ZUlf OlssonAdd AES-GCM Authenticated Encryption (RFC 7714) supportSee https://tools.ietf.org/html/rfc7714See https://tools.ietf.org/html/rfc7714https://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/gst-plugins-good/-/issues/816v4l2videodec: handle bt2020_102022-05-26T13:36:16ZKevin Songv4l2videodec: handle bt2020_10V4l2object has trick to handle bt2020 as v4l2 don't have those defines. I have one stream which is bt2020_10 which is parsed from h265parse. But v4l2videodec can't handle it. it will changed to bt2020_12 as below code. I think we can map...V4l2object has trick to handle bt2020 as v4l2 don't have those defines. I have one stream which is bt2020_10 which is parsed from h265parse. But v4l2videodec can't handle it. it will changed to bt2020_12 as below code. I think we can map gst bt2020_10/12 to v4l2 bt709, but need consider input caps transfer when map v4l2 bt709 back to gst bt2020_10/12. Is it reasonable?
switch (transfer) {
case V4L2_XFER_FUNC_709:
if (colorspace == V4L2_COLORSPACE_BT2020 && fmt->fmt.pix.height >= 2160)
cinfo->transfer = GST_VIDEO_TRANSFER_BT2020_12;
else
cinfo->transfer = GST_VIDEO_TRANSFER_BT709;
break;https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/767srtpdec: example pipelines do not work, caps are not detected2022-05-26T07:42:13ZBugzilla Migration Usersrtpdec: example pipelines do not work, caps are not detected## Submitted by Kevin Mullican
**[Link to original bug (#796941)](https://bugzilla.gnome.org/show_bug.cgi?id=796941)**
## Description
The example pipelines on the docs page https://gstreamer.freedesktop.org/data/doc/gstreamer/head/g...## Submitted by Kevin Mullican
**[Link to original bug (#796941)](https://bugzilla.gnome.org/show_bug.cgi?id=796941)**
## Description
The example pipelines on the docs page https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-srtpdec.html do not work.
System:
$ uname -a
Linux big-p 4.4.0-17134-Microsoft` #137`-Microsoft Thu Jun 14 18:46:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
$ dpkg -l | grep gst | grep bad
ii gstreamer1.0-plugins-bad:amd64 1.8.3-1ubuntu0.2 amd64 GStreamer plugins from the "bad" set
source:
gst-launch-1.0 audiotestsrc ! alawenc ! rtppcmapay ! 'application/x-rtp, payload=(int)8, ssrc=(uint)1356955624' ! srtpenc key="012345678901234567890123456789012345678901234567890123456789" ! udpsink port=5004
dest:
GST_DEBUG=srtpdec:5 gst-launch-1.0 udpsrc port=5004 caps='application/x-srtp, payload=(int)8, ssrc=(uint)1356955624, srtp-key=(buffer)012345678901234567890123456789012345678901234567890123456789, srtp-cipher=(string)aes-128-icm, srtp-auth=(string)hmac-sha1-80, srtcp-cipher=(string)aes-128-icm, srtcp-auth=(string)hmac-sha1-80' ! srtpdec ! rtppcmadepay ! alawdec ! pulsesink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:00.080196000 5703 0x26388f0 WARN srtpdec gstsrtpdec.c:770:request_key_with_signal:`<srtpdec0>` Could not get caps for stream with SSRC 1356955624
0:00:00.083958000 5703 0x26388f0 WARN srtpdec gstsrtpdec.c:1212:gst_srtp_dec_chain:`<srtpdec0>` Invalid buffer, dropping
...
repeats forever
Version: 1.8.3https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1227jpegdec: Segfault in libgstjpeg gst_jpeg_dec_handle_frame2022-05-25T05:50:35ZJames Hilliardjpegdec: Segfault in libgstjpeg gst_jpeg_dec_handle_frame### 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/ -->
Capturing a mjpeg stream through pipewire from a uvc camera has visual glitching and crashes with a segfault in libgstjpeg.
I am using libjpeg-turbo.
#### Setup
- **Operating System:** buildroot
- **Device:** Computer
- **GStreamer Version:** 1.20.1
- **Command line:** N/A
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open mjpeg camera stream in wpewebkit
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Within minutes
### Related non-duplicate issues
#1118 #1121 #1122
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->
```c
(gdb) bt
#0 gst_jpeg_dec_handle_frame (bdec=0x7f5e2c1e9a00, frame=0x7f5e80089a00) at ../ext/jpeg/gstjpegdec.c:1352
#1 0x00007f5ef8259977 in gst_video_decoder_decode_frame (decoder=decoder@entry=0x7f5e2c1e9a00, frame=frame@entry=0x7f5e80089a00) at ../gst-libs/gst/video/gstvideodecoder.c:4003
#2 0x00007f5ef8259d6c in gst_video_decoder_chain_forward (decoder=decoder@entry=0x7f5e2c1e9a00, buf=buf@entry=0x7f5e30122d80, at_eos=at_eos@entry=0) at ../gst-libs/gst/video/gstvideodecoder.c:2489
#3 0x00007f5ef825bd67 in gst_video_decoder_chain (pad=<optimized out>, parent=0x7f5e2c1e9a00, buf=0x7f5e30122d80) at ../gst-libs/gst/video/gstvideodecoder.c:2831
#4 0x00007f5efaf27a18 in gst_pad_chain_data_unchecked (pad=pad@entry=0x5646094e0c10, type=type@entry=4112, data=data@entry=0x7f5e30122d80) at ../gst/gstpad.c:4447
#5 0x00007f5efaf2935e in gst_pad_push_data (pad=pad@entry=0x5646094e0520, type=type@entry=4112, data=data@entry=0x7f5e30122d80) at ../gst/gstpad.c:4711
#6 0x00007f5efaf2e377 in gst_pad_push (pad=pad@entry=0x5646094e0520, buffer=buffer@entry=0x7f5e30122d80) at ../gst/gstpad.c:4830
#7 0x00007f5e8af381b9 in gst_single_queue_push_one (allow_drop=<synthetic pointer>, object=0x7f5e30122d80, sq=0x7f5e301326e0, mq=0x564609480730) at ../plugins/elements/gstmultiqueue.c:1941
#8 gst_multi_queue_loop (pad=<optimized out>) at ../plugins/elements/gstmultiqueue.c:2270
#9 0x00007f5efaf4ddf4 in gst_task_func (task=0x7f5e30122710) at ../gst/gsttask.c:384
#10 0x00007f5efb0b16db in g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/gthreadpool.c:354
#11 0x00007f5efb0b1044 in g_thread_proxy (data=0x7f5eac09b120) at ../glib/gthread.c:827
#12 0x00007f5efab2d0e6 in start_thread (arg=<optimized out>) at pthread_create.c:442
#13 0x00007f5efab93fec in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb) bt full
#0 gst_jpeg_dec_handle_frame (bdec=0x7f5e2c1e9a00, frame=0x7f5e80089a00) at ../ext/jpeg/gstjpegdec.c:1352
ret = GST_FLOW_OK
dec = 0x7f5e2c1e9a00
vframe = {info = {finfo = 0x7f5ef82bb8a8 <formats+488>, interlace_mode = GST_VIDEO_INTERLACE_MODE_PROGRESSIVE, flags = GST_VIDEO_FLAG_NONE, width = 1280, height = 720, size = 1382400, views = 1,
chroma_site = GST_VIDEO_CHROMA_SITE_NONE, colorimetry = {range = GST_VIDEO_COLOR_RANGE_0_255, matrix = GST_VIDEO_COLOR_MATRIX_BT601, transfer = GST_VIDEO_TRANSFER_UNKNOWN,
primaries = GST_VIDEO_COLOR_PRIMARIES_UNKNOWN}, par_n = 1, par_d = 1, fps_n = 30, fps_d = 1, offset = {0, 921600, 1152000, 0}, stride = {1280, 640, 640, 0}, ABI = {abi = {
multiview_mode = GST_VIDEO_MULTIVIEW_MODE_MONO, multiview_flags = GST_VIDEO_MULTIVIEW_FLAGS_NONE, field_order = GST_VIDEO_FIELD_ORDER_UNKNOWN}, _gst_reserved = {0x0, 0x0, 0x0, 0x0}}},
flags = GST_VIDEO_FRAME_FLAG_NONE, buffer = 0x7f5e9009fa20, meta = 0x0, id = -1, data = {0x7f5dd9600078, 0x7f5dd96e1078, 0x7f5dd9719478, 0x7f5e897dcdc7}, map = {{memory = 0x7f5dd9600000,
flags = (GST_MAP_READ | GST_MAP_WRITE),
data = 0x7f5dd9600078 "RPNMMMOQVZ^_^\\\\]][WSPQUZ`_]ZXXYZZYXXXYYYYWWZ\\\\\\^^\\\\]]\\[[XXZ\\^`aa`aa_\\[[ZZZYWUSRRSSSRSVY\\^]\\[[[[[\\[YXVUX[^^__^]\\\\\\]^``a``a_][[ZZYZ[[[[^aaa`__]\\]_aa_]^`aa__`bcbabb`^]\\]_`cdda__bcfeccdcb``cgkmllkiijjjiii"..., size = 1382400, maxsize = 1382400, user_data = {0x481482b536055200, 0x7f5ef829b08b, 0x7f5efafb59e0 <_gst_debug_min>, 0x56460940d6e0}, _gst_reserved = {
0x7f5efaf1eb38 <gst_debug_log_valist+77>, 0x7f5dddd095e0, 0x7f5efaf76fbb, 0x7f5e857205e0}}, {memory = 0x7f5e857205e0, flags = (unknown: 740203288),
data = 0x7f5efb0ceb03 <g_private_get+6> "\213\070Z\351\025\307\371\377H\203\354\030H\211t$\b\350\327\373\377\377H\213t$\b\213\070\350;\322\371\377\205\300t\016\211\307H\215\065\242\203\006", size = 0,
maxsize = 5193919985072034304, user_data = {0x7f5dddd095a0, 0x7f5dddd09780, 0x7f5eac091800, 0x3010}, _gst_reserved = {0x7f5dddd098a0, 0x7f5dddd09780, 0x30101, 0x7f5efaf1ec66 <gst_debug_log+139>}}, {
memory = 0x7f5efaf76fbb, flags = (unknown: 3721434592), data = 0x3000000030 <error: Cannot access memory at address 0x3000000030>, size = 140045913811768, maxsize = 140041130120832, user_data = {
0x7f5ef8299d3b, 0x18, 0x5646094e0c10, 0x4b1e}, _gst_reserved = {0x7f5e857205e0, 0x7f5efafb59e0 <_gst_debug_min>, 0x481482b536055200, 0x3}}, {memory = 0x7f5e2c1e9800, flags = (unknown: 2148047360),
data = 0x7f5e2c1e9a00 "\240\337\v,^\177", size = 140045914429920, maxsize = 0, user_data = {0x31, 0x7f5efaf1ec66 <gst_debug_log+139>, 0x7f5ef8299d3b, 0x7f5dddd09680}, _gst_reserved = {0x3000000030,
0x7f5dddd09768, 0x7f5ef8299d3b, 0x0}}}, _gst_reserved = {0x7f5e80089a00, 0x7f5e2c1e9a00, 0x7f5efafb59e0 <_gst_debug_min>, 0x7f5efb0ceb03 <g_private_get+6>}}
num_fields = <optimized out>
output_height = <optimized out>
height = <optimized out>
width = <optimized out>
code = <optimized out>
need_unmap = 1
state = 0x0
release_frame = 1
has_eoi = <optimized out>
data = 0x7f5dcced4078 "\377\330\377", <incomplete sequence \333>
nbytes = 180540
__func__ = "gst_jpeg_dec_handle_frame"
_g_boolean_var_ = <optimized out>
_g_boolean_var_ = <optimized out>
_g_boolean_var_ = <optimized out>
#1 0x00007f5ef8259977 in gst_video_decoder_decode_frame (decoder=decoder@entry=0x7f5e2c1e9a00, frame=frame@entry=0x7f5e80089a00) at ../gst-libs/gst/video/gstvideodecoder.c:4003
priv = 0x7f5e2c1e9800
decoder_class = 0x7f5e2c0bdfa0
ret = GST_FLOW_OK
__func__ = "gst_video_decoder_decode_frame"
#2 0x00007f5ef8259d6c in gst_video_decoder_chain_forward (decoder=decoder@entry=0x7f5e2c1e9a00, buf=buf@entry=0x7f5e30122d80, at_eos=at_eos@entry=0) at ../gst-libs/gst/video/gstvideodecoder.c:2489
frame = 0x7f5e80089a00
was_keyframe = 1
priv = 0x7f5e2c1e9800
klass = <optimized out>
ret = GST_FLOW_OK
__func__ = "gst_video_decoder_chain_forward"
#3 0x00007f5ef825bd67 in gst_video_decoder_chain (pad=<optimized out>, parent=0x7f5e2c1e9a00, buf=0x7f5e30122d80) at ../gst-libs/gst/video/gstvideodecoder.c:2831
decoder = 0x7f5e2c1e9a00
ret = GST_FLOW_OK
__func__ = "gst_video_decoder_chain"
#4 0x00007f5efaf27a18 in gst_pad_chain_data_unchecked (pad=pad@entry=0x5646094e0c10, type=type@entry=4112, data=data@entry=0x7f5e30122d80) at ../gst/gstpad.c:4447
chainfunc = 0x7f5ef825ba83 <gst_video_decoder_chain>
ret = <optimized out>
parent = 0x7f5e2c1e9a00
handled = 0
__func__ = "gst_pad_chain_data_unchecked"
_g_boolean_var_ = <optimized out>
_g_boolean_var_ = <optimized out>
_g_boolean_var_ = <optimized out>
#5 0x00007f5efaf2935e in gst_pad_push_data (pad=pad@entry=0x5646094e0520, type=type@entry=4112, data=data@entry=0x7f5e30122d80) at ../gst/gstpad.c:4711
peer = 0x5646094e0c10
ret = <optimized out>
handled = 0
__func__ = "gst_pad_push_data"
_g_boolean_var_ = <optimized out>
#6 0x00007f5efaf2e377 in gst_pad_push (pad=pad@entry=0x5646094e0520, buffer=buffer@entry=0x7f5e30122d80) at ../gst/gstpad.c:4830
res = <optimized out>
#7 0x00007f5e8af381b9 in gst_single_queue_push_one (allow_drop=<synthetic pointer>, object=0x7f5e30122d80, sq=0x7f5e301326e0, mq=0x564609480730) at ../plugins/elements/gstmultiqueue.c:1941
buffer = 0x7f5e30122d80
timestamp = 2998952533066
duration = <optimized out>
_g_boolean_var_ = <optimized out>
result = GST_FLOW_OK
srcpad = 0x5646094e0520
result = <optimized out>
srcpad = <optimized out>
__func__ = "gst_single_queue_push_one"
_g_boolean_var_ = <optimized out>
buffer = <optimized out>
timestamp = <optimized out>
duration = <optimized out>
_g_boolean_var_ = <optimized out>
_g_boolean_var_ = <optimized out>
_g_boolean_var_ = <optimized out>
event = <optimized out>
_g_boolean_var_ = <optimized out>
_g_boolean_var_ = <optimized out>
_g_boolean_var_ = <optimized out>
_g_boolean_var_ = <optimized out>
_g_boolean_var_ = <optimized out>
_g_boolean_var_ = <optimized out>
query = <optimized out>
res = <optimized out>
_g_boolean_var_ = <optimized out>
_g_boolean_var_ = <optimized out>
#8 gst_multi_queue_loop (pad=<optimized out>) at ../plugins/elements/gstmultiqueue.c:2270
sq = 0x7f5e301326e0
item = <optimized out>
sitem = 0x7f5eb00bcad0
mq = 0x564609480730
object = 0x7f5e30122d80
newid = 597
result = <optimized out>
next_time = <optimized out>
is_buffer = 1
is_query = 0
do_update_buffering = 0
dropping = <optimized out>
srcpad = 0x5646094e0520
__func__ = "gst_multi_queue_loop"
#9 0x00007f5efaf4ddf4 in gst_task_func (task=0x7f5e30122710) at ../gst/gsttask.c:384
lock = 0x5646094e0590
tself = 0x7f5eac09b120
priv = 0x7f5e301226c0
__func__ = "gst_task_func"
_g_boolean_var_ = <optimized out>
#10 0x00007f5efb0b16db in g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/gthreadpool.c:354
task = 0x7f5e9805d8c0
pool = 0x5646090ca7a0
#11 0x00007f5efb0b1044 in g_thread_proxy (data=0x7f5eac09b120) at ../glib/gthread.c:827
thread = 0x7f5eac09b120
__func__ = "g_thread_proxy"
_g_boolean_var_ = <optimized out>
#12 0x00007f5efab2d0e6 in start_thread (arg=<optimized out>) at pthread_create.c:442
ret = <optimized out>
pd = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140041219197144, -8403116295774794287, 140041130124864, -160, 0, 8387712, 8491987764563938769, 8493743978443574737}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#13 0x00007f5efab93fec in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.
```