gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2024-02-10T20:29:24Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3273RFC: Moving the srt plugin to -good2024-02-10T20:29:24ZJonas DanielssonRFC: Moving the srt plugin to -goodHello!
We (the good people at Spiideo) are using the SRT plugin in our stack, both as a sender and receiver, to ingest audio/video to our processing nodes, and we also use it as a means to send data out from our processing to consumers....Hello!
We (the good people at Spiideo) are using the SRT plugin in our stack, both as a sender and receiver, to ingest audio/video to our processing nodes, and we also use it as a means to send data out from our processing to consumers. The state of the plugin matters to us.
Getting the plugin from `gst-plugins-bad` to `gst-plugins good` is something we are willing to spend some time on.
Why?
* Finding out if there are any known issues out there that people are anxious about
* Getting some eyes on what might be missing in the plugin
* Making sure documentation is up-to-date
* Getting some critical eyes on the test needed to feel good about the plugin
* Not having to explain to management types why we are using bad stuff
From [subprojects/gstreamer/docs/random/moving-plugins](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gstreamer/docs/random/moving-plugins?ref_type=heads):
```plaintext
PROCESS
-------
- Issue in gitlab gets filed by someone requesting a move from bad
to good/ugly
This is "requesting" the move.
- a second person reviews the request and code, and verifies that the
plugin meets the checklist items below, by commenting on the bug
and giving a rundown of what still needs to be done
This is "sponsoring" the move.
- when the checklist is met, a third person can approve the move.
This is "approving" the move.
- an admin performs the move.
This is "performing" the move. (Are you laughing yet ?)
```
We are willing to put in work to raise the quality of the plugin to where it needs to be for a move to make sense. Is there anyone out there with some bandwidth to "sponsor" this by helping us getting the rundown of what needs to be done?
Reading the checklist from [subprojects/gstreamer/docs/random/moving-plugins](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gstreamer/docs/random/moving-plugins?ref_type=heads) I see there are some more work to be done on unit-test and manual tests, but there are probably more things to be done.
The srt library used seems to be MPL 2.0: https://github.com/Haivision/srt
Is this worthwhile? Is this wanted? Is this madness?
All the besthttps://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/2968Video freezes when resuming paused pipeline2024-02-10T18:48:29ZŁukasz GrabskiVideo freezes when resuming paused pipelineHi,
I'm trying to run the following scenario:
1. My first element is a filesrc with a file location pointing to a mp4 file,
2. It goes to decodebin,
3. Then I have an autovideosink and autoaudiosink connected to dynamically added pads ...Hi,
I'm trying to run the following scenario:
1. My first element is a filesrc with a file location pointing to a mp4 file,
2. It goes to decodebin,
3. Then I have an autovideosink and autoaudiosink connected to dynamically added pads of decodebin
4. I set the pipeline state to PLAYING and I can see the video and hear audio working correctly,
5. Then I set the pipeline state to PAUSED - video and audio pauses as expected,
6. Then I change the pipeline status back to PLAYING
The effect I'm observing is that audio starts playing again but video remains paused :disappointed:
I tried pausing given element instead of whole pipeline and for some reason it is effective only when doing it on autoaudiosink ;) Settting PAUSED on any other element has no effect. But, when i PAUSE/PLAY autoaudiosink the video unpauses correctly together with audio ;D
I appreciate any help here, I just need to pause/play whole pipeline on demand.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3291Rust: make debug builds instead of --release builds for monorepo subpipelines?2024-02-10T18:25:31ZTim-Philipp Müllertim@centricular.comRust: make debug builds instead of --release builds for monorepo subpipelines?Not 100% sure, but I was wondering if we're currently always creating `--release` builds, and if so if there's a way to create debug builds instead?
Might save some CI cycles for monorepo sub-pipelines.
(In fact we might not need to bu...Not 100% sure, but I was wondering if we're currently always creating `--release` builds, and if so if there's a way to create debug builds instead?
Might save some CI cycles for monorepo sub-pipelines.
(In fact we might not need to build plugins-rs at all for any monorepo change that doesn't affect public API, but I guess that's another discussion)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3275tcpserversrc thowing "pausing after gst_pad_push() = error" randomly in a pla...2024-02-10T14:00:21ZViranjan Pagartcpserversrc thowing "pausing after gst_pad_push() = error" randomly in a playing pipeline![file](/uploads/33002f41d3c1146136f11840805f98ef/file.png)
source bin (containing tcpserversrc) has the logic to reconnect when data is not arriving from tcpclientsrc or source is disconnected
source bin is reset by putting it into NUL...![file](/uploads/33002f41d3c1146136f11840805f98ef/file.png)
source bin (containing tcpserversrc) has the logic to reconnect when data is not arriving from tcpclientsrc or source is disconnected
source bin is reset by putting it into NULL and PLAYING state.
Suddenly when some buffers are consumed by the tcpserversrc then tvpserversrc throws error "pausing after gst_pad_push() = error"https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2516gl: Propagation of GL display/context not working correctly if using GL eleme...2024-02-09T14:41:21Zmarcbullgl: Propagation of GL display/context not working correctly if using GL elements outside and inside playsinkThe following pipeline does not work with 1.22 / git main (and deadlocks for other reasons with 1.20):
```shell
$ gst-launch-1.0 videotestsrc ! glvideomixer ! sink.video_sink playsink name=sink video-sink="glimagesink"
```
What happe...The following pipeline does not work with 1.22 / git main (and deadlocks for other reasons with 1.20):
```shell
$ gst-launch-1.0 videotestsrc ! glvideomixer ! sink.video_sink playsink name=sink video-sink="glimagesink"
```
What happens here is that outside and inside playsink a different GL display and context are used, and both contexts are not sharing with each other.
This then causes no window to show up, rendering to fail and for each frame errors as follows to be printed
```
0:00:00.103075402 3920565 0x7f0664002180 ERROR gldebug gstgldebug.c:306:_gst_gl_debug_callback:<glcontextegl1> high: GL error from API id:2, GL_INVALID_FRAMEBUFFER_OPERATION in glClear(incomplete framebuffer)
0:00:00.103086683 3920565 0x7f0664002180 ERROR gldebug gstgldebug.c:306:_gst_gl_debug_callback:<glcontextegl1> high: GL error from API id:2, GL_INVALID_FRAMEBUFFER_OPERATION in glDrawElements
0:00:00.136571386 3920565 0x7f0664002180 ERROR gldebug gstgldebug.c:306:_gst_gl_debug_callback:<glcontextegl1> high: GL error from API id:2, GL_INVALID_FRAMEBUFFER_OPERATION in glClear(incomplete framebuffer)
0:00:00.136615900 3920565 0x7f0664002180 ERROR gldebug gstgldebug.c:306:_gst_gl_debug_callback:<glcontextegl1> high: GL error from API id:2, GL_INVALID_FRAMEBUFFER_OPERATION in glDrawElements
0:00:00.169940583 3920565 0x7f0664002180 ERROR gldebug gstgldebug.c:306:_gst_gl_debug_callback:<glcontextegl1> high: GL error from API id:2, GL_INVALID_FRAMEBUFFER_OPERATION in glClear(incomplete framebuffer)
```
Original issue description below
----
I have a problem with the gtk4paintablesink and OpenGL playback, when using a video-stream-combiner with gst_play. I used a modified Glide to produce this problem. You can find it here: https://github.com/marcbull/glide/tree/video-compositor
The repository contains two Dot files of the pipeline and logs for both cases.
Without a video-stream-combiner property set, the gtk4paintablesink shows the expected video frames. If I assign a glvideomixer to the video-stream-combiner property, the view stays black, but you can hear audio playback.
I experienced this on Linux and on macOS.
Glide was started like this:
```
GST_DEBUG_DUMP_DOT_DIR=/tmp/gst GST_DEBUG="gtk4paintablesink:7" cargo r -- -i -c SampleVideo_1280x720_1mb.mp4 &| tee /tmp/glide.log
```
I added an command line argument to enable the use of the glvideomixer:
```
-c, --compositor Use glvideomixer as video-stream-combiner in the pipeline
```
The issue also occurs with the playbin3 element. It can be enabled with the following command line argument:
```
-p, --playbin3 Use playbin3 instead of playbin2
```
Is this a problem in the gtk4paintablesink or another component?
Thanks for your help.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2449playbin3 no longer uses contexts from the sink2024-02-09T13:50:30ZMichael Olbrichplaybin3 no longer uses contexts from the sinkWith GStreamer 1.22.0 playbin3 no longer uses the contexts provided by the sink. It's easy to test on hardware with VA-API support:
```
GST_DEBUG=vaapisink:2 gst-launch-1.0 playbin3 uri=file://some/file/that/will/use/a/vaapi/decoder vide...With GStreamer 1.22.0 playbin3 no longer uses the contexts provided by the sink. It's easy to test on hardware with VA-API support:
```
GST_DEBUG=vaapisink:2 gst-launch-1.0 playbin3 uri=file://some/file/that/will/use/a/vaapi/decoder video-sink=vaapisink
```
This fails a "Internal data stream error." and the vaapisink reports:
```
0:00:00.363445698 162906 0x7f29c402f9e0 WARN vaapisink gstvaapisink.c:1557:gst_vaapisink_show_frame_unlocked:<vaapisink0> incoming surface has different VAAPI Display
```
From what I can tell, this was broken in 6bffbe283ad6a662753fc8164fd8efd9d80d106e. Before that commit, playbin3 explicitly activated the sink and collected all provided contexts. Now this no longer happens and the decoder uses a different context than the sink.
@bilboed, any advice on how to fix this?Edward HerveyEdward Herveyhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3279glcolorconvert: Prefer xRGB formats if downstream supports it and the input i...2024-02-08T15:11:47ZSebastian Drögeglcolorconvert: Prefer xRGB formats if downstream supports it and the input is not an alpha formatBased on discussions on IRC earlier.
```
11:26 <Company> slomo: oh yeah, GTK gained xrgb formats at some point, no idea when, so detecting that when not using alpha would avoid that mess for apps like snapshot
[...]
11:29 <ystreet00> gs...Based on discussions on IRC earlier.
```
11:26 <Company> slomo: oh yeah, GTK gained xrgb formats at some point, no idea when, so detecting that when not using alpha would avoid that mess for apps like snapshot
[...]
11:29 <ystreet00> gstgl kinda always prefers RGBA textures over RGBx atm
11:30 <slomo> ystreet00: yeah was going to ask about that. can we make glupload prefer RGB if downstream handles it and the input is not an alpha format?
11:30 <Company> GL doesn't have the RGBx concept, or?
11:30 <Company> you need to manually carry that information
11:31 <Company> and setup GL_ONE alpha swizzle on the texture
11:32 <ystreet00> gstreamer does have RGBx formats which are represented in gstgl as a RGBA texture with the alpha channel undefined
11:32 <ystreet00> you also want to do this in glcolorconvert and not glupload
11:33 <Company> you don't set a swizzle?
11:33 <Company> I think GTK assumes that a swizzle is set, but I don't remember
11:34 <Company> otherwise we'd need different shaders when blending from it, and that'd be more work
11:35 <ystreet00[m]> we do not set a swizzle
11:36 <Company> so you do custom shaders?
11:36 <ystreet00> yes
11:36 <Company> any reason for that?
11:36 <Company> supporting old GLES that didn't have swizzles?
11:36 <ystreet00> I don't remember off the top of my head about GLES 2.0 support for swizzles
11:37 <Company> I think it doesn't
11:37 <ystreet00> we already had the shader templating infrastructure for different YUV layouts, so more or less reused that for RGBA vs RGBx differences as well
11:37 <Company> that makes sense
11:38 <Company> GLES 2.0 doesn't have swizzles
11:39 <Company> the new renderer doesn't support GLES 2.0 and I think the old one just treats those formats as unsupported then
```
CC @ystreet @Companyhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3281decodebin3: No valid frames decoded before end of stream2024-02-07T20:08:02ZJonas Kvingedecodebin3: No valid frames decoded before end of stream### Describe your issue
`./gst-libs/gst/audio/gstaudiodecoder.c(2492): gst_audio_decoder_sink_eventfunc (): /GstPlayBin3:pipeline-12-pipeline/GstURIDecodeBin3:uridecodebin3/GstDecodebin3:decodebin3-11/GstFlacDec:flacdec23: no valid fram...### Describe your issue
`./gst-libs/gst/audio/gstaudiodecoder.c(2492): gst_audio_decoder_sink_eventfunc (): /GstPlayBin3:pipeline-12-pipeline/GstURIDecodeBin3:uridecodebin3/GstDecodebin3:decodebin3-11/GstFlacDec:flacdec23: no valid frames found`
File: https://mega.nz/file/bYVSSAaa#_p_6lwzA015i0nWGgB5vmave3qwbizR8f_hV5kY89zs
Not sure if the file is broken, or this is a bug in GStreamer. Could you please have a look.
#### Expected Behavior
Play file
#### Observed Behavior
Error
#### Setup
- **Operating System: Linux
- **Device:** Computer
- **GStreamer Version:** 1.22.9
- **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`:
`GST_DEBUG=*:5 gst-launch-1.0 playbin3 uri=file:////home/jonas/Downloads/test.flac`
### How reproducible is the bug?
Every time
### Screenshots if relevant
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
https://github.com/strawberrymusicplayer/strawberry/issues/1373https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2590video-converter: `gst_video_converter_set_config()` has no effect and configu...2024-02-07T17:53:04ZSebastian Drögevideo-converter: `gst_video_converter_set_config()` has no effect and configuration is only taken into account during construction`gst_video_converter_set_config()` is copying over all values to the internal `GstStructure` but nothing is ever reading from that.`gst_video_converter_set_config()` is copying over all values to the internal `GstStructure` but nothing is ever reading from that.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3280qtmux with non-seekable downstream collects all input buffers before outputti...2024-02-07T14:38:53ZJan Schmidtqtmux with non-seekable downstream collects all input buffers before outputting anySince https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/732 if qtmux has a non-seekable downstream, it will in the default mode, collect the entire input stream into the `output_buffers` list before outputting an...Since https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/732 if qtmux has a non-seekable downstream, it will in the default mode, collect the entire input stream into the `output_buffers` list before outputting any of them.
Not only does that mean that memory usage is potentially unbounded, but also CPU consumption is dominated by `g_list_append` walking the super-long output buffers list repeatedly.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2703`Queued GOP time is negative` error in splitmuxsink for rtspsrc2024-02-07T10:31:34ZZiad Hatahet`Queued GOP time is negative` error in splitmuxsink for rtspsrcWe're hitting this error when running a GStreamer pipeline to capture HLS video segments:
```
ERROR: from element /GstPipeline:pipeline0/GstSplitMuxSink:splitmuxsink: Timestamping error on input streams
Additional debug info:
../gst/mul...We're hitting this error when running a GStreamer pipeline to capture HLS video segments:
```
ERROR: from element /GstPipeline:pipeline0/GstSplitMuxSink:splitmuxsink: Timestamping error on input streams
Additional debug info:
../gst/multifile/gstsplitmuxsink.c(2594): handle_gathered_gop (): /GstPipeline:pipeline0/GstSplitMuxSink:splitmuxsink:
Queued GOP time is negative -0:00:00.035816292
Execution ended after 0:22:00.008870101
```
The pipeline that produced this error is
```
$ gst-launch-1.0 rtspsrc location=rtsp://$USER:$PASSWORD@$IP is-live=true protocols=tcp \
! rtph264depay wait-for-keyframe=true request-keyframe=true \
! h264parse \
! splitmuxsink name=splitmuxsink max-size-time=10000000000 send-keyframe-requests=true muxer=mpegtsmux location=segment%05d.ts
```
There should not be any errors when running the pipeline. I tried setting `config-interval=-1` on the `h264parse` node, but the issue persists.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3278Memory leak in GStreamer1.222024-02-06T16:16:02ZGokila MMemory leak in GStreamer1.22Hi,
We have integrated GStreamer 1.22 with our application and started seeing memory leaks. We have captured the UMDH snap shots to identify the memory leak. It is pointing to one of the GStreamer api. Kindly let us know if you have any...Hi,
We have integrated GStreamer 1.22 with our application and started seeing memory leaks. We have captured the UMDH snap shots to identify the memory leak. It is pointing to one of the GStreamer api. Kindly let us know if you have any details on this GStreamer api or any change made recently.
![image](/uploads/b41e0631b347b1fc751bd428d0348fd3/image.png)
Thanks in advance.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/3241gst_bin_recalculate_latency() doesnt work (Latency calculation fails)2024-02-04T07:00:55ZIsrael Robotnickgst_bin_recalculate_latency() doesnt work (Latency calculation fails)### Describe your issue
Since Gst 1.22, I get a warning message repeatedly "Can't determine running time for this packet without knowing configured latency" message from rtpsession element.
This should happen if using gst_bin_recalculat...### Describe your issue
Since Gst 1.22, I get a warning message repeatedly "Can't determine running time for this packet without knowing configured latency" message from rtpsession element.
This should happen if using gst_bin_recalculate_latency() on the pipeline element every time a LATENCY message goes on the bus.
Attached two fils: logs level 6 + pipeline graph
#### Expected Behavior
Latency calculation should work, no Can't determine running time for this packet without knowing configured latency" message
#### Observed Behavior
Ï still get the message.
More over, I do gst_bin_recalculate_latency() on the pipeline when elements signal "LATENCY" on the bus, EXCEPT sink (fakesink, udpsink) elements. For some reason if I do this to sink elements as well, the pipeline stops. Still in my pipeline it the rtpsession is created
after any sink element, so I don't think it's an issue.
#### Setup
- **Operating System: Ubuntu 22.04
- **Device:** Virtual Machine
- **GStreamer Version: 1.22
- **Command line: Dynamic pipeline (python bindings)
The pipeline attached on picture (pipeline_debug.jpg) made by Gstreamer
### Steps to reproduce the bug
1. Create dynamic pipeline as in picture [pipeline_debug](/uploads/46bd1b112cbffbd6cedcba499b93845b/pipeline_debug.jpg)
udpsrc ! mpegtsparse ! tsdemux ! tee ! parsebin ! tee name=output ! queue2 ! fakesink output. ! h264timestamper ! rtph264pay ! webrtcbin
2. Listen to GST bus, to message Gst.MessageType.LATENCY
Whenever it happens, do pipelineElement.recalculate_latency()
### How reproducible is the bug?
Every time, also if I change the input element to rtspsrc.
### Screenshots if relevant
### Solutions you have tried
I silenced the log, but it doesnt really fix the issue.
I tried to change the input elements, and as I mentioned I disabled recalculate_latency when fakesink or udpsink creates the LATENCY message,
because it stops the whole pipeline. (Im watching the PTS by pad buffer probes of each packet in each pad in my pipeline, to know when something is wrong. And doing recalculate_latency causes the PTS to stop, meaning I stop getting buffers)
### Related non-duplicate issues
This message ("Can't determine running time for this packet without knowing configured latency") didn't happen on GST 1.20, but from issue 1659 I understand its just because it was silenced before 1.22)
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1659
### Additional Information
[logswithcalc.txt](/uploads/7bbc34190c1be8f1f7401fe8ce0b24b4/logswithcalc.txt)
[pipeline_debug](/uploads/46bd1b112cbffbd6cedcba499b93845b/pipeline_debug.jpg)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3270WavPack plugin does not support DSD2024-02-04T03:09:36ZJared BrelandWavPack plugin does not support DSD### Describe your issue
WavPack supports compression of DSD (DSF, etc.) files since version 5.0. GStreamer individually supports playback of both WavPack files and DSD files via their respective plugins, but does not (as far as I can te...### Describe your issue
WavPack supports compression of DSD (DSF, etc.) files since version 5.0. GStreamer individually supports playback of both WavPack files and DSD files via their respective plugins, but does not (as far as I can tell) support WavPack-compressed DSD files. It would be great to add support for this so DSD files can be both compressed and tagged (DSF format supports tagging, but it is not compressed).
#### Expected Behavior
Playing a WavPack file w/ embedded DSD audio should work.
#### Observed Behavior
Playback fails with "FAILED: Could not determine type of stream."
#### Setup
- Linux
- Computer
- 1.20.6
- Playback via Strawberry w/ gstreamer backend, but gst-typefind-1.0 returns the same message
### Steps to reproduce the bug
1. Download example DSF/DSD file (e.g., "Rodeo on a Ridge" from https://www.oppodigital.com/hra/dsd-by-davidelias.aspx)
1. Compress the file with wavpack: `wavpack 07\ -\ David\ Elias\ -\ Acoustic\ Trio\ -\ Rodeo\ On\ A\ Ridge\ \(DSD64\).dsf`
1. Compress any PCM/WAV file with wavpack for comparison
1. Verify DSF file plays successfully with, e.g., Strawberry
1. Verify PCM WavPack file plays successfully
1. Verify DSD WavPack file fails to play
1. Run `gst-typefind-1.0` against the PCM WavPack file - note it's detected as audio/x-wavpack
1. Run `gst-typefind-1.0` against the DSD WavPack file - in the Rodeo on a Ridge example, it returns video/x-h263. In other tests I've seen "FAILED: Could not determine type of stream." and (if the file has been tagged) application/x-apetag.
### How reproducible is the bug?
Always
### Screenshots if relevant
### Solutions you have tried
The DSD-compressed WavPack file is playble by both ffmpeg (ffplay) and mpv. It's also playable with Strawberry if I switch it to use VLC as its backend. This leads me to conclude the limitation is with the GStreamer plugin.
### Related non-duplicate issues
### Additional Information
I'm not especially familiar with GStreamer, so apologies if the above details (ie., using gst-typefind-1.0) are not adequate. Please let me know what additional info would help and I'm happy to provide.
Thanks.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3170python: test failures with Python 3.122024-02-03T19:06:52ZJeremy Bichapython: test failures with Python 3.12- gst-python 1.22.7 (or 1.22.6)
- Debian Unstable or Ubuntu 24.04 LTS (under development)
- Originally reported at https://bugs.debian.org/1055575
gst-python's build tests are failing with python 3.12. I also tried cherrypicking https:/...- gst-python 1.22.7 (or 1.22.6)
- Debian Unstable or Ubuntu 24.04 LTS (under development)
- Originally reported at https://bugs.debian.org/1055575
gst-python's build tests are failing with python 3.12. I also tried cherrypicking https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5587 but it didn't help.
One issue is that the `imp` module [has been removed](https://docs.python.org/3/whatsnew/3.12.html#imp) from Python 3.12's standard library.
I got many more errors after I created a simple patch to use `importlib.util` instead. Maybe that just means my patch was wrong or maybe many other things needs to be fixed.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2973check.gst-editing-services.complex_effect_bin_desc is racy2024-02-03T17:29:25ZAlicia Boya Garcíacheck.gst-editing-services.complex_effect_bin_desc is racyReproduced on 887b4095cae94d828e15a5a962c1c82b29a2405c (Aug 11 2023).
`gst-validate-launcher -f check.gst-editing-services.complex_effect_bin_desc`
`Bail out! Fatal report received: 0:00:00.455073445 <(null)>: 3662 (critical) : validat...Reproduced on 887b4095cae94d828e15a5a962c1c82b29a2405c (Aug 11 2023).
`gst-validate-launcher -f check.gst-editing-services.complex_effect_bin_desc`
`Bail out! Fatal report received: 0:00:00.455073445 <(null)>: 3662 (critical) : validateflow: The recorded log does not match the expectation file.: Mismatch error in pad videosink:sink, line 8. Expected: buffer: checksum=b4a126ab26f314a74ef860a9af457327a28d680b, pts=0:00:00.100000000, dur=0:00:00.000000001, meta=GstVideoMeta Actual: event eos: (no structure)`https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3260Build gst-python fails to find pygobject-3.02024-02-03T17:10:50ZJavier YepezBuild gst-python fails to find pygobject-3.0### Describe your issue
I'm trying to compile gst-python but it isn't finding the pygobject-3.0 when installed in a Conda environment. I installed these libraries in the environment:
```
name: base
channels:
- defaults
- pytorch
...### Describe your issue
I'm trying to compile gst-python but it isn't finding the pygobject-3.0 when installed in a Conda environment. I installed these libraries in the environment:
```
name: base
channels:
- defaults
- pytorch
- conda-forge
dependencies:
- python==3.10
- pycairo
- pygobject
- meson
- ninja
- cmake
- pytorch
- opencv
- matplotlib
- ipykernel
- pip
```
and also these ones through `apt-get install g++ build-essential libglib2.0-dev libglib2.0-dev-bin libgstreamer1.0-dev libtool m4 autoconf automake libgirepository1.0-dev libcairo2-dev`
Once installed and activated, running `meson build` can't find pygobject:
```
The Meson build system
Version: 1.2.1
Source dir: /opt/nvidia/deepstream/deepstream-6.4/sources/deepstream_python_apps/3rdparty/gstreamer/subprojects/gst-python
Build dir: /opt/nvidia/deepstream/deepstream-6.4/sources/deepstream_python_apps/3rdparty/gstreamer/subprojects/gst-python/build
Build type: native build
Project name: gst-python
Project version: 1.20.3
C compiler for the host machine: cc (gcc 11.3.0 "cc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0")
C linker for the host machine: cc ld.bfd 2.38
Host machine cpu family: x86_64
Host machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Run-time dependency gstreamer-1.0 found: YES 1.20.3
Run-time dependency gstreamer-base-1.0 found: YES 1.20.3
Run-time dependency gmodule-2.0 found: YES 2.72.4
Found CMake: /root/.local/bin/cmake (3.19.6)
Run-time dependency pygobject-3.0 found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency pygobject-3.0
meson.build:23:16: ERROR: Neither a subproject directory nor a pygobject.wrap file was found.
A full log can be found at /opt/nvidia/deepstream/deepstream-6.4/sources/deepstream_python_apps/3rdparty/gstreamer/subprojects/gst-python/build/meson-logs/meson-log.txt
WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.
```
Is there a way to manually set the pygobject path? Which one should it be?
```
/opt/conda/lib/pkgconfig/pygobject-3.0.pc
/opt/conda/pkgs/pygobject-3.46.0-py310h30b043a_1
/opt/conda/pkgs/pygobject-3.46.0-py310h30b043a_1/include/pygobject-3.0
/opt/conda/pkgs/pygobject-3.46.0-py310h30b043a_1/include/pygobject-3.0/pygobject.h
/opt/conda/pkgs/pygobject-3.46.0-py310h30b043a_1/lib/pkgconfig/pygobject-3.0.pc
```
### Expected Behavior
Meson finds PyGObject
#### Setup
- **Operating System:** 5.15.133.1-microsoft-standard-WSL2
- **Device:** Virtual Machine
- **GStreamer Version:** 1.22.9
- **Command line:** `meson build`https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3263videoconvert to GRAY8 is very slow compared to BGR2024-02-02T18:10:39ZLuc Busquinvideoconvert to GRAY8 is very slow compared to BGRI have this RTSP pipeline in my code:
`rtspsrc protocols=tcp tcp-timeout=5000000 retry=5 location="rtsp://192.168.42.10:554/user=admin&password=&channel=1&stream=0.sdp/" ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! video/x-r...I have this RTSP pipeline in my code:
`rtspsrc protocols=tcp tcp-timeout=5000000 retry=5 location="rtsp://192.168.42.10:554/user=admin&password=&channel=1&stream=0.sdp/" ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! video/x-raw,format=GRAY8 ! appsink max-buffers=25 drop=true sync=1 name=appsink`
It's running on a RPi4 with Bookworm and GStreamer 1.22.0. The server is a IP camera that is sending I420 YUV video.
When I set `video/x-raw,format=BGR`, the pipeline has no problems keeping up with 1080p @ 25fps, however when setting to `video/x-raw,format=GRAY8`, the pipeline slows down significantly and I can only stream to 720p @ 15fps.
As a workaround, I keep `video/x-raw,format=BGR` and convert to grayscale in python.
I'm wondering why the conversion to gray in GStreamer is so much slower.