GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-09-18T09:31:16Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2977Multiple fast seeks of audio only seeks once - gstbaseparse same index entry2023-09-18T09:31:16Zlaurence-ejraeeMultiple fast seeks of audio only seeks once - gstbaseparse same index entryHi, I am running gstreamer 1.18.6 on wpewebkit and experience an issue with carrying out multiple forward seeks in quick succession.
I am debugging in gstreamer and found something strange: each seek time requested (e.g. 10s, then 20s) r...Hi, I am running gstreamer 1.18.6 on wpewebkit and experience an issue with carrying out multiple forward seeks in quick succession.
I am debugging in gstreamer and found something strange: each seek time requested (e.g. 10s, then 20s) returns the same index entry from gstbaseparse.c. See logs:
_0:00:5
3.811120079 1688 0x11523c10 DEBUG baseparse gstbaseparse.c:4539:gst_base_parse_find_offset:<mpegaudioparse0> found index entry for 0:00:10.626931066 at 0:00:04.048979440, offset 161959_
_0:00:54.000858782 1688 0x11523c10 DEBUG baseparse gstbaseparse.c:4539:gst_base_parse_find_offset:<mpegaudioparse0> found index entry for 0:00:20.888155555 at 0:00:04.048979440, offset 161959_
I have checked logs for the index entry being added but it seems to only be called once, and I assume this would be for one time value:
_0:00:53.809345856 1688 0x117949e0 LOG baseparse gstbaseparse.c:1996:gst_base_parse_add_index_entry:<mpegaudioparse0> Adding key=1 index entry 0:00:04.048979440 @ offset 0x000278a7_
In the working case (when I carry out the seeks with a longer delay between them), I see each seek time is associated with a **different** index entry:
_0:13:18.005031154 1688 0x11523c10 DEBUG baseparse gstbaseparse.c:4539:gst_base_parse_find_offset:<mpegaudioparse1> found index entry for 0:00:11.097131066 at 0:00:04.048979440, offset 161959_
_0:13:18.590774672 1688 0x11523c10 DEBUG baseparse gstbaseparse.c:4539:gst_base_parse_find_offset:<mpegaudioparse1> found index entry for 0:00:21.358355555 at 0:00:06.138775280, offset 245551_
Does anyone know if this is intended - are multiple time values meant to be associated with a single index entry, or is this the cause of my issue? If not intended, perhaps some help in identifying why the different time values are finding the same index entry.
Thank you.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2976idle pad probe may be called twice even though it returns GST_PAD_PROBE_REMOVE2023-09-15T06:12:10ZMichael Olbrichidle pad probe may be called twice even though it returns GST_PAD_PROBE_REMOVEIn some cases, it can happen that an idle probe is called twice even though it should only be called once because it returns GST_PAD_PROBE_REMOVE unconditionally.
What seems to happen is this:
- `gst_pad_add_probe()` is called
- the pr...In some cases, it can happen that an idle probe is called twice even though it should only be called once because it returns GST_PAD_PROBE_REMOVE unconditionally.
What seems to happen is this:
- `gst_pad_add_probe()` is called
- the probe is added to the probe list
- it detects that the pad is idle so it can call the callback directly
- `GST_OBJECT_UNLOCK (pad);` (https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/b20f66ceac080fc4c635cd50f39cfa3220662639/subprojects/gstreamer/gst/gstpad.c#L1508)
- the callback is executed.
- at this point the other thread can pass though the pad. At the end, it will call all idle probes including the one that is processed in the first thread!
- `GST_OBJECT_LOCK (pad);`
- the probe is removed from the probe list
I'm not quite sure what the correct fix is. Probably not adding the probe to the list until after the callback was called. But I'm not sure if there any side effects that I'm missing.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/427Ndisrcdemux: video-only case not supported2023-09-21T15:00:09ZLokesha RNdisrcdemux: video-only case not supportedWe are trying to stream only video case(File content only video stream, no audio stream) playback using NDI project with the help of Camera / VLC player / OBS studio in arm based target device.
Issue faced : Unable to play video-only ca...We are trying to stream only video case(File content only video stream, no audio stream) playback using NDI project with the help of Camera / VLC player / OBS studio in arm based target device.
Issue faced : Unable to play video-only case
Cause : In ndisrcdemux unable send no_more_pads signal for video-only because it is waiting for the
condition if self.obj().num_src_pads() == 2 to be satisfied.
self.obj().add_pad(&srcpad).unwrap();
if self.obj().num_src_pads() == 2 {
self.obj().no_more_pads();
}
Please help us to resolve this issue?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2975playbin cannot seek2023-09-14T06:20:43ZFang .playbin cannot seek### Describe your issue
When using playbin with a url to a mp4 file, `gst_element_seek_simple` returns 0 and seeking does not happen.
#### Expected Behavior
Seeking should happen.
#### Observed Behavior
Seeking does not happen.
#### S...### Describe your issue
When using playbin with a url to a mp4 file, `gst_element_seek_simple` returns 0 and seeking does not happen.
#### Expected Behavior
Seeking should happen.
#### Observed Behavior
Seeking does not happen.
#### Setup
Windows, C++
gstreamer v1.22.0 & v1.22.5 (tested both versions, behaviour is same)
### Steps to reproduce the bug
The bug can be reproduced with the following short sample code:
```
#include <gst/gst.h>
#include <stdio.h>
#include <Windows.h>
const char* PLAYBIN_URI = "URI HERE";
int main(int argc, char* argv[])
{
gst_init(&argc, &argv);
GstElement *playbin_v = gst_element_factory_make("playbin3", "bin_v");
g_object_set(playbin_v, "flags", 1, "uri", PLAYBIN_URI, NULL);
gst_element_set_state(playbin_v, GST_STATE_PLAYING);
Sleep(5000);
gboolean result = gst_element_seek_simple(playbin_v, GST_FORMAT_TIME, (GstSeekFlags)(GST_SEEK_FLAG_FLUSH), 60000000000);
fprintf(stderr, "Result of gst_element_seek_simple is %u", result);
Sleep(1000000);
return 0;
}
```
For some mp4 URLs, seeking will work. For some mp4 URLs, seeking does not work.
Working example: set PLAYBIN_URI to `https://drive.google.com/uc?id=1AiOoaHEgJ_7ndachSuBFYGpq7DrRFIfh&export=download` You will see 5 seconds of a road in the desert, then the video skips forwards to a forest scene.
Non working example: set PLAYBIN_URI to `https://drive.google.com/uc?id=1P3hWAZtcW_vp7RX6ORfLyebs3BoxtMXZ&export=download`
Note that there is nothing inherently wrong with the non working video. You can play this video in your chrome browser (https://drive.google.com/file/d/1P3hWAZtcW_vp7RX6ORfLyebs3BoxtMXZ/view), and seeking does in fact work.
The working video has both video and audio. The non working video is video only (with no audio).
### How reproducible is the bug?
Always
### Screenshots if relevant
### Solutions you have tried
Changing playbin's flag from 1 (video) to 3 (video+audio) does not fix the problem.
Changing the seek flags to `GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_KEY_UNIT` does not fix the problem.
Setting the pipeline to pause before the seek does not fix the problem.
Using `gst_element_seek` instead of `gst_element_seek_simple` does not fix the problem.
### Related non-duplicate issues
### Additional Information
These two mp4 files were obtained from yt-dlp (version 2023.7.6). I downloaded the mp4s using yt-dlp and uploaded them onto my google drive (this is because the download links generated by yt-dlp expire after a few hours, so I can't use them as examples in this ticket).
The working example was obtained by: `yt-dlp -f 22 https://www.youtube.com/watch?v=-kUyorDlEmo`
The non working example was obtained by: `yt-dlp -f 135 https://www.youtube.com/watch?v=-kUyorDlEmo`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/2972message: keep weak reference to `src`?2023-09-13T15:07:42ZKyrylo Polezhaievmessage: keep weak reference to `src`?Maybe `GstMessage` should have weak reference to `src`?
Pipelines in my app live long, creating and removing sinks when necessary. I wasn't interested in bus messages, so I didn't add bus callback. Those sinks were posting messages on b...Maybe `GstMessage` should have weak reference to `src`?
Pipelines in my app live long, creating and removing sinks when necessary. I wasn't interested in bus messages, so I didn't add bus callback. Those sinks were posting messages on bus and got referenced, so removing them from pipeline (last reference) wasn't enough to dispose of them.
With bus watch attached, everything is okay. But probably whether sink should be disposed or not should not depend on whether user added bus watch.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2970webrtcbin - Unable to add second video steam to peer and perform renegotiation2023-10-04T20:42:20ZAbiola Adimiwebrtcbin - Unable to add second video steam to peer and perform renegotiation### Describe your issue
Created an app in using **webrtcbin** to perform a video call with audio between **Peer A** and **Peer B**. After establishing the call between **Peer A** and **Peer B**, we attempted to add a second camera strea...### Describe your issue
Created an app in using **webrtcbin** to perform a video call with audio between **Peer A** and **Peer B**. After establishing the call between **Peer A** and **Peer B**, we attempted to add a second camera stream to the peer connection from **Peer A** and generate a new **_SDP_** that will be sent to **Peer B** but the app crashed with following messages:
```plaintext
2:35:37.045888617 660 0x2771440 LOG webrtcbin gstwebrtcbin.c:2424:_create_webrtc_transceiver:<webrtcbin0> created new transceiver <webrtctransceiver3> with direction sendrecv (4), mline 4294967295, kind unknown (0)
2:35:37.046655669 660 0x2771440 LOG webrtcbin gstwebrtcbin.c:8153:gst_webrtc_bin_request_new_pad:<webrtcbin0> Created new transceiver <webrtctransceiver3>
2:35:37.047017694 660 0x2771440 DEBUG webrtcbin gstwebrtcbin.c:484:gst_webrtc_bin_pad_new:<'':sink_2> new visible pad with direction sink
2:35:37.069498890 660 0x2e2ccf8 INFO webrtcbin gstwebrtcbin.c:4792:_create_sdp_task:<webrtcbin0> creating offer sdp with options (NULL)
2:35:37.069712905 660 0x2e2ccf8 LOG webrtcbin gstwebrtcbin.c:3909:_create_offer_task:<webrtcbin0> using previous negotiatied transceiver <webrtctransceiver0> with mid 0 into media index 0
2:35:37.069790577 660 0x2e2ccf8 LOG webrtcbin gstwebrtcbin.c:1959:_find_codec_preferences:<webrtcbin0> retrieving codec preferences from <webrtctransceiver0>
2:35:37.070070262 660 0x2e2ccf8 LOG webrtcbin gstwebrtcbin.c:1901:_query_pad_caps:<webrtcbin0> Using peer query caps: application/x-rtp, media=(string)audio, clock-rate=(int)48000, encoding-name=(string)OPUS, sprop-stereo=(string)1, encoding-params=(string)2, sprop-maxcapturerate=(string)48000, payload=(int)111, seqnum-offset=(uint)535, timestamp-offset=(uint)4217038865, ssrc=(uint)3326287363
2:35:37.070211272 660 0x2e2ccf8 DEBUG webrtcbin gstwebrtcbin.c:3435:sdp_media_from_transceiver:<webrtctransceiver0> 0 Using previous ice parameters
2:35:37.070390951 660 0x2e2ccf8 DEBUG webrtcbin gstwebrtcbin.c:3506:sdp_media_from_transceiver:<webrtcbin0> Adding 0-th caps application/x-rtp, media=(string)audio, clock-rate=(int)48000, encoding-name=(string)OPUS, sprop-stereo=(string)1, encoding-params=(string)2, sprop-maxcapturerate=(string)48000, payload=(int)111, seqnum-offset=(uint)535, timestamp-offset=(uint)4217038865, ssrc=(uint)3326287363, rtcp-fb-transport-cc=(boolean)true to 0-th media
2:35:37.070820313 660 0x2e2ccf8 LOG webrtcbin gstwebrtcbin.c:3909:_create_offer_task:<webrtcbin0> using previous negotiatied transceiver <webrtctransceiver2> with mid 1 into media index 1
2:35:37.070894318 660 0x2e2ccf8 LOG webrtcbin gstwebrtcbin.c:1959:_find_codec_preferences:<webrtcbin0> retrieving codec preferences from <webrtctransceiver2>
2:35:37.071137668 660 0x2e2ccf8 LOG webrtcbin gstwebrtcbin.c:1901:_query_pad_caps:<webrtcbin0> Using peer query caps: application/x-rtp, media=(string)video, payload=(int)[ 0, 127 ], clock-rate=(int)90000, encoding-name=(string)H264
2:35:37.072343750 660 0x2e2c970 DEBUG webrtcbin gstwebrtcbin.c:331:gst_webrtcbin_sink_event:<webrtcbin0> On <webrtcbin0:sink_2> checking negotiation? 1, caps application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, sprop-parameter-sets=(string)"Z0JAFKaBQfk\=\,aM48gA\=\=", profile-level-id=(string)424014, profile=(string)constrained-baseline, payload=(int)96, ssrc=(uint)75864864, timestamp-offset=(uint)683525656, seqnum-offset=(uint)24265, a-framerate=(string)25
2:35:37.074151873 660 0x2e2ccf8 DEBUG webrtcbin gstwebrtcbin.c:3435:sdp_media_from_transceiver:<webrtctransceiver2> 1 Using previous ice parameters
2:35:37.074379555 660 0x2e2ccf8 DEBUG webrtcbin gstwebrtcbin.c:3506:sdp_media_from_transceiver:<webrtcbin0> Adding 0-th caps application/x-rtp, media=(string)video, payload=(int)[ 0, 127 ], clock-rate=(int)90000, encoding-name=(string)H264, rtcp-fb-nack-pli=(boolean)true, rtcp-fb-ccm-fir=(boolean)true, rtcp-fb-transport-cc=(boolean)true to 1-th media
2:35:37.074480562 660 0x2e2ccf8 ERROR webrtcbin gstwebrtcbin.c:3512:sdp_media_from_transceiver:<webrtcbin0> Failed to build media from caps application/x-rtp, media=(string)video, payload=(int)[ 0, 127 ], clock-rate=(int)90000, encoding-name=(string)H264, rtcp-fb-nack-pli=(boolean)true, rtcp-fb-ccm-fir=(boolean)true, rtcp-fb-transport-cc=(boolean)true for transceiver <webrtctransceiver2>
2:35:37.074601237 660 0x2e2ccf8 WARN webrtcbin gstwebrtcbin.c:4811:_create_sdp_task:<webrtcbin0> returning error: Could not reuse transceiver
2:35:37.074988597 660 0x2e2c970 LOG webrtcbin gstwebrtcbin.c:1729:_check_if_negotiation_is_needed:<webrtcbin0> checking if negotiation is needed
2:35:37.075261615 660 0x2e2c970 LOG webrtcbin gstwebrtcbin.c:1783:_check_if_negotiation_is_needed:<webrtcbin0> unassociated transceiver 1 <webrtctransceiver1> mid (null)
```
#### Expected Behavior
Ability to add new camera streams at any point to **webrtcbin** and get the updated SDP
#### Observed Behavior
App crashed after failing to add new video streamhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/425(s3sink): adding ability to generate presigned url in s3sink2023-09-14T03:19:16ZRamyak Mehra(s3sink): adding ability to generate presigned url in s3sinkFirst of all thanks for the plugin it had been of great help. While working on a project, I needed to add some custom signals and handle generation of presigned url, I extended the current implementation to support that. I am not sure if...First of all thanks for the plugin it had been of great help. While working on a project, I needed to add some custom signals and handle generation of presigned url, I extended the current implementation to support that. I am not sure if it is a good feature to have on the public repo too. let me know and I can make a PR for the same.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2969androidmedia: IllegalStateException when dequeueing output buffer in audio de...2023-09-15T06:10:24ZBevin Bensonandroidmedia: IllegalStateException when dequeueing output buffer in audio decoderI have GstPlayer working with gstreamer-1.0-android-universal-1.20.6 and NDK 21. I have a dependency on NDK 25, so I have built gstreamer-1.0 with NDK 25 (using cerbero) and I'm trying to use this new build in my app.
The app is compil...I have GstPlayer working with gstreamer-1.0-android-universal-1.20.6 and NDK 21. I have a dependency on NDK 25, so I have built gstreamer-1.0 with NDK 25 (using cerbero) and I'm trying to use this new build in my app.
The app is compiling and running, but I'm getting the following error when gst_player_play is called:
```
../gst-libs/gst/play/gstplay.c:939:on_error:<play3> Error: Error from element /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin6/GstDecodeBin:decodebin3/GstAmcAudioDec-OmxGoogleOpusDecoder:amcaudiodec-omxgoogleopusdecoder1: GStreamer encountered a general supporting library error
.../sys/androidmedia/gstamcaudiodec.c(620): gst_amc_audio_dec_loop (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin6/GstDecodeBin:decodebin3/GstAmcAudioDec-OmxGoogleOpusDecoder:amcaudiodec-omxgoogleopusdecoder1:
Failed to call Java method: java.lang.IllegalStateException
java.lang.IllegalStateException
at android.media.MediaCodec.native_dequeueOutputBuffer(Native Method)
at android.media.MediaCodec.dequeueOutputBuffer(MediaCodec.java:3573)
(gst-play-error-quark, 0)
```
I'm new to developing with the NDK, so any help would be appreciated.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/2967vapostproc: Fails to negotiate with the glimagesink when GST_GL_API=opengl2023-12-15T09:56:39ZHe Junyanvapostproc: Fails to negotiate with the glimagesink when GST_GL_API=openglThe pipeline of
```
GST_GL_PLATFORM=egl gst-launch-1.0 -vf filesrc location=test.264 ! h264parse ! vah264dec ! vapostproc ! glimagesink
```
will fail to negotiate, and we need to specify GST_GL_API=gles2:
```
GST_GL_PLATFORM=egl GST_GL_A...The pipeline of
```
GST_GL_PLATFORM=egl gst-launch-1.0 -vf filesrc location=test.264 ! h264parse ! vah264dec ! vapostproc ! glimagesink
```
will fail to negotiate, and we need to specify GST_GL_API=gles2:
```
GST_GL_PLATFORM=egl GST_GL_API=gles2 gst-launch-1.0 -vf filesrc location=test.264 ! h264parse ! vah264dec ! vapostproc ! glimagesink
```
to work.
In fact, the vapostproc ! glimagesink can link with ARGB kind caps.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/422gtk4paintablesink: Add force-aspect-ratio property2023-09-11T08:14:45ZPhilippe Normandgtk4paintablesink: Add force-aspect-ratio propertyMost video sinks implement it and `playsink` also has plumbing for it.Most video sinks implement it and `playsink` also has plumbing for it.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2964GstClock synced signal race with finalize call2023-09-08T14:03:52ZRobert RosengrenGstClock synced signal race with finalize callIn the scenario that a client sets up synced signal to gstclock (might be indirectly via gst_ntp_clock_new and similar) and later unrefs the clock instance, there will be a race with the actual emitted signal. Signal will be emited in cl...In the scenario that a client sets up synced signal to gstclock (might be indirectly via gst_ntp_clock_new and similar) and later unrefs the clock instance, there will be a race with the actual emitted signal. Signal will be emited in clock thread, and unref might happen in lets say mainloop. If so the signal might show up with an unreferenced clock.
See https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gstreamer/gst/gstclock.c?ref_type=heads#L1765 where emiting the signal outside of any locks, and finalize https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gstreamer/gst/gstclock.c?ref_type=heads#L804 that is result of the unref
Should this be better protected in the gstclock code, with mutex or similar? (...or is this all up to client to figure out somehow? )https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2962Add an option to allow loopable audio files to play "forever"2023-09-07T13:13:37ZPeter OccilAdd an option to allow loopable audio files to play "forever"Add an option to allow loopable audio files (such as .spc as well as certain MIDI files with loop points) to play "forever", rather than stop after a set amount of time.
How this can be implemented will likely depend on the plugin -- ma...Add an option to allow loopable audio files (such as .spc as well as certain MIDI files with loop points) to play "forever", rather than stop after a set amount of time.
How this can be implemented will likely depend on the plugin -- many audio formats support loop points, while others don't.
For example, in the `gme` plugin this appears to be hard-coded to 2.5 minutes and doesn't allow looping "forever" even if the input audio file has loop points (and to implement files that practically loop "forever", the stopping point can be set, say, to a ludicrous number of hours, in `libgme` using `gme_set_fade`).
Related: #1756.
--------------
I hope that this request as well as #2956 will help improve playback support in the _Totem_ application as follows:
- Better seeking and looping in MIDI files and loopable audio files.
- A user preference (in _Totem_'s Preferences box) to set the instrument source file (e.g., .sf2, .dls) for playing MIDI files.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/421How to run webrtcsink2023-09-12T20:51:39Zfarhad ashtariHow to run webrtcsinkHi, I'm a newcomer to Gstreamer and I just want to run the webrtcsink by following "https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/tree/main/net/webrtc". during the installation process, I faced some issues and all were solved...Hi, I'm a newcomer to Gstreamer and I just want to run the webrtcsink by following "https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/tree/main/net/webrtc". during the installation process, I faced some issues and all were solved but I still can't solve an issue that is reviewed in !1241 .
From what I found out, there are two solutions in order to tackle this problem.
The first one is installing GStreamer 1.22 and building libgstrswebrtc and libgstrsrtp plugins on top of that. Unfortunately, it's not possible because I work on Ubuntu 22.0.4 LTS, and when I use the apt library manager in order to install GStreamer, it will install GStreamer 1.20 which is not compatible with what I do ("https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/tree/main/net/webrtc"). So, I should change the source code by adding a macro for conditional compile, which is explained in !1241 .
The second solution is installing GStreamer 1.22 by making it from source code using meson builder. I did it but it didn't work properly and the problem still isn't solved but I wonder if I have made a mistake or not.
I would be thankful if you could tell me how I can solve this issue and which solution above, will help me.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/1006Diagonal VSYNC tearing line seen on NXP IMX8MM device (Vivante EGL)2023-09-06T07:59:04ZVincas DargisDiagonal VSYNC tearing line seen on NXP IMX8MM device (Vivante EGL)Our use case is to display RTSP video stream with `qmlglsink`. We've noticed that on some IMX8MM tablet there's diagonal VSYNC tearing line that we do not see in Debian Linux desktops with Intel graphics. I've discovered while using 1.22...Our use case is to display RTSP video stream with `qmlglsink`. We've noticed that on some IMX8MM tablet there's diagonal VSYNC tearing line that we do not see in Debian Linux desktops with Intel graphics. I've discovered while using 1.22.1, but issue persist with latest 1.22.5 too.
I can reproduce this with `glimagesink` outside of Qt application with this pipeline:
```
./gst-launch-1.0 rtspsrc "location=rtsp:..." protocols=tcp latency=200 drop-on-latency=true buffer-mode=slave ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! h264parse ! queue max-size-buffers=0 ! imxvpudec_h264 ! queue max-size-buffers=0 ! glimagesink
```
And I see tearing lines in different places (tear is "moving"):
![vsync_example_0](/uploads/d09d21ff1b72bbe0a1bf443934e604ab/vsync_example_0.png)
![vsync_example_1](/uploads/3aa98b13d1b58cb1bc9064dc28bb46f8/vsync_example_1.png)
I can see these diagonal lines with `videotestsrc` too, while avoiding HW decoding & rtsp & stuff:
```
./gst-launch-1.0 -v videotestsrc pattern=blink ! video/x-raw,width=1280,height=720 ! glimagesink
```
![vsync_example_2](/uploads/3d4cf600c4bf49e4835499858dae5617/vsync_example_2.png)
If I use `fbdevsink` instead, I do see horizontal (not diagonal as before) VSYNC tear like this:
```
./gst-launch-1.0 -v videotestsrc pattern=blink ! video/x-raw,width=1280,height=720 ! fbdevsink
```
![vsync_example_3](/uploads/e0fdced6a65d11672d250aa2c09c1fb8/vsync_example_3.png)
`glimagesink` uses `gldisplayvivfb0`:
```
0:00:00.135351738 24859 0xaaaafa99f270 INFO glcontext gstglcontext.c:348:gst_gl_context_new: creating a context for display <gldisplayvivfb0>, user choice:(null)
0:00:00.135668352 24859 0xaaaafa99f270 INFO glwindow gstglwindow.c:295:gst_gl_window_new: creating a window, user choice:(null)
0:00:00.136573447 24859 0xaaaafa952180 INFO glcontext gstglcontext.c:1319:gst_gl_context_create_thread:<glcontextegl0> Attempting to create opengl context. user chosen api(s) (any), compiled api support (gles2) d
isplay api (opengl opengl3 gles2)
0:00:00.145544523 24859 0xaaaafa952180 INFO glcontext gstglcontext_egl.c:901:gst_gl_context_egl_create_context: egl initialized, version: 1.5
0:00:00.146080005 24859 0xaaaafa952180 INFO glcontext gstglcontext_egl.c:1016:gst_gl_context_egl_create_context: Bound OpenGL|ES
0:00:00.146212876 24859 0xaaaafa952180 INFO glcontext gstglcontext_egl.c:744:gst_gl_context_egl_choose_config: config set: 33, 1
0:00:00.150108371 24859 0xaaaafa952180 INFO glcontext gstglcontext_egl.c:1056:gst_gl_context_egl_create_context: gl context created: 281473366367152
0:00:00.151999183 24859 0xaaaafa952180 INFO glcontext gstglcontext_egl.c:1154:gst_gl_context_egl_create_context: surface created
0:00:00.152109429 24859 0xaaaafa952180 INFO glcontext gstglcontext.c:1333:gst_gl_context_create_thread:<glcontextegl0> created context
0:00:00.153559006 24859 0xaaaafa952180 INFO glcontext gstglcontext.c:1349:gst_gl_context_create_thread:<glcontextegl0> available GL APIs: gles2
0:00:00.153946368 24859 0xaaaafa952180 INFO glcontext gstglcontext.c:1112:_create_context_info:<glcontextegl0> GL_VERSION: OpenGL ES 2.0 V6.4.3.p2.336687
0:00:00.153981992 24859 0xaaaafa952180 INFO glcontext gstglcontext.c:1114:_create_context_info:<glcontextegl0> GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 1.0.0
0:00:00.154003491 24859 0xaaaafa952180 INFO glcontext gstglcontext.c:1117:_create_context_info:<glcontextegl0> GL_VENDOR: Vivante Corporation
0:00:00.154022615 24859 0xaaaafa952180 INFO glcontext gstglcontext.c:1119:_create_context_info:<glcontextegl0> GL_RENDERER: Vivante GC7000NanoUltra
0:00:00.154537348 24859 0xaaaafa952180 INFO glcontext gstgldebug.c:338:_gst_gl_debug_enable:<glcontextegl0> No debugging support available
0:00:00.154568347 24859 0xaaaafa952180 INFO glcontext gstglcontext.c:1172:_unlock_create_thread:<glcontextegl0> gl thread running
0:00:00.154618971 24859 0xaaaafa99f270 INFO glcontext gstglcontext.c:1079:gst_gl_context_create:<glcontextegl0> gl thread created
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2958riff-media: The calculation for the bitrate is not correct2023-09-05T12:19:11Zshengqi2022riff-media: The calculation for the bitrate is not correctWhen audio format is DVI_ADPCM, the calculation for the bitrate is not the same as ffmpeg or media info tool.
For example, for the audio file I uploaded, the blockalign is 256, the channels number is 1, and the rate is 11025. As per th...When audio format is DVI_ADPCM, the calculation for the bitrate is not the same as ffmpeg or media info tool.
For example, for the audio file I uploaded, the blockalign is 256, the channels number is 1, and the rate is 11025. As per these parameters, GStreamer calculates the byterate as 11200 bytes/s, which is equivalent to 89.6 kb/s. However, the result from FFmpeg and the information provided by MediaInfo tool both indicate a bitrate of 44 kb/s.
I have some questions about the method used to calculate the value of `av_bps`. And What does `spb` represent, and why is the number of channels\*4 subtracted from `blockalign`?
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/gst-libs/gst/riff/riff-media.c?ref_type=heads#L1449
This discrepancy could result in a mismatch between the displayed total duration of the audio playback and its actual duration, like this:
![image.png](/uploads/b275966d64d3215c1289007488bf504d/image.png)
Gstreamer log:
```plaintext
0:00:00.515638769 897 0x1efb60 INFO riff riff-read.c:514:gst_riff_parse_strf_auds:<wavparse0> strf tag found in context auds:
0:00:00.515652385 897 0x1efb60 INFO riff riff-read.c:515:gst_riff_parse_strf_auds:<wavparse0> format 17
0:00:00.515664692 897 0x1efb60 INFO riff riff-read.c:516:gst_riff_parse_strf_auds:<wavparse0> channels 1
0:00:00.515677462 897 0x1efb60 INFO riff riff-read.c:517:gst_riff_parse_strf_auds:<wavparse0> rate 11025
0:00:00.515690000 897 0x1efb60 INFO riff riff-read.c:518:gst_riff_parse_strf_auds:<wavparse0> av_bps 5588
0:00:00.515702538 897 0x1efb60 INFO riff riff-read.c:519:gst_riff_parse_strf_auds:<wavparse0> blockalign 256
0:00:00.515714923 897 0x1efb60 INFO riff riff-read.c:520:gst_riff_parse_strf_auds:<wavparse0> bits/sample 4
0:00:00.515727538 897 0x1efb60 INFO riff riff-read.c:522:gst_riff_parse_strf_auds:<wavparse0> 2 bytes extradata
0:00:00.515739154 897 0x1efb60 LOG GST_BUFFER gstbuffer.c:780:_gst_buffer_free: finalize 0xb5b27540
0:00:00.515751538 897 0x1efb60 DEBUG wavparse gstwavparse.c:1164:gst_wavparse_stream_headers:<wavparse0> creating the caps
0:00:00.515765692 897 0x1efb60 DEBUG riff riff-media.c:1426:gst_riff_create_audio_caps: fixing av_bps to calculated value 11200 of IMA DVI ADPCM
0:00:00.515831077 897 0x1efb60 DEBUG wavparse gstwavparse.c:1230:gst_wavparse_stream_headers:<wavparse0> blockalign = 256
0:00:00.515847231 897 0x1efb60 DEBUG wavparse gstwavparse.c:1231:gst_wavparse_stream_headers:<wavparse0> width = 2048
0:00:00.515860231 897 0x1efb60 DEBUG wavparse gstwavparse.c:1232:gst_wavparse_stream_headers:<wavparse0> depth = 4
0:00:00.515872923 897 0x1efb60 DEBUG wavparse gstwavparse.c:1233:gst_wavparse_stream_headers:<wavparse0> av_bps = 11200
0:00:00.515885538 897 0x1efb60 DEBUG wavparse gstwavparse.c:1234:gst_wavparse_stream_headers:<wavparse0> frequency = 11025
0:00:00.515897846 897 0x1efb60 DEBUG wavparse gstwavparse.c:1235:gst_wavparse_stream_headers:<wavparse0> channels = 1
0:00:00.515919846 897 0x1efb60 DEBUG wavparse gstwavparse.c:1236:gst_wavparse_stream_headers:<wavparse0> bytes_per_sample = 256
0:00:00.515933846 897 0x1efb60 DEBUG wavparse gstwavparse.c:1242:gst_wavparse_stream_headers:<wavparse0> bps = 11200
```
FFmpeg result:
![image.png](/uploads/40b25a6ccedeb0b879be1e4ac0f2ad2b/image.png)
mediainfo tool result:
![image.png](/uploads/6b9cb966d397c9dfcba6f532b6896ca2/image.png)
[11khz_4bit_ima_adpcm_mono_44kbps.wav](/uploads/e71405c46b6f496d1d2946b43f6a9465/11khz_4bit_ima_adpcm_mono_44kbps.wav)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2956Enhancing GStreamer's MIDI playback support2023-10-09T13:04:39ZPeter OccilEnhancing GStreamer's MIDI playback supportThe following is an enhancement request on GStreamer's support for playing standard MIDI files (.mid):
- One or more additional plugins that support software synthesis of standard MIDI files using other _instrument source_ formats besid...The following is an enhancement request on GStreamer's support for playing standard MIDI files (.mid):
- One or more additional plugins that support software synthesis of standard MIDI files using other _instrument source_ formats besides SoundFont 2 (e.g., downloadable sounds [.dls]; .sbk; Timidity's patch format; OPL2, OPL3, and other FM instrument banks). (I know that the `fluidsynth` plugin supports SoundFont 2.) This could allow a media player to offer a preference for setting the file path for the instrument source (instrument sound bank). In this sense, the source code in the projects _libADLMIDI_, _libOPNMIDI_, and _OPL3BankEditor_ may be useful here.
- Support for seeking within a standard MIDI file such that a pause and resume function can be offered by a media player.
- Support for popular looping conventions seen in MIDI files.
EDIT (Sep. 7): It seems that the `fluidsynth` library used by the `fluidsynth` plugin already supports .dls (downloadable sounds), not just SoundFont 2, in the `soundfont` parameter. In that case, the parameter's description should be changed in order to note the instrument sources supported by the `fluidsynth` plugin, not just SoundFont 2.
EDIT (Oct. 9): Edited.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2955hlssink2 get-fragment-stream callback does not work if I call with after flag...2023-09-04T17:13:01ZGuru Govindanhlssink2 get-fragment-stream callback does not work if I call with after flag set to trueGstreamer version: 1.20.5
I have a rust pipeline that needs to know when a ts segment is written so that we can do some additional processing. I setup a signal callback for the "get-fragment-stream" and set the after value boolean to t...Gstreamer version: 1.20.5
I have a rust pipeline that needs to know when a ts segment is written so that we can do some additional processing. I setup a signal callback for the "get-fragment-stream" and set the after value boolean to true so that I get notified after the default callback is called.
But if I set the after to true, I dont get notified at all after the file segments are written. It works if I set the flag to false that is before calling the default implementation.
The following is a code snippet of how it is implemented. I tried both the "connect" and "connect_closure" and it is the same result.
```
vod_sink.connect_closure(
"get-fragment-stream",
true, // after
glib::closure!(
move |_elem: &Element, filename: &str| -> FileOutputStream {
//TODO: use the file name to probe the file
let file = File::for_path(filename);
log::info!("vod-sink connect_closure callback filename={}", filename);
match fs::metadata(&filename) {
Ok(info) => log::info!("found the file in the path created={:?}", info.created()),
Err(e) => log::error!("The file is not yet created={}", filename),
}
file.replace(None, false, FileCreateFlags::NONE, Cancellable::NONE).unwrap()
}),
);
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2952va: Decoders fails to negotated in playbin22024-02-20T14:27:42ZNicolas Dufresneva: Decoders fails to negotated in playbin2One regression from adding DMABuf modifiers is that playbin2 results in not-negotiated. One thing about the dmabuf caps feature and modifiers is that it strictly require GstVideoMeta support. I've used this patch to verify this thought:
...One regression from adding DMABuf modifiers is that playbin2 results in not-negotiated. One thing about the dmabuf caps feature and modifiers is that it strictly require GstVideoMeta support. I've used this patch to verify this thought:
```diff
diff --git a/subprojects/gst-integration-testsuites/medias b/subprojects/gst-integration-testsuites/medias
index 121f890949..b4dd49b992 160000
--- a/subprojects/gst-integration-testsuites/medias
+++ b/subprojects/gst-integration-testsuites/medias
@@ -1 +1 @@
-Subproject commit 121f8909493df214564c3db7fbba1dcb9217348e
+Subproject commit b4dd49b992efde30a049f9813d08b539edbcaccd
diff --git a/subprojects/gst-plugins-bad/sys/va/gstvabasedec.c b/subprojects/gst-plugins-bad/sys/va/gstvabasedec.c
index ad1e4fd5f9..c2be43de40 100644
--- a/subprojects/gst-plugins-bad/sys/va/gstvabasedec.c
+++ b/subprojects/gst-plugins-bad/sys/va/gstvabasedec.c
@@ -619,6 +619,9 @@ gst_va_base_dec_decide_allocation (GstVideoDecoder * decoder, GstQuery * query)
else
gst_query_add_allocation_pool (query, pool, size, min, max);
+ if (!has_videometa)
+ GST_WARNING("disable dmabuf");
+
base->copy_frames = (!has_videometa && gst_va_pool_requires_video_meta (pool)
&& gst_caps_is_raw (caps));
if (base->copy_frames) {
```
Looking at this decide_allocation, its incomplete since even copy frame cannot work with modifiers. So I think we should add a way to disable dmabuf whenever there is no VideoMeta support. This should fix the negotiation error and regain slow performance. At the moment, it seems like the decoder just blindly produce dmabuf. Pehaps something deeper, but this needs fixing for sure.
cc @vjaquez @He_JunyanNicolas DufresneNicolas Dufresne