GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-03-02T12:05:46Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1443gst_base_sink_get_stats documentation is misleading2023-03-02T12:05:46ZRares Branicigst_base_sink_get_stats documentation is misleadingThe documentation for GstBaseSink / gst_base_sink_get_stats at
https://gstreamer.freedesktop.org/documentation/base/gstbasesink.html?gi-language=c#gst_base_sink_get_stats
says
"average-rate" G_TYPE_DOUBLE **average frame rate**,
sugg...The documentation for GstBaseSink / gst_base_sink_get_stats at
https://gstreamer.freedesktop.org/documentation/base/gstbasesink.html?gi-language=c#gst_base_sink_get_stats
says
"average-rate" G_TYPE_DOUBLE **average frame rate**,
suggesting the property can be used to get the video frame rate, for example.
Playing a file with 30000/1001 frame rate, the values reported vary between 0.11 and 0.17.
fpsdisplaysink does not use frame-stats.
Perhaps the documentation could be more precise as to the meaning and intent of this property.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2824qml: gstreamer destroys EGLDisplay when application is using it2023-07-18T18:51:33Zshang qiangqml: gstreamer destroys EGLDisplay when application is using itwe have a QML player application
[QMLTest.tgz](/uploads/746eddad7673833577f4e7b970734b31/QMLTest.tgz)
when stop the video player ,screen will freeze(with wayland desktop)
this application has two issue:
1. gstreamer destory the qt's ...we have a QML player application
[QMLTest.tgz](/uploads/746eddad7673833577f4e7b970734b31/QMLTest.tgz)
when stop the video player ,screen will freeze(with wayland desktop)
this application has two issue:
1. gstreamer destory the qt's EGLDisplay
2. the the wayland server will not send ping pong ,when switch to the background and swich back
with the first issue:
```
diff --git a/gst-libs/gst/gl/egl/gstgldisplay_egl.c b/gst-libs/gst/gl/egl/gstgldisplay_egl.c
index 8eb53a2d5..ad6beae88 100644
--- a/gst-libs/gst/gl/egl/gstgldisplay_egl.c
+++ b/gst-libs/gst/gl/egl/gstgldisplay_egl.c
@@ -298,7 +298,7 @@ gst_gl_display_egl_from_gl_display (GstGLDisplay * display)
ret->display =
gst_gl_display_egl_get_from_native (display_type, native_display);
-
+ ret->foreign_display = true;
if (!ret->display) {
GST_WARNING_OBJECT (ret, "failed to get EGLDisplay from native display");
gst_object_unref (ret);
```
1 i use this to fix the issue ,why we cancel this fix ?
: https://gitlab.freedesktop.org/dylanmccall/gst-plugins-base/-/commit/f9135c64bd6d2aa2310e8ed7d8a7b695ecf47e2c
2 how can i use this function gst_gl_display_egl_set_foreign_display?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1445webrtcbin video fails when MTU too low2022-09-23T10:12:55ZDaniel Squireswebrtcbin video fails when MTU too lowgst 1.20.3
We just ~~resolved~~ got to the bottom of a problem whereby the video stream would never be established, or never transfer any frames at least when everything (data and audio channels) appeared to function ok. It turned out ...gst 1.20.3
We just ~~resolved~~ got to the bottom of a problem whereby the video stream would never be established, or never transfer any frames at least when everything (data and audio channels) appeared to function ok. It turned out to be caused by the MTU of one of our VPNs over which the traffic was flowing being too low. The network where this problem arose had an MTU size of just 1403.
When the video stream should have been working gst was repeatedly logging msgs as follows (GST_DEBUG=4):
```
0:00:11.381818323 797 0x7f8a08002000 INFO GST_ELEMENT_PADS gstelement.c:1016:gst_element_get_static_pad: found pad rtpbin:send_rtcp_src_0
0:00:11.435831254 797 0x7f8a08085c00 INFO gstrtpfunnel gstrtpfunnel.c:510:gst_rtp_funnel_src_event:<rtpfunnel0:src> Sending custom-upstream event: 0x7f89e4006340, time 99:99:99.999999999, seq-num 616, GstForceKeyUnit, ssrc=(uint)94573595, all-headers=(boolean)false; to <rtpfunnel0:sink_1>
0:00:11.435851033 797 0x7f8a08085c00 INFO h264parse gsth264parse.c:3738:gst_h264_parse_src_event:<h264parse0> received upstream force-key-unit event, seqnum 616 running_time 99:99:99.999999999 all_headers 0 count 0
0:00:11.447129010 797 0x7f8a1c0020c0 INFO x264enc gstx264enc.c:2539:gst_x264_enc_encode_frame:<x264enc0> Forcing key frame
0:00:11.448016669 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:3664:gst_h264_parse_event:<h264parse0> received downstream force key unit event, seqnum 617 running_time 0:00:00.166666666 all_headers 0 count 0
0:00:11.448052839 797 0x7f8a1c002060 INFO baseparse gstbaseparse.c:4088:gst_base_parse_set_latency:<h264parse0> min/max latency 0:00:00.000000000, 0:00:00.000000000
0:00:11.448075375 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:2748:check_pending_key_unit_event: now 0:00:00.166666666 wanted 0:00:00.166666666
0:00:11.448081315 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:2793:gst_h264_parse_prepare_key_unit:<h264parse0> pushing downstream force-key-unit event 617 0:00:00.166666666 count 0
0:00:11.448088904 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:2813:gst_h264_parse_prepare_key_unit:<h264parse0> preparing key unit, have sps 1 have pps 1
0:00:11.840538905 797 0x7f8a08085c00 INFO gstrtpfunnel gstrtpfunnel.c:510:gst_rtp_funnel_src_event:<rtpfunnel0:src> Sending custom-upstream event: 0x7f89e4006840, time 99:99:99.999999999, seq-num 621, GstForceKeyUnit, ssrc=(uint)94573595, all-headers=(boolean)false; to <rtpfunnel0:sink_1>
0:00:11.840597021 797 0x7f8a08085c00 INFO h264parse gsth264parse.c:3738:gst_h264_parse_src_event:<h264parse0> received upstream force-key-unit event, seqnum 621 running_time 99:99:99.999999999 all_headers 0 count 0
0:00:11.849826188 797 0x7f8a1c0020c0 INFO x264enc gstx264enc.c:2539:gst_x264_enc_encode_frame:<x264enc0> Forcing key frame
0:00:11.852715761 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:3664:gst_h264_parse_event:<h264parse0> received downstream force key unit event, seqnum 622 running_time 0:00:00.266666666 all_headers 0 count 0
0:00:11.852839639 797 0x7f8a1c002060 INFO baseparse gstbaseparse.c:4088:gst_base_parse_set_latency:<h264parse0> min/max latency 0:00:00.000000000, 0:00:00.000000000
0:00:11.852901699 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:2748:check_pending_key_unit_event: now 0:00:00.266666666 wanted 0:00:00.266666666
0:00:11.852918394 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:2793:gst_h264_parse_prepare_key_unit:<h264parse0> pushing downstream force-key-unit event 622 0:00:00.266666666 count 0
0:00:11.852938911 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:2813:gst_h264_parse_prepare_key_unit:<h264parse0> preparing key unit, have sps 1 have pps 1
0:00:12.243366082 797 0x7f8a08085c00 INFO gstrtpfunnel gstrtpfunnel.c:510:gst_rtp_funnel_src_event:<rtpfunnel0:src> Sending custom-upstream event: 0x7f89e40068b0, time 99:99:99.999999999, seq-num 628, GstForceKeyUnit, ssrc=(uint)94573595, all-headers=(boolean)false; to <rtpfunnel0:sink_1>
0:00:12.243383407 797 0x7f8a08085c00 INFO h264parse gsth264parse.c:3738:gst_h264_parse_src_event:<h264parse0> received upstream force-key-unit event, seqnum 628 running_time 99:99:99.999999999 all_headers 0 count 0
0:00:12.247009282 797 0x7f8a1c0020c0 INFO x264enc gstx264enc.c:2539:gst_x264_enc_encode_frame:<x264enc0> Forcing key frame
0:00:12.247914017 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:3664:gst_h264_parse_event:<h264parse0> received downstream force key unit event, seqnum 629 running_time 0:00:00.366666666 all_headers 0 count 0
0:00:12.247945606 797 0x7f8a1c002060 INFO baseparse gstbaseparse.c:4088:gst_base_parse_set_latency:<h264parse0> min/max latency 0:00:00.000000000, 0:00:00.000000000
0:00:12.247970664 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:2748:check_pending_key_unit_event: now 0:00:00.366666666 wanted 0:00:00.366666666
0:00:12.247976893 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:2793:gst_h264_parse_prepare_key_unit:<h264parse0> pushing downstream force-key-unit event 629 0:00:00.366666666 count 0
0:00:12.247983377 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:2813:gst_h264_parse_prepare_key_unit:<h264parse0> preparing key unit, have sps 1 have pps 1
0:00:12.645309095 797 0x7f8a08085c00 INFO gstrtpfunnel gstrtpfunnel.c:510:gst_rtp_funnel_src_event:<rtpfunnel0:src> Sending custom-upstream event: 0x7f89e4006920, time 99:99:99.999999999, seq-num 637, GstForceKeyUnit, ssrc=(uint)94573595, all-headers=(boolean)false; to <rtpfunnel0:sink_1>
0:00:12.645328962 797 0x7f8a08085c00 INFO h264parse gsth264parse.c:3738:gst_h264_parse_src_event:<h264parse0> received upstream force-key-unit event, seqnum 637 running_time 99:99:99.999999999 all_headers 0 count 0
0:00:12.647015554 797 0x7f8a1c0020c0 INFO x264enc gstx264enc.c:2539:gst_x264_enc_encode_frame:<x264enc0> Forcing key frame
0:00:12.647934388 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:3664:gst_h264_parse_event:<h264parse0> received downstream force key unit event, seqnum 638 running_time 0:00:00.466666666 all_headers 0 count 0
0:00:12.647966549 797 0x7f8a1c002060 INFO baseparse gstbaseparse.c:4088:gst_base_parse_set_latency:<h264parse0> min/max latency 0:00:00.000000000, 0:00:00.000000000
0:00:12.647983782 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:2748:check_pending_key_unit_event: now 0:00:00.466666666 wanted 0:00:00.466666666
0:00:12.647989867 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:2793:gst_h264_parse_prepare_key_unit:<h264parse0> pushing downstream force-key-unit event 638 0:00:00.466666666 count 0
0:00:12.647996782 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:2813:gst_h264_parse_prepare_key_unit:<h264parse0> preparing key unit, have sps 1 have pps 1
0:00:13.046618437 797 0x7f8a08085c00 INFO gstrtpfunnel gstrtpfunnel.c:510:gst_rtp_funnel_src_event:<rtpfunnel0:src> Sending custom-upstream event: 0x7f89e4006990, time 99:99:99.999999999, seq-num 646, GstForceKeyUnit, ssrc=(uint)94573595, all-headers=(boolean)false; to <rtpfunnel0:sink_1>
0:00:13.046637594 797 0x7f8a08085c00 INFO h264parse gsth264parse.c:3738:gst_h264_parse_src_event:<h264parse0> received upstream force-key-unit event, seqnum 646 running_time 99:99:99.999999999 all_headers 0 count 0
0:00:13.047121193 797 0x7f8a1c0020c0 INFO x264enc gstx264enc.c:2539:gst_x264_enc_encode_frame:<x264enc0> Forcing key frame
0:00:13.048011072 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:3664:gst_h264_parse_event:<h264parse0> received downstream force key unit event, seqnum 647 running_time 0:00:00.566666666 all_headers 0 count 0
0:00:13.048055961 797 0x7f8a1c002060 INFO baseparse gstbaseparse.c:4088:gst_base_parse_set_latency:<h264parse0> min/max latency 0:00:00.000000000, 0:00:00.000000000
0:00:13.048083709 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:2748:check_pending_key_unit_event: now 0:00:00.566666666 wanted 0:00:00.566666666
0:00:13.048091228 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:2793:gst_h264_parse_prepare_key_unit:<h264parse0> pushing downstream force-key-unit event 647 0:00:00.566666666 count 0
0:00:13.048097650 797 0x7f8a1c002060 INFO h264parse gsth264parse.c:2813:gst_h264_parse_prepare_key_unit:<h264parse0> preparing key unit, have sps 1 have pps 1
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1448avidemux: missing colorimetry in CAPS2023-02-03T20:53:50ZMarianna Smidth Buschleavidemux: missing colorimetry in CAPSI have a problem where I record RAW frames (YUY2) into an AVI container and then want to "play" it through a v4l2 loopback device.
`v4l2sink` seems to require a colorimetry of `2:4:7:1`.
However, even if I specify it when saving and lat...I have a problem where I record RAW frames (YUY2) into an AVI container and then want to "play" it through a v4l2 loopback device.
`v4l2sink` seems to require a colorimetry of `2:4:7:1`.
However, even if I specify it when saving and later demuxing the file I get negotiation errors.
When I inspect the CAPS negotiation it seems to be because `avidemux` is not outputting any `colorimetry` information.
The only way I can get it to work is by adding a `videoconvert` before the `v4l2sink`, but I would like to avoid the extra processing.
```shell
GST_DEBUG=*:3 gst-launch-1.0 videotestsrc num-buffers=10 ! video/x-raw,format=YUY2,colorimetry=2:4:7:1 ! avimux ! filesink location=/tmp/test2.avi
GST_DEBUG=*:3,GST_CAPS:5 gst-launch-1.0 filesrc location=/tmp/test2.avi ! avidemux ! v4l2sink device=/dev/video9
GST_DEBUG=*:3,GST_CAPS:5 gst-launch-1.0 filesrc location=/tmp/test2.avi ! avidemux ! video/x-raw,format=YUY2, colorimetry=2:4:7:1 ! v4l2sink device=/dev/video9
```
```shell
0:00:00.343173842 29454 0x5619d9bf7400 DEBUG GST_CAPS gstutils.c:3185:gst_pad_query_accept_caps:<capsfilter1:sink> accept caps of video/x-raw, format=(string)YUY2, framerate=(fraction)30/1, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1
0:00:00.343353157 29454 0x5619d9bf7400 DEBUG GST_CAPS gstutils.c:3185:gst_pad_query_accept_caps:<v4l2sink0:sink> accept caps of video/x-raw, format=(string)YUY2, colorimetry=(string)2:4:7:1, framerate=(fraction)30/1, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1
0:00:00.343500729 29454 0x5619d9bf7400 WARN basetransform gstbasetransform.c:1370:gst_base_transform_setcaps:<capsfilter1> transform could not transform video/x-raw, format=(string)YUY2, framerate=(fraction)30/1, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1 in anything we support
0:00:00.343604933 29454 0x5619d9bf7400 DEBUG GST_CAPS gstutils.c:3185:gst_pad_query_accept_caps:<capsfilter1:sink> accept caps of video/x-raw, format=(string)YUY2, framerate=(fraction)30/1, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1
0:00:00.343720671 29454 0x5619d9bf7400 DEBUG GST_CAPS gstutils.c:3185:gst_pad_query_accept_caps:<v4l2sink0:sink> accept caps of video/x-raw, format=(string)YUY2, colorimetry=(string)2:4:7:1, framerate=(fraction)30/1, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1
0:00:00.343835285 29454 0x5619d9bf7400 WARN basetransform gstbasetransform.c:1370:gst_base_transform_setcaps:<capsfilter1> transform could not transform video/x-raw, format=(string)YUY2, framerate=(fraction)30/1, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1 in anything we support
0:00:00.343943517 29454 0x5619d9bf7400 DEBUG GST_CAPS gstutils.c:3185:gst_pad_query_accept_caps:<capsfilter1:sink> accept caps of video/x-raw, format=(string)YUY2, framerate=(fraction)30/1, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1
0:00:00.344048412 29454 0x5619d9bf7400 DEBUG GST_CAPS gstutils.c:3185:gst_pad_query_accept_caps:<v4l2sink0:sink> accept caps of video/x-raw, format=(string)YUY2, colorimetry=(string)2:4:7:1, framerate=(fraction)30/1, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1
0:00:00.344182050 29454 0x5619d9bf7400 WARN basetransform gstbasetransform.c:1370:gst_base_transform_setcaps:<capsfilter1> transform could not transform video/x-raw, format=(string)YUY2, framerate=(fraction)30/1, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1 in anything we support
0:00:00.344795439 29454 0x5619d9bf7400 DEBUG GST_CAPS gstutils.c:3185:gst_pad_query_accept_caps:<capsfilter1:sink> accept caps of video/x-raw, format=(string)YUY2, framerate=(fraction)30/1, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1
0:00:00.344966076 29454 0x5619d9bf7400 DEBUG GST_CAPS gstutils.c:3185:gst_pad_query_accept_caps:<v4l2sink0:sink> accept caps of video/x-raw, format=(string)YUY2, colorimetry=(string)2:4:7:1, framerate=(fraction)30/1, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1
0:00:00.345080302 29454 0x5619d9bf7400 WARN basetransform gstbasetransform.c:1370:gst_base_transform_setcaps:<capsfilter1> transform could not transform video/x-raw, format=(string)YUY2, framerate=(fraction)30/1, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1 in anything we support
0:00:00.345242583 29454 0x5619d9bf7400 WARN avidemux gstavidemux.c:5787:gst_avi_demux_loop:<avidemux0> error: Internal data stream error.
0:00:00.345325166 29454 0x5619d9bf7400 WARN avidemux gstavidemux.c:5787:gst_avi_demux_loop:<avidemux0> error: streaming stopped, reason not-negotiated (-4)
ERROR: from element /GstPipeline:pipeline0/GstAviDemux:avidemux0: Internal data stream error.
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1450codecs: Baseclass for stateless encoders2022-09-23T11:40:08ZSeungha Yangseungha@centricular.comcodecs: Baseclass for stateless encodersI'm slowly looking at d3d12 encoding API (kind of stateless encoding API, like VA), and some code in va encoders such as reconstructed/reference picture management code can be reused for the other APIs, maybe for Vulkan encoding as well ...I'm slowly looking at d3d12 encoding API (kind of stateless encoding API, like VA), and some code in va encoders such as reconstructed/reference picture management code can be reused for the other APIs, maybe for Vulkan encoding as well in the future
cc @vjaquez @He_Junyanhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1453twcc: Received packets are ignored by the extension2023-02-17T22:28:46ZPhilippe Normandtwcc: Received packets are ignored by the extensionIn a recv-only webrtcbin pipeline, without bundle (so I have one RTP session for the audio stream and one for the video stream), the twcc managers are not properly configured and emit this log:
```
rtpsession rtptwcc.c:306:rtp_twcc_mana...In a recv-only webrtcbin pipeline, without bundle (so I have one RTP session for the audio stream and one for the video stream), the twcc managers are not properly configured and emit this log:
```
rtpsession rtptwcc.c:306:rtp_twcc_manager_get_recv_twcc_seqnum: Received TWCC packet, but no extension registered; ignoring
```
The `twcc->recv_ext_id` variable is never set, because the rtpsession caps are `application/x-rtp`, so not enough information... Proper caps seem known only downstream, after `rtpptdemux`.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1455aggregator: Crash when adding random pads2022-09-21T19:49:00Zkbaltaggregator: Crash when adding random pads- GStreamer version 1.20.3 Fedora 36
- crate version: 0.18.8
Adding and linking arbitrary pads to elements with multiple 'request-pads' like `audiomixer` leads to a SIGSEGV.
Swapping `audiomixer name=sink_element ! fakesink` with `fake...- GStreamer version 1.20.3 Fedora 36
- crate version: 0.18.8
Adding and linking arbitrary pads to elements with multiple 'request-pads' like `audiomixer` leads to a SIGSEGV.
Swapping `audiomixer name=sink_element ! fakesink` with `fakesink name=sink_element` gets rid of the crash and instead (as expected) yields an `Internal data stream error.`
```rust
use gstreamer as gst;
use gst::prelude::*;
fn main() {
gst::init().unwrap();
let pipeline = gst::parse_launch("
audiotestsrc name=src_element
audiomixer name=sink_element ! fakesink
").unwrap();
let pipeline = pipeline.downcast::<gst::Pipeline>().unwrap();
let src_element = pipeline.by_name("src_element").unwrap();
let src = src_element.static_pad("src").unwrap();
let sink_element = pipeline.by_name("sink_element").unwrap();
// Create a new pad and add it to the sink_element
let problematic_pad = gst::Pad::new(None, gst::PadDirection::Sink);
sink_element.add_pad(&problematic_pad).unwrap();
// then link the pad to the source
src.link(&problematic_pad).unwrap();
pipeline.set_state(gst::State::Playing).unwrap();
let bus = pipeline.bus().unwrap();
for msg in bus.iter_timed(gst::ClockTime::NONE) {
use gst::MessageView;
match msg.view() {
MessageView::Error(err) => {
break;
}
MessageView::Eos(..) => break,
_ => (),
}
}
}
```
Valgrind output
```text
==285970== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==285970== Access not within mapped region at address 0x150
==285970== at 0x4AC2469: g_mutex_lock (gthread-posix.c:1516)
==285970== by 0x5581179: gst_aggregator_do_events_and_queries (gstaggregator.c:946)
==285970== by 0x493A9D7: gst_element_do_foreach_pad (gstelement.c:1403)
==285970== by 0x5588906: gst_aggregator_aggregate_func (gstaggregator.c:1372)
==285970== by 0x4987590: gst_task_func (gsttask.c:384)
==285970== by 0x4A9ED01: g_thread_pool_thread_proxy.lto_priv.0 (gthreadpool.c:354)
==285970== by 0x4A9C301: g_thread_proxy (gthread.c:827)
==285970== by 0x4CE5E2C: start_thread (pthread_create.c:442)
==285970== by 0x4D6A363: clone (clone.S:100)
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1459pkg-config problem in static build2022-09-28T05:17:29ZJavad Rahimipkg-config problem in static build### Describe your issue
When trying to build the simple hello world example with static libraries, the following error is reported:
```bash
$ gcc basic-tutorial-1.c -o basic-tutorial-1 `pkg-config --cflags --libs gstreamer-full-1.0`
gcc...### Describe your issue
When trying to build the simple hello world example with static libraries, the following error is reported:
```bash
$ gcc basic-tutorial-1.c -o basic-tutorial-1 `pkg-config --cflags --libs gstreamer-full-1.0`
gcc: fatal error: cannot execute ‘/usr/lib/gcc/x86_64-linux-gnu/11/cc1’: execv: Argument list too long
compilation terminated.
```
After extracting the output of `pkg-config --cflags --libs gstreamer-full-1.0` command. Its output was too long, such that even the editor was not able to open it.
#### Setup
- **Operating System: Linux Mint 21
- **Device: Computer
- **GStreamer Version: 1.18
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open terminal
2. configure with `meson` :
```
$ meson build-gst-full \
-Ddefault_library=static \
-Dintrospection=disabled \
--buildtype=release \
--strip \
--wrap-mode=forcefallback
```
3. build with `ninja`:
```
$ ninja -C build-gst-full
```
### How reproducible is the bug?
When I tried the build the hello world example in Fedora docker image `registry.freedesktop.org/gstreamer/gst-plugins-bad/amd64/fedora:2021-03-30.0-master`). It was working normally
I have attached the output of `pkg-config` for your reference.
[ins](/uploads/a025a766c103492127bbdd5974317b89/ins)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1460meson: recursive include of subprojects when using --wrap-mode=forcefallback2023-02-08T18:52:13ZStéphane Cerveauscerveau@igalia.commeson: recursive include of subprojects when using --wrap-mode=forcefallback### Describe your issue
When the build is configured with `--wrap-mode=forcefallback`, it fails on
```
subprojects/harfbuzz/meson.build:78:2: ERROR: Recursive include of subprojects: gst-plugins-base => libdrm => cairo => fontconfig ...### Describe your issue
When the build is configured with `--wrap-mode=forcefallback`, it fails on
```
subprojects/harfbuzz/meson.build:78:2: ERROR: Recursive include of subprojects: gst-plugins-base => libdrm => cairo => fontconfig => freetype2 => harfbuzz => freetype2.
```
#### Expected Behavior
To finish the configure properly with `--wrap-mode=forcefallback`
#### Observed Behavior
#### Setup
- **Operating System:** Linux
- **Device:** Computer
- **GStreamer Version:** 1.21
- **Command line:** `meson builddir-fallback -Dintrospection=disabled --wrap-mode=forcefallback`
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open terminal
2. type `command`
### How reproducible is the bug?
Always
### Screenshots if relevant
### Solutions you have tried
Added `-Dharfbuzz:freetype=disabled` but the build was still failing for cairo complaining about a recursive dependency with harfbuzz. `subprojects/harfbuzz/meson.build:127:2: ERROR: Recursive include of subprojects: gst-plugins-base => libdrm => cairo => fontconfig => freetype2 => harfbuzz => cairo`
Added `-Dharfbuzz:cairo=disabled` and it failed on link stage with `subprojects/cairo/test/svg2png`.
Added `-Dcairo:tests=disabled` and it failed now with `.../builddir/../subprojects/pango/pango/pango-ot-info.c:95: undefined reference to `hb_ft_face_create'`. So I guess now that pango needs harfbuzz to have some freetype enabling.
### Related non-duplicate issues
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2507
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1459
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1461webrtc/nice: synchronous disposal of Nice agent triggers g_warnings when "TUR...2024-03-26T11:27:28ZMathieu Duponchellewebrtc/nice: synchronous disposal of Nice agent triggers g_warnings when "TURN refreshes" are pending.Since https://gitlab.freedesktop.org/libnice/libnice/-/merge_requests/179/diffs?commit_id=bbf7f2d7beb24c7d620e62c2030701e6961a29d4 NiceAgent will log a g_warning when trying to dispose a Nice agent with "alive reservations" on a TURN ser...Since https://gitlab.freedesktop.org/libnice/libnice/-/merge_requests/179/diffs?commit_id=bbf7f2d7beb24c7d620e62c2030701e6961a29d4 NiceAgent will log a g_warning when trying to dispose a Nice agent with "alive reservations" on a TURN server.
Currently, webrtcbin disposes of the agent synchronously when its state is going down, which can trigger the warnings without the user having any control over that.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1466Pipeline manipulation as changing elements in a pipeline by removed and added...2022-09-30T07:13:14ZledtriPipeline manipulation as changing elements in a pipeline by removed and added element cause memory leak### 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 have tried the example dynamic changing elements in a pipeline by removed and added element in every 1 second. I observer that RES and SHR memory increase overtime.
The tutorial sample code from the official Gstreamer page: [Link tutorial](https://gstreamer.freedesktop.org/documentation/application-development/advanced/pipeline-manipulation.html?gi-language=c#:~:text=This%20example%20changes%20the%20video%20effect%20on%20a%20simple%20pipeline%20once%20per%20second%3A)
**This issues is critical to our system if have a change dynamic in pipeline from a bin which is included a lot of child elements and repeate in many time. The application OOM and crash overtime.**
#### Expected Behavior
<!-- What did you expect to happen -->
The memory need to be stable when changing element in the pipeline
#### Observed Behavior
<!-- What actually happened -->
After running about 10 minute the RES and SHR memory increase overtime from 0.2% to 0.8% after 10 minutes.
#### Setup
- **Operating System: 22.04**
- **Device:** Computer <!-- Delete as appropriate !-->
- **GStreamer Version: 1.20.3**
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open terminal
2. `gcc add_delete.c $(pkg-config --cflags --libs gstreamer-1.0) -o add_delete`
3. `./add_delete`
[add_delete.c](/uploads/6c23320abc7dc1ef40f7c0b0ffaf74f1/add_delete.c)
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Use `htop` and check the percent memory take by `./add_delete` process overtime
### Screenshots if relevant
![Screenshot_from_2022-09-29_15-05-57](/uploads/09249b5cc933f2e11590f0348028b69e/Screenshot_from_2022-09-29_15-05-57.png)
![Screenshot_from_2022-09-29_15-06-22](/uploads/0e1efeeae6522c24e5c0317282327b9b/Screenshot_from_2022-09-29_15-06-22.png)
![Screenshot_from_2022-09-29_15-17-50](/uploads/2c74715c18a7e59e499e65cecca79c69/Screenshot_from_2022-09-29_15-17-50.png)
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->
Uncomment `#define DEFAULT_EFFECTS "identity,exclusion"`
Comment `g_queue_push_tail (&effects, gst_object_ref (cur_effect));`
to apply changing only 2 times of elements. build and run again. This is output of valgrind when running modified application.
<details><summary>Click to expand</summary>
```
valgrind --leak-check=yes ./add_delete
==290871== Memcheck, a memory error detector
==290871== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==290871== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==290871== Command: ./add_delete
==290871==
Adding effect 'identity'
Adding effect 'exclusion'
Adding effect 'navigationtest'
Adding effect 'agingtv'
Adding effect 'videoflip'
Adding effect 'vertigotv'
Adding effect 'gaussianblur'
Adding effect 'shagadelictv'
Adding effect 'edgetv'
Switching from 'identity0' to 'exclusion0'..
Switching from 'exclusion0' to 'navigationtest0'..
Switching from 'navigationtest0' to 'agingtv0'..
Switching from 'agingtv0' to 'videoflip0'..
Switching from 'videoflip0' to 'vertigotv0'..
Switching from 'vertigotv0' to 'gaussianblur0'..
==290871== Thread 4 queue0:src:
==290871== Conditional jump or move depends on uninitialised value(s)
==290871== at 0x48673D7: ??? (in /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstgaudieffects.so)
==290871== by 0x6CA8DD0: ??? (in /usr/lib/x86_64-linux-gnu/libgstvideo-1.0.so.0.2001.0)
==290871== by 0x63E3CB0: default_generate_output (gstbasetransform.c:2192)
==290871== by 0x63E314B: gst_base_transform_chain (gstbasetransform.c:2345)
==290871== by 0x49077CC: gst_pad_chain_data_unchecked (gstpad.c:4447)
==290871== by 0x490AD68: gst_pad_push_data (gstpad.c:4711)
==290871== by 0x490B18D: gst_pad_push (gstpad.c:4830)
==290871== by 0x63E321E: gst_base_transform_chain (gstbasetransform.c:2381)
==290871== by 0x49077CC: gst_pad_chain_data_unchecked (gstpad.c:4447)
==290871== by 0x490AD68: gst_pad_push_data (gstpad.c:4711)
==290871== by 0x490B18D: gst_pad_push (gstpad.c:4830)
==290871== by 0x6361874: UnknownInlinedFun (gstqueue.c:1388)
==290871== by 0x6361874: gst_queue_loop (gstqueue.c:1541)
==290871==
==290871== Conditional jump or move depends on uninitialised value(s)
==290871== at 0x48673DF: ??? (in /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstgaudieffects.so)
==290871== by 0x6CA8DD0: ??? (in /usr/lib/x86_64-linux-gnu/libgstvideo-1.0.so.0.2001.0)
==290871== by 0x63E3CB0: default_generate_output (gstbasetransform.c:2192)
==290871== by 0x63E314B: gst_base_transform_chain (gstbasetransform.c:2345)
==290871== by 0x49077CC: gst_pad_chain_data_unchecked (gstpad.c:4447)
==290871== by 0x490AD68: gst_pad_push_data (gstpad.c:4711)
==290871== by 0x490B18D: gst_pad_push (gstpad.c:4830)
==290871== by 0x63E321E: gst_base_transform_chain (gstbasetransform.c:2381)
==290871== by 0x49077CC: gst_pad_chain_data_unchecked (gstpad.c:4447)
==290871== by 0x490AD68: gst_pad_push_data (gstpad.c:4711)
==290871== by 0x490B18D: gst_pad_push (gstpad.c:4830)
==290871== by 0x6361874: UnknownInlinedFun (gstqueue.c:1388)
==290871== by 0x6361874: gst_queue_loop (gstqueue.c:1541)
==290871==
Switching from 'gaussianblur0' to 'shagadelictv0'..
Switching from 'shagadelictv0' to 'edgetv0'..
==290871==
==290871== HEAP SUMMARY:
==290871== in use at exit: 2,630,957 bytes in 25,990 blocks
==290871== total heap usage: 125,059 allocs, 99,069 frees, 36,987,677 bytes allocated
==290871==
==290871== Thread 1:
==290871== 384 bytes in 1 blocks are possibly lost in loss record 2,730 of 2,876
==290871== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==290871== by 0x40147D9: calloc (rtld-malloc.h:44)
==290871== by 0x40147D9: allocate_dtv (dl-tls.c:375)
==290871== by 0x40147D9: _dl_allocate_tls (dl-tls.c:634)
==290871== by 0x4BF8834: allocate_stack (allocatestack.c:430)
==290871== by 0x4BF8834: pthread_create@@GLIBC_2.34 (pthread_create.c:647)
==290871== by 0x4AD29A4: g_system_thread_new (gthread-posix.c:1323)
==290871== by 0x4AD2C4A: UnknownInlinedFun (gthread.c:932)
==290871== by 0x4AD2C4A: g_thread_pool_start_thread.constprop.0 (gthreadpool.c:477)
==290871== by 0x4AB0482: g_thread_pool_push (gthreadpool.c:723)
==290871== by 0x493AB3B: default_push (gsttaskpool.c:111)
==290871== by 0x493A382: UnknownInlinedFun (gsttask.c:712)
==290871== by 0x493A382: gst_task_set_state_unlocked (gsttask.c:744)
==290871== by 0x493A47C: gst_task_set_state (gsttask.c:792)
==290871== by 0x490D366: gst_pad_start_task (gstpad.c:6306)
==290871== by 0x63E7E34: gst_base_src_perform_seek (gstbasesrc.c:1831)
==290871== by 0x63EB69E: gst_base_src_start_complete (gstbasesrc.c:3639)
==290871==
==290871== 384 bytes in 1 blocks are possibly lost in loss record 2,731 of 2,876
==290871== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==290871== by 0x40147D9: calloc (rtld-malloc.h:44)
==290871== by 0x40147D9: allocate_dtv (dl-tls.c:375)
==290871== by 0x40147D9: _dl_allocate_tls (dl-tls.c:634)
==290871== by 0x4BF8834: allocate_stack (allocatestack.c:430)
==290871== by 0x4BF8834: pthread_create@@GLIBC_2.34 (pthread_create.c:647)
==290871== by 0x4AD29A4: g_system_thread_new (gthread-posix.c:1323)
==290871== by 0x4AD2C4A: UnknownInlinedFun (gthread.c:932)
==290871== by 0x4AD2C4A: g_thread_pool_start_thread.constprop.0 (gthreadpool.c:477)
==290871== by 0x4AB0482: g_thread_pool_push (gthreadpool.c:723)
==290871== by 0x48E5D53: gst_element_call_async (gstelement.c:3866)
==290871== by 0x48C483E: gst_bin_handle_message_func.lto_priv.0 (gstbin.c:3922)
==290871== by 0x48B7CBB: bin_bus_handler (gstbin.c:3252)
==290871== by 0x48D0861: gst_bus_post (gstbus.c:357)
==290871== by 0x48E65E9: gst_element_post_message_default.lto_priv.0 (gstelement.c:2117)
==290871== by 0x48E63B1: gst_element_post_message (gstelement.c:2160)
==290871==
==290871== 768 bytes in 2 blocks are possibly lost in loss record 2,763 of 2,876
==290871== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==290871== by 0x40147D9: calloc (rtld-malloc.h:44)
==290871== by 0x40147D9: allocate_dtv (dl-tls.c:375)
==290871== by 0x40147D9: _dl_allocate_tls (dl-tls.c:634)
==290871== by 0x4BF8834: allocate_stack (allocatestack.c:430)
==290871== by 0x4BF8834: pthread_create@@GLIBC_2.34 (pthread_create.c:647)
==290871== by 0x4AD29A4: g_system_thread_new (gthread-posix.c:1323)
==290871== by 0x4AD2C4A: UnknownInlinedFun (gthread.c:932)
==290871== by 0x4AD2C4A: g_thread_pool_start_thread.constprop.0 (gthreadpool.c:477)
==290871== by 0x4AB0482: g_thread_pool_push (gthreadpool.c:723)
==290871== by 0x493AB3B: default_push (gsttaskpool.c:111)
==290871== by 0x493A382: UnknownInlinedFun (gsttask.c:712)
==290871== by 0x493A382: gst_task_set_state_unlocked (gsttask.c:744)
==290871== by 0x493A47C: gst_task_set_state (gsttask.c:792)
==290871== by 0x490D366: gst_pad_start_task (gstpad.c:6306)
==290871== by 0x6361FA1: gst_queue_src_activate_mode (gstqueue.c:1754)
==290871== by 0x490073E: activate_mode_internal (gstpad.c:1216)
==290871==
==290871== 3,909 (624 direct, 3,285 indirect) bytes in 1 blocks are definitely lost in loss record 2,828 of 2,876
==290871== at 0x4A06F9D: g_type_create_instance (gtype.c:1907)
==290871== by 0x49EDF4C: g_object_new_internal (gobject.c:2011)
==290871== by 0x49EF1AC: g_object_new_with_properties (gobject.c:2181)
==290871== by 0x48E9CCF: gst_element_factory_create_with_properties (gstelementfactory.c:494)
==290871== by 0x48EA531: gst_element_factory_make_with_properties (gstelementfactory.c:689)
==290871== by 0x10AEBE: main (in /data/tests/add_delete)
==290871==
==290871== LEAK SUMMARY:
==290871== definitely lost: 624 bytes in 1 blocks
==290871== indirectly lost: 3,285 bytes in 35 blocks
==290871== possibly lost: 1,536 bytes in 4 blocks
==290871== still reachable: 388,984 bytes in 3,092 blocks
==290871== suppressed: 2,123,448 bytes in 22,394 blocks
==290871== Reachable blocks (those to which a pointer was found) are not shown.
==290871== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==290871==
==290871== Use --track-origins=yes to see where uninitialised values come from
==290871== For lists of detected and suppressed errors, rerun with: -s
==290871== ERROR SUMMARY: 254 errors from 6 contexts (suppressed: 1 from 1)
```
</details>https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1468gst-full: Link Gstreamer in Static modem with CMake2022-09-30T09:26:53ZJavad Rahimigst-full: Link Gstreamer in Static modem with CMake### Describe your issue
When Trying to compiled an application with the statically linked Gstreamer library, the following error is generated:
```bash
[ 33%] Linking CXX executable rcvstream_exe
/usr/bin/ld: /opt/g/b/libgstreamer-full-1...### Describe your issue
When Trying to compiled an application with the statically linked Gstreamer library, the following error is generated:
```bash
[ 33%] Linking CXX executable rcvstream_exe
/usr/bin/ld: /opt/g/b/libgstreamer-full-1.0.a(gstplugin.c.o): undefined reference to symbol 'g_module_supported'
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/rcvstream_exe.dir/build.make:164: rcvstream_exe] Error 1
make[1]: *** [CMakeFiles/Makefile2:78: CMakeFiles/rcvstream_exe.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
Failed <<< imp_rcvstream [1.99s, exited with code 2]
```
#### Setup
- **Operating System: Ubuntu 20.04**
- **Device:** Computer
- **GStreamer Version: 1.20 (main branch)**
- **Command line:**
### Steps to reproduce the bug
The application is built based on `cmake` and `colcon`
1. open terminal
2. type `colcon build`
### Additional Information
I have attached the `CMakelists.txt` file for your reference.
[CMakelists.txt](/uploads/796baa78f75a3aa670b7e9c5aef2b63c/CMakelists.txt)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1469The `concat` and `flacenc` elements don’t interact well together, leading to ...2023-12-01T11:12:18ZSimonas KazlauskasThe `concat` and `flacenc` elements don’t interact well together, leading to an SIGABRT### Describe your issue
Running a gstreamer pipeline that combines `concat` and `flacenc` like so can sometimes abort the entire process (and doesn’t work if it doesn't)
```
gst-launch-1.0 concat name=input audiotestsrc num-buffers=1...### Describe your issue
Running a gstreamer pipeline that combines `concat` and `flacenc` like so can sometimes abort the entire process (and doesn’t work if it doesn't)
```
gst-launch-1.0 concat name=input audiotestsrc num-buffers=100 ! input.sink_0 audiotestsrc num-buffers=100 ! input.sink_1 input. ! flacenc ! fakesink
```
#### Expected Behavior
This failing probably has a pretty good reason. I’m not seeing a good way to resolve it quite yet. This aborting, probably does not – I would expect gstreamer pipelines combining high quality elements to generally never abort.
#### Observed Behavior
The command fails with SIGABRT and the following messages:
```
WARNING: from element /GstPipeline:pipeline0/GstFlacEnc:flacenc0: The stream is in the wrong format.
Additional debug info:
../ext/flac/gstflacenc.c(1396): gst_flac_enc_handle_frame (): /GstPipeline:pipeline0/GstFlacEnc:flacenc0: Stream discontinuity detected. The output may have wrong timestamps, consider using audiorate to handle discontinuities
ERROR: from element /GstPipeline:pipeline0/GstFlacEnc:flacenc0: received more encoded samples 4608 than provided 4096 as inputs
Additional debug info:
../gst-libs/gst/audio/gstaudioencoder.c(1039): gst_audio_encoder_finish_frame (): /GstPipeline:pipeline0/GstFlacEnc:flacenc0
Execution ended after 0:00:00.004580563
Setting pipeline to NULL ...
**
GStreamer-Audio:ERROR:../gst-libs/gst/audio/gstaudioencoder.c:1046:gst_audio_encoder_finish_frame: code should not be reached
Bail out! GStreamer-Audio:ERROR:../gst-libs/gst/audio/gstaudioencoder.c:1046:gst_audio_encoder_finish_frame: code should not be reached
fish: Job 1, 'gst-launch-1.0 concat name=inpu…' terminated by signal SIGABRT (Abort)
```
#### Setup
- **Operating System:** NixOS
- **GStreamer Version:** 1.20.3
- **Command line:** `gst-launch-1.0 concat name=input audiotestsrc num-buffers=100 ! input.sink_0 audiotestsrc num-buffers=100 ! input.sink_1 input. ! flacenc ! fakesink`
### Steps to reproduce the bug
1. Run `gst-launch-1.0 concat name=input audiotestsrc num-buffers=100 ! input.sink_0 audiotestsrc num-buffers=100 ! input.sink_1 input. ! flacenc ! fakesink`
### How reproducible is the bug?
Always
### Solutions you have tried
Changing the number of buffers can hide the abort, but the discontinuity error remains.
### 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/1473mfvideosrc: Expose camera control options2024-01-09T01:01:11ZSeungha Yangseungha@centricular.commfvideosrc: Expose camera control optionsimage quality related properties (e.g., brightness) and camera properties (zoom, focus, etc) are controllable via `IAMVideoProcAmp` and `IAMCameraControl` interfacesimage quality related properties (e.g., brightness) and camera properties (zoom, focus, etc) are controllable via `IAMVideoProcAmp` and `IAMCameraControl` interfaceshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1474avauddec: handle gapless WMA properly2022-10-07T16:31:16ZMathieu Duponchelleavauddec: handle gapless WMA properlyIn order to fix the regression described https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1348, we are going to first restore the behavior of our wrapper with FFmpeg pre https://trac.ffmpeg.org/ticket/7473, by outputting lead-...In order to fix the regression described https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1348, we are going to first restore the behavior of our wrapper with FFmpeg pre https://trac.ffmpeg.org/ticket/7473, by outputting lead-in samples that FFmpeg now would like us to skip, and discarding trailing samples that FFmpeg used to not give us.
This results in our decoder outputting the same data before and after the FFmpeg patch, but we should now have a reflexion on how to fix this properly, the main complicating factor being that the base decoder class really wants subclasses to provide an accurate mapping from input to output samples, this in order to preserve metadata.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1477Playback hangs after seeking forward/backwards2023-12-29T05:51:16ZPedro CastroPlayback hangs after seeking forward/backwards### Describe your issue
Playback hangs after seeking forward and backwards a number of times, with some video files.
This has been reproduced in Gnome Subtitles, Totem and gst-play-1.0.
Might be related to #1088 (which I can also reprodu...### Describe your issue
Playback hangs after seeking forward and backwards a number of times, with some video files.
This has been reproduced in Gnome Subtitles, Totem and gst-play-1.0.
Might be related to #1088 (which I can also reproduce with these files).
#### Setup
- **Operating System:** Ubuntu 22.04 / 22.10
- **GStreamer Version:** 1.20.3
### Steps to reproduce the bug
1. open terminal
2. type `gst-play-1.0 video.mp4`
3. seek forward some times
4. seek backward for a while (until the beginning)
5. repeat seek forward and backward
6. after a while, playback hangs
### How reproducible is the bug?
This bug is always reproducible for certain video files.
### Related non-duplicate issues
gnome-subtitles: https://gitlab.gnome.org/GNOME/gnome-subtitles#200
totem: https://gitlab.gnome.org/GNOME/totem/-/issues/526
### Additional Information
$ mediainfo video.mp4
<details>
<code>
General
Complete name : video.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 1.66 GiB
Duration : 1 h 29 min
Overall bit rate : 2 639 kb/s
Writing application : Lavf58.35.100
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1 h 29 min
Bit rate : 2 250 kb/s
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 24.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.061
Stream size : 1.41 GiB (85%)
Writing library : x264 core 158
Encoding settings : cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=12 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=2250 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=31250 / vbv_bufsize=31250 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Codec configuration box : avcC
Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 1 h 29 min
Bit rate mode : Constant
Bit rate : 384 kb/s
Channel(s) : 6 channels
Channel layout : C L R Ls Rs LFE
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 247 MiB (15%)
Default : Yes
Alternate group : 1
</code>
</details>https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/248jsontovtt: potential panic when assuming segment.stop is set2022-10-06T11:34:26ZMathieu Duponchellejsontovtt: potential panic when assuming segment.stop is setThe following discussion from !889 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/889#note_1578633): (+14 comments)
> Why is `segment.stop` guarant...The following discussion from !889 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/889#note_1578633): (+14 comments)
> Why is `segment.stop` guaranteed to be not `None` here? @mehhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1480matroskamux: headers should have GST_CLOCK_TIME_NONE as pts instead of 02022-10-06T14:14:58ZGuillaume Desmottesmatroskamux: headers should have GST_CLOCK_TIME_NONE as pts instead of 0`matroskamux` always set `0:00:00.000000000` as pts on the headers buffers, even if its input does not start at `0`.
This breaks clock sync and may fully fill queues having a `max-size-time`.
This can be reproduced using this test app:
...`matroskamux` always set `0:00:00.000000000` as pts on the headers buffers, even if its input does not start at `0`.
This breaks clock sync and may fully fill queues having a `max-size-time`.
This can be reproduced using this test app:
```rust
use gst::prelude::*;
fn main() {
gst::init().unwrap();
let pipeline = gst::parse_launch(
"audiotestsrc is-live=true num-buffers=30 ! avenc_aac ! matroskamux ! fakesink",
)
.unwrap()
.downcast::<gst::Pipeline>()
.unwrap();
pipeline.use_clock(Some(&gst::SystemClock::obtain()));
pipeline.set_start_time(gst::ClockTime::NONE);
pipeline.set_base_time(gst::ClockTime::ZERO);
let bus = pipeline.bus().unwrap();
pipeline
.set_state(gst::State::Playing)
.expect("Unable to set the pipeline to the `Playing` state");
for msg in bus.iter_timed(gst::ClockTime::NONE) {
use gst::MessageView;
match msg.view() {
MessageView::Eos(..) => break,
MessageView::Error(err) => {
println!(
"Error from {:?}: {} ({:?})",
err.src().map(|s| s.path_string()),
err.error(),
err.debug()
);
break;
}
_ => (),
}
}
pipeline
.set_state(gst::State::Null)
.expect("Unable to set the pipeline to the `Null` state");
}
```
See the pts of the buffers:
```
gstpad.c:4446:gst_pad_chain_data_unchecked:<avenc_aac0:sink> calling chainfunction &gst_audio_encoder_chain with buffer buffer: 0x563d0d3765a0, pts 63:08:44.941758719, dts 99:99:99.999999999, dur 0:00:00.023219954, size 4096, offset 0, offset_end 1024, flags 0x40
gstpad.c:4446:gst_pad_chain_data_unchecked:<avenc_aac0:sink> calling chainfunction &gst_audio_encoder_chain with buffer buffer: 0x563d0d376900, pts 63:08:44.964978673, dts 99:99:99.999999999, dur 0:00:00.023219955, size 4096, offset 1024, offset_end 2048, flags 0x0
gstpad.c:4446:gst_pad_chain_data_unchecked:<avenc_aac0:sink> calling chainfunction &gst_audio_encoder_chain with buffer buffer: 0x7f8bb40aa000, pts 63:08:44.988198628, dts 99:99:99.999999999, dur 0:00:00.023219954, size 4096, offset 2048, offset_end 3072, flags 0x0
gstpad.c:4446:gst_pad_chain_data_unchecked:<matroskamux0:audio_0> calling chainfunction &gst_collect_pads_chain with buffer buffer: 0x563d0d3767e0, pts 63:08:44.941758719, dts 63:08:44.941758719, dur 0:00:00.023219954, size 194, offset 0, offset_end 194, flags 0x40
gstpad.c:4446:gst_pad_chain_data_unchecked:<matroskamux0:audio_0> calling chainfunction &gst_collect_pads_chain with buffer buffer: 0x563d0d376a20, pts 63:08:44.964978673, dts 63:08:44.964978673, dur 0:00:00.023219955, size 253, offset 194, offset_end 447, flags 0x0
gstpad.c:4446:gst_pad_chain_data_unchecked:<matroskamux0:audio_0> calling chainfunction &gst_collect_pads_chain with buffer buffer: 0x563d0d376c60, pts 63:08:44.988198628, dts 63:08:44.988198628, dur 0:00:00.023219954, size 191, offset 447, offset_end 638, flags 0x0
gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x563d0d376ea0, pts 0:00:00.000000000, dts 99:99:99.999999999, dur 99:99:99.999999999, size 32, offset 0, offset_end 32, flags 0x6440
gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7f8bb40aa000, pts 0:00:00.000000000, dts 99:99:99.999999999, dur 99:99:99.999999999, size 221, offset 32, offset_end 253, flags 0x6400
gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x563d0d376b40, pts 63:08:44.941758719, dts 99:99:99.999999999, dur 99:99:99.999999999, size 18, offset 253, offset_end 271, flags 0x4000
gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x563d0d376d80, pts 63:08:44.941758719, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 271, offset_end 278, flags 0x6000
gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x563d0d376b40, pts 63:08:44.941758719, dts 63:08:44.941758719, dur 0:00:00.023219954, size 194, offset 278, offset_end 472, flags 0x2000
gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x563d0d376d80, pts 63:08:44.964978673, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 472, offset_end 479, flags 0x6000
gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x563d0d376b40, pts 63:08:44.964978673, dts 63:08:44.964978673, dur 0:00:00.023219955, size 253, offset 479, offset_end 732, flags 0x2000
```
I think the headers buffers should use `GST_CLOCK_TIME_NONE` as `mp4mux` does:
```
gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x5642a0956b40, pts 99:99:99.999999999, dts 99:99:99.999999999, dur 99:99:99.999999999, size 32, offset none, offset_end none, flags 0x4000
gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x5642a0956c60, pts 99:99:99.999999999, dts 99:99:99.999999999, dur 99:99:99.999999999, size 8, offset none, offset_end none, flags 0x0
gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x5642a09567e0, pts 63:10:30.384196669, dts 63:10:30.384196669, dur 0:00:00.023219954, size 194, offset 0, offset_end 194, flags 0x40
gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fcf7c00a120, pts 63:10:30.407416623, dts 63:10:30.407416623, dur 0:00:00.023219955, size 253, offset 194, offset_end 447, flags 0x0
gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fcf7c00a480, pts 63:10:30.430636578, dts 63:10:30.430636578, dur 0:00:00.023219954, size 191, offset 447, offset_end 638, flags 0x0
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1481matroskamux: wrong timestamps when muxing 2 streams not starting from pts=0 w...2022-10-06T14:14:57ZGuillaume Desmottesmatroskamux: wrong timestamps when muxing 2 streams not starting from pts=0 with offset-to-zero=trueSee the following example muxing 2 live streams not starting from ts 0 with `offset-to-zero=true`.
```rust
use gst::prelude::*;
fn main() {
gst::init().unwrap();
let pipeline = gst::parse_launch(
"audiotestsrc is-live=true...See the following example muxing 2 live streams not starting from ts 0 with `offset-to-zero=true`.
```rust
use gst::prelude::*;
fn main() {
gst::init().unwrap();
let pipeline = gst::parse_launch(
"audiotestsrc is-live=true num-buffers=30 ! avenc_aac ! matroskamux name=mux offset-to-zero=true ! fakesink videotestsrc is-live=true num-buffers=30 ! x264enc ! mux.",
)
.unwrap()
.downcast::<gst::Pipeline>()
.unwrap();
pipeline.use_clock(Some(&gst::SystemClock::obtain()));
pipeline.set_start_time(gst::ClockTime::NONE);
pipeline.set_base_time(gst::ClockTime::ZERO);
let bus = pipeline.bus().unwrap();
pipeline
.set_state(gst::State::Playing)
.expect("Unable to set the pipeline to the `Playing` state");
for msg in bus.iter_timed(gst::ClockTime::NONE) {
use gst::MessageView;
match msg.view() {
MessageView::Eos(..) => break,
MessageView::Error(err) => {
println!(
"Error from {:?}: {} ({:?})",
err.src().map(|s| s.path_string()),
err.error(),
err.debug()
);
break;
}
_ => (),
}
}
pipeline
.set_state(gst::State::Null)
.expect("Unable to set the pipeline to the `Null` state");
}
```
The timestamps produced by `matroskamux` are not increasing. It's like if the buffers are alternating with two different scales, one starting at `0` and the other at the actual first pts:
```
0:00:01.110768053 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa4d3b900, pts 0:00:00.000000000, dts 99:99:99.999999999, dur 99:99:99.999999999, size 32, offset 0, offset_end 32, flags 0x6440
0:00:01.111052039 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa4d3b7e0, pts 0:00:00.000000000, dts 99:99:99.999999999, dur 99:99:99.999999999, size 448, offset 32, offset_end 480, flags 0x6400
0:00:01.111105323 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14240, pts 0:00:00.002746153, dts 99:99:99.999999999, dur 99:99:99.999999999, size 15, offset 480, offset_end 495, flags 0x4000
0:00:01.111136018 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14360, pts 0:00:00.002746153, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 495, offset_end 502, flags 0x6000
0:00:01.111162210 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14480, pts 63:40:49.373482124, dts 63:40:49.306815458, dur 0:00:00.033333333, size 7110, offset 502, offset_end 7612, flags 0x2200
0:00:01.111898769 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14120, pts 0:00:00.136079486, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 7612, offset_end 7619, flags 0x6000
0:00:01.111938140 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14000, pts 63:40:49.506815457, dts 63:40:49.340148791, dur 0:00:00.033333333, size 5015, offset 7619, offset_end 12634, flags 0x2200
0:00:01.113260784 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14360, pts 0:00:00.000000000, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 12634, offset_end 12641, flags 0x6000
0:00:01.113292468 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14240, pts 63:40:49.370735971, dts 63:40:49.370735971, dur 0:00:00.023219954, size 194, offset 12641, offset_end 12835, flags 0x2000
0:00:01.113795581 779880 0x55fdd7fe9000 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x55fdd7eb05a0, pts 0:00:00.069412819, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 12835, offset_end 12842, flags 0x6000
0:00:01.113837833 779880 0x55fdd7fe9000 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x55fdd7eb07e0, pts 63:40:49.440148790, dts 63:40:49.373482124, dur 0:00:00.033333334, size 5123, offset 12842, offset_end 17965, flags 0x2200
0:00:01.114506691 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14120, pts 0:00:00.023219954, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 17965, offset_end 17972, flags 0x6000
0:00:01.114546110 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14480, pts 63:40:49.393955925, dts 63:40:49.393955925, dur 0:00:00.023219955, size 253, offset 17972, offset_end 18225, flags 0x2000
0:00:01.114884561 779880 0x55fdd7fe9000 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa4d3bea0, pts 0:00:00.036079486, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 18225, offset_end 18232, flags 0x6000
0:00:01.114931175 779880 0x55fdd7fe9000 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x55fdd7eb0a20, pts 63:40:49.406815457, dts 63:40:49.406815457, dur 0:00:00.033333333, size 4923, offset 18232, offset_end 23155, flags 0x2200
0:00:01.115023172 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14360, pts 0:00:00.046439909, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 23155, offset_end 23162, flags 0x6000
0:00:01.115040745 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14000, pts 63:40:49.417175880, dts 63:40:49.417175880, dur 0:00:00.023219954, size 191, offset 23162, offset_end 23353, flags 0x2000
0:00:01.115289244 779880 0x55fdd7fe9000 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14240, pts 0:00:00.102746153, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 23353, offset_end 23360, flags 0x6000
0:00:01.115322443 779880 0x55fdd7fe9000 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa4d3bea0, pts 63:40:49.473482124, dts 63:40:49.440148790, dur 0:00:00.033333333, size 4893, offset 23360, offset_end 28253, flags 0x2200
0:00:01.115414261 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14120, pts 0:00:00.069659863, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 28253, offset_end 28260, flags 0x6000
0:00:01.115432788 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x55fdd7eb07e0, pts 63:40:49.440395834, dts 63:40:49.440395834, dur 0:00:00.023219955, size 171, offset 28260, offset_end 28431, flags 0x2000
0:00:01.115724215 779880 0x55fdd7fe9000 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x55fdd7eb05a0, pts 0:00:00.092879818, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 28431, offset_end 28438, flags 0x6000
0:00:01.115748994 779880 0x55fdd7fe9000 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa4d3bb40, pts 63:40:49.463615789, dts 63:40:49.463615789, dur 0:00:00.023219955, size 181, offset 28438, offset_end 28619, flags 0x2000
0:00:01.116026105 779880 0x55fdd7fe9000 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14000, pts 0:00:00.269412819, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 28619, offset_end 28626, flags 0x6000
0:00:01.116051859 779880 0x55fdd7fe9000 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x55fdd7eb05a0, pts 63:40:49.640148790, dts 63:40:49.473482124, dur 0:00:00.033333334, size 5128, offset 28626, offset_end 33754, flags 0x2200
0:00:01.116841187 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14360, pts 0:00:00.116099773, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 33754, offset_end 33761, flags 0x6000
0:00:01.116913605 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x55fdd7eb0a20, pts 63:40:49.486835744, dts 63:40:49.486835744, dur 0:00:00.023219954, size 192, offset 33761, offset_end 33953, flags 0x2000
0:00:01.117515988 779880 0x55fdd7fe9000 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14240, pts 0:00:00.202746153, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 33953, offset_end 33960, flags 0x6000
0:00:01.117544591 779880 0x55fdd7fe9000 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa4d3bc60, pts 63:40:49.573482124, dts 63:40:49.506815457, dur 0:00:00.033333333, size 5095, offset 33960, offset_end 39055, flags 0x2200
0:00:01.118009013 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14120, pts 0:00:00.139319727, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 39055, offset_end 39062, flags 0x6000
0:00:01.118037798 779880 0x55fdd7b58760 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa4d3bea0, pts 63:40:49.510055698, dts 63:40:49.510055698, dur 0:00:00.023219955, size 136, offset 39062, offset_end 39198, flags 0x2000
0:00:01.118311011 779880 0x55fdd7fe9000 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa4d3bb40, pts 0:00:00.162539682, dts 99:99:99.999999999, dur 99:99:99.999999999, size 7, offset 39198, offset_end 39205, flags 0x6000
0:00:01.118338143 779880 0x55fdd7fe9000 DEBUG GST_SCHEDULING gstpad.c:4446:gst_pad_chain_data_unchecked:<fakesink0:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7fefa5f14240, pts 63:40:49.533275653, dts 63:40:49.533275653, dur 0:00:00.023219955, size 208, offset 39205, offset_end 39413, flags 0x2000
```
The headers buffers starting at `0` is #1480https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1483gst-python can't find gi.repository.Gst2022-10-13T18:42:11Zdpatel257gst-python can't find gi.repository.Gst```
root@system:/# gst-inspect-1.0 /usr/local/lib/gstreamer-1.0/libgstpython.so
** (gst-inspect-1.0:342): CRITICAL **: 16:54:27.652: can't find gi.repository.Gst
Could not load plugin file: File "/usr/local/lib/gstreamer-1.0/libgstpytho...```
root@system:/# gst-inspect-1.0 /usr/local/lib/gstreamer-1.0/libgstpython.so
** (gst-inspect-1.0:342): CRITICAL **: 16:54:27.652: can't find gi.repository.Gst
Could not load plugin file: File "/usr/local/lib/gstreamer-1.0/libgstpython.so" appears to be a GStreamer plugin, but it failed to initialize
```
I am building the stack on Ubuntu20.04 container using following:
```
RUN cd /opt/build/gstreamer-1.20.3 && \
meson build --libdir=/usr/local/lib --libexecdir=/usr/local/lib \
--prefix=/usr/local --buildtype=plain -Dexamples=disabled -Dtests=disabled -Ddoc=disabled -Dintrospection=enabled -Dgtk_doc=disabled \
-Dpython=enabled \
-Dcustom_subprojects="gst-libav,gst-plugins-base,gst-plugins-good,gst-plugins-bad,gst-plugins-ugly,gst-python" \
-Dlibsoup:sysprof=disabled -Dgpl=enabled && \
cd build && \
ninja install && \
DESTDIR=/opt/dist ninja install
```
Installed possibly required packages too: `apt install python3-gi python3-gi-cairo gir1.2-gtk-3.0`
Even then, it can not load gst-python successfully.
Thanks in advance.