GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-10-20T07:34:15Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/824add support for DASH events2021-10-20T07:34:15ZBugzilla Migration Useradd support for DASH events## Submitted by A Ashley
**[Link to original bug (#796923)](https://bugzilla.gnome.org/show_bug.cgi?id=796923)**
## Description
Section 5.10.3 (Inband Event Signalling) of the MPEG DASH specification defines a new box type "emsg" th...## Submitted by A Ashley
**[Link to original bug (#796923)](https://bugzilla.gnome.org/show_bug.cgi?id=796923)**
## Description
Section 5.10.3 (Inband Event Signalling) of the MPEG DASH specification defines a new box type "emsg" that is used to convey events. These events can be used to signal changes in the DASH stream, convey metadata or provide application specific information.
Section 5.10.4 (DASH-specific events) defines a method for an in-band signal to indicate that a live DASH stream has finished.
Currently there is no support in qtdemux or dashdemux for these DASH events.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/763compositor pipeline stalling pipeline at "Redistribute latency"2021-09-24T14:36:35ZBugzilla Migration Usercompositor pipeline stalling pipeline at "Redistribute latency"## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#796927)](https://bugzilla.gnome.org/show_bug.cgi?id=796927)**
## Description
I am facing an unclear stall of a pipeline involving a raw h264 file source, vaa...## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#796927)](https://bugzilla.gnome.org/show_bug.cgi?id=796927)**
## Description
I am facing an unclear stall of a pipeline involving a raw h264 file source, vaapi decoding and compositor. This affects 1.14.2 and master.
1) generate a sample
gst-launch-1.0 videotestsrc num-buffers=30 ! "video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, framerate=(fraction)30/1" ! vaapih264enc bitrate=16000 keyframe-period=30 rate-control=2 aud=true ! "video/x-h264,profile=baseline" ! filesink location=/tmp/sample.h264
2) launch this:
gst-launch-1.0 filesrc location=/tmp/sample.h264 ! h264parse ! vaapih264dec ! vaapipostproc ! queue ! vmix. compositor name=vmix ! "video/x-raw, format=(string)NV12, width=(int)3840, height=(int)2160, framerate=(fraction)30, colorimetry=(string)bt709" ! tee name=tvmix tvmix. ! queue name=qmain1080p ! videorate ! queue name=qscale1080p ! videoscale ! queue name=qcsp1080 ! videoconvert ! "video/x-raw, format=(string)NV12, width=(int)1920, height=(int)1080, framerate=(fraction)30, pixel-aspect-ratio=(fraction)1/1" ! fakesink tvmix. ! queue ! fakesink sync=False
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapipostproc0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0";
Got context from element 'vaapipostproc0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0";
Redistribute latency...
Redistribute latency...
[STALLED]
I can work around it by:
- inserting identity or videorate right after vaapipostproc
- setting drop-only=true to videorate
- removing the trailing tvmix. ! queue ! fakesink sync=False
- replacing vaapih264dec and postproc by software components (like avdec_h264 or openh264dec)
The last items in the debug log are:
0:00:01.131839487 6613 0x5599f71268a0 DEBUG GST_PADS gstpad.c:4072:gst_pad_query:<qmain1080p:sink> sent query 0x7f0f84006de0 (allocation), result 1
0:00:01.131852946 6613 0x5599f71268a0 DEBUG tee gsttee.c:637:gst_tee_query_allocation:`<tvmix>` Aggregating AllocationParams align=15 prefix=0 padding=0
0:00:01.131863008 6613 0x5599f71268a0 DEBUG tee gsttee.c:659:gst_tee_query_allocation:`<tvmix>` Aggregating allocation pool size=12441600 min_buffers=1
0:00:01.131878205 6613 0x5599f71268a0 DEBUG tee gsttee.c:595:gst_tee_query_allocation:`<tvmix>` Aggregating allocation from pad tvmix:src_1
0:00:01.131889278 6613 0x5599f71268a0 DEBUG query gstquery.c:678:gst_query_new_custom: creating new query 0x7f0f84006d40 allocation
0:00:01.131900974 6613 0x5599f71268a0 DEBUG GST_PADS gstpad.c:4049:gst_pad_query:<queue4:sink> doing query 0x7f0f84006d40 (allocation)
[STALLED]https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/768Oggdemux seeking fail with theora2021-09-24T13:25:54ZEdward HerveyOggdemux seeking fail with theoraThis is the major reason the theora rtsp validate tests fail
In a nutshell:
* Seek to a position via rtsp-server
* oggdemux in rtsp-server has an off-by-one error in where the keyframe *really* is
* oggdemux outputs a wrong (off by one ...This is the major reason the theora rtsp validate tests fail
In a nutshell:
* Seek to a position via rtsp-server
* oggdemux in rtsp-server has an off-by-one error in where the keyframe *really* is
* oggdemux outputs a wrong (off by one frame duration) segment start value
* oggdemux starts outputting from the page containing that (off by one) keyframe
* payloader (rightfully) doesn't set any PTS
* udpsink (rightfully) drops the out-of-segment buffer
This ends up in having to wait a long time for the next keyframe to arrive, even potentially locking the player client-side (audio arrives, but video never arrives before maximum buffering).
Note that one wouldn't see this issue with regular (non-rtsp) playback because the demuxer would (almost all the time) output from the proper page, so the decoder would still have the data (even though it would end up clipping that first frame).
I've lost my sanity trying to figure out what would cause that off-by-one error, someone else please look into it.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/765souphttpsrc: "don't fail when seeking past the end of the content" needs a test2021-09-24T13:33:57ZSebastian Drögesouphttpsrc: "don't fail when seeking past the end of the content" needs a testThe following discussion from !385 should be addressed:
- [ ] @ndufresne started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/385#note_399908): (+4 comments)
> That looks aligned with t...The following discussion from !385 should be addressed:
- [ ] @ndufresne started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/385#note_399908): (+4 comments)
> That looks aligned with the intent. Do you think you could contribute a test into https://gitlab.freedesktop.org/gstreamer/gst-integration-testsuites ? This is a good candidate for gst-validate since seeking passed the end of a file seems to be something we'd like to have consistent across all sources/formats.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/769basetextoverlay blocks on text pad when 'silent' property is true2021-09-24T13:25:54ZChris Ayoupbasetextoverlay blocks on text pad when 'silent' property is trueIf the `silent` property is set to true, basetextoverlay simply pushes video buffers (https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/ext/pango/gstbasetextoverlay.c#L2795) and `gst_base_text_overlay_pop_text()` ne...If the `silent` property is set to true, basetextoverlay simply pushes video buffers (https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/ext/pango/gstbasetextoverlay.c#L2795) and `gst_base_text_overlay_pop_text()` never gets called. As a result, when buffers are being fed to the `text_sink`, `gst_base_text_overlay_text_chain()` blocks forever as an existing buffer never got consumed (https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/ext/pango/gstbasetextoverlay.c#L2671-2681 ).
I wasn't expecting this to happen (until I read the code, of course). I expected the text to continue to be consumed silently. Is this intentional behaviour?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/766matroskaparse/matroskademux Fails when TrackUID is 02021-10-01T00:23:56Zahokamatroskaparse/matroskademux Fails when TrackUID is 0When loading a webm/mkv file with a TrackUID of 0 gstreamer fails to play the file.
I checked the Matroska specification and saw that this should be the case, but files with TrackUID's of 0 still play in many other applications (Chrome, ...When loading a webm/mkv file with a TrackUID of 0 gstreamer fails to play the file.
I checked the Matroska specification and saw that this should be the case, but files with TrackUID's of 0 still play in many other applications (Chrome, Firefox, mpv, ffplay) to name a few.
Instead of the erroring out in this situation, would it not be better to just throw a warning and continue?
Attached is a webm file which triggers the described event.
![test](/uploads/57813d9c2bed6a685c2c2ef8f606c1b6/test.webm)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/765waylandsink: add property to set window resolution2021-09-24T14:36:35ZBugzilla Migration Userwaylandsink: add property to set window resolution## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#796932)](https://bugzilla.gnome.org/show_bug.cgi?id=796932)**
## Description
add two property for user to set window resolution when using waylandsink in cmdline## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#796932)](https://bugzilla.gnome.org/show_bug.cgi?id=796932)**
## Description
add two property for user to set window resolution when using waylandsink in cmdlinehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/770opus: Multichannel audio not correctly reordered2022-07-11T23:20:58ZIgnazioopus: Multichannel audio not correctly reorderedWhen we try to encode and then decode a 7.1 multichannel audio stream with opus the order of the decoded channels is not the original one.
The issue can be reproduced on both Windows and Linux by comparing the audio reproduced on a 7.1 ...When we try to encode and then decode a 7.1 multichannel audio stream with opus the order of the decoded channels is not the original one.
The issue can be reproduced on both Windows and Linux by comparing the audio reproduced on a 7.1 audio device using the subsequent pipelines and this sample wav file: https://www2.iis.fraunhofer.de/AAC/7.1auditionOutLeader%20v2.wav
`
gst-launch-1.0 -vv -m filesrc location=sample_7_1.wav ! decodebin ! audioconvert ! autoaudiosink
`
`
gst-launch-1.0 -vv -m filesrc location=sample_7_1.wav ! decodebin ! audioconvert ! opusenc bitrate=128000 ! queue ! opusdec ! audioconvert ! autoaudiosink
`
When opusenc + opusdec are used the source channels are played in this order:
- Front-Left: OK
- Front-Right: OK
- Front-Central -> Sise-Left Speaker
- LFE -> Side-Right Speaker
- Rear-Left -> Front-Central Speaker
- Rear-Right -> Subwoofer
- Side-Left -> Rear-Left Speaker
- Side-Right -> Rear-Right Speaker
According the encoder's caps the 8 channel mapping is `<0, 6, 1, 4, 5, 2, 3, 7>` which corresponds to map the
`{FL, FR, RL, RR, SL, SR, FC, LFE}` encoded channels to the vorbis order `{FL, FC, FR, SL, SR, RL, RR, LFE}`.
The issue seem not raised with 6 channels
However during some tests we were able to play the channels in the correct speakers by using the `<0, 4, 1, 2, 3, 6, 7, 5>` mapping.
Our suspect is that opusenc is encoding the channels in an unexpected order like `{FL, FR, SL, SR, FC, LFE, RL, RR}`.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/766avfassetsrc: deadlock on processing (flushing) seek event2021-09-24T14:36:36ZBugzilla Migration Useravfassetsrc: deadlock on processing (flushing) seek event## Submitted by Stephan Hesse `@tchakabam`
**[Link to original bug (#796933)](https://bugzilla.gnome.org/show_bug.cgi?id=796933)**
## Description
Running on XCode Simulator any iDevice model with iOS v11.4 as well as real devices (f...## Submitted by Stephan Hesse `@tchakabam`
**[Link to original bug (#796933)](https://bugzilla.gnome.org/show_bug.cgi?id=796933)**
## Description
Running on XCode Simulator any iDevice model with iOS v11.4 as well as real devices (for example iPhone 7 with v11.4.1):
Reproduce:
When playing a local MP3 or MP4 file via playbin, and filesrc factory-rank is downgraded against avfassetsrc (like it is done in the current gst-examples iOS playback project) performing any flushing seek will cause a deadlock to happen.
When processing the seek event, we are waiting somewhere after `avfassetsrc.m:726:gst_avf_asset_src_stop_reading`
...but I haven't investigated the exact cause yet. Someone who has touched this code before has an idea here?
See logs here: https://gist.github.com/tchakabam/0b277e1947ba51395399206725049171
A local file URL can be bundled in the project `Resources` folder and passed to the player conveniently like so:
```
NSString *localFile = @"guitars.m4a";
NSURL *localURL = [[NSBundle mainBundle] URLForResource: localFile withExtension:nil];
g_object_set (player, "uri", [localURL.absoluteString UTF8String], NULL);
```
... just adding that snippet, because the current gst-examples code doesn't include any local files for testing (only the deprecated media library stuff).
We suspect this issue might be result of Apple-side API implementation having evolved since previous versions when this plugin was made and that it used to work back then. Could that be possible?
Our current workaround is to use the filesrc instead to access local media, which results in a decodebin/atdec based pipeline, which as expected works fine.
Some more questions:
We were also wondering what the advantages are to use a monolithic approach to reading/decoding as it is done with avfassetsrc compared to filesrc/decodebin based pipeline? We suspect performance is more optimal when using the native system component to do the whole job, but is it really noticeable? When playing HLS via adaptivedemux for example we don't seem having to worry about that, and it is using the same pipeline downstream, while it's more logic in adaptivedemux than what happens in filesrc I would guess. Or is there such a large overhead in accessing files with filesrc compared to AVAssetReader? Should we worry about using the filesrc mode and actively try to fix this so our app can use avfassetsrc instead?
Version: 1.14.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/767srtpdec: example pipelines do not work, caps are not detected2022-05-26T07:42:13ZBugzilla Migration Usersrtpdec: example pipelines do not work, caps are not detected## Submitted by Kevin Mullican
**[Link to original bug (#796941)](https://bugzilla.gnome.org/show_bug.cgi?id=796941)**
## Description
The example pipelines on the docs page https://gstreamer.freedesktop.org/data/doc/gstreamer/head/g...## Submitted by Kevin Mullican
**[Link to original bug (#796941)](https://bugzilla.gnome.org/show_bug.cgi?id=796941)**
## Description
The example pipelines on the docs page https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-srtpdec.html do not work.
System:
$ uname -a
Linux big-p 4.4.0-17134-Microsoft` #137`-Microsoft Thu Jun 14 18:46:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
$ dpkg -l | grep gst | grep bad
ii gstreamer1.0-plugins-bad:amd64 1.8.3-1ubuntu0.2 amd64 GStreamer plugins from the "bad" set
source:
gst-launch-1.0 audiotestsrc ! alawenc ! rtppcmapay ! 'application/x-rtp, payload=(int)8, ssrc=(uint)1356955624' ! srtpenc key="012345678901234567890123456789012345678901234567890123456789" ! udpsink port=5004
dest:
GST_DEBUG=srtpdec:5 gst-launch-1.0 udpsrc port=5004 caps='application/x-srtp, payload=(int)8, ssrc=(uint)1356955624, srtp-key=(buffer)012345678901234567890123456789012345678901234567890123456789, srtp-cipher=(string)aes-128-icm, srtp-auth=(string)hmac-sha1-80, srtcp-cipher=(string)aes-128-icm, srtcp-auth=(string)hmac-sha1-80' ! srtpdec ! rtppcmadepay ! alawdec ! pulsesink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:00.080196000 5703 0x26388f0 WARN srtpdec gstsrtpdec.c:770:request_key_with_signal:`<srtpdec0>` Could not get caps for stream with SSRC 1356955624
0:00:00.083958000 5703 0x26388f0 WARN srtpdec gstsrtpdec.c:1212:gst_srtp_dec_chain:`<srtpdec0>` Invalid buffer, dropping
...
repeats forever
Version: 1.8.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/772Audio stuttering with pulseaudio , debug reports pulse pulsesink.c:702 ...Got...2021-09-24T13:25:55ZMarius CirstaAudio stuttering with pulseaudio , debug reports pulse pulsesink.c:702 ...Got underflow I am playing a stream with pulseaudio like this:
gst-launch-1.0 playbin -v --gst-fatal-warnings --gst-debug-level=4 uri=https://edge214.rcs-rds.ro/V4-3036850-beb1b900f18955083bcd7cb147a0bba4-1495840202-0-1591903019-4-digi24/digi24/... I am playing a stream with pulseaudio like this:
gst-launch-1.0 playbin -v --gst-fatal-warnings --gst-debug-level=4 uri=https://edge214.rcs-rds.ro/V4-3036850-beb1b900f18955083bcd7cb147a0bba4-1495840202-0-1591903019-4-digi24/digi24/digi24-abr.m3u8
Unfortunately the stream has some location restrictions so you might not be able to get it to play. From time to time, randomly I have 1-2 seconds when the audio is not playing but it recovers. At exactly that time the debug reports error in the console :
0:04:32.827319214 14791 0x55a32c1a1b30 WARN pulse pulsesink.c:702:gst_pulsering_stream_underflow_cb:<pulsesink1> Got underflow
It then recovers and plays normally until it happens again.
I've attached the full output from the console.
I am using Manjaro Linux with versions:
gstreamer: 1.16.2-2
pulseaudio: 13.0-3
I can probably work around this by using ALSA output but I still think it should work. Playing the same stream with mplayer ( or mpv ) [gstLog.txt](/uploads/d9c596739f0addb1033a5748a2f1210d/gstLog.txt)works without any audio interruptions.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/769rtpbin: warning: rtpsource.c:XXXX:calculate_jitter: cannot get clock-rate for...2021-09-24T13:33:58ZPeter Srtpbin: warning: rtpsource.c:XXXX:calculate_jitter: cannot get clock-rate for pt NNI've been trying to debug other issues I've been having by setting GST_DEBUG=2, however the logs were getting spammed with the following warning message repeatedly. (the full log is attached)
```
0:00:00.159406572 5991 0x1422800 WARN ...I've been trying to debug other issues I've been having by setting GST_DEBUG=2, however the logs were getting spammed with the following warning message repeatedly. (the full log is attached)
```
0:00:00.159406572 5991 0x1422800 WARN rtpsource rtpsource.c:1013:calculate_jitter: cannot get clock-rate for pt 96
```
Digging into the related code it seems that for whatever reason rtpsource is unable to obtain the clock-rate through the use of callbacks. I don't have the log handy but I have seen that in one different test case it was able to correctly get the clock-rate as part of rtp_source_update_caps, but then would some how set it back to -1 and then continually warn me that it couldn't get it as part of the callback from fetch_clock_rate_from_payload.
```
0:00:00.139710579 5991 0x1422800 DEBUG rtpsource rtpsource.c:1058:init_seq: base_seq 3737
0:00:00.139730486 5991 0x1422800 DEBUG rtpsource rtpsource.c:1137:update_receiver_stats: probation: seqnr 3737 == expected 3737
0:00:00.139748005 5991 0x1422800 DEBUG rtpsource rtpsource.c:1151:update_receiver_stats: probation 1: queue packet
0:00:00.158875276 5991 0x1422800 DEBUG rtpbin gstrtpbin.c:3481:pt_map_requested:<rtpbin> payload map requested for pt 96 in session 0
0:00:00.158921295 5991 0x1422800 DEBUG rtpbin gstrtpbin.c:881:get_pt_map: searching pt 96 in cache
0:00:00.158970998 5991 0x1422800 DEBUG rtpbin gstrtpbin.c:894:get_pt_map: emitting signal for pt 96 in session 0
0:00:00.159028406 5991 0x1422800 DEBUG rtpbin gstrtpbin.c:945:get_pt_map: no pt map could be obtained
0:00:00.159078202 5991 0x1422800 DEBUG rtpbin gstrtpbin.c:3492:pt_map_requested:<rtpbin> could not get caps
0:00:00.159130665 5991 0x1422800 DEBUG rtpsession gstrtpsession.c:1667:gst_rtp_session_get_caps_for_pt:<rtpsession0> could not get caps
0:00:00.159178035 5991 0x1422800 DEBUG rtpsession rtpsession.c:1542:source_clock_rate: got clock-rate -1 for pt 96
0:00:00.159225554 5991 0x1422800 DEBUG rtpsource rtpsource.c:944:fetch_clock_rate_from_payload: got clock-rate -1
0:00:00.159275609 5991 0x1422800 DEBUG rtpsource rtpsource.c:1137:update_receiver_stats: probation: seqnr 3738 == expected 3738
0:00:00.159315794 5991 0x1422800 DEBUG rtpsource rtpsource.c:1146:update_receiver_stats: probation done!
0:00:00.159363479 5991 0x1422800 DEBUG rtpsource rtpsource.c:1058:init_seq: base_seq 3738
0:00:00.159406572 5991 0x1422800 WARN rtpsource rtpsource.c:1013:calculate_jitter: cannot get clock-rate for pt 96
```
Here are the two commands used. (each run in a different terminal).
```
gst-launch-1.0 rtpbin name=rtpbin \
audiotestsrc ! amrnbenc ! rtpamrpay ! rtpbin.send_rtp_sink_0 \
rtpbin.send_rtp_src_0 ! udpsink host=127.0.0.1 port=5002 \
rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5003 sync=false async=false \
udpsrc port=5007 ! rtpbin.recv_rtcp_sink_0
gst-launch-1.0 -v rtpbin name=rtpbin \
udpsrc caps="application/x-rtp,media=(string)audio,clock-rate=(int)8000,encoding-name=(string)AMR,encoding-params=(string)1,octet-align=(string)1" \
port=5002 ! rtpbin.recv_rtp_sink_0 \
rtpbin. ! rtpamrdepay ! amrnbdec ! alsasink \
udpsrc port=5003 ! rtpbin.recv_rtcp_sink_0 \
rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5007 sync=false async=false
```
The full error log with "export GST_DEBUG=2,rtp*:5" is attached to help see the full context.
[simple_example_cannot_get_clock_rate_for_pt.txt](/uploads/b5d33f0f5efcc5465aff7c51e91d8ceb/simple_example_cannot_get_clock_rate_for_pt.txt)
I'm not really sure why it keeps saying "no pt map could be obtained" when the caps are specified on the udpsrc.
I also tried writing a custom program where I implement the callback for "request-pt-map" but it didn't seem to have any effect. I'm not sure if I needed to force clear the pt cache with "clear-pt-map" or not.
Anyways I would have thought the example provided above should work fine as the cap is available for the udpsrc, and the rtpjitterbuffer has not difficulty getting the clock-rate from the caps.
```
0:00:00.162786993 5991 0x1422800 DEBUG rtpjitterbuffer gstrtpjitterbuffer.c:1408:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> got caps application/x-rtp, media=(string)audio, clock-rate=(int)8000, encoding-name=(string)AMR, encoding-params=(string)1, octet-align=(string)1, ssrc=(uint)2921936800
0:00:00.162815456 5991 0x1422800 DEBUG rtpjitterbuffer gstrtpjitterbuffer.c:1430:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> got clock-rate 8000
```
Let me know if there's any additional information I can provide that would help me determine if I am just doing something wrong or if there is some issue causing rtpbin to not be able to supply the caps to rtpsession and rtpsource (perhaps due to missing callbacks).
I've reproduced this on 1.14, 1.16.2 and 1.17.2.1 (the latest master)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/768facedetect: handle haardetect max-size settings in plugin properties2023-03-13T14:39:06ZBugzilla Migration Userfacedetect: handle haardetect max-size settings in plugin properties## Submitted by flavie lancereau
**[Link to original bug (#796942)](https://bugzilla.gnome.org/show_bug.cgi?id=796942)**
## Description
Since version 2.2 of opencv, a parameter appeared in the haardetect function, this is the maximu...## Submitted by flavie lancereau
**[Link to original bug (#796942)](https://bugzilla.gnome.org/show_bug.cgi?id=796942)**
## Description
Since version 2.2 of opencv, a parameter appeared in the haardetect function, this is the maximum size. This one allows to limit the number of iteration of the search and thus to optimize this one. By default in gstreamer this parameter is set to CvSize(0,0) so no limitation, however it would be useful to be able to modify it in the plugin properties.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/770souphttpsrc: Dynamic blocksize adjustment constantly increases blocksize, cau...2021-09-24T13:33:59ZCarlos Rafael Gianisouphttpsrc: Dynamic blocksize adjustment constantly increases blocksize, causing problems with queue2 bufferingIn a pipeline with souphttpsrc and a downstream queue2 element, souphttpsrc's dynamic blocksize adjustment can cause problems, because the blocksize constantly increases.
I was able to see the constant increases with this test command l...In a pipeline with souphttpsrc and a downstream queue2 element, souphttpsrc's dynamic blocksize adjustment can cause problems, because the blocksize constantly increases.
I was able to see the constant increases with this test command line:
gst-launch-1.0 souphttpsrc location="<HTTP audio stream URL>" ! identity silent=false ! queue2 max-size-buffers=1 max-size-bytes=0 max-size-time=0 ! decodebin ! fakesink sync=true -v
Result:
```
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (32768 bytes, dts: none, pts: none, duration: none, offset: 39232, offset_end: -1, flags: 00000000 , meta: none) 0x7f7c3ae520
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (65536 bytes, dts: none, pts: none, duration: none, offset: 72000, offset_end: -1, flags: 00000000 , meta: none) 0x7f7c3ae630
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (131072 bytes, dts: none, pts: none, duration: none, offset: 137536, offset_end: -1, flags: 00000000 , meta: none) 0x7f840484b0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (238416 bytes, dts: none, pts: none, duration: none, offset: 268608, offset_end: -1, flags: 00000000 , meta: none) 0x7f840485c0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (262144 bytes, dts: none, pts: none, duration: none, offset: 507024, offset_end: -1, flags: 00000000 , meta: none) 0x7f840486d0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (524288 bytes, dts: none, pts: none, duration: none, offset: 769168, offset_end: -1, flags: 00000000 , meta: none) 0x7f840487e0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (1048576 bytes, dts: none, pts: none, duration: none, offset: 1293456, offset_end: -1, flags: 00000000 , meta: none) 0x7f840488f0
```
I then disabled the dynamic blocksize adjustment in souphttpsrc to verify. Result:
```
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (8192 bytes, dts: none, pts: none, duration: none, offset: 6952, offset_end: -1, flags: 00000000 , meta: none) 0x7f905c3300
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (13416 bytes, dts: none, pts: none, duration: none, offset: 15144, offset_end: -1, flags: 00000000 , meta: none) 0x7f905c3410
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (7140 bytes, dts: none, pts: none, duration: none, offset: 28560, offset_end: -1, flags: 00000000 , meta: none) 0x7f905c3520
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (4284 bytes, dts: none, pts: none, duration: none, offset: 35700, offset_end: -1, flags: 00000000 , meta: none) 0x7f905c3630
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (11424 bytes, dts: none, pts: none, duration: none, offset: 39984, offset_end: -1, flags: 00000000 , meta: none) 0x7f980494b0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (7140 bytes, dts: none, pts: none, duration: none, offset: 51408, offset_end: -1, flags: 00000000 , meta: none) 0x7f980495c0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (5712 bytes, dts: none, pts: none, duration: none, offset: 58548, offset_end: -1, flags: 00000000 , meta: none) 0x7f980496d0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (4284 bytes, dts: none, pts: none, duration: none, offset: 64260, offset_end: -1, flags: 00000000 , meta: none) 0x7f980497e0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (1428 bytes, dts: none, pts: none, duration: none, offset: 68544, offset_end: -1, flags: 00000000 , meta: none) 0x7f980498f0
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (2856 bytes, dts: none, pts: none, duration: none, offset: 69972, offset_end: -1, flags: 00000000 , meta: none) 0x7f98049a00
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (4284 bytes, dts: none, pts: none, duration: none, offset: 72828, offset_end: -1, flags: 00000000 , meta: none) 0x7f98049b10
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (2856 bytes, dts: none, pts: none, duration: none, offset: 77112, offset_end: -1, flags: 00000000 , meta: none) 0x7f98049c20
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (5712 bytes, dts: none, pts: none, duration: none, offset: 79968, offset_end: -1, flags: 00000000 , meta: none) 0x7f98049d30
```
Commit 1081a2ee50885f69375f12144bda6ae3bf3c3498 in gst-plugins-good at least applies some degree of limitation, but the buffer size still gets big enough to match the capacity of queue2. The result is that in typical HTTP streaming pipelines, the queue2 then only has room for one incoming buffer, so the buffer fill level constantly switches between 0% and 100%. (Note: The test pipeline above artificially limits the queue2 capacity to 1 buffer, but this is only for testing purposes.) Since applications typically pause when the buffering message reports <100%, this ultimately results in a stuttering playback, because the player pauses & unpauses all the time.
The proper solution perhaps would be a new type of query sent downstream by souphttpsrc to ask what max buffer size is allowed. If queue2 exists downstream, it could then pick a number that guarantees that at least N buffers fit into it. Aside from that, some sort of "max-dynamic-blocksize" property would perhaps make sense. It would act as a hard limit for dynamically adjusted buffer sizes. Default value 0 (= no limit). If it is set to a value smaller than that of the blocksize property, it would result in a GObject warning (since that would make no sense).https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/775glwindow_win32: Possible deadlock when drawing on external HWND2021-09-24T13:25:56ZSeungha Yangseungha@centricular.comglwindow_win32: Possible deadlock when drawing on external HWNDWhen [subclassing](https://docs.microsoft.com/en-us/windows/win32/winmsg/about-window-procedures#window-procedure-subclassing) is used and also if parent window and child window are running on different thread, we should be careful to im...When [subclassing](https://docs.microsoft.com/en-us/windows/win32/winmsg/about-window-procedures#window-procedure-subclassing) is used and also if parent window and child window are running on different thread, we should be careful to implement that as it has a chance to cause deadlock in any cases (i.e., parent window thread and child window thread are waiting each other)
In case of d3d11videosink, we avoided the issue by creating child window on parent window's thread so it would not cause thread issue. And d3dvideosink will be running on external window's thread so it's deadlock free.
We need to investigate how to avoid such deadlock with glimagesink on Windows.
Some references
- https://docs.microsoft.com/en-us/windows/win32/procthread/creating-windows-in-threads
- https://stackoverflow.com/questions/41337948/how-to-display-a-modal-dialog-window-from-another-process
- https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1299https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3066qtdemux: Add support for DNxHR2023-10-24T10:34:32ZAndrew Howardqtdemux: Add support for DNxHRUsing GStreamer 1.16.2 for thumbnailing in Photo Mechanic, it does not appear that files from the Atomos Shogun 7 are support by GStreamer.
Filing this request on behalf of a customer, who shared the attached file that was generated by...Using GStreamer 1.16.2 for thumbnailing in Photo Mechanic, it does not appear that files from the Atomos Shogun 7 are support by GStreamer.
Filing this request on behalf of a customer, who shared the attached file that was generated by this device: ![JOA_S001_S001_T004](/uploads/bc6849e3d4de8f25f5c0d04455ee172c/JOA_S001_S001_T004.MOV)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/771openslessink: Equalizer support2021-09-24T14:36:37ZBugzilla Migration Useropenslessink: Equalizer support## Submitted by barunsingh
**[Link to original bug (#796970)](https://bugzilla.gnome.org/show_bug.cgi?id=796970)**
## Description
Hi All,
Current implementation of opensles audio sink element does not have any implementation...## Submitted by barunsingh
**[Link to original bug (#796970)](https://bugzilla.gnome.org/show_bug.cgi?id=796970)**
## Description
Hi All,
Current implementation of opensles audio sink element does not have any implementation of audio effects as opensles provides. I was looking into the source code, and it seems that we can add equalizer support along with interfaces in this elements.
Please suggest further.
Thanks.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/776gstaudiobasesrc: skew handling if we are ahead of ringbuffer missing2021-09-24T13:25:56ZDanny Smithgstaudiobasesrc: skew handling if we are ahead of ringbuffer missingIn our pipeline ( "audio hw" -> alsasrc -> .. -> udpsink ) we are taking samples from the audio interface and transmitting them using RTP.
The audio codec clock and pipeline clock are not derived from the same clock and thus have a diff...In our pipeline ( "audio hw" -> alsasrc -> .. -> udpsink ) we are taking samples from the audio interface and transmitting them using RTP.
The audio codec clock and pipeline clock are not derived from the same clock and thus have a differing view on the sample rate.
This introduces skew and if the skew is positive i.e. the audio codec is running slower than the pipeline clock it works as expected. If the codec clock is running slightly faster than the pipeline clock, buffers start accumulating in the pipeline and after a while no audio is rendered.
We are using the default slave method "GST_AUDIO_BASE_SRC_SLAVE_SKEW". When looking at the code we can see that the case where segment_skew is positive is handled (segment_skew >= ringbuffer->spec.segtotal) but not the case where the segment_skew is negative.
Should this be addressed or is there another way to handle this case in the pipeline?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/774H264 compatibility issue with RTP (no window pops up)2021-09-24T13:34:00ZFengyu GaoH264 compatibility issue with RTP (no window pops up)I'm working on Ubuntu 20.04, with GStreamer 1.16.2 and FFmpeg 4.2.2
Here's detailed steps to reproduce the issue.
1. Download test video from https://www.freedesktop.org/software/gstreamer-sdk/data/media/sintel_trailer-480p.webm
2. Con...I'm working on Ubuntu 20.04, with GStreamer 1.16.2 and FFmpeg 4.2.2
Here's detailed steps to reproduce the issue.
1. Download test video from https://www.freedesktop.org/software/gstreamer-sdk/data/media/sintel_trailer-480p.webm
2. Convert to VP9 / PCM with FFmpeg command `ffmpeg -i sintel.webm -c:v vp9 -ar 8000 -ac 1 -c:a pcm_s16le sintel-vp9-pcm.mkv`
3. Convert to H264 / PCM with FFmpeg command `ffmpeg -i sintel.webm -c:v libx264 -ar 8000 -ac 1 -c:a pcm_s16le sintel-h264-pcm.mkv`
Now we have two video files, sintel-vp9-pcm.mkv and sintel-h264-pcm.mkv, and we are going to send the video / audio streams by RTP.
Commands for VP9 are:
```bash
# sender
gst-launch-1.0 rtpbin name=rtpbin \
filesrc location=/tmp/sintel-vp9-pcm.mkv ! matroskademux name=demux \
demux.audio_0 ! "audio/x-raw, format=S16LE, width=16, rate=8000, channels=1, layout=interleaved" ! alawenc ! rtppcmapay ! rtpbin.send_rtp_sink_0 \
demux.video_0 ! rtpvp9pay ! rtpbin.send_rtp_sink_1 \
rtpbin.send_rtp_src_0 ! udpsink host=127.0.0.1 port=5000 sync=true async=false \
rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5001 sync=false async=false \
rtpbin.send_rtp_src_1 ! udpsink host=127.0.0.1 port=5002 sync=true async=false \
rtpbin.send_rtcp_src_1 ! udpsink host=127.0.0.1 port=5003 sync=false async=false
# client
gst-launch-1.0 rtpbin name=rtpbin \
udpsrc address=127.0.0.1 port=5000 caps="application/x-rtp, media=audio, encoding-name=PCMA, clock-rate=8000" ! rtpbin.recv_rtp_sink_0 \
udpsrc address=127.0.0.1 port=5001 caps="application/x-rtcp" ! rtpbin.recv_rtcp_sink_0 \
udpsrc address=127.0.0.1 port=5002 caps="application/x-rtp, media=video, encoding-name=VP9, clock-rate=90000" ! rtpbin.recv_rtp_sink_1 \
udpsrc address=127.0.0.1 port=5003 caps="application/x-rtcp" ! rtpbin.recv_rtcp_sink_1 \
rtpbin. ! rtppcmadepay ! queue ! autoaudiosink sync=true \
rtpbin. ! rtpvp9depay ! queue ! avdec_vp9 ! autovideosink sync=true
```
It works and a window will pop up showing the video with audio.
Commands for H264 are:
```bash
# sender
gst-launch-1.0 rtpbin name=rtpbin \
filesrc location=/tmp/sintel-h264-pcm.mkv ! matroskademux name=demux \
demux.audio_0 ! "audio/x-raw, format=S16LE, width=16, rate=8000, channels=1, layout=interleaved" ! alawenc ! rtppcmapay ! rtpbin.send_rtp_sink_0 \
demux.video_0 ! rtph264pay ! rtpbin.send_rtp_sink_1 \
rtpbin.send_rtp_src_0 ! udpsink host=127.0.0.1 port=5000 sync=true async=false \
rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5001 sync=false async=false \
rtpbin.send_rtp_src_1 ! udpsink host=127.0.0.1 port=5002 sync=true async=false \
rtpbin.send_rtcp_src_1 ! udpsink host=127.0.0.1 port=5003 sync=false async=false
# client
gst-launch-1.0 rtpbin name=rtpbin \
udpsrc address=127.0.0.1 port=5000 caps="application/x-rtp, media=audio, encoding-name=PCMA, clock-rate=8000" ! rtpbin.recv_rtp_sink_0 \
udpsrc address=127.0.0.1 port=5001 caps="application/x-rtcp" ! rtpbin.recv_rtcp_sink_0 \
udpsrc address=127.0.0.1 port=5002 caps="application/x-rtp, media=video, encoding-name=H264, clock-rate=90000" ! rtpbin.recv_rtp_sink_1 \
udpsrc address=127.0.0.1 port=5003 caps="application/x-rtcp" ! rtpbin.recv_rtcp_sink_1 \
rtpbin. ! rtppcmadepay ! queue ! autoaudiosink sync=true \
rtpbin. ! rtph264depay ! queue ! avdec_h264 ! autovideosink sync=true
```
It does not work and no window pops up. There is no warning / error logs either.
It seems that something's wrong with the elements' internal implementations, or an appropriate warning / error message is absent.
The test video files are provided as attachments:
[sintel-h264-pcm.mkv.zip](/uploads/ea7e8834fc5fbcda7b2ce9d9d984cc49/sintel-h264-pcm.mkv.zip)
[sintel-vp9-pcm.mkv.zip](/uploads/bb2e6fd296142e138b89665c574cb85c/sintel-vp9-pcm.mkv.zip)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/773openh264enc: cmInitParaError on EOS2021-09-24T14:36:37ZBugzilla Migration Useropenh264enc: cmInitParaError on EOS## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#797021)](https://bugzilla.gnome.org/show_bug.cgi?id=797021)**
## Description
I did not notice any negative effects, but the openh264 encoder complains when r...## Submitted by Florent Thiery `@florent.thiery`
**[Link to original bug (#797021)](https://bugzilla.gnome.org/show_bug.cgi?id=797021)**
## Description
I did not notice any negative effects, but the openh264 encoder complains when receiving the EOS event:
GST_DEBUG=videoencoder:7,openh264enc:7 gst-launch-1.0 videotestsrc num-buffers=10 ! openh264enc ! fakesink
...
0:00:00.046820534 6897 0x55bb2aff0ca0 LOG openh264enc gstopenh264enc.cpp:989:gst_openh264enc_handle_frame:`<openh264enc0>` openh264 picture coded OK!
...
0:00:00.046936637 6897 0x55bb2aff0ca0 DEBUG videoencoder gstvideoencoder.c:1216:gst_video_encoder_sink_event:`<openh264enc0>` received event 28174, eos
[OpenH264] this = 0x0x7f0d4c009220, Error:CWelsH264SVCEncoder::EncodeFrame(), cmInitParaError.
Got EOS from element "pipeline0".