GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-06-21T09:02:51Zhttps://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/2684Video and audio freeze when seeking an AVI file2024-02-10T18:48:30ZFrom SkyVideo and audio freeze when seeking an AVI fileWhen playing an AVI file (container #0: Audio Video Interleave (AVI), video #1: MPEG-4 Video (Simple Profile), audio #2: MPEG-1 Layer 3 (MP3)), it will be well if play continuously, but seeking play position may cause video freezes, whil...When playing an AVI file (container #0: Audio Video Interleave (AVI), video #1: MPEG-4 Video (Simple Profile), audio #2: MPEG-1 Layer 3 (MP3)), it will be well if play continuously, but seeking play position may cause video freezes, while audio becomes silent or sometimes stuttering. This occurs with gnome's totem player, gst-play-1.0, and some simple pipeline with avidemux, avdec_mpeg4, avdec_mp3.
There's no such issue when play video only, but it will be stutter seeking when only play audio from AVI file. Change avdec_mp3 to mpg123audiodec does not solve the problem. I'm not sure which plugin cause the problem, but it seems only relate to AVI. There's no problem when play mp3 audio file and other video format.
Same video files play well with ffplay.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/gst-plugins-bad/-/issues/1775SRT simple loopback test pipeline not working_gstreamer_v_1.16.32023-07-18T15:57:01ZSujin KimSRT simple loopback test pipeline not working_gstreamer_v_1.16.3Hi,
Trying to do some SRT loopback test at NVIDIA AGX Orin which is using gstreamer v1.16.3.
However with no errors following pipeline is not working properly. Cannot see any video displays..
Encode : gst-launch-1.0 v4l2src io-mode=4 d...Hi,
Trying to do some SRT loopback test at NVIDIA AGX Orin which is using gstreamer v1.16.3.
However with no errors following pipeline is not working properly. Cannot see any video displays..
Encode : gst-launch-1.0 v4l2src io-mode=4 device=/dev/video0 do-timestamp=true ! 'video/x-raw, width=1920, height=1088, framerate=60/1, format=BGRx' ! nvvidconv ! 'video/x-raw(memory:NVMM), ftrate=4000000 ! h265parse ! mpegtsmux ! srtsink uri=srt://:8888
Decode : gst-launch-1.0 srtsrc uri=srt://127.0.0.1:8888 ! tsparse ! tsdemux ! h265parse ! nvv4l2decoder ! nvvidconv ! queue ! ximagesink
Can any one give me some advises?
Am I using MPEG-TS MUX/DEMUX wrong?
P.S. Loop back test over UDP using udpsink and udpsrc works finehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2682flacparse: Seeking in variable blocksize FLAC file fails, timestamp is wrong2023-06-21T05:16:46ZMartijn van Beurdenflacparse: Seeking in variable blocksize FLAC file fails, timestamp is wrongWhen playing [this file](https://github.com/ietf-wg-cellar/flac-test-files/blob/main/subset/24%20-%20variable%20blocksize%20file%20created%20with%20flake%20revision%20264.flac) with gst-play-1.0, gst 1.22.3, FLAC 1.4.2, the position stay...When playing [this file](https://github.com/ietf-wg-cellar/flac-test-files/blob/main/subset/24%20-%20variable%20blocksize%20file%20created%20with%20flake%20revision%20264.flac) with gst-play-1.0, gst 1.22.3, FLAC 1.4.2, the position stays at 0:00:00.0, seeking forward results in immediate termination of playback and seeking backwards results in seeking all the way to the start of the file
#### Setup
- **Operating System:** OpenSUSE Tumbleweed 20230614-0
- **Device:** Computer
- **GStreamer Version:** 1.22.3
- **Command line:** gst-play-1.0 24\ -\ variable\ blocksize\ file\ created\ with\ flake\ revision\ 264.flac
### Steps to reproduce the bug
1. open terminal
2. type `gst-play-1.0 24\ -\ variable\ blocksize\ file\ created\ with\ flake\ revision\ 264.flac`
3. observe timestamp not increasing
4. seek backwards
5. observe playback starting at beginning of file
6. seek forwards
7. observe termination of playback
### How reproducible is the bug?
Always
### Solutions you have tried
I can't seem to find the location in the source code where the timestamp is updated, nor figure out how seeking is performed exactly.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2681Better Audio Clock Skew Correction2023-06-23T11:25:31ZJamie WBetter Audio Clock Skew CorrectionCurrently, GStreamer has support for `skew` and `resample` methods (and bring-your-own) of correcting clock skew.
However, these are not good enough for professional use, as - for instance - GStreamer struggles on its own to reliably p...Currently, GStreamer has support for `skew` and `resample` methods (and bring-your-own) of correcting clock skew.
However, these are not good enough for professional use, as - for instance - GStreamer struggles on its own to reliably play out a live audio stream (even locally generated) without re-syncing in a very noticable way (#317, gst-plugins-base#80, https://narkive.com/oUoa2zeg).
This can be observed by running these really simple pipelines on the same machine (and waiting for 5 - 30 minutes - depending on how accurate the clock in your sound card is - to observe a glitch or drop-out):
# Terminal 1
gst-launch-1.0 audiotestsrc wave=sine freq=1000 volume=0.1 is-live=1 do-timestamp=1 \
! audio/x-raw,sample-rate=48000,channels=2,format=S16LE \
! queue \
! srtsink uri="srt://127.0.0.1:9001?mode=caller" sync=true wait-for-connection=0
# Terminal 2
gst-launch-1.0 srtsrc uri="srt://127.0.0.1:9001?mode=listener" do-timestamp=1 keep-listening=1 \
! rawaudioparse pcm-format=s16le \
! queue \
! alsasink
The resample method produces very audible artefacts and only works when sync=false on the sink, and the `skew` method drops buffers (skips) or introduces noticable underruns when the drift reaches a certain threshold.
I note the PipeWire project implements a Delay-Locked Loop and good adaptive resampling that could be re-purposed for use inside GStreamer. This can be done inside a project by using a custom `slave-method` on a sink (and indeed an easier but limited workaround on Linux is to play out to pipewiresink and let that handle synchronisation). But this is something I'd really want to see GStreamer do natively/better in the GstAudioBaseSink.
I'd love to have a go at this but admittedly I'm not a strong C developer.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2680nvcodec: No way to crop cuda memory without device transfer2023-06-16T19:36:03ZBrandon Oglenvcodec: No way to crop cuda memory without device transferI have a gstreamer pipeline where I am trying to keep all operations on GPU to improve throughput and ideally reduce latency. In broad strokes this pipeline fetches some segment of h264 video, crops, resizes and finally encodes back to h...I have a gstreamer pipeline where I am trying to keep all operations on GPU to improve throughput and ideally reduce latency. In broad strokes this pipeline fetches some segment of h264 video, crops, resizes and finally encodes back to h264. I have hit a roadblock at the moment where it does not seem possible to crop the video without a transfer back to host memory where I can use the `videocrop` element. I noticed in the gst-plugins-bad nvenc plugin directory, the `cuda-converter.c` file implements most of the kernel functions for the plugin. This file has a list of TODO's including cropping, is there any ETA to such functionality becoming available?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2679tsdemux sends gap event before segment event on sparse streams2023-06-16T11:29:45ZBenjamin Muzaltsdemux sends gap event before segment event on sparse streamstsdemux sends a new gap event on sparse streams with timesamp=0 in gst_ts_demux_update_program() and gst_ts_demux_program_started()
This happens before the segment event is sent out.
Downstream from tsdemux, this causes an ugly critical...tsdemux sends a new gap event on sparse streams with timesamp=0 in gst_ts_demux_update_program() and gst_ts_demux_program_started()
This happens before the segment event is sent out.
Downstream from tsdemux, this causes an ugly critical warning in GstAggregator based elements when they try to clip the event without a segment.
If streams always need a gap event at the beginning of sparse streams, maybe the gap event should be sent at the end of calculate_and_push_newsegment() using the start of the segment for the timestamp instead of a timestamp of 0?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2678vpxenc (vp8 and vp9) don't seem to respect calculated bitrate2023-06-18T00:20:00Zkyteinskyvpxenc (vp8 and vp9) don't seem to respect calculated bitrate### Describe your issue
vp8enc and vp9enc use the correct bitrate when `target-bitrate` is set to a fixed number but do not calculate the same when `target-bitrate = 0` and `bits-per-pixel = 0.1`.
#### Expected Behavior
The bitrate of t...### Describe your issue
vp8enc and vp9enc use the correct bitrate when `target-bitrate` is set to a fixed number but do not calculate the same when `target-bitrate = 0` and `bits-per-pixel = 0.1`.
#### Expected Behavior
The bitrate of the encoder to be calculated based on the `bits-per-pixel` value.
#### Observed Behavior
The bitrate falls back to the default 256000 value when `target-bitrate = 0` and `bits-per-pixel = 0.1`.
#### Setup
- **Operating System:** Fedora 37
- **Device:** Computer
- **GStreamer Version:** 1.20.5
- **Command line:** (I am using it in a C project)
### Steps to reproduce the bug
1. Create a sample pipeline using vp8enc or vp9enc in C
2. Set the properties `target-bitrate = 0` and `bits-per-pixel = 0.1`
3. Compile and launch the program with the `GST_DEBUG_DUMP_DOT_DIR` environment variable set (/tmp for example)
4. Use the following line to dump a dot file
`GST_DEBUG_BIN_TO_DOT_FILE (bin, GST_DEBUG_GRAPH_SHOW_ALL, "bin-file");`
5. Generate an image from the dumped file
`dot -Tpng -oimage.png bin-file.dot`
This image file shows the properties set for the encoder.
### How reproducible is the bug?
Always
### Screenshots if relevant
![pipeline image](/uploads/be4899ec0a2df4dea3b195ae2fbfd1ee/image.png)
### Solutions you have tried
Knew it wouldn't work, but still tried setting `target-bitrate` to 1, the result was it was set to 0. The video output was non-existent after this as expected.
### Related non-duplicate issues
### Additional Informationhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2677AMF amfh264enc gop-size2023-06-16T02:29:12ZpigeatgarlicAMF amfh264enc gop-size### 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 -->
#### Observed Behavior
Our application using amf and nvcodec, which require the encoder to disable IDR frame generation periodically (by setting gop-size to -1 or 0), and instead call gst_video_event_new_upstream_force_key_unit.
However, for AMFh264enc, when we set AMF_VIDEO_ENCODER_IDR_PERIOD to 0, IDR still be generated every 4sec (~gop-size=200), I Frame did not generated when we call AMF_VIDEO_ENCODER_FORCE_PICTURE_TYPE.
I highly doubt that this issue cause by AMF it self
#### Setup
- **Operating System:** Window 10
- **Device:** Virtual Machine with AMD v520 GPU
- **GStreamer Version:** 1.22.3
- **Command line:**
### 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?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
### Screenshots if relevant
![image](/uploads/c9c8adfcdd07d0916866972ec0d41601/image.png)
### Solutions you have tried
### 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/2676ci: Windows SDK needs to be updated2023-06-16T09:28:35ZMaurizio Buratoci: Windows SDK needs to be updatedfor testing purpose i downloaded the latest artifacts from here: https://gitlab.freedesktop.org/gstreamer/cerbero/-/jobs/43863575/artifacts/download?file_type=archive but d3d11screencapturesrc element in this build is obsolete and is mis...for testing purpose i downloaded the latest artifacts from here: https://gitlab.freedesktop.org/gstreamer/cerbero/-/jobs/43863575/artifacts/download?file_type=archive but d3d11screencapturesrc element in this build is obsolete and is missing most of the properties that was added in the last year (ex: no capture-api property)
```
gst-inspect-1.0 d3d11screencapturesrc
Factory Details:
Rank none (0)
Long-name Direct3D11 Screen Capture Source
Klass Source/Video
Description Captures desktop screen
Author Seungha Yang <seungha@centricular.com>
Documentation https://gstreamer.freedesktop.org/documentation/d3d11/d3d11screencapturesrc.html
Plugin Details:
Name d3d11
Description Direct3D11 plugin
Filename D:\GB32\gstreamer\1.0\msvc_x86_64\lib\gstreamer-1.0\gstd3d11.dll
Version 1.23.0.1
License LGPL
Source module gst-plugins-bad
Documentation https://gstreamer.freedesktop.org/documentation/d3d11/
Binary package GStreamer Bad Plug-ins git
Origin URL Unknown package origin
GObject
+----GInitiallyUnowned
+----GstObject
+----GstElement
+----GstBaseSrc
+----GstD3D11ScreenCaptureSrc
Pad Templates:
SRC template: 'src'
Availability: Always
Capabilities:
video/x-raw(memory:D3D11Memory)
format: BGRA
width: [ 1, 16384 ]
height: [ 1, 16384 ]
framerate: [ 0/1, 2147483647/1 ]
pixel-aspect-ratio: 1/1
video/x-raw
format: BGRA
width: [ 1, 16384 ]
height: [ 1, 16384 ]
framerate: [ 0/1, 2147483647/1 ]
pixel-aspect-ratio: 1/1
Element has no clocking capabilities.
Element has no URI handling capabilities.
Pads:
SRC: 'src'
Pad Template: 'src'
Element Properties:
blocksize : Size in bytes to read per buffer (-1 = default)
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967295 Default: 4096
crop-height : Height of screen capture area (0 = maximum)
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967295 Default: 0
crop-width : Width of screen capture area (0 = maximum)
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967295 Default: 0
crop-x : Horizontal coordinate of top left corner for the screen capture area
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967295 Default: 0
crop-y : Vertical coordinate of top left corner for the screen capture area
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967295 Default: 0
do-timestamp : Apply current stream time to buffers
flags: readable, writable
Boolean. Default: false
monitor-handle : A HMONITOR handle of monitor to capture
flags: readable, writable, changeable only in NULL or READY state
Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 0
monitor-index : Zero-based index for monitor to capture (-1 = primary monitor)
flags: readable, writable, changeable only in NULL or READY state
Integer. Range: -1 - 2147483647 Default: -1
name : The name of the object
flags: readable, writable
String. Default: "d3d11screencapturesrc0"
num-buffers : Number of buffers to output before sending EOS (-1 = unlimited)
flags: readable, writable
Integer. Range: -1 - 2147483647 Default: -1
parent : The parent of the object
flags: readable, writable
Object of type "GstObject"
show-cursor : Whether to show mouse cursor
flags: readable, writable
Boolean. Default: false
typefind : Run typefind before negotiating (deprecated, non-functional)
flags: readable, writable, deprecated
Boolean. Default: false
```
could you please check if the bot is compiling an old source?
i would like to test the new d3d11 stuff 1.23https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2675mp4mux reserved-max-duration property should not accept value 02023-06-15T19:00:02ZFlorent Thierymp4mux reserved-max-duration property should not accept value 0mp4mux's property documentation states that value 0 is accepted:
```
reserved-max-duration: When set to a value > 0, reserves space for index tables at the beginning of the file.
flags: accès en lecture, accès ...mp4mux's property documentation states that value 0 is accepted:
```
reserved-max-duration: When set to a value > 0, reserves space for index tables at the beginning of the file.
flags: accès en lecture, accès en écriture
Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 18446744073709551615
```
However:
```
$ gst-launch-1.0 videotestsrc is-live=true ! x264enc tune=zerolatency ! mp4mux reserved-max-duration=0 reserved-moov-update-period=30000000000 ! filesink location=/tmp/test.mp4
...
ERROR: from element /GstPipeline:pipeline0/GstMP4Mux:mp4mux0: reserved-max-duration of 0 is not allowed
Additional debug info:
../subprojects/gst-plugins-good/gst/isomp4/gstqtmux.c(3052): gst_qt_mux_start_file (): /GstPipeline:pipeline0/GstMP4Mux:mp4mux0
```
As a workaround, i used the value `-1`
```
$ LANG=C gst-launch-1.0 videotestsrc is-live=true ! x264enc tune=zerolatency ! mp4mux reserved-max-duration=-1 reserved-moov-update-period=30000000000 ! filesink location=/tmp/test.mp4
```
Why is 0 even in the accepted range ? Should the documentation not state `When set to a value >= 0` ?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/gst-plugins-rs/-/issues/376gtk4paintablesink: fails to display correctly the colors on MacOS2023-06-15T11:03:51ZStéphane Cerveauscerveau@igalia.comgtk4paintablesink: fails to display correctly the colors on MacOS### Describe your issue
The color space is incorrect using gtkpaintablesink in a GTK application and with gstreamer pipeline such
as videotestsrc ! videoconvert ! gtkpaintablesink
#### Expected Behavior
To have the right color space
##...### Describe your issue
The color space is incorrect using gtkpaintablesink in a GTK application and with gstreamer pipeline such
as videotestsrc ! videoconvert ! gtkpaintablesink
#### Expected Behavior
To have the right color space
#### Observed Behavior
The colors are not correct
#### Setup
- **Operating System:** MacOS Catalina
- **Device:** Computer
- **GStreamer Version:** 1.23.1
- **Command line:**
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system, for example: -->
1. Use GstPipelineStudio to reproduce the issue
### How reproducible is the bug?
Always
### Screenshots if relevant
![Capture_d_écran_2023-06-15_à_10.10.24](/uploads/0103834009a0e4d8a01bee2f57ed3154/Capture_d_écran_2023-06-15_à_10.10.24.png)
### Solutions you have tried
I have a try with glimagesink and this is working fine
### 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/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/cerbero/-/issues/433ci: build gst-plugins-rs in debug mode for git monorepo ci, for faster builds?2024-02-12T12:42:31ZTim-Philipp Müllertim@centricular.comci: build gst-plugins-rs in debug mode for git monorepo ci, for faster builds?Currently the gst-plugins-rs build takes a long time, especially on macOS, and is the bottleneck for any monorepo merge request.
I wonder if it would make sense to perhaps build gst-plugins-rs in debug mode instead of release mode for s...Currently the gst-plugins-rs build takes a long time, especially on macOS, and is the bottleneck for any monorepo merge request.
I wonder if it would make sense to perhaps build gst-plugins-rs in debug mode instead of release mode for such merge request pipelines?
Debug mode should be faster, but will generate larger artefacts.
Question is how much faster and how much larger are the artefacts - something to try perhaps.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/gstreamer/-/issues/2671Gstreamer Android Not Working With Android Cmake Project2023-06-14T11:53:23ZM. 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/2670mpegtsmux does not work with meta/x-klv2023-06-15T12:48:21ZAlex Cmpegtsmux does not work with meta/x-klv### The issue
mpegtsmux does not insert the data packets into the stream.
Revisiting this [issue](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1504), which exists in all mpegtsmux (since 1.16)
#### Expected Behavior
Mul...### The issue
mpegtsmux does not insert the data packets into the stream.
Revisiting this [issue](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1504), which exists in all mpegtsmux (since 1.16)
#### Expected Behavior
Multiplexing video and data packets marked as *meta/x-klv* should have them inserted into the ts stream.
#### Observed Behavior
The data pid is present in PMT, but no actuall data is inserted.
Here is a simple pipeline to reproduce the issue (packet.bin is a raw klv buffer, but can be any data for this test)
```
gst-launch-1.0 -e v4l2src device=/dev/video0 ! video/x-raw,width=640,height=480,framerate=30/1 ! videoconvert ! video/x-raw,format=I420 ! x264enc speed-preset=ultrafast tune=zerolatency bitrate=1000 ! video/x-h264,stream-format=byte-stream,alignment=au ! queue ! mpegtsmux alignment=7 name=mux mux. ! filesink sync=false location=~/home/test.ts multifilesrc do-timestamp=TRUE location=~/packet.bin loop=true ! identity sleep-time=330000 ! meta/x-klv ! queue ! mux.
```
Thanks,
Alexhttps://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 cmake