gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2023-11-25T11:29:09Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3152test suite is failing : elements_id3mux unit test fail and Received signal 112023-11-25T11:29:09ZZhipeng Daitest suite is failing : elements_id3mux unit test fail and Received signal 11
elements_id3mux unit test failed when I run ptest for gstreamer-plugins-bad at gstreamer-1.20.1.
this is the output from signal running the elements_id3mux unit. failed and Received signal 11.
```
sh-3.2# sh elements_id3mux.sh
+ CK_DEFA...
elements_id3mux unit test failed when I run ptest for gstreamer-plugins-bad at gstreamer-1.20.1.
this is the output from signal running the elements_id3mux unit. failed and Received signal 11.
```
sh-3.2# sh elements_id3mux.sh
+ CK_DEFAULT_TIMEOUT=20
+ GST_PLUGIN_LOADING_WHITELIST=gstreamer:gst-plugins-base:gst-plugins-good:gst-plugins-bad
+ GST_REGISTRY=/home/root/.cache/gst-plugins-bad/elements_id3mux.registry
+ GST_STATE_IGNORE_ELEMENTS=
+ exec /usr/libexec/installed-tests/gst-plugins-bad/elements_id3mux
Running suite(s): id3mux
50%: Checks: 2, Failures: 0, Errors: 1
../gst-plugins-bad-1.20.1/tests/check/elements/id3mux.c:500:E:general:test_id3mux_v2_3:0: (after this point) Received signal 11 (Segmentation fault)
Check suite id3mux ran in 4.528s (tests failed: 1)
```
I track where the issue occures, found when call "g_convert" return null at /tests/check/elements/id3mux.c.
and I print the error message
```
diff --git a/tests/check/elements/id3mux.c b/tests/check/elements/id3mux.c
index 190aff406..0d477f487 100644
--- a/tests/check/elements/id3mux.c
+++ b/tests/check/elements/id3mux.c
@@ -148,9 +148,14 @@ utf_string_in_buf (GstBuffer * buf, const gchar * s, int v2version)
gint i, len;
gchar *free_str = NULL;
GstMapInfo map;
+ GError *error;
if (v2version == 3) {
- free_str = g_convert (s, -1, "UTF-16LE", "UTF-8", NULL, NULL, NULL);
+ free_str = g_convert (s, -1, "UTF-16LE", "UTF-8", NULL, NULL, &error);
+ if (free_str == NULL) {
+ GST_ERROR("convert failed: %s", error->message);
+ g_error_free (error);
+ }
s = free_str;
}
```
Final print the error: "Conversion from character set “UTF-8” to “UTF-16LE” is not supported.
```
sh-3.2# sh elements_id3mux.sh
+ CK_DEFAULT_TIMEOUT=20
+ GST_PLUGIN_LOADING_WHITELIST=gstreamer:gst-plugins-base:gst-plugins-good:gst-plugins-bad
+ GST_REGISTRY=/home/root/.cache/gst-plugins-bad/elements_id3mux.registry
+ GST_STATE_IGNORE_ELEMENTS=
+ exec /usr/libexec/installed-tests/gst-plugins-bad/elements_id3mux
Running suite(s): id3mux
Unexpected critical/warning: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Conversion from character set ?UTF-8? to ?UTF-16LE? is not supported
Stack trace:
/usr/lib64/libgstreamer-1.0.so.0(+0x7c43c) [0x7fa626c43c]
/usr/lib64/libgstcheck-1.0.so.0(+0xad98) [0x7fa5fdad98]
/usr/lib64/libglib-2.0.so.0(g_logv+0x238) [0x7fa606f4d8]
/usr/lib64/libglib-2.0.so.0(g_log+0x80) [0x7fa606f770]
/usr/lib64/libglib-2.0.so.0(g_set_error+0xbc) [0x7fa604e5c0]
/usr/lib64/libglib-2.0.so.0(g_convert+0xb8) [0x7fa60422c8]
/usr/libexec/installed-tests/gst-plugins-bad/elements_id3mux(+0x35b8) [0x55778c35b8]
/usr/libexec/installed-tests/gst-plugins-bad/elements_id3mux(+0x3cc4) [0x55778c3cc4]
/usr/libexec/installed-tests/gst-plugins-bad/elements_id3mux(+0x4584) [0x55778c4584]
/usr/lib64/libgstcheck-1.0.so.0(srunner_run_tagged+0x450) [0x7fa5fe93c0]
/usr/lib64/libgstcheck-1.0.so.0(gst_check_run_suite+0x70) [0x7fa5fdc4a0]
/usr/libexec/installed-tests/gst-plugins-bad/elements_id3mux(+0x2098) [0x55778c2098]
/lib64/libc.so.6(+0x2b230) [0x7fa5e4b230]
/lib64/libc.so.6(__libc_start_main+0x9c) [0x7fa5e4b30c]
/usr/libexec/installed-tests/gst-plugins-bad/elements_id3mux(+0x21f0) [0x55778c21f0]
50%: Checks: 2, Failures: 1, Errors: 0
../gstreamer-1.20.1/libs/gst/check/gstcheck.c:286:F:general:test_id3mux_v2_3:0: Unexpected critical/warning: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Conversion from character set “UTF-8” to “UTF-16LE” is not supported
Check suite id3mux ran in 4.179s (tests failed: 1)
```
**I have two questions to ask:**
**1. should check if “free_str” is empty to avoid Received signal 11?**
**2. how to solve error "Conversion from character set “UTF-8” to “UTF-16LE”? is there any solution?**
**thanks for your reply.**https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3149playbin3 error: Switching from passthrough to parsebin on inputs is not suppo...2024-03-06T08:09:47ZNicholas Lamprechtplaybin3 error: Switching from passthrough to parsebin on inputs is not supported !Hello,
i am currently using gstreamer to develop a scheduling system for a small TV Station. I implement the playlist system using the gapless play feature of playbin3. As long as i change the uri attribute of the playbin from a video fi...Hello,
i am currently using gstreamer to develop a scheduling system for a small TV Station. I implement the playlist system using the gapless play feature of playbin3. As long as i change the uri attribute of the playbin from a video file to a video file or from html (e.g. web+https://google.com) to video everything works great. But as soon as i want to change the uri from video to html I get the error you see in the tickets title. If the playbin3 is really not capable of switching from passthrough to parsebin can anyone give me a hint on how to build a workaround?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3148Incompatibility Qt6 Gstreamer 1.22.62023-11-22T09:47:28ZMichaël KoppIncompatibility Qt6 Gstreamer 1.22.6Hi,
We used gstreamer 1.19.2 for our application but due to a bug we had to upgrade it. I tried the 1.22.6 release then and I got these messages :
GLib-GObject-CRITICAL **: 16:25:01.689: cannot register existing type 'GWin32RegistryKe...Hi,
We used gstreamer 1.19.2 for our application but due to a bug we had to upgrade it. I tried the 1.22.6 release then and I got these messages :
GLib-GObject-CRITICAL **: 16:25:01.689: cannot register existing type 'GWin32RegistryKey'
GLib-GObject-CRITICAL **: 16:25:01.689: cannot add private field to invalid (non-instantiatable) type '<invalid>'
GLib-GObject-CRITICAL **: 16:25:01.689: cannot register existing type 'GInitable'
GLib-GObject-CRITICAL **: 16:25:01.689: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed
GLib-CRITICAL **: 16:25:01.689: g_once_init_leave: assertion 'result != 0' failed
GLib-GObject-CRITICAL **: 16:25:01.689: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed
GLib-CRITICAL **: 16:25:01.689: g_once_init_leave: assertion 'result != 0' failed
gst_init_check does not return when it happens. I tried Qt 6.2.4 6.2.8 and 6.5.0 with msvc and I have the exact same behavior.
My application sets the GST_PLUGIN_PATH at the begining, if this folder doesn't exist gst_init_check returns.
Therefore, in order to reproduce the problem you have to set GST_PLUGIN_PATH to your gstreamer install, use gstreamer 1.22.6 and any of the 3 versions of Qt mentionned earlier (maybe with the use of QApplication).
#### Expected Behavior
gst_init_check returns if the gstreamer path pointed by GST_PLUGIN_PATH exists
#### Observed Behavior
gst_init_check doesn't return and I have the following output in debug
GLib-GObject-CRITICAL **: 16:25:01.689: cannot register existing type 'GWin32RegistryKey'
GLib-GObject-CRITICAL **: 16:25:01.689: cannot add private field to invalid (non-instantiatable) type '<invalid>'
GLib-GObject-CRITICAL **: 16:25:01.689: cannot register existing type 'GInitable'
GLib-GObject-CRITICAL **: 16:25:01.689: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed
GLib-CRITICAL **: 16:25:01.689: g_once_init_leave: assertion 'result != 0' failed
GLib-GObject-CRITICAL **: 16:25:01.689: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed
GLib-CRITICAL **: 16:25:01.689: g_once_init_leave: assertion 'result != 0' failed
#### Setup
- **Operating System:Windows 10 Pro 19044.1826
- **Device:** Computer Dual boot Ubuntu 22.04
- **GStreamer Version:1.22.6
- **Command line:** cmake then run exe
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. Create a C++ project with Qt6.2.8 for example and gstreamer 1.22.6
2. In the main function set the GST_PLUGIN_PATH with _putenv_s, then use QApplication, then gst_init_check
3. Build in debug and run
### How reproducible is the bug?
Always with this configuration
### Screenshots if relevant
![image](/uploads/379dd17fee43b62dddba408f9c53424f/image.png)
### Solutions you have tried
Retrograde version to 1.20.0
### Related non-duplicate issues
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3147rtmp2sink: anon_inode:[eventfd] leak when rtmp-server can't access2023-11-28T05:38:44ZWangpf-githubrtmp2sink: anon_inode:[eventfd] leak when rtmp-server can't accessanon_inode:[eventfd] leak occur when rtmp-server ip-address can't access:
if rtmp-server ip-address can not access, anon_inode:[eventfd] leak will occur,
every time call retry, generate a newly added anon_inode:[eventfd] that will not re...anon_inode:[eventfd] leak occur when rtmp-server ip-address can't access:
if rtmp-server ip-address can not access, anon_inode:[eventfd] leak will occur,
every time call retry, generate a newly added anon_inode:[eventfd] that will not release, refer to Gstreamer-Debug.
if rtmp2sink can establish connection with rtmp-server ip-address, but server can not access,the newly added anon_inode:[eventfd] that will be released.
```
2:06:02.203485698 12720 0x55a40294c0 DEBUG rtmp2sink gstrtmp2sink.c:856:gst_rtmp2_sink_render:<rtmp-sink> Waiting for connection
2:06:05.166758954 12720 0x55a4031460 ERROR rtmpclient rtmpclient.c:470:socket_connect_done: Socket connection error
2:06:05.166836829 12720 0x55a4031460 ERROR rtmp2sink gstrtmp2sink.c:1119:send_connect_error:<rtmp-sink> Failed to connect (g-io-error-quark:37): Could not connect to 192.168.13.176: No route to host
2:06:05.166851413 12720 0x55a4031460 WARN rtmp2sink gstrtmp2sink.c:1130:send_connect_error:<rtmp-sink> error: Failed to connect
2:06:05.166858413 12720 0x55a4031460 WARN rtmp2sink gstrtmp2sink.c:1130:send_connect_error:<rtmp-sink> error: error g-io-error-quark:37: Could not connect to 192.168.13.176: No route to host
2:06:05.166866288 12720 0x55a4031460 DEBUG GST_MESSAGE gstelement.c:2241:gst_element_message_full_with_details:<rtmp-sink> start
2:06:05.166885538 12720 0x55a4031460 INFO GST_ERROR_SYSTEM gstelement.c:2271:gst_element_message_full_with_details:<rtmp-sink> posting message: Failed to connect
2:06:05.166942121 12720 0x55a4031460 INFO GST_ERROR_SYSTEM gstelement.c:2298:gst_element_message_full_with_details:<rtmp-sink> posted error message: Failed to connect
2:06:05.166962538 12720 0x55a4031460 DEBUG rtmp2sink gstrtmp2sink.c:565:stop_task:<rtmp-sink> Stopping loop
2:06:05.167118288 12720 0x55a4031460 DEBUG rtmp2sink gstrtmp2sink.c:1021:gst_rtmp2_sink_task_func:<rtmp-sink> gst_rtmp2_sink_task exiting
Error received from element rtmp-sink: Failed to connect
** Message: 13:25:22.266: [289] in message_callback: set timer retry, mutex_unlock
2:06:05.167495704 12720 0x55a3d02830 DEBUG rtmp2sink gstrtmp2sink.c:637:gst_rtmp2_sink_unlock:<rtmp-sink> unlock
2:06:05.167517288 12720 0x55a3d02830 DEBUG rtmp2sink gstrtmp2sink.c:653:gst_rtmp2_sink_unlock_stop:<rtmp-sink> unlock_stop
2:06:05.167608579 12720 0x55a3d02830 DEBUG rtmp2sink gstrtmp2sink.c:637:gst_rtmp2_sink_unlock:<rtmp-sink> unlock
2:06:05.167625496 12720 0x55a3d02830 DEBUG rtmp2sink gstrtmp2sink.c:653:gst_rtmp2_sink_unlock_stop:<rtmp-sink> unlock_stop
2:06:05.178304581 12720 0x55a3d02830 DEBUG rtmp2sink gstrtmp2sink.c:579:gst_rtmp2_sink_stop:<rtmp-sink> stop
** Message: 13:25:22.278: [313] in message_callback: mutex_lock
** Message: 13:25:22.278: [319] in message_callback: mutex_unlock
```
Use the folow pipeline:
```c
#define PIPELINE_TEST \
"videotestsrc is-live=true ! video/x-raw,width=1920,height=1080,format=NV12,framerate=30/1 ! " \
"x264enc ! h264parse name=video-parse ! flvmux ! " \
"rtmp2sink name=rtmp-sink chunk-size=65536 " \
"location=rtmp://192.168.13.176/12/1"
Retry when connect to rtmp-sever error:
static gboolean
retry_callback(gpointer user_data)
{
GstElement* pipeline = user_data;
g_mutex_lock(&retry_lock);
on_error = FALSE;
if (source_tag) {
g_source_remove(source_tag);
source_tag = 0;
}
g_mutex_unlock(&retry_lock);
gst_element_set_state(pipeline, GST_STATE_PLAYING);
return FALSE;
}
static gboolean
message_callback(GstBus* bus, GstMessage* message, gpointer user_data)
{
GstElement* pipeline = user_data;
GError *err;
gchar *debug_info;
switch (GST_MESSAGE_TYPE(message)) {
case GST_MESSAGE_EOS:
if (message->src == GST_OBJECT(pipeline))
gst_element_set_state(pipeline, GST_STATE_NULL);
break;
case GST_MESSAGE_ERROR:
gst_message_parse_error (message, &err, &debug_info);
g_printerr ("Error received from element %s: %s\n",
GST_OBJECT_NAME (message->src), err->message);
// g_printerr ("Debugging information: %s\n",
// debug_info ? debug_info : "none");
g_clear_error (&err);
g_free (debug_info);
g_mutex_lock(&retry_lock);
if(!on_error && source_tag == 0)
{
on_error = TRUE;
if (app->retry_delay >= 0)
source_tag = g_timeout_add(app->retry_delay, retry_callback, pipeline);
g_message ("[%d] in %s: set timer retry, mutex_unlock", __LINE__, __FUNCTION__);
g_mutex_unlock(&retry_lock);
gst_element_set_state(pipeline, GST_STATE_NULL);
break;
}
g_mutex_unlock(&retry_lock);
break;
case GST_MESSAGE_STATE_CHANGED:
if (message->src == GST_OBJECT(pipeline)) {
GstState oldstate, newstate;
gst_message_parse_state_changed(message, &oldstate, &newstate, NULL);
if (newstate == GST_STATE_NULL) {
g_message ("[%d] in %s: mutex_lock", __LINE__, __FUNCTION__);
g_mutex_lock(&retry_lock);
if (!on_error && source_tag) {
g_source_remove(source_tag);
source_tag = 0;
}
g_message ("[%d] in %s: mutex_unlock", __LINE__, __FUNCTION__);
g_mutex_unlock(&retry_lock);
}
}
break;
default:
break;
}
return TRUE;
}
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3144Integration tests job logs no longer dump failures2023-11-21T15:11:33ZJordan PetridіsIntegration tests job logs no longer dump failuresThe following discussion from !5699 should be addressed:
- [ ] @ndufresne started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5699#note_2177029): (+1 comment)
> @thiblahute strange that the a...The following discussion from !5699 should be addressed:
- [ ] @ndufresne started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5699#note_2177029): (+1 comment)
> @thiblahute strange that the actual error for that integration test is not printed in the log, any idea if it was like this or if this is a regression?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3143dssim: Wrap is completely outdated2023-11-24T20:58:40ZSebastian Drögedssim: Wrap is completely outdatedThe current commit is 5 years old, and since then the whole library was rewritten in Rust (while still providing a C API).
CC @thiblahuteThe current commit is 5 years old, and since then the whole library was rewritten in Rust (while still providing a C API).
CC @thiblahutehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3135va: move vafilter formats blocked to vacaps2023-11-17T14:40:13ZVíctor Manuel Jáquez Lealva: move vafilter formats blocked to vacapsIn vafilter we have a list of blocked formats for iHD because they are not well supported:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/sys/va/gstvafilter.c?ref_type=heads#L245
it should be...In vafilter we have a list of blocked formats for iHD because they are not well supported:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/sys/va/gstvafilter.c?ref_type=heads#L245
it should be better handled in vacaps so vapostproc won't expose those formats as valid until fixed by the driver
Related with https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3127https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3134timecodestamper with LTC input and non-live video never advances2023-11-17T12:57:08ZJan Schmidttimecodestamper with LTC input and non-live video never advancesThis pipeline never prerolls:
`gst-launch-1.0 videotestsrc ! timecodestamper name=stampy ! fakesink filesrc location=LTC_01000000_10mins_30fps_44100x24.wav ! decodebin ! audioconvert ! stampy.ltc_sink`
When the video is not live, the `t...This pipeline never prerolls:
`gst-launch-1.0 videotestsrc ! timecodestamper name=stampy ! fakesink filesrc location=LTC_01000000_10mins_30fps_44100x24.wav ! decodebin ! audioconvert ! stampy.ltc_sink`
When the video is not live, the `transform_ip` function enters this code that depends on `ltc_current_running_time` becoming a valid clock time, but there is no code anywhere to set the variable to anything other than `GST_CLOCK_TIME_NONE`:
```
while ((timecodestamper->ltc_current_running_time == GST_CLOCK_TIME_NONE
|| timecodestamper->ltc_current_running_time <
running_time + 8 * frame_duration)
&& !timecodestamper->video_flushing && !timecodestamper->ltc_eos) {
GST_TRACE_OBJECT (timecodestamper,
"Waiting for LTC audio to advance, EOS or flushing");
g_cond_wait (&timecodestamper->ltc_cond_video, &timecodestamper->mutex);
}
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3130x264enc.c: failing tests on armv7 and armhf2023-11-15T11:35:29ZKrassy Boykinovx264enc.c: failing tests on armv7 and armhf### 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/ -->
When running the compilation on Alpine Linux armv7 and armhf builders the tests for the x264enc module fail. They report an illegal instruction.
#### Expected Behavior
<!-- What did you expect to happen -->
Run the tests without problems
#### Observed Behavior
Tests fail
#### Setup
- Alpine Linux edge
- CI/CD container on armv7, armhf
- gst-plugins-ugly >= 1.22.7
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. Build on armv7 / armhf
2. observe
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Happens every time
### Solutions you have tried
Temporarely commenting out the tests fixed the pipeline (https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/55370)
### Related non-duplicate issues
May be related to https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2666
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->
```
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/bin/ninja -C /builds/chereskata/aports/community/gst-plugins-ugly/src/gst-plugins-ugly-1.22.7/output
ninja: nothing to do
ninja: entering directory '/builds/chereskata/aports/community/gst-plugins-ugly/src/gst-plugins-ugly-1.22.7/output'
ninja: nothing to do
1/3 elements_amrnbenc OK 0.20s
2/3 elements_x264enc FAIL 0.23s exit status 6
>>> CK_DEFAULT_TIMEOUT=20 GST_PLUGIN_LOADING_WHITELIST=gstreamer:gst-plugins-base:gst-plugins-good:gst-plugins-ugly@/builds/chereskata/aports/community/gst-plugins-ugly/src/gst-plugins-ugly-1.22.7/output MALLOC_PERTURB_=186 GST_PLUGIN_SYSTEM_PATH_1_0='' GST_REGISTRY=/builds/chereskata/aports/community/gst-plugins-ugly/src/gst-plugins-ugly-1.22.7/output/tests/check/elements_x264enc.registry GST_PLUGIN_SCANNER_1_0=/usr/libexec/gstreamer-1.0/gst-plugin-scanner GST_PLUGIN_PATH_1_0=/builds/chereskata/aports/community/gst-plugins-ugly/src/gst-plugins-ugly-1.22.7/output:/usr/lib/gstreamer-1.0:/usr/lib/gstreamer-1.0 /builds/chereskata/aports/community/gst-plugins-ugly/src/gst-plugins-ugly-1.22.7/output/tests/check/elements_x264enc
――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――
Running suite(s): x264enc
0%: Checks: 6, Failures: 0, Errors: 6
../tests/check/elements/x264enc.c:253:E:general:test_video_baseline:0: (after this point) Received signal 4 (Illegal instruction)
../tests/check/elements/x264enc.c:253:E:general:test_video_main:0: (after this point) Received signal 4 (Illegal instruction)
../tests/check/elements/x264enc.c:253:E:general:test_video_high:0: (after this point) Received signal 4 (Illegal instruction)
../tests/check/elements/x264enc.c:253:E:general:test_video_high10:0: (after this point) Received signal 4 (Illegal instruction)
../tests/check/elements/x264enc.c:253:E:general:test_video_high422:0: (after this point) Received signal 4 (Illegal instruction)
../tests/check/elements/x264enc.c:253:E:general:test_video_high444:0: (after this point) Received signal 4 (Illegal instruction)
Check suite x264enc ran in 0.029s (tests failed: 6)
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
3/3 generic_states OK 0.23s
Summary of Failures:
2/3 elements_x264enc FAIL 0.23s exit status 6
Ok: 2
Expected Fail: 0
Fail: 1
Unexpected Pass: 0
Skipped: 0
Timeout: 0
```
Thank you!https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3129downloadbuffer: Deadlocks when handling non-flushing seek2023-12-11T10:49:50ZPhilippe Normanddownloadbuffer: Deadlocks when handling non-flushing seekOriginally filed in https://bugs.webkit.org/show_bug.cgi?id=260796
In WebKit when the player is configured for looping videos, it performs a non-flushing segment seek back to position 0. This can lead to downloadbuffer waiting forever f...Originally filed in https://bugs.webkit.org/show_bug.cgi?id=260796
In WebKit when the player is configured for looping videos, it performs a non-flushing segment seek back to position 0. This can lead to downloadbuffer waiting forever for a download to complete. There is code in place to unlock the getrange() (pull mode) when the element receives a flush-start, but that's not triggered when there's no flush.
So I think downloadbuffer should also unlock its getrange() when it receives segment seek on its src pad?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3127Add vapostproc XR24 DMA modifier input and output caps support2023-11-30T09:38:58ZjluiIAdd vapostproc XR24 DMA modifier input and output caps supportXR24/BGRx input and output colour formats exist in gst-vaapi legacy dmabuf.
Add XR24 DMA modifier input and output colour format support for vapostproc.XR24/BGRx input and output colour formats exist in gst-vaapi legacy dmabuf.
Add XR24 DMA modifier input and output colour format support for vapostproc.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3126Impossible to create Gst.Bitmask using gst-python2023-11-15T10:09:14ZJulien 'Lta' BALLETImpossible to create Gst.Bitmask using gst-python### 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/ -->
It is currently impossible to create a Gst.Bitmask using python on Ubuntu 23.04 (python3-gst-1.0 1.22.5-1).
#### Expected Behavior
It's expected to create a `Gst.Bitmask`
#### Observed Behavior
<!-- What actually happened -->
`TypeError: Bitmask() takes no arguments`
#### Setup
- **Operating System:** Ubuntu 23.04
- **Device:** Computer
- **GStreamer Version:** python3-gst-1.0 1.22.5-1
- **Command line:**
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. Write this content to a file:
Here's a repro script:
```python
import gi
gi.require_version('GLib', '2.0')
gi.require_version('GObject', '2.0')
gi.require_version('Gst', '1.0')
from gi.repository import Gst, GObject, GLib
Gst.Bitmask(0x4242)
```
1. Execute the script
### How reproducible is the bug?
Always
### Screenshots if relevant
### Solutions you have tried
Tried to manually import the relevant override, or to manipulate the GObject.Value directly
### Related non-duplicate issues
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3125Repeatable hang/crash after 5681 hours2023-12-06T16:21:06ZTJ SmithRepeatable hang/crash after 5681 hours### Describe your issue
We use gstreamer in a long running embedded device to receive and play audio streams. We are experiencing an issue where our pipeline consistently crashes after running for 5681 hours. We have 4 different logged ...### Describe your issue
We use gstreamer in a long running embedded device to receive and play audio streams. We are experiencing an issue where our pipeline consistently crashes after running for 5681 hours. We have 4 different logged instances of this now. The exact failure message is inconsistent. We have two cases of "realloc(): invalid pointer," one case of "free(): invalid pointer," and one case of "corrupted double-linked list."
#### Expected Behavior
We expect our gstreamer pipeline to keep working indefinitely and not crash or hang.
#### Observed Behavior
We observe a crash shortly after 5681 hours of run time. When run without G_DEBUG=fatal_warnings, the pipeline silently hangs, which is worse than the crash as we can't automatically recover from that.
#### Setup
- **Operating System:** Buildroot Linux 5.0.0
- **Device:** Embedded armv7l
- **GStreamer Version:** 1.16.0
- **Command line:** `GST_DEBUG_NO_COLOR=1 G_DEBUG=fatal_warnings GST_DEBUG=4 gst-launch-1.0 -mv udpsrc port=5555 ! rawaudioparse use-sink-caps=false format=pcm pcm-format=s16le sample-rate=22050 num-channels=2 ! queue ! audioconvert ! audioresample ! alsasink`
### Steps to reproduce the bug
Given that this error takes 236 days to appear, it's hard to have more specific reproduction steps than our particular embedded use-case. The devices that experience this issue have relatively diverse usage patterns (ranging from about a few distinct streams per day to hundreds per day), so the only common factor seems to be the 5681 hours. The crash seems to occur on the first stream attempted after that <span dir="">\~</span>5681 hour mark is hit. In particular, the times of the 4 crash reports I have are as follows (236 days, 17 hours, 21 minutes; 236 days, 18 hours, 41 minutes; 237 days, 6 hours, 48 minutes; and 236 days, 18 hours, 4 minutes)
### How reproducible is the bug?
It seems to be consistent, but we're not totally sure, as we don't have perfect statistics on all of our devices and their uptimes.
### Screenshots if relevant
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
I've attached the debug logs that we were able to capture. We only captured at debug level 4 due to the long-running nature of the issue and space constraints.
[free_fail.txt](/uploads/1830465ad94e17cb5d4a860182314ae9/free_fail.txt)
[linked_list_fail.txt](/uploads/c740306d7e28f60b5e2f667d3976344b/linked_list_fail.txt)
[realloc_fail1.txt](/uploads/5efb18be8fc4dd72b348900e5f686069/realloc_fail1.txt)
[realloc_fail2.txt](/uploads/266aeb4dc9a163b769e4a3b0d45300db/realloc_fail2.txt)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3124gst-plugins-bad: elements_dash_mpd fails (triggered by something in $HOME)2023-11-14T13:21:20ZXi Ruoyaogst-plugins-bad: elements_dash_mpd fails (triggered by something in $HOME)```
Running suite(s): dash
noname.xml:1: namespace error : Namespace prefix customns on bar is not defined
Set> <ContentProtection schemeIdUri="TestSchemeIdUri"> <customns:bar
...```
Running suite(s): dash
noname.xml:1: namespace error : Namespace prefix customns on bar is not defined
Set> <ContentProtection schemeIdUri="TestSchemeIdUri"> <customns:bar
^
noname.xml:1: parser error : Start tag expected, '<' not found
<?xml version="1.0"?>
^
noname.xml:1: parser error : Opening and ending tag mismatch: MPD line 1 and NPD
sh:schema:mpd:2011" profiles="urn:mpeg:dash:profile:isoff-main:2011"> </NPD>
^
99%: Checks: 122, Failures: 0, Errors: 1
../tests/check/elements/dash_mpd.c:6071:E:simpleMPD:dash_mpdparser_xlink_period:0: (after this point) Test timeout expired
Check suite dash ran in 20.293s (tests failed: 1)
```
Interestingly, if I set `HOME=`, then the test passes. Removing `$HOME/.cache/gstreamer-1.0/registry.x86_64.bin` does not help.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3123appsrc: do-timestamp=true can lead to invalid timestamps if pushing a buffer ...2023-11-13T16:40:18ZSebastian Drögeappsrc: do-timestamp=true can lead to invalid timestamps if pushing a buffer between gst_element_set_clock() and gst_element_set_base_time()See title. This happens in `gst_app_src_push_internal()` and can happen if the application is already pushing buffers before the `appsrc` is in `PLAYING` state. Then there's a small window where the clock is already set from `gstpipeline...See title. This happens in `gst_app_src_push_internal()` and can happen if the application is already pushing buffers before the `appsrc` is in `PLAYING` state. Then there's a small window where the clock is already set from `gstpipeline.c:change_state()` but the base time is not yet (from a few lines below / `gstbin.c:change_state_func()`).
Avoiding this would require being able to know whether the base time returned by `gst_element_get_base_time()` is valid. As we initialize it to `0`, this is currently not possible. Also it would have to be reset whenever the clock changes / becomes invalid.
Theoretically we could initialize the base time to `GST_CLOCK_TIME_NONE`: any calculations with the unset `0` base time are invalid anyway, so they won't become more correct when calculating with `GST_CLOCK_TIME_NONE`. But this probably breaks someone's code out there.
Also *maybe* this case can be detected by considering `base_time == 0 && start_time != NONE` as "invalid base time", but I'm not entirely sure if that actually covers all situations.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3119gst-examples: webrtc java version does not find gstreamer lib on Windows (and...2024-03-24T23:25:51Zvdeconinckgst-examples: webrtc java version does not find gstreamer lib on Windows (and then more)The java sendrecv sample fails with the following error (although I correctly launch it with `java -Djna.library.path=<path_to_gstreamer_bin>`):
```plaintext
java.lang.UnsatisfiedLinkError: Could not load library gstreamer
```
After a ...The java sendrecv sample fails with the following error (although I correctly launch it with `java -Djna.library.path=<path_to_gstreamer_bin>`):
```plaintext
java.lang.UnsatisfiedLinkError: Could not load library gstreamer
```
After a bit of fiddling, I think I found the cause and solution(s):
The name of the gstreamer lib in the current Windows distribution has changed from `gstreamer.1.0.dll` to `gstreamer.1.0-0.dll` (note the additional `-0`) but the build.gradle compile dependency still points to `gst1-java-core:0.9.4` which does not support that naming.
Upgrading to the latest core release (1.4.0) fixes that issue:
```plaintext
compile "org.freedesktop.gstreamer:gst1-java-core:1.4.0"
```
But then other issues arise due to the API change. Namely:
- the webrtc imports must be updated due to the package change, as follows:
```plaintext
import org.freedesktop.gstreamer.webrtc.*;
import org.freedesktop.gstreamer.webrtc.WebRTCBin.CREATE_OFFER;
import org.freedesktop.gstreamer.webrtc.WebRTCBin.ON_ICE_CANDIDATE;
import org.freedesktop.gstreamer.webrtc.WebRTCBin.ON_NEGOTIATION_NEEDED;
```
- the call to `Gst.init()` must specify a requested version (1.14) otherwise it assumes 1.8 and a version check fails later on (this one was hard to find, although it is documented in https://github.com/gstreamer-java/gst1-java-core/blob/master/README.md ) :
```plaintext
Gst.init(new Version(1,14));
```
- the call to `pad.getCaps()` must be updated to `pad.getAllowedCaps()` as follows:
```plaintext
Structure caps = pad.getAllowedCaps().getStructure(0);
```
I hope it will be patched in a future version. In the meantime it is documented here for others encountering the same issue :-)
Keep on the good work.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3118openh264: Allow multi-thread decoding when building for version 2.1.0+2023-11-09T18:38:57ZBaptiste Mille-Mathiasopenh264: Allow multi-thread decoding when building for version 2.1.0+It seems that since 2.1.0 of OpenH264, multi-threaded decoding is possible. This may allow workaround performance issue with this decoder:
https://github.com/cisco/openh264/commit/aa759cb5a207665d3ae83c7076ea326a1a9d2458
This is a prop...It seems that since 2.1.0 of OpenH264, multi-threaded decoding is possible. This may allow workaround performance issue with this decoder:
https://github.com/cisco/openh264/commit/aa759cb5a207665d3ae83c7076ea326a1a9d2458
This is a proposal to enable this as a property, and perhaps add a decent default number of cores. Though be aware of the release note saying:
```
Experimentally support for multi-thread decoding(default disabled,and may result in random problems if enabled)
```
https://github.com/cisco/openh264/releases/tag/v2.1.0
**The original message:**
This is a video in mp4 containers produced by a gopro (don't know the model)
I haver the problem in totem and pitivi.![GOPR1171](/uploads/6b3b2a87b41bfff38ce03a0df2894ce1/GOPR1171.MP4)
I attach a video to this bug.
```
gstreamer1-1.16.2-2.fc32.x86_64
gstreamer1-plugin-openh264-1.16.2-1.fc32.x86_64
gstreamer1-plugins-bad-free-1.16.2-3.fc32.x86_64
gstreamer1-plugins-base-1.16.2-3.fc32.x86_64
gstreamer1-plugins-base-tools-1.16.2-3.fc32.x86_64
gstreamer1-plugins-good-1.16.2-2.fc32.x86_64
gstreamer1-plugins-good-gtk-1.16.2-2.fc32.x86_64
gstreamer1-plugins-good-qt-1.16.2-2.fc32.x86_64
gstreamer1-plugins-ugly-1.16.2-2.fc32.x86_64
gstreamer1-plugins-ugly-free-1.16.2-2.fc32.x86_64
libnice-gstreamer1-0.1.17-2.fc32.x86_64
python3-gstreamer1-1.16.2-2.fc32.x86_64
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3117validate: Make it possible to run gst-validate-launcher on embedded device (t...2023-11-09T18:17:09ZBugzilla Migration Uservalidate: Make it possible to run gst-validate-launcher on embedded device (that might not support python)## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#736137)](https://bugzilla.gnome.org/show_bug.cgi?id=736137)**
## Description
The gst-validate-launcher is written in python, we should make sure that the tests...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#736137)](https://bugzilla.gnome.org/show_bug.cgi?id=736137)**
## Description
The gst-validate-launcher is written in python, we should make sure that the tests can be run on embedded platforms, and hopefully even the ones that do not support python (android, iOS?).
For that we might want to launch the test through ssh?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3116qmlglsink: QT integration in python not working due to mismatch for PyQT2023-11-09T17:42:36ZOlivier Algoetqmlglsink: QT integration in python not working due to mismatch for PyQTHello,
I am trying to use PyQT5 with qmlglsink: Qt: v 5.9.5 PyQt: v 5.10.1
Error given: TypeError: could not convert '\<PyQt5.QtQuick.QQuickItem object at 0x7f746b0dc8\>' to type 'gpointer' when setting property 'GstQtSink.widget'
Exa...Hello,
I am trying to use PyQT5 with qmlglsink: Qt: v 5.9.5 PyQt: v 5.10.1
Error given: TypeError: could not convert '\<PyQt5.QtQuick.QQuickItem object at 0x7f746b0dc8\>' to type 'gpointer' when setting property 'GstQtSink.widget'
Example code:
```python
import sys
from PyQt5.QtGui import QGuiApplication
from PyQt5.QtQml import QQmlApplicationEngine
import PyQt5.QtQuick as QtQuick
import gi
gi.require_version("Gst", "1.0")
gi.require_version("GstVideo", "1.0")
from gi.repository import GObject, Gst, GstVideo
app = QGuiApplication(sys.argv)
engine = QQmlApplicationEngine()
engine.quit.connect(app.quit)
GObject.threads_init()
Gst.init(None)
class GstDisplay:
def __init__(self):
pipeline = "videotestsrc ! glupload ! qmlglsink name=sink"
self.pipeline = Gst.parse_launch(pipeline) # xvimagesink, ximagesink
self.setup_pipeline()
self.sink = self.pipeline.get_by_name("sink")
def setup_pipeline(self):
self.state = Gst.State.NULL
bus = self.pipeline.get_bus()
bus.add_signal_watch()
bus.enable_sync_message_emission()
def start_pipeline(self):
self.pipeline.set_state(Gst.State.PLAYING)
gstpipe=GstDisplay()
gstpipe.start_pipeline()
engine.load('main.qml')
root=engine.rootObjects()[0]
videoItem=engine.rootObjects()[0].findChild(QtQuick.QQuickItem,name="videoItem")
gstpipe.sink.set_property("widget", videoItem)```
main.qml:
import QtQuick 2.0
import QtQuick.Controls 2.0
import QtMultimedia 5.0
import org.freedesktop.gstreamer.GLVideoItem 1.0
ApplicationWindow {
visible: true
width: 1920
height: 1080
title: "HelloApp"
GstGLVideoItem {
id: video
objectName: "videoItem"
anchors.centerIn: parent
width: parent.width
height: parent.height
}
}
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3115gst-python: How to register metadata using python bindings i.e. Gst.meta_regi...2023-11-09T17:40:03ZHimanshu Mittalgst-python: How to register metadata using python bindings i.e. Gst.meta_register()Gst.meta_register() requires 6 arguments where last 3 arguments are Gst.MetaInitFunction, Gst.MetaFreeFunction and Gst.MetaTransformFunction respectively. I am not able to pass those 3 arguments in python. It throws ValueError: GType Inv...Gst.meta_register() requires 6 arguments where last 3 arguments are Gst.MetaInitFunction, Gst.MetaFreeFunction and Gst.MetaTransformFunction respectively. I am not able to pass those 3 arguments in python. It throws ValueError: GType Invalid.
I have tried to send it as:
1. Regular python function: Throws ValueError
2. Using ctypes functype wrapper on regular python function: Unable to implement because Gst.Buffer do not have ctypes structure.
3. Wrapping them in Gst.MetaInitFunction and alike: Throws NotImplementedError
I want to register my custom metadata with python so that I can take advantage of python dynamic data types. My meta changes on run time and hence I want to register my metadata every time it encounters a new metadata format. This is not possible to write in C as I cannot define this dynamic ctype Structures in C. I must call Gst.meta_register() from python to achieve this.
Any help would be appreciated.
Thanks,
Himanshu Mittal