gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2024-01-16T11:12:01Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3227v4l2h264dec seems too restrictive when it comes to colorimetry caps2024-01-16T11:12:01ZMartin Dørumv4l2h264dec seems too restrictive when it comes to colorimetry capsI have a pipeline which is more or less `appsrc ! h264parse ! v4l2h264dec ! appsink`. It didn't work with certain h264 streams, and I found out it's due to colorimetry caps.
When I query the v4l2h264dec element's sink pad's caps after s...I have a pipeline which is more or less `appsrc ! h264parse ! v4l2h264dec ! appsink`. It didn't work with certain h264 streams, and I found out it's due to colorimetry caps.
When I query the v4l2h264dec element's sink pad's caps after setting the pipeline's state to playing, this is what it reports: `video/x-h264, width=(int)[ 64, 1920 ], height=(int)[ 64, 1920 ], framerate=(fraction)[ 0/1, 2147483647/1 ], stream-format=(string)byte-stream, alignment=(string)au, level=(string){ 1, 1b, 1.1, 1.2, 1.3, 2, 2.1, 2.2, 3, 3.1, 3.2, 4, 4.1, 4.2, 5, 5.1 }, profile=(string){ baseline, constrained-baseline, main, high, stereo-high, multiview-high }, colorimetry=(string){ bt601, smpte240m, bt709, 1:3:5:1, 2:4:5:2, 2:4:5:3, 1:4:7:1, 2:4:7:1, 2:4:12:8, bt2020, 2:0:0:0 }, parsed=(boolean)true`.
The relevant part here is the colorimetry: `colorimetry=(string){ bt601, smpte240m, bt709, 1:3:5:1, 2:4:5:2, 2:4:5:3, 1:4:7:1, 2:4:7:1, 2:4:12:8, bt2020, 2:0:0:0 }`. When playing the problematic h264 streams, the input caps contains `colorimetry=(string)2:4:16:3`, which isn't in the list of supported colorimetries, which causes the problem.
There's a couple of related issues here:
1. Why does v4l2h264dec constrain the colorimetries at all? Doesn't it just output the color values which were in the h264 stream? Isn't it the responsibility of the consumer of the decoded video frames to handle the colorimetry?
2. The colorimetry tuple `2:4:16:3` means range=[16..235], matrix=BT601, transfer=BT601, primaries=BT470BG. From what I can tell, this is identical to bt601. Shouldn't v4l2h264dec therefore also claim to support `2:4:16:3` when it claims to support bt601? Alternatively, shouldn't gstreamer treat them as equivalent when checking if pads are compatible?
And for my own sake: currently, I work around this by hard-coding `caps=video/x-h264,colorimetry=bt601` in the appsrc. This seems to work, but is it an alright workaround? Or does v4l2h264dec actually care about colorimetry in some way which could make this workaround problematic?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3226Interaction between rtpbin and rtpst2022-1-fec does not work when using the r...2024-01-16T11:20:53ZMorten Olsen LysgaardInteraction between rtpbin and rtpst2022-1-fec does not work when using the rtpbin `request-fec-decoder` signal.CC @meh
GStreamers `ulpfec` element is designed to be compatible with the "broken" FEC in Googles-WebRTC implementation, read here for reference: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/581
Because of this, i...CC @meh
GStreamers `ulpfec` element is designed to be compatible with the "broken" FEC in Googles-WebRTC implementation, read here for reference: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/581
Because of this, it is expecting to receive a single combined stream of RTP packets with both FEC and media packets combined.
The code for `request-fec-decoder` signal on `rtpbin` was originally designed for the `ulpfec`.
Because of that, the fec-element returned by the `request-fec-decoder` signal-handler is plugged in in a spot that works for `ulpfec`.
Contrary to `ulpfec`, `rtpst2022-1-fec` is implemented so that it works in the general case. It expects to receive 3 independent RTP-streams, 1 media and 2 FEC.
If you want to use `rtpst2022-1-fec` with `rtpbin`, and use the `request-fec-decoder` signal to instantiate it for `rtpbin`, it will be plugged in the wrong place inside `rtpbin`, and because of this, it will not work. Instead, using `rtpst2022-1-fec` **requires** that one uses the `fec-decoders` property of the `rtpbin`, as then it will be plugged in by some different code-path inside rtpbin which places it is the correct spot.
See the attached scripts that demonstrate the problem.
* [send.sh](/uploads/528c237302a01be213dd4c15dc0df4d1/send.sh) sends a test rtp stream with rtpst2022-1 fec encoding and H264
* [receive.sh](/uploads/eed21298c3af5a2a382a4bd93a1d7982/receive.sh) receives the stream and displays it using gst-launch-1.0 syntax. Works well.
* [ receive.py](/uploads/40017378f8bc18f1df56a0272cf3c53a/receive.py) receives the stream and displays it. Allows for setting a bool wether to use the `request-fec-decoder` signal or the `fec-decoders` factory string. When using the signal, the receiver breaks and does not show any video.
Matrix chat for reference of when this issue was discovered: https://matrix.to/#/!rFXJkaEjvUdqUHMPew:gstreamer.org/$f6MnvwIYygfCdCNIge66EZwy5_GkwcfH8NGkDynUlmY?via=gstreamer.org&via=matrix.org&via=gnome.orhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3222Incorrect RTSP SETUP Command Format in GStreamer 1.22.02024-02-01T19:05:21ZLuc BusquinIncorrect RTSP SETUP Command Format in GStreamer 1.22.0**Description:**
With GStreamer version 1.22.0, I am encountering an issue when establishing an RTSP connection to an IP camera. The SETUP command in the RTSP handshake is missing essential credentials, preventing the stream from being ...**Description:**
With GStreamer version 1.22.0, I am encountering an issue when establishing an RTSP connection to an IP camera. The SETUP command in the RTSP handshake is missing essential credentials, preventing the stream from being established. While other commands, such as OPTIONS and DESCRIBE, are formatted correctly, the SETUP command is incomplete compared to previous versions and other RTSP clients like VLC.
This issue was not present in GStreamer version 1.14.
**Expected SETUP Command (GStreamer 1.14 and VLC):**
`SETUP rtsp://192.168.42.10:554/user=admin&password=&channel=1&stream=0.sdp/trackID=3 RTSP/1.0`
**Actual SETUP Command in GStreamer 1.22.0:**
`SETUP rtsp://192.168.42.10:554/trackID=3 RTSP/1.0`
#### Environment
- OS: Debian 12
- Device: Raspberry Pi 5
- GStreamer Version: 1.22.0
- Pipeline Used: `gst-launch-1.0 rtspsrc location='rtsp://192.168.42.10:554/user=admin&password=&channel=1&stream=0.sdp'`
### Steps to Reproduce
1. Open a terminal.
2. Execute the command: `gst-launch-1.0 rtspsrc location='rtsp://192.168.42.10:554/user=admin&password=&channel=1&stream=0.sdp'`.
3. Use Wireshark to observe the RTSP SETUP command.
### Frequency of Occurrence
The bug occurs consistently and is reproducible every time the above command is executed.
### Impact
The malformed SETUP command results in the failure to establish an RTSP stream from the IP camera, which is a critical functionality for applications relying on real-time video feeds.
### Additional Information
- The RTSP stream from the IP camera works as expected when accessed using VLC, which suggests that the camera's RTSP server is functioning correctly.
- The issue seems to be specific to the GStreamer version 1.22.0, as earlier versions (e.g., 1.14) do not exhibit this behavior.
- Network traffic analysis via Wireshark confirms the discrepancy in the SETUP command between GStreamer versions.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3223dashsink: Why there is no implementation for segment timeline?2024-01-15T10:12:44ZJasur Dovurovdashsink: Why there is no implementation for segment timeline?There are some implementation files for Segment Timeline Representation [gstmpdsegmenttimelinenode.h](ext/dash/gstmpdsegmenttimelinenode.h) and [gstmpdsegmenttimelinenode.c](ext/dash/gstmpdsegmenttimelinenode.c), but it has not been impl...There are some implementation files for Segment Timeline Representation [gstmpdsegmenttimelinenode.h](ext/dash/gstmpdsegmenttimelinenode.h) and [gstmpdsegmenttimelinenode.c](ext/dash/gstmpdsegmenttimelinenode.c), but it has not been implemented inside struct [_GstMPDRepresentationNode](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/discontinued-for-monorepo/ext/dash/gstmpdrepresentationnode.h#L35) and also not implemented in [gstdashsink.c](ext/dash/gstdashsink.c) and there is only boolean choice `use-segment-list` to select SegmentList or SegmentTemplate. Are there any plans to continue to integrate this feature to the dashsink?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3220webrtcdsp: echo cancellation issue with stereo signal2024-01-27T16:52:46ZFabien Danieauwebrtcdsp: echo cancellation issue with stereo signal### Describe your issue
The echo cancellation feature of webrtcdsp breaks the stereo of an audio signal.
Discussed here: https://discourse.gstreamer.org/t/webrtcdsp-stereo-echo-cancellation/739/2
#### Expected Behavior
Captured stereo ...### Describe your issue
The echo cancellation feature of webrtcdsp breaks the stereo of an audio signal.
Discussed here: https://discourse.gstreamer.org/t/webrtcdsp-stereo-echo-cancellation/739/2
#### Expected Behavior
Captured stereo should be played back as is by the speakers.
`gst-launch-1.0 alsasrc ! webrtcdsp echo-cancel=true ! webrtcechoprobe ! audioconvert ! alsasink`
#### Observed Behavior
Only one channel is output. Goes back to normal with echo-cancel=false.
#### Setup
- **Operating System:** Ubuntu 22.04
- **Device:** Computer
- **GStreamer Version:** 1.23.1 (commit 79ffe4f4)
### Steps to reproduce the bug
This pipeline sends two different signals on the left and right channels. Using echo-cancel=true or false, the stereo is degraded.
```
gst-launch-1.0 \
audiotestsrc volume=0.1 ! capsfilter caps=audio/x-raw,format=S16LE,rate=8000,channels=1,channel-mask=\(bitmask\)0x1 name=left \
audiotestsrc freq=1320 volume=0.1 ! capsfilter caps=audio/x-raw,format=S16LE,rate=8000,channels=1,channel-mask=\(bitmask\)0x2 name=right \
interleave name=i left. ! i. right. ! i. \
i. ! webrtcdsp echo-cancel=true ! webrtcechoprobe \
! audioconvert ! audioresample ! alsasink
```
### How reproducible is the bug?
Systematic
### Additional Information
Discussed with @fengalin. The regression seems to have appeared since https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/d5755744c3e2b70e9f04704ae9d18b928d9fa456https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3218webrtcbin: set-description implementation is not spec-compliant2024-01-23T08:30:16ZPhilippe Normandwebrtcbin: set-description implementation is not spec-compliantOur implementation of https://w3c.github.io/webrtc-pc/#set-the-session-description doesn't look correct. For instance, we apply step 6.5 (https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/0d04660c5dca53096db1711d7925e1920685b137/...Our implementation of https://w3c.github.io/webrtc-pc/#set-the-session-description doesn't look correct. For instance, we apply step 6.5 (https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/0d04660c5dca53096db1711d7925e1920685b137/subprojects/gst-plugins-bad/ext/webrtc/gstwebrtcbin.c#L6454) before step 6.4 (https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/0d04660c5dca53096db1711d7925e1920685b137/subprojects/gst-plugins-bad/ext/webrtc/gstwebrtcbin.c#L6595)
Also, an addition to the spec from a couple years ago, calling `set-local-description` without description should either use an internally generated offer, or answer, depending on the signaling state. Currently we reject this case (bad input).https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3224Buffers Stuck When Pausing Live Source with Custom Sink2024-01-29T22:54:11ZStefan KieszkowskiBuffers Stuck When Pausing Live Source with Custom SinkHello, I'm having troubles pausing then playing the live source element of a pipeline. The issue is that there are frames that don't make it to the sink when I pause the live source element until after I play it again. Here is my pipelin...Hello, I'm having troubles pausing then playing the live source element of a pipeline. The issue is that there are frames that don't make it to the sink when I pause the live source element until after I play it again. Here is my pipeline sans caps filters:
`autovideosrc ! x264enc ! customSink`
When I change the `autovideosrc`'s state PLAYING->PAUSED, the pipeline immediately stops, and upon setting state back PAUSED->PLAYING, the first few frames that `customSink` receives are the old ones from just before pausing the element.
I've tried several things including ASYNC handling and flushing, and also came across resources suggesting it may involve pull/push configuration of elements or the pipeline clock settings. I've experimented with just about every possible configuration and order I could come up with, and still not getting the desired behavior. Any guidance would be greatly appreciated.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3216gl/glx: gst_gl_context_glx_activate causes leaks2024-02-06T13:39:05ZRobert Madergl/glx: gst_gl_context_glx_activate causes leaksFrom https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5727:
Adding passtrough support to `glcolorconvert` causes leaks on glx. There are [various tests blocklisted for valgrind](https://gitlab.freedesktop.org/gstreame...From https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5727:
Adding passtrough support to `glcolorconvert` causes leaks on glx. There are [various tests blocklisted for valgrind](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-devtools/validate/launcher/testsuites/check.py?ref_type=heads#L92-95) already mentioning reasons like "driver leaks" but not linking an issue, so I assume this is caused by the MR and figured it would make sense to create this issue, possibly allowing to remove a bunch of valgrind blocklist entries once fixed.
<details><summary>valgrind summary</summary>
Running suite(s): autovideoconvert
0%: Checks: 1, Failures: 0, Errors: 1
../subprojects/gst-plugins-bad/tests/check/elements/autovideoconvert.c:89:E:general:test_autovideoconvert_videoconvert:0: (after this point) Early exit with return value 20
Check suite autovideoconvert ran in 13.314s (tests failed: 1)
**Duration**: 17.789213180541992
## test_autovideoconvert_videoconvert.valgrind:
```
==17399== Memcheck, a memory error detector
==17399== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==17399== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==17399== Command: /builds/rmader/gstreamer/build/subprojects/gst-plugins-bad/tests/check/elements_autovideoconvert
==17399== Parent PID: 14558
==17399==
==17501==
==17501== HEAP SUMMARY:
==17501== in use at exit: 1,279,683 bytes in 8,547 blocks
==17501== total heap usage: 93,048 allocs, 84,501 frees, 73,210,986 bytes allocated
==17501==
==17501== 5,355 bytes in 255 blocks are definitely lost in loss record 4,227 of 4,250
==17501== at 0x484286F: malloc (vg_replace_malloc.c:381)
==17501== by 0x4C0114E: strdup (strdup.c:42)
==17501== by 0x9B73781: ???
==17501== by 0x9B73524: ???
==17501== by 0x89DFE91: FixupDispatchTable (GLdispatch.c:257)
==17501== by 0x89E0C1F: UnknownInlinedFun (GLdispatch.c:587)
==17501== by 0x89E0C1F: __glDispatchMakeCurrent (GLdispatch.c:555)
==17501== by 0x8902CD1: InternalMakeCurrentDispatch (libglx.c:921)
==17501== by 0x890711A: CommonMakeCurrent (libglx.c:1074)
==17501== by 0x865883A: gst_gl_context_glx_activate (gstglcontext_glx.c:878)
==17501== by 0x86230CC: gst_gl_context_activate (gstglcontext.c:777)
==17501== by 0x862513C: gst_gl_context_create_thread (gstglcontext.c:1335)
==17501== by 0x4A5DC41: g_thread_proxy (gthread.c:826)
==17501== by 0x4F532A4: start_thread (pthread_create.c:481)
==17501== by 0x4C71322: clone (clone.S:95)
==17501==
{
<insert_a_suppression_name_here>
Memcheck:Leak
match-leak-kinds: definite
fun:malloc
fun:strdup
obj:*
obj:*
fun:FixupDispatchTable
fun:UnknownInlinedFun
fun:__glDispatchMakeCurrent
fun:InternalMakeCurrentDispatch
fun:CommonMakeCurrent
fun:gst_gl_context_glx_activate
fun:gst_gl_context_activate
fun:gst_gl_context_create_thread
fun:g_thread_proxy
fun:start_thread
fun:clone
}
==17501== LEAK SUMMARY:
==17501== definitely lost: 5,355 bytes in 255 blocks
==17501== indirectly lost: 0 bytes in 0 blocks
==17501== possibly lost: 0 bytes in 0 blocks
==17501== still reachable: 264,722 bytes in 2,714 blocks
==17501== suppressed: 989,782 bytes in 5,403 blocks
==17501== Reachable blocks (those to which a pointer was found) are not shown.
==17501== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==17501==
==17501== For lists of detected and suppressed errors, rerun with: -s
==17501== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
==17399==
==17399== HEAP SUMMARY:
==17399== in use at exit: 655,371 bytes in 1,595 blocks
==17399== total heap usage: 59,723 allocs, 58,128 frees, 35,552,145 bytes allocated
==17399==
==17399== LEAK SUMMARY:
==17399== definitely lost: 0 bytes in 0 blocks
==17399== indirectly lost: 0 bytes in 0 blocks
==17399== possibly lost: 0 bytes in 0 blocks
==17399== still reachable: 96 bytes in 2 blocks
==17399== suppressed: 648,459 bytes in 1,526 blocks
==17399== Reachable blocks (those to which a pointer was found) are not shown.
==17399== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==17399==
==17399== For lists of detected and suppressed errors, rerun with: -s
==17399== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)
</details>https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3212debug: Add API to push/pop current object to TLS for logging purposes2024-01-09T06:54:20ZSebastian Drögedebug: Add API to push/pop current object to TLS for logging purposesCurrently we either have to pass through objects to code that does not concern itself with the object just for logging purposes, or get logs that are unconnected to the object that initially initiated them.
It would be great if we had s...Currently we either have to pass through objects to code that does not concern itself with the object just for logging purposes, or get logs that are unconnected to the object that initially initiated them.
It would be great if we had some API that allows pushing/popping the current object to a TLS variable, and then `GST_DEBUG()` etc make use of that if set. This would, for example, allow the code in `GstVideoConverter` to print the `videoconvert` object as part of the debug logs instead of just printing generic logs.
Main question here would be if this has considerable performance impact if logging is disabled (you'd still need to push/pop the object because you don't know what actual debug category and level is used at a later time).https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3211mfvideosrc: add a video device dialog (feature request)2024-01-09T01:00:59ZMaurizio Buratomfvideosrc: add a video device dialog (feature request)the libavdevice offer a show_video_device_dialog option that if set to true, before capture starts, popup a display dialog to the end user, allowing them to change video device properties and configurations manually.
would it be possibl...the libavdevice offer a show_video_device_dialog option that if set to true, before capture starts, popup a display dialog to the end user, allowing them to change video device properties and configurations manually.
would it be possible to add such option to mfvideosrc? this is especially usefull when capturing a webcam because sometimes the user want to change some device setting before the capture start
thank youhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3210netsim: unclear how to use max-kbps2024-01-08T11:23:50ZGuillaume Desmottesnetsim: unclear how to use max-kbpsI tried using `netsim max-kbps=` but was surprised that the property is not working. Turned out we have to set `max-bucket-size` as well or the property is ignored.
It's really not that clear from the doc:
```
max-bucket-size : T...I tried using `netsim max-kbps=` but was surprised that the property is not working. Turned out we have to set `max-bucket-size` as well or the property is ignored.
It's really not that clear from the doc:
```
max-bucket-size : The size of the token bucket, related to burstiness resilience (-1 = unlimited)
flags: readable, writable
Integer. Range: -1 - 2147483647 Default: -1
max-kbps : The maximum number of kilobits to let through per second (-1 = unlimited)
flags: readable, writable
Integer. Range: -1 - 2147483647 Default: -1
```
```
/**
* GstNetSim:max-bucket-size:
*
* The size of the token bucket, related to burstiness resilience.
*
* Since: 1.14
*/
/**
* GstNetSim:max-kbps:
*
* The maximum number of kilobits to let through per second. Setting this
* property to a positive value enables network congestion simulation using
* a token bucket algorithm. Also see the "max-bucket-size" property,
*
* Since: 1.14
*/
```
We could raise a warning if `max-kbps=` is set but not `max-bucket-size`, and probably improve the documentation but I'm not even sure what `max-bucket-size` actually control.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3209osxaudiosink not switching to new output device2024-01-07T22:20:31ZHuanosxaudiosink not switching to new output device### Describe your issue
<!-- Please provide a clear and concise summary of the bug. -->
Switching audio devices on macOS does not change the output device of osxaudiosink. It will keep playing on the device that it started with.
<!-- For...### Describe your issue
<!-- Please provide a clear and concise summary of the bug. -->
Switching audio devices on macOS does not change the output device of osxaudiosink. It will keep playing on the device that it started with.
<!-- For any GStreamer usage questions or application development support
please head over to our new GStreamer Discourse forum at
https://discourse.gstreamer.org/ instead, or find us on
the #gstreamer IRC channel on https://www.oftc.net -->
#### Expected Behavior
<!-- What did you expect to happen -->
Output should be on the newly selected audio device.
#### Observed Behavior
<!-- What actually happened -->
#### Setup
- **Operating System:** macOS 14.2.1
- **Device:** MacBook Pro 2023
- **GStreamer Version:** 1.22.8
### 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 audiotestsrc volume=0.1 ! osxaudiosink``
3. In sound settings, switch audio output device
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
Always
<!-- Any other information such as logs. Make use of <details> for long output -->
### Solutions you have tried
autoaudiosink does not work either.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3208d3d11screencapturesrc: frames lost2024-03-04T15:46:51ZMaurizio Buratod3d11screencapturesrc: frames lostI noticed that periodically some frames are missing in the d3d11screencapturesrc capture.
To reproduce the problem I used this test video: ![30fps_judder_test](/uploads/28c751a92185986bb700406f7f18e428/30fps_judder_test.mp4) played in v...I noticed that periodically some frames are missing in the d3d11screencapturesrc capture.
To reproduce the problem I used this test video: ![30fps_judder_test](/uploads/28c751a92185986bb700406f7f18e428/30fps_judder_test.mp4) played in vlc. then i capture vlc with this pipeline:
`gst-launch-1.0.exe -e d3d11screencapturesrc capture-api=1 window-handle=2229322 window-capture-mode=1 ! queue ! d3d11videosink`
in this video you can see the results: ![20240107_022310](/uploads/642deccb787c2c6ddace7d0698fa30a4/20240107_022310.mp4)
on the right vlc player, on the left d3d11screencapturesrc capturing vlc
if you look at 00:05 the captured video is not smooth and it looks like some frames are dropped. this problem occurs occasionally however at least 1 time every 5 minutes. I tried the same test with other tools that use windows graphics capture api and and i didn't see this problem.
Could you please check if d3d11screencapturesrc can loose frames in some situation?
i'm testing Gstreamer version=1.23.0.1 artifactshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3206Consider disabling telemetry events for ONNX runtime2024-01-05T14:08:55ZStephan SeitzConsider disabling telemetry events for ONNX runtimeThis issue just represents my personal consideration I had and does not represent the opinion of any company.
As per Microsoft's privacy notice https://github.com/microsoft/onnxruntime/blob/main/docs/Privacy.md, ONNX runtime builds prov...This issue just represents my personal consideration I had and does not represent the opinion of any company.
As per Microsoft's privacy notice https://github.com/microsoft/onnxruntime/blob/main/docs/Privacy.md, ONNX runtime builds provided by Microsoft (not own builds or builds provided by Linux distributions) might send telemetry via Windows telemetry APIs. This might not be intended by GStreamer users.
Onnx runtime offers a method on Ort::Env to disable telemetry events like this (in gstonnxclient.cpp)
```
env =
Ort::Env (OrtLoggingLevel::ORT_LOGGING_LEVEL_WARNING,
"GstOnnxNamespace");
env.DisableTelemetryEvents();
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3205rtspclientsink has both a LGPL and MIT license2024-01-05T12:47:01ZNiels De Graefnielsdegraef@gmail.comrtspclientsink has both a LGPL and MIT licenseIt looks like rtspclientsink has both LGPL and MIT licenses, so it's a bit unclear what the current legal status is of it's source code.
In talking to some people on IRC/Matrix, we figured out that:
* The licenses were already part of ...It looks like rtspclientsink has both LGPL and MIT licenses, so it's a bit unclear what the current legal status is of it's source code.
In talking to some people on IRC/Matrix, we figured out that:
* The licenses were already part of the initial version (commit f54dd50203)
* @thaytan apparently started the element by copying gstrtspsrc
* @wtay posted the original code for that in commit a365a29c77d, which mentions the dual license
* @slomo noted that a lot of code has been added, which means a lot of it probably falls under LGPL already
So maybe we should remove the MIT license there?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3204Audio sync problem with alsasink2024-01-05T11:51:32ZPaul GheorgheAudio sync problem with alsasink
Hello, I have this pipeline on my Nvidia Jetson Nano, which uses an HDMI to USB card to capture video and audio. I use gstreamer version 1.14.
gst-launch-1.0 -e v4l2src device=/dev/video0 do-timestamp=true ! queue2 ! image/jpeg,width=1...
Hello, I have this pipeline on my Nvidia Jetson Nano, which uses an HDMI to USB card to capture video and audio. I use gstreamer version 1.14.
gst-launch-1.0 -e v4l2src device=/dev/video0 do-timestamp=true ! queue2 ! image/jpeg,width=1280,height=720,framerate=30/1 ! jpegparse ! jpegdec ! queue2 ! nvoverlaysink sync=false alsasrc device=hw:CARD=MS2109,DEV=0 blocksize=12800 do-timestamp=true ! queue2 ! audio/x-raw,format=S16LE,layout=interleaved,rate=48000,channels=2 ! queue2 ! alsasink device=hw:0,3 sync=false blocksize=12800
Video works without lag, but audio lags behind after a few hours. If I set sync to true, audio stops working.
I see this in debug messages:
WARN audiobasesink gstaudiobasesink.c:1463:gst_audio_base_sink_skew_slaving:<autoaudiosink0-actual-sink-pulse> correct clock skew +0:00:00.029243609 > +0:00:00.020000000
I'm blocked for weeks... any idea what can I try? Thanks!https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3201Error Building GStreamer 1.22 on Fedora 392024-01-01T20:37:51Z8r4nError Building GStreamer 1.22 on Fedora 39I attempted to build the branch tagged with version 1.22 but was unsuccessful. Details follow..
| binary | version |
| ------ | ------ |
| meson | 1.2.3 |
| ninja | 1.11.1 |
| clang | 17.0.6 |
[meson-setup.log](/uploads/673497e5122047d...I attempted to build the branch tagged with version 1.22 but was unsuccessful. Details follow..
| binary | version |
| ------ | ------ |
| meson | 1.2.3 |
| ninja | 1.11.1 |
| clang | 17.0.6 |
[meson-setup.log](/uploads/673497e5122047d9f5fed690b166dff5/meson-setup.log)
[ninja-build.log](/uploads/ae903e2012acc036b6569f4f0790d9be/ninja-build.log)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3196glcolorconvert: Copies the GstMeta twice2024-02-23T22:08:00ZOlivier Crêteolivier.crete@ocrete.caglcolorconvert: Copies the GstMeta twiceIn `glcolorconvertelement`, we copy the GstMeta twice, which causes them to be duplicated.
They're first copied in [`gst-libs/gst/gl/gstglcolorconvert.c`](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-pl...In `glcolorconvertelement`, we copy the GstMeta twice, which causes them to be duplicated.
They're first copied in [`gst-libs/gst/gl/gstglcolorconvert.c`](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/gst-libs/gst/gl/gstglcolorconvert.c?page=4#L3027-L3050), which was added in !2094 .. but the element also does a copy at [`ext/gl/gstglcolorconvertelement.c`](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/ext/gl/gstglcolorconvertelement.c#L237) which calls basetransform to do it.
I'm totally unsure which one we should keep. My gut feeling is that metadata copying being in the element, but I'm not sure why this was changed in !2094.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3194decklink: unable to reduce bit depth from 10 to 8 bit using the video-format2023-12-22T12:25:56ZWojciech Kapsadecklink: unable to reduce bit depth from 10 to 8 bit using the video-formatThere is no way to reduce the bit depth from 10 bit to 8 bit to save computing power while leaving autodetection of resolution enabled. The "video-format" flag does not work without specifying the "mode" flag at the same time. For exampl...There is no way to reduce the bit depth from 10 bit to 8 bit to save computing power while leaving autodetection of resolution enabled. The "video-format" flag does not work without specifying the "mode" flag at the same time. For example, an attempt to reduce a 10bit-yuv video to 8bit-yuv ends up with the message: "Video input format does not match the user-set format".https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3193va decoder : playback issue with h264 file2024-01-08T19:50:30ZEdward Herveyva decoder : playback issue with h264 fileThe `2D Forced Subtitles Sample #2 (PGS)` From the [Kodi Samples](https://kodi.wiki/view/Samples) causes visual glitches when using the va h264 decoder
Link to download : https://drive.google.com/file/d/0BwxFVkl63-lEVEluSFZ4NlhpLUk/view...The `2D Forced Subtitles Sample #2 (PGS)` From the [Kodi Samples](https://kodi.wiki/view/Samples) causes visual glitches when using the va h264 decoder
Link to download : https://drive.google.com/file/d/0BwxFVkl63-lEVEluSFZ4NlhpLUk/view?usp=sharing&resourcekey=0-jrRNAhII3KVOq5Qid60tCw
`uridecodebin3 uri=file:///... ! queue ! glimagesink` (fails with any videosinks)
Forcing the ffmpeg h264 decoder results in no visual glitches.
There are some warning from `matroskademux` and from `h264decoder` which could help pinpoint the issue:
```
matroskareadcommon matroska-read-common.c:762:gst_matroska_read_common_parse_skip:<matroskademux0:sink> Unknown CueTrackPositions subelement 0xf0 - ignoring
h264decoder gsth264picture.c:405:gst_h264_dpb_get_short_ref_by_pic_num: No short term reference picture for 28
h264decoder gsth264decoder.c:3193:modify_ref_pic_list:<vah264dec0> Malformed stream, no pic num 28
```