GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-06-21T08:25:21Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2688webrtcbin: Starting a video media stream some time after a session has been s...2023-06-21T08:25:21ZDaniel Squireswebrtcbin: Starting a video media stream some time after a session has been started results in.......a long pause whereby a number of frames seem to be looped repeatedly, after some time there will be a rapid "catchup event" where lots of frames play very fast. During this whole time from starting the video stream to normal playback ......a long pause whereby a number of frames seem to be looped repeatedly, after some time there will be a rapid "catchup event" where lots of frames play very fast. During this whole time from starting the video stream to normal playback some of the hosts CPU cores are pegged at 100%.
The longer the delay between starting the session and starting the video stream the worse the situation, i.e. the longer the time before video plays normally.
Does anybody have any idea why this is happening in terms of gstreamer pipeline configuration? It feels to me like something is mixing up epocs/timestamps between start of a session and start of the video stream.
The video media stream at this point is from gstreamer to the browser.
I just remembered these types of queries belong on the mailing list so I have posted there and will close this for now.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2686baseparse/h264: basesink clipping one of the first NALUs because of DTS out o...2023-06-20T13:46:43ZBugzilla Migration Userbaseparse/h264: basesink clipping one of the first NALUs because of DTS out of segment## Submitted by Marwen
**[Link to original bug (#797257)](https://bugzilla.gnome.org/show_bug.cgi?id=797257)**
## Description
Created attachment 373871
The log for the first buffers
gst-launch-1.0 -v videotestsrc ! x264enc ! ...## Submitted by Marwen
**[Link to original bug (#797257)](https://bugzilla.gnome.org/show_bug.cgi?id=797257)**
## Description
Created attachment 373871
The log for the first buffers
gst-launch-1.0 -v videotestsrc ! x264enc ! h264parse ! capsfilter caps="video/x-h264, stream-format=byte-stream, alignment=nal" ! fakesink silent=0
I enabled the logs for the parser and sink with GST_DEBUG=baseparse:7,h264parse:7,codecparsers_h264:7,basesink:7 to have the full picture. You can find the log for the first buffers attached.
The sink is dropping the second NALU of the stream because it fells out of the segment. That's because, in absence of a valid pts, the basesink is clipping on the dts which i don't think is a good idea since dts can fall out of the segment (especially for the first frames of h264 streams with b-frames).
The problem here comes also from the parser when transforming from a byte-stream format AU aligned to NAL aligned: when an AU is containing multiple NALU, only the first output buffer (NALU) is having the pts/dts of the input buffer(AU) while the following NALUs are having pts set to none and dts incremented by duration for every buffer. The attached log shows :
- First input buffer to h264parse with size 7144:
--> baseparse gstbaseparse.c:2189:gst_base_parse_handle_buffer:`<h264parse0>` handling buffer of size 7144 with dts 999:59:59.933333334, pts 1000:00:00.000000000, duration 99:99:99.999999999
- producing following buffers (NALUs):
--> baseparse gstbaseparse.c:2433:gst_base_parse_push_frame:`<h264parse0>` processing buffer of size 6 with dts 999:59:59.933333334, pts 1000:00:00.000000000, duration 0:00:00.033333333
--> baseparse gstbaseparse.c:2433:gst_base_parse_push_frame:`<h264parse0>` processing buffer of size 33 with dts 999:59:59.966666667, pts 99:99:99.999999999, duration 0:00:00.033333333
--> baseparse gstbaseparse.c:2433:gst_base_parse_push_frame:`<h264parse0>` processing buffer of size 9 with dts 1000:00:00.000000000, pts 99:99:99.999999999, duration 0:00:00.033333333
--> baseparse gstbaseparse.c:2433:gst_base_parse_push_frame:`<h264parse0>` processing buffer of size 761 with dts 1000:00:00.033333333, pts 99:99:99.999999999, duration 0:00:00.033333333
--> baseparse gstbaseparse.c:2433:gst_base_parse_push_frame:`<h264parse0>` processing buffer of size 6335 with dts 1000:00:00.066666666, pts 99:99:99.999999999, duration 0:00:00.033333333
- Next input buffer to h264 with sie 5348:
--> baseparse gstbaseparse.c:2189:gst_base_parse_handle_buffer:`<h264parse0>` handling buffer of size 5348 with dts 999:59:59.966666667, pts 1000:00:00.133333333, duration 99:99:99.999999999
The main problem is that the second NALU (with buffer size 6) is clipped out in the basesink because it have no valid pts and its dts is falling out of the segment (start: 1000:00:00.000000000).
I'm not sure if it's better to set all NALUs to the same pts of the "parent" AU or set it to none, but the DTS is certainly set wrong.
So the questions are :
- Should the basesink ever clip based on the DTS (even if no PTS is valid) ?
- What should be the (PTS,DTS) of the NALUs coming from the same AU ?
**Attachment 373871**, "The log for the first buffers":
[gst_log_h264.txt](/uploads/0677d1bba84a0ee0b8a9e7318e5fd7b6/gst_log_h264.txt)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/999videoflip wont allow setting video-direction with string2023-06-20T11:22:28ZJayson Reisvideoflip wont allow setting video-direction with stringHi there, while checking the docs, I saw that videoflip deprecated method property and says to use video-direction but, it is not possible to use the strings as values, here is a sample pipeline:
```
gst-launch-1.0 videotestsrc ! videofl...Hi there, while checking the docs, I saw that videoflip deprecated method property and says to use video-direction but, it is not possible to use the strings as values, here is a sample pipeline:
```
gst-launch-1.0 videotestsrc ! videoflip video-direction=rotate-180 ! autovideosink
```
the rationale there is because method= seems to be ignored on windows builds (1.22.3) but, using video-direction=2 works so i tried to port my code without successhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2685Crash when using rtsp client with TLS2023-06-21T09:02:51ZGustav JohanssonCrash when using rtsp client with TLS### Describe your issue
We gather multiple streams to the same device using rtsp with openssl TLS. Our process crashes often when we attempt to close all streams and restart them, but only when we are using TLS.
The errors we receive fr...### Describe your issue
We gather multiple streams to the same device using rtsp with openssl TLS. Our process crashes often when we attempt to close all streams and restart them, but only when we are using TLS.
The errors we receive from the coredumps are often "unsorted double linked list corrupted".
I've been able to get more information using valgrind with 7 streams. Please view "Addition information" to view the stacktrace from valgrind.
I'm unable to provide exact details on how to reproduce the issue, but I'll attempt to answer any questions that you might have. I don't know what I can try to give a better description.
We have currently been using gstreamer version 1.22.0 and 1.22.2.
#### Expected Behavior
Streams should be closing without memory issues.
<!-- What did you expect to happen -->
#### Observed Behavior
The process crashes because of invalid read.
<!-- What actually happened -->
#### Setup
- **Operating System:** GNU/Linux
- **Device:** Embedded aarch64 device <!-- Delete as appropriate !-->
- **GStreamer Version:** 1.22.0 and 1.22.2
- **Command line:** Not available.
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
I'm not sure on how to reproduce using only gstreamer tools, but this is essentially what we do:
1. Setup multiple streams to one process using rtsp client with openssl TLS:
2. Restart the streams in loop until the crash appears.
3. A crash can appear between a few minutes to a few hours.
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Intermittent: it can happen after a few minutes up to multiple hours. I'm assuming this could be a race condition caused by unprotected shared data.
### Additional Information
<details>
```
==1088346==
==1088346== Invalid read of size 4
==1088346== at 0x4BF76F8: g_wakeup_signal (gwakeup.c:232)
==1088346== by 0x4BA3E27: g_source_set_ready_time (gmain.c:2023)
==1088346== by 0x4E2556B: cancellable_source_cancelled (gcancellable.c:688)
==1088346== by 0x4AC7C0F: _g_closure_invoke_va (gclosure.c:893)
==1088346== by 0x4AE1A93: g_signal_emit_valist (gsignal.c:3406)
==1088346== by 0x4AE1C97: g_signal_emit (gsignal.c:3553)
==1088346== by 0x4E25E2F: g_cancellable_cancel (gcancellable.c:513)
==1088346== by 0x51B4D47: gst_rtsp_connection_flush (gstrtspconnection.c:3118)
==1088346== by 0x8779E23: gst_rtspsrc_connection_flush (gstrtspsrc.c:5288)
==1088346== by 0x8779FEB: gst_rtspsrc_loop_send_cmd (gstrtspsrc.c:6171)
==1088346== by 0x8782E33: gst_rtspsrc_change_state (gstrtspsrc.c:9295)
==1088346== by 0x504C913: gst_element_change_state (gstelement.c:3083)
==1088346== by 0x504CB07: gst_element_set_state_func (gstelement.c:3037)
==1088346== by 0x502F257: gst_bin_element_set_state (gstbin.c:2581)
==1088346== by 0x502F257: gst_bin_change_state_func (gstbin.c:2923)
==1088346== by 0x506B6A7: gst_pipeline_change_state (gstpipeline.c:529)
==1088346== by 0x504C913: gst_element_change_state (gstelement.c:3083)
==1088346== by 0x504CB07: gst_element_set_state_func (gstelement.c:3037)
==1088346== by 0x16D63F: pipeline_info_unref (cache.c:658)
==1088346== by 0x16ECB3: cache_info_free (cache.c:1197)
==1088346== by 0x16ECB3: cache_info_free (cache.c:1174)
==1088346== by 0x1681C3: base_buffer_stop_caching_unlocked (basebuffer.c:1139)
==1088346== by 0x1681C3: base_buffer_set_state_unlocked (basebuffer.c:2411)
==1088346== by 0x16A86F: base_buffer_message_handler (basebuffer.c:1033)
==1088346== by 0x503784B: gst_bus_source_dispatch (gstbus.c:821)
==1088346== by 0x4BA63FB: g_main_dispatch (gmain.c:3417)
==1088346== by 0x4BA63FB: g_main_context_dispatch (gmain.c:4135)
==1088346== by 0x4BA6787: g_main_context_iterate.constprop.0 (gmain.c:4211)
==1088346== by 0x4BA6B27: g_main_loop_run (gmain.c:4411)
==1088346== by 0x165D1B: loop_func (basebuffer.c:2762)
==1088346== by 0x4BD1E67: g_thread_proxy (gthread.c:827)
==1088346== by 0x5410657: start_thread (pthread_create.c:442)
==1088346== by 0x547765B: thread_start (clone.S:79)
==1088346== Address 0xa239674 is 4 bytes inside a block of size 8 free'd
==1088346== at 0x4867FD8: free (vg_replace_malloc.c:872)
==1088346== by 0x4BA45BF: g_main_context_unref (gmain.c:636)
==1088346== by 0x8BF1717: g_tls_bio_wait_available (gtlsbio.c:539)
==1088346== by 0x8BECB9B: perform_openssl_io (gtlsconnection-openssl.c:341)
==1088346== by 0x8BED28B: g_tls_connection_openssl_read (gtlsconnection-openssl.c:926)
==1088346== by 0x8BF6663: g_tls_connection_base_read (gtlsconnection-base.c:2057)
==1088346== by 0x8BF77E3: g_tls_input_stream_read (gtlsinputstream.c:82)
==1088346== by 0x4E5A5EF: g_input_stream_read (ginputstream.c:198)
==1088346== by 0x51AFBD7: fill_raw_bytes (gstrtspconnection.c:1426)
==1088346== by 0x51B0C27: fill_bytes (gstrtspconnection.c:1489)
==1088346== by 0x51B0C27: read_bytes (gstrtspconnection.c:1510)
==1088346== by 0x51B1003: build_next (gstrtspconnection.c:2464)
==1088346== by 0x51B3D33: gst_rtsp_connection_receive_usec (gstrtspconnection.c:2797)
==1088346== by 0x8785E9B: gst_rtspsrc_connection_receive (gstrtspsrc.c:2804)
==1088346== by 0x8785E9B: gst_rtspsrc_loop_interleaved (gstrtspsrc.c:5678)
==1088346== by 0x8785E9B: gst_rtspsrc_loop (gstrtspsrc.c:6215)
==1088346== by 0x8785E9B: gst_rtspsrc_thread (gstrtspsrc.c:9177)
==1088346== by 0x508DEFB: gst_task_func (gsttask.c:384)
==1088346== by 0x4BD29C7: g_thread_pool_thread_proxy (gthreadpool.c:354)
==1088346== by 0x4BD1E67: g_thread_proxy (gthread.c:827)
==1088346== by 0x5410657: start_thread (pthread_create.c:442)
==1088346== by 0x547765B: thread_start (clone.S:79)
==1088346== Block was alloc'd at
==1088346== at 0x486551C: malloc (vg_replace_malloc.c:381)
==1088346== by 0x4BAC5E7: g_malloc (gmem.c:125)
==1088346== by 0x4BC55F7: g_slice_alloc (gslice.c:1072)
==1088346== by 0x4BF75BB: g_wakeup_new (gwakeup.c:141)
==1088346== by 0x4BA2E4F: g_main_context_new_with_flags (gmain.c:733)
==1088346== by 0x8BF165F: g_tls_bio_wait_available (gtlsbio.c:495)
==1088346== by 0x8BECB9B: perform_openssl_io (gtlsconnection-openssl.c:341)
==1088346== by 0x8BED28B: g_tls_connection_openssl_read (gtlsconnection-openssl.c:926)
==1088346== by 0x8BF6663: g_tls_connection_base_read (gtlsconnection-base.c:2057)
==1088346== by 0x8BF77E3: g_tls_input_stream_read (gtlsinputstream.c:82)
==1088346== by 0x4E5A5EF: g_input_stream_read (ginputstream.c:198)
==1088346== by 0x51AFBD7: fill_raw_bytes (gstrtspconnection.c:1426)
==1088346== by 0x51B0C27: fill_bytes (gstrtspconnection.c:1489)
==1088346== by 0x51B0C27: read_bytes (gstrtspconnection.c:1510)
==1088346== by 0x51B1003: build_next (gstrtspconnection.c:2464)
==1088346== by 0x51B3D33: gst_rtsp_connection_receive_usec (gstrtspconnection.c:2797)
==1088346== by 0x8785E9B: gst_rtspsrc_connection_receive (gstrtspsrc.c:2804)
==1088346== by 0x8785E9B: gst_rtspsrc_loop_interleaved (gstrtspsrc.c:5678)
==1088346== by 0x8785E9B: gst_rtspsrc_loop (gstrtspsrc.c:6215)
==1088346== by 0x8785E9B: gst_rtspsrc_thread (gstrtspsrc.c:9177)
==1088346== by 0x508DEFB: gst_task_func (gsttask.c:384)
==1088346== by 0x4BD29C7: g_thread_pool_thread_proxy (gthreadpool.c:354)
==1088346== by 0x4BD1E67: g_thread_proxy (gthread.c:827)
==1088346== by 0x5410657: start_thread (pthread_create.c:442)
==1088346== by 0x547765B: thread_start (clone.S:79)
==1088346==
```
</details>https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2683ci: libsoup is not being built on MSVC ci because of missing libxml22023-06-22T08:59:39ZTim-Philipp Müllertim@centricular.comci: libsoup is not being built on MSVC ci because of missing libxml2See e.g. https://gitlab.freedesktop.org/ylatuya/gstreamer/-/jobs/43989667
Also https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4890#note_1965025
> libsoup| subprojects\\libsoup-2.74.3\\meson.build:123:15: Exception:...See e.g. https://gitlab.freedesktop.org/ylatuya/gstreamer/-/jobs/43989667
Also https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4890#note_1965025
> libsoup| subprojects\\libsoup-2.74.3\\meson.build:123:15: Exception: Subproject "subprojects/libxml2" required but not found.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2674Follow-up from "v4l2codecs: Always chain up to parent decide_allocation funct...2024-01-09T18:32:32ZNicolas DufresneFollow-up from "v4l2codecs: Always chain up to parent decide_allocation function"The following discussion from !4630 should be addressed:
- [ ] @ndufresne started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4630#note_1912472): (+1 comment)
> Does mpeg2 needs this too ?The following discussion from !4630 should be addressed:
- [ ] @ndufresne started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4630#note_1912472): (+1 comment)
> Does mpeg2 needs this too ?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2673How to make a delay (hopefully, few seconds) in a sub-pipeline while the othe...2023-06-15T22:59:44ZbkimHow to make a delay (hopefully, few seconds) in a sub-pipeline while the other sub-pipeline keeps processing as it does, in which those two sub ones receives identical video data from the same sourceHi,
I am trying to figure out how to make a delay (about few seconds, e.g., 5 sec in the sample below) on a sub-pipeline while the other sub-pipeline keeps processing as it does. Here, those two sub-pipelines use the same source by bran...Hi,
I am trying to figure out how to make a delay (about few seconds, e.g., 5 sec in the sample below) on a sub-pipeline while the other sub-pipeline keeps processing as it does. Here, those two sub-pipelines use the same source by branching with tee element as below.
In order to give a delay, I configure the property of min-threshold*** in queue element, however it doesn't work as expected. The result of running the pipeline below just shows two renderers which are both in stuck.
How can I give a delay only in a sub pipeline while keeping other pipeline process without delay?
The following link wasn't helpful for now
: https://stackoverflow.com/questions/16977233/pipeline-gstremer-video-streaming-with-delay
```
gst-launch-1.0 -v videotestsrc ! clockoverlay ! tee name=t ! videoconvert ! queue max-size-buffers=0 max-size-time=0 max-size-bytes=0 min-threshold-time=5000000000 ! videoconvert ! autovideosink t. ! queue ! videoconvert ! autovideosink
```
![notworking_queue_delay_on_a_branch_samesrc](/uploads/d601a6c5c4ff2cbb0ad36ed228768077/notworking_queue_delay_on_a_branch_samesrc.png)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2672webrtcbin: error when receiving "application" in stream2023-06-15T08:13:17ZHugo Svirakwebrtcbin: error when receiving "application" in streamIt seems the data-channel "application" merges with the video stream which effectively causes nicesrc to give an "Internal data stream error".
A work around we had was removing "application" from the SDP description, which worked fine t...It seems the data-channel "application" merges with the video stream which effectively causes nicesrc to give an "Internal data stream error".
A work around we had was removing "application" from the SDP description, which worked fine to fix the issue in the short term. But now the other end wants this channel back.https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/119Gstreamer Android Not Working With Android Cmake Project2023-06-14T11:53:56ZM. Usama LiaqatGstreamer Android Not Working With Android Cmake Projecti have an android cmake project i want to use gstreaemr in it using cmake. but unfortunately i am unable to find any solution and gstreamer examples are still in old mk files architecture. i need CMakeLists.txt. kindly update your projec...i have an android cmake project i want to use gstreaemr in it using cmake. but unfortunately i am unable to find any solution and gstreamer examples are still in old mk files architecture. i need CMakeLists.txt. kindly update your project examples according to cmakehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2668gstreamer-1.22 with cudaconvert problem2023-06-15T14:45:32ZArthur Khairullingstreamer-1.22 with cudaconvert problemHello. My question is about gstreamer + cudaconvert.
Current situation:
We have a camera, and we get a stream from it with 1920 * 1080 dimensions. And we use 3 channels. So the size of the frame should be 1920 * 1080 * 3 = 6220800 bytes...Hello. My question is about gstreamer + cudaconvert.
Current situation:
We have a camera, and we get a stream from it with 1920 * 1080 dimensions. And we use 3 channels. So the size of the frame should be 1920 * 1080 * 3 = 6220800 bytes.
When i use gstreamer 1.20, i can use a such pipeline part ```“appsrc name=source%d ! h264parse ! nvh264dec ! cudaconvert ! video/x-raw(memory:CUDAMemory), format=(string)BGR ! appsink name=sink%d emit-signals=true async=false sync=false”``` and after getting the frame using gstreamer api i have a frame with size which equals to 6220800 bytes.
When i use gstreamer 1.22 with the same pipeline part, after getting the frame using gstreamer api i have a frame with size which equals to 6635520 bytes.
Why there is such strange situation with a frame size.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2666Tests elements_rtpbin_buffer_list and elements_rtpulpfec fails on ARMv72023-11-15T11:21:01ZMarius BakkeTests elements_rtpbin_buffer_list and elements_rtpulpfec fails on ARMv7Hello,
Running the test suite with Meson on ARMv7 causes two test failures.
```
The output from the failed tests:
...Hello,
Running the test suite with Meson on ARMv7 causes two test failures.
```
The output from the failed tests:
51/99 elements_rtpbin_buffer_list FAIL 0.42 s (exit status 1)
--- command ---
GST_PLUGIN_SYSTEM_PATH_1_0='' CK_DEFAULT_TIMEOUT='20' GST_PLUGIN_LOADING_WHITELIST='gstreamer:gst-plugins-base:gst-plugins-good@/tmp/guix-build-gst-plugins-good-1.16.2.drv-0/build' GST_PLUGIN_PATH_1_0='/tmp/guix-build-gst-plugins-good-1.16.2.drv-0/build:/gnu/store/xnb7x6i43b52d507kzfspn99nl4j02wq-gstreamer-1.16.2/lib/gstreamer-1.0:/gnu/store/bbk41hqg3lj61xhvkzmrnrf2r5r73pxj-gst-plugins-base-1.16.2/lib/gstreamer-1.0' GST_STATE_IGNORE_ELEMENTS='aasink autoaudiosrc autoaudiosink autovideosrc autovideosink cacasink cairotextoverlay gtkglsink gtksink jackaudiosrc jackaudiosink osssrc osssink osxaudiosink osxaudiosrc osxvideosrc osxvideosink pulsesink pulsesrc pulsemixer v4l2src' GST_REGISTRY='/tmp/guix-build-gst-plugins-good-1.16.2.drv-0/build/tests/check/elements_rtpbin_buffer_list.registry' GSETTINGS_BACKEND='memory' /tmp/guix-build-gst-plugins-good-1.16.2.drv-0/build/tests/check/elements_rtpbin_buffer_list
--- stdout ---
Running suite(s): BufferList
0%: Checks: 1, Failures: 0, Errors: 1
../gst-plugins-good-1.16.2/tests/check/elements/rtpbin_buffer_list.c:151:E:general:test_bufferlist:0: (after this point) Received signal 7 (Bus error)
Check suite bufferlist ran in 0.014s (tests failed: 1)
-------
60/99 elements_rtpulpfec FAIL 0.57 s (exit status 5)
--- command ---
GST_PLUGIN_SYSTEM_PATH_1_0='' CK_DEFAULT_TIMEOUT='20' GST_PLUGIN_LOADING_WHITELIST='gstreamer:gst-plugins-base:gst-plugins-good@/tmp/guix-build-gst-plugins-good-1.16.2.drv-0/build' GST_REGISTRY='/tmp/guix-build-gst-plugins-good-1.16.2.drv-0/build/tests/check/elements_rtpulpfec.registry' GST_PLUGIN_PATH_1_0='/tmp/guix-build-gst-plugins-good-1.16.2.drv-0/build:/gnu/store/xnb7x6i43b52d507kzfspn99nl4j02wq-gstreamer-1.16.2/lib/gstreamer-1.0:/gnu/store/bbk41hqg3lj61xhvkzmrnrf2r5r73pxj-gst-plugins-base-1.16.2/lib/gstreamer-1.0' GST_STATE_IGNORE_ELEMENTS='aasink autoaudiosrc autoaudiosink autovideosrc autovideosink cacasink cairotextoverlay gtkglsink gtksink jackaudiosrc jackaudiosink osssrc osssink osxaudiosink osxaudiosrc osxvideosrc osxvideosink pulsesink pulsesrc pulsemixer v4l2src' GSETTINGS_BACKEND='memory' /tmp/guix-build-gst-plugins-good-1.16.2.drv-0/build/tests/check/elements_rtpulpfec
--- stdout ---
Running suite(s): rtpfec
72%: Checks: 18, Failures: 0, Errors: 5
../gst-plugins-good-1.16.2/tests/check/elements/rtpulpfec.c:295:E:general:rtpulpfecdec_recovered_from_many:0: (after this point) Received signal 7 (Bus error)
../gst-plugins-good-1.16.2/tests/check/elements/rtpulpfec.c:295:E:general:rtpulpfecdec_recovered_from_many:1: (after this point) Received signal 7 (Bus error)
../gst-plugins-good-1.16.2/tests/check/elements/rtpulpfec.c:295:E:general:rtpulpfecdec_recovered_from_many:2: (after this point) Received signal 7 (Bus error)
../gst-plugins-good-1.16.2/tests/check/elements/rtpulpfec.c:295:E:general:rtpulpfecdec_recovered_from_many:3: (after this point) Received signal 7 (Bus error)
../gst-plugins-good-1.16.2/tests/check/elements/rtpulpfec.c:463:E:general:rtpulpfecdec_recovered_using_recovered_packet:0 (after this point) Received signal 7 (Bus error)
Check suite rtpfec ran in 0.182s (tests failed: 5)
-------
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2665asfmux: crash due to memory alignment error on 32-bit ARM platforms2023-11-07T13:55:54ZZach van Rijnasfmux: crash due to memory alignment error on 32-bit ARM platformsFound in gst-plugins-bad `1.20.3` but appears to be present in the [latest code](
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/gst/asfmux/gstasfobjects.c#L312):
```
$ CK_FORK=no meson test e...Found in gst-plugins-bad `1.20.3` but appears to be present in the [latest code](
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/gst/asfmux/gstasfobjects.c#L312):
```
$ CK_FORK=no meson test elements_asfmux -v --gdb
ninja: Entering directory `/usr/src/packages/user/gst-plugins-bad/src/gst-plugins-bad-1.20.2/build'
ninja: no work to do.
1/1 elements_asfmux RUNNING
>>> GST_REGISTRY=/usr/src/packages/user/gst-plugins-bad/src/gst-plugins-bad-1.20.2/build/tests/check/elements_asfmux.registry GST_PLUGIN_SYSTEM_PATH_1_0='' GST_PLUGIN_PATH_1_0=/usr/src/packages/user/gst-plugins-bad/src/gst-plugins-bad-1.20.2/build:/usr/lib/gstreamer-1.0:/usr/lib/gstreamer-1.0 GST_STATE_IGNORE_ELEMENTS='' CK_DEFAULT_TIMEOUT=20 MALLOC_PERTURB_=147 GST_PLUGIN_SCANNER_1_0=/usr/libexec/gstreamer-1.0/gst-plugin-scanner GST_PLUGIN_LOADING_WHITELIST=gstreamer:gst-plugins-base:gst-plugins-good:gst-plugins-ugly:gst-libav:libnice:gst-plugins-bad@/usr/src/packages/user/gst-plugins-bad/src/gst-plugins-bad-1.20.2/build gdb --quiet --args /usr/src/packages/user/gst-plugins-bad/src/gst-plugins-bad-1.20.2/build/tests/check/elements_asfmux
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
Reading symbols from /usr/src/packages/user/gst-plugins-bad/src/gst-plugins-bad-1.20.2/build/tests/check/elements_asfmux...
(gdb) run
Starting program: /usr/src/packages/user/gst-plugins-bad/src/gst-plugins-bad-1.20.2/build/tests/check/elements_asfmux
[Detaching after fork from child process 749116]
Running suite(s): asfmux
Program received signal SIGBUS, Bus error.
0xf79cc36c in gst_asf_put_guid (buf=buf@entry=0xf7a6a096 "", guid=...) at ../gst/asfmux/gstasfobjects.c:318
318 *aux16 = GUINT16_TO_LE (guid.v2);
(gdb) bt
#0 0xf79cc36c in gst_asf_put_guid (buf=buf@entry=0xf7a6a096 "", guid=...) at ../gst/asfmux/gstasfobjects.c:318
#1 0xf79ca7c2 in gst_asf_mux_write_file_properties (buf=<synthetic pointer>, asfmux=0xf7c08018) at ../gst/asfmux/gstasfmux.c:656
#2 gst_asf_mux_start_file (asfmux=0xf7c08018) at ../gst/asfmux/gstasfmux.c:1347
#3 gst_asf_mux_collected (collect=0xf799c491, data=0xf7c08018) at ../gst/asfmux/gstasfmux.c:1966
#4 0xf799c7fe in ?? () from /usr/lib/libgstbase-1.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
...
(gdb) disas
Dump of assembler code for function gst_asf_put_guid:
0xf79cc354 <+0>: sub sp, #8
0xf79cc356 <+2>: push {r4, r7}
0xf79cc358 <+4>: add r7, sp, #0
0xf79cc35a <+6>: add.w r12, r7, #8
0xf79cc35e <+10>: ldrd r1, r4, [r7, #16]
0xf79cc362 <+14>: stmia.w r12, {r2, r3}
0xf79cc366 <+18>: ldr r3, [r7, #12]
0xf79cc368 <+20>: rev r4, r4
0xf79cc36a <+22>: rev r1, r1
=> 0xf79cc36c <+24>: strd r2, r3, [r0]
0xf79cc370 <+28>: strd r4, r1, [r0, #8]
0xf79cc374 <+32>: mov sp, r7
0xf79cc376 <+34>: pop {r4, r7}
0xf79cc378 <+36>: add sp, #8
0xf79cc37a <+38>: bx lr
```
There may be other places in this file (or in the project) where this issue occurs.
See also:
* https://git.adelielinux.org/adelie/packages/-/issues/1040
* gstreamer/gst-plugins-good#689
* gstreamer/gstreamer!4842https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2657Creating a new MR with merge assigned starts the CI2023-06-23T13:21:20ZEdward HerveyCreating a new MR with merge assigned starts the CIWhen creating a new MR, if you assign @gstreamer-merge-bot to it, the CI will be started *before* it has actually re-written the commits and waited its turn.
Expected behaviour : Assigning the bot initially should work as if it was assi...When creating a new MR, if you assign @gstreamer-merge-bot to it, the CI will be started *before* it has actually re-written the commits and waited its turn.
Expected behaviour : Assigning the bot initially should work as if it was assigned *after* the MR was createdhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/998gst_element_send_event(element, gst_event_new_eos()) takes a long time to return2023-07-27T10:07:40ZDivya Sampath Kumargst_element_send_event(element, gst_event_new_eos()) takes a long time to returnHello,
I have a gstreamer pipeline: appsrc -> identity -> customsink. The identity element is essentially being used as a heartbeat to track if data is flowing from appsrc to customsink. If there is no data flow for 45 seconds (i.e no h...Hello,
I have a gstreamer pipeline: appsrc -> identity -> customsink. The identity element is essentially being used as a heartbeat to track if data is flowing from appsrc to customsink. If there is no data flow for 45 seconds (i.e no heartbeats), I send an EOS event using gst_element_send_event(sink, gst_event_new_eos()). However, this takes 15 minutes to return or maybe more in some cases. I am trying to understand what this event usually waits on and what are the possible scenarios it can hang. I also have a buffer callback on collect pads in customsink that sends an EOS message on the bus when the received buffer is NULL.
How can I gracefully terminate the pipeline in this design where the application is sending the EOS because it detected no data flow for 45 seconds.
More about the application:
The application has a Java, JNI and a C++ component. A start() method is invoked in the Java layer that translates to start() in C++ via JNI. This method set GST pipeline to PLAYING state. At any point, if the identity element is not hit in the pipeline (indicating no heartbeats), a stop() call is made to stop the pipeline. This translates the same way as the start() call. In the stop() call this is the order of things:
```
gst_element_send_event(sink, gst_event_new_eos());
gst_element_set_state(pipeline, GST_STATE_NULL);
g_main_loop_quit(main_loop);
gst_bus_remove_signal_watch(bus);
gst_object_unref(bus);
gst_object_unref(pipeline);
```
In the custom sink, I have a callback registered that listens in on the incoming buffer on the collect pad:
`gst_collect_pads_set_buffer_function (collect,GST_DEBUG_FUNCPTR (gst_handle_buffer), sink);`
In this callback, I am checking if the incoming buffer is NULL to detect EOS and take the necessary action like this:
```
if (buffer == NULL && data == NULL) {
LOG_INFO("Received event);
// Take necessary library action
LOG_INFO("Sending eos");
// send out eos message to gstreamer bus
message = gst_message_new_eos (GST_OBJECT_CAST (sink));
gst_element_post_message (GST_ELEMENT_CAST (sink), message);
ret = GST_FLOW_EOS;
}
```
My hunch is this pad is still receiving data because of which the gst_element_send_event is taking a long time to get processed. But if there was data, identity element should have been hit in the buffer flow, unless it is getting optimized out since the element does nothing with the buffer.
I have collected some verbose Gstreamer logs. Hope it helps in providing some pointers on what could be going on. In the attached log file, the EOS event seems to be resolving after 2 minutes.https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/110gStreamer iOS libs missing distribution package2023-06-12T07:38:49ZRaktim BoragStreamer iOS libs missing distribution packageI'm new to gStreamer development so this might be not a bug but a lack of understanding on my behalf.
I followed the installation instructions from [here](https://gstreamer.freedesktop.org/documentation/installing/for-ios-development.ht...I'm new to gStreamer development so this might be not a bug but a lack of understanding on my behalf.
I followed the installation instructions from [here](https://gstreamer.freedesktop.org/documentation/installing/for-ios-development.html?gi-language=c) and download the iOS package 1.22.3 from [here](https://gstreamer.freedesktop.org/data/pkg/ios/1.22.3/).
On unpacking the files I can see that the `Libraries` point to the `lib` folder.
```lrwxr-xr-x 1 rbrk staff 3 Jun 7 18:15 Versions/Current/Libraries -> lib```
But the `lib` folder seems to be missing in the downloaded package.
In comparison, the macOSX gStreamer package (runtime + development) downloaded from [here](https://gstreamer.freedesktop.org/download/#macos) installs the `lib` folder as well.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2653va: vapostproc incorrect crop results2023-06-21T22:55:21ZU. Artie Eoffva: vapostproc incorrect crop results### Describe your issue
vapostproc cropping with passthrough disabled does not work correctly when the upstream buffer is not importable (i.e. not from a vapool). For example, left crop actually crops the right.
#### Expected Behavior...### Describe your issue
vapostproc cropping with passthrough disabled does not work correctly when the upstream buffer is not importable (i.e. not from a vapool). For example, left crop actually crops the right.
#### Expected Behavior
Image is cropped correctly:
![1step](/uploads/4f5fa83f8854cc1cd66ca07dc0dc7c98/1step.jpg)
#### Observed Behavior
Image is cropped incorrectly:
![2step](/uploads/75d1e48b6455530eff12725a692bda77/2step.jpg)
#### Reproduce Steps
```
gst-launch-1.0 -vf videotestsrc num-buffers=100 ! video/x-raw,format=NV12,width=320,height=240 \
! filesink location=test.yuv
gst-launch-1.0 -vf filesrc location=test.yuv ! rawvideoparse format=nv12 width=320 height=240 \
! videocrop left=100 ! vapostproc disable-passthrough=true ! autovideosink
```
I added a ```GST_DEBUG_OBJECT (self, "crop %p enabled:%d", crop, self->crop_enabled);``` in ```gstvafilter.c::_fill_va_sample``` function and for this use-case it prints:
```
vafilter gstvafilter.c:1556:_fill_va_sample:<vafilter2> crop (nil) enabled:32
```
#### Additional Information
The following command-line works correctly.
```
gst-launch-1.0 -vf videotestsrc num-buffers=100 ! video/x-raw,format=NV12,width=320,height=240 \
! videocrop left=100 ! vapostproc disable-passthrough=true ! autovideosink
```
...and with added debug information as above, it prints
```
vafilter gstvafilter.c:1556:_fill_va_sample:<vafilter2> crop 0x7f5474067f20 enabled:32
```
cc: @vjaquez @He_Junyanhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2652gst_ptp_init doesn't accept uint64 params.2023-06-13T01:13:52ZAdam Woolhethergst_ptp_init doesn't accept uint64 params.### 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/ -->
#### Expected Behavior
<!-- What did you expect to happen -->
Assign my PTP Clock ID as a a parameter to `gst_ptp_init`
#### Observed Behavior
Received this error at runtime
Have tried uint64_t variant, converting to hexadacimal, typecasting to guint64.
```
** (gst-ptp-helper:4093872): ERROR **: 18:15:21.014: Error parsing options: Integer value ?0xd0880c012a420008? for -c out of range
```
#### Setup
- **Operating System:**
Linux 6.1.21-v8+ # 1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 unknown unknown GNU/Linux
- **Device:** Computer
- **GStreamer Version:**
Package: libgstreamer1.0-dev
Version: 1.18.4-2.1
Priority: optional
Section: libdevel
Source: gstreamer1.0
- **Command line:**
bash
### Steps to reproduce the bug
```
guint64 my_ptp = 15026273355865128968;
if (!gst_ptp_init(my_ptp, NULL)) {
g_printerr("failed to initiate ptp clock in gstreamer\n");
goto exit;
}
```
or hexadecimal variant: 0xD04758D8C39CC850
### How reproducible is the bug?
Always
### Additional Informationhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2651omxh264enc profile negotiation fails with non fixated caps2023-07-25T13:06:02ZJames Kentomxh264enc profile negotiation fails with non fixated caps### omxh264enc profile negotiation fails if the caps are not fixed
if trying to use the CABAC entropy encoding the encoder needs to be producing profile "high" or above, if the encoder is given a pixel format that forces this (e.g. NV16 ...### omxh264enc profile negotiation fails if the caps are not fixed
if trying to use the CABAC entropy encoding the encoder needs to be producing profile "high" or above, if the encoder is given a pixel format that forces this (e.g. NV16 or NV12_10LE32) then everything works. however if given a format supported by main or below such as NV12 we have to set output caps to negotiate the profile.
if the caps contain a list of accepted values such as:
`video/x-h264,alignment=nal,profile={ high, high-10, high-4:2:2 }`
then the profile is not fed to the omx layer, so the encoder chooses an appropriate profile instead. when this is then fed back the caps are checked and negotiation fails when they don't match.
I believe this happens here:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-omx/omx/gstomxh264enc.c#L695
#### Expected Behavior
caps should negotiate the profile to one of the values in the list
#### Observed Behavior
the caps are rejected once the encoder starts producing buffers:
0:00:07.681852659 368 0x558abecd80 WARN GST_CAPS gstpad.c:5757:pre_eventfunc_check:<vid_enc_caps_0:sink> caps video/x-h264, stream-format=(string)byte-stream, alignment=(string)nal, profile=(string)constrained-baseline, level=(string)3.1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, width=(int)1280, height=(int)720, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)bt709 not accepted
#### Setup
- linux
- Xilinx ZCU106
- 1.20.5
- gst-launch-1.0 videotestsrc ! video/x-raw,width=320,height=240,framerate=24/1,format=NV12 ! omxh264enc entropy-mode=CABAC ! video/x-h264,profile={ high, high-10, high-4:2:2 } ! fakesink
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. open terminal
2. type `gst-launch-1.0 videotestsrc ! video/x-raw,width=320,height=240,framerate=24/1,format=NV12 ! omxh264enc entropy-mode=CABAC ! video/x-h264,profile={ high, high-10, high-4:2:2 } ! fakesink`
### How reproducible is the bug?
Always happens for NV12 format if a list of profiles is provided in the caps. if a single profile is provided then negotiation works as expected
### Solutions you have tried
adding `peercaps = gst_caps_fixate (peercaps);` before [gstomxh264enc.c#L694](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-omx/omx/gstomxh264enc.c#L694) fixes the issue for my use case, but I'm not convinced it will be correct for all scenarioshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2649Follow-up from "basetsmux: Fix language crash when ts_pad->stream is NULL"2023-06-12T10:26:17ZJan Alexander SteffensFollow-up from "basetsmux: Fix language crash when ts_pad->stream is NULL"The following discussion from !4785 should be addressed:
- [x] @heftig started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4785#note_1946865): (+1 comment)
> I just noticed this says "Matrosk...The following discussion from !4785 should be addressed:
- [x] @heftig started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4785#note_1946865): (+1 comment)
> I just noticed this says "Matroska". Was this copied from `matroskamux`?
>
> I think MPEG-TS would prefer the ISO 639-2T codes.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2647API doc issues in new API2023-06-07T08:32:12ZEdward HerveyAPI doc issues in new API```
../subprojects/gstreamer/gst/gstutils.c:3675: Warning: Gst: gst_util_simplify_fraction: unknown parameter 'b' in documentation comment, should be one of 'denominator', 'numerator', 'threshold'
../subprojects/gstreamer/gst/gstutils.c:...```
../subprojects/gstreamer/gst/gstutils.c:3675: Warning: Gst: gst_util_simplify_fraction: unknown parameter 'b' in documentation comment, should be one of 'denominator', 'numerator', 'threshold'
../subprojects/gstreamer/gst/gstutils.c:3674: Warning: Gst: gst_util_simplify_fraction: unknown parameter 'a' in documentation comment, should be one of 'denominator', 'numerator', 'threshold'
../subprojects/gstreamer/gst/gstutils.c:3677: Warning: Gst: gst_util_simplify_fraction: unknown parameter 'threashold' in documentation comment, should be one of 'denominator', 'numerator', 'threshold'
../subprojects/gstreamer/gst/gstutils.c:3688: Warning: Gst: gst_util_simplify_fraction: invalid return annotation
```
cc @mgrzeschik