GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T13:22:28Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/318alsasink: slave-method causes high CPU usage with low latency audio2021-09-24T13:22:28ZBugzilla Migration Useralsasink: slave-method causes high CPU usage with low latency audio## Submitted by Petr Kulhavy
**[Link to original bug (#776151)](https://bugzilla.gnome.org/show_bug.cgi?id=776151)**
## Description
Using other than "none" slave-method in alsasink in combination with low latency audio adds up 5-10%...## Submitted by Petr Kulhavy
**[Link to original bug (#776151)](https://bugzilla.gnome.org/show_bug.cgi?id=776151)**
## Description
Using other than "none" slave-method in alsasink in combination with low latency audio adds up 5-10% CPU usage on an embedded system. With low latency I really mean few milliseconds, e.g. latency-time=1000
I have not investigated it much but some of the suspects seem to be gst_clock_get_time() and gst_audio_clock_get_time().https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/317alsasink: slave-method=resample corrupts audio2021-09-24T13:22:27ZBugzilla Migration Useralsasink: slave-method=resample corrupts audio## Submitted by Petr Kulhavy
**[Link to original bug (#776149)](https://bugzilla.gnome.org/show_bug.cgi?id=776149)**
## Description
When using slave-method "resample" on alsasink in combination with udpsrc the audio is broken. It so...## Submitted by Petr Kulhavy
**[Link to original bug (#776149)](https://bugzilla.gnome.org/show_bug.cgi?id=776149)**
## Description
When using slave-method "resample" on alsasink in combination with udpsrc the audio is broken. It sounds like the sound is "stretched" in time.
Interestingly in combination with audiotestsrc the audio sounds fine.
This is my pipeline:
gst-launch-1.0 udpsrc uri="udp://224.100.1.1:5004" caps="application/x-rtp,media=(string)audio,encoding-name=(string)L24,clock-rate=(int)48000,encoding-params=(string)2,channels=(int)2" multicast-iface="eth0" ! rtpL24depay ! audioconvert ! audio/x-raw,channels=2,rate=48000,format=
S24LE !alsasink slave-method=resample
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/316add -std=c++11 to CXXFLAGS2021-09-24T13:22:27ZBugzilla Migration Useradd -std=c++11 to CXXFLAGS## Submitted by Ben
**[Link to original bug (#776016)](https://bugzilla.gnome.org/show_bug.cgi?id=776016)**
## Description
This is needed for the Qt example## Submitted by Ben
**[Link to original bug (#776016)](https://bugzilla.gnome.org/show_bug.cgi?id=776016)**
## Description
This is needed for the Qt examplehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/315Volume control per audio channel2021-09-24T13:22:27ZBugzilla Migration UserVolume control per audio channel## Submitted by Victor Toso `@victortoso`
**[Link to original bug (#775897)](https://bugzilla.gnome.org/show_bug.cgi?id=775897)**
## Description
Having a volume control per audio channel would be very nice. Looking around, I see tha...## Submitted by Victor Toso `@victortoso`
**[Link to original bug (#775897)](https://bugzilla.gnome.org/show_bug.cgi?id=775897)**
## Description
Having a volume control per audio channel would be very nice. Looking around, I see that this would be a nice to have for some time [0].
[0] https://blogs.gnome.org/jessevdk/2010/12/17/fun-with-gstreamer-controlling-volume-of-channels-independently/
I'm willing to work on this but I'm still new in GStreamer land.
Any idea on what a desirable API for this would be? Any other hints welcome :)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/314Deadlock when using shmsrc+decodebin+videomixer2021-09-24T13:22:26ZBugzilla Migration UserDeadlock when using shmsrc+decodebin+videomixer## Submitted by Sean-Der
**[Link to original bug (#775495)](https://bugzilla.gnome.org/show_bug.cgi?id=775495)**
## Description
Created attachment 341182
source code
I have a long running parent process that consumes mkv from...## Submitted by Sean-Der
**[Link to original bug (#775495)](https://bugzilla.gnome.org/show_bug.cgi?id=775495)**
## Description
Created attachment 341182
source code
I have a long running parent process that consumes mkv from multiple temporary processes using shmsrc and then combines them via videomixer. If there is a better way to do this I would love to hear as well. I also am not sure which element is the culprit for the bug, if you swap/remove any of them the issues doesn't happen.
Sometimes when the parent process is overloaded it will deadlock. I am able to reproduce the deadlock by creating an artificial pause in the handoff of an identity. Once the fpsdisplaysink stops printing I can attach via gdb and see where everything is stuck.
I have attached the source code and the bt
The shmsink for the example is
gst-launch-1.0 videotestsrc ! matroskamux ! shmsink wait-for-connection=true socket-path=/tmp/foobar
**Attachment 341182**, "source code":
[code.c](/uploads/8318e2c92f7b87e5eff7f2f50c551c09/code.c)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/313discoverer: Use decodebin3 and GstStreams API2021-09-24T13:22:25ZBugzilla Migration Userdiscoverer: Use decodebin3 and GstStreams API## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#775486)](https://bugzilla.gnome.org/show_bug.cgi?id=775486)**
## Description
See summary## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#775486)](https://bugzilla.gnome.org/show_bug.cgi?id=775486)**
## Description
See summaryhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/312video: Bottom-field-first is a bad default2021-09-24T13:22:25ZBugzilla Migration Uservideo: Bottom-field-first is a bad default## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#775231)](https://bugzilla.gnome.org/show_bug.cgi?id=775231)**
## Description
For interlaced video, we have a flag to specifically signal that we have top-field-first...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#775231)](https://bugzilla.gnome.org/show_bug.cgi?id=775231)**
## Description
For interlaced video, we have a flag to specifically signal that we have top-field-first. However everything except for NTSC DV is top-field-first, so that would make a much better default (and almost no code is setting the flags anyway).
I'm not sure how to best change this in 1.x though, any ideas?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/311theora: fails over HTTP or RTSP with 'No valid frames decoded before end of s...2021-09-24T13:22:23ZBugzilla Migration Usertheora: fails over HTTP or RTSP with 'No valid frames decoded before end of stream'## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#775107)](https://bugzilla.gnome.org/show_bug.cgi?id=775107)**
## Description
Validate tests (BX corresponds to the build number where the issue happends in the...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#775107)](https://bugzilla.gnome.org/show_bug.cgi?id=775107)**
## Description
Validate tests (BX corresponds to the build number where the issue happends in the last` ~runs`):
validate.http.transcode.to_vorbis_and_vp8_in_webm.vorbis_theora_1_ogg:
B4014, B4079, B4084, B233, B268,
validate.http.transcode.to_mp3_and_h264_in_mp4.vorbis_theora_1_ogg: B4087, B262,
validate.http.transcode.to_vorbis_and_theora_in_ogg.vorbis_theora_1_ogg:
B4035, B4063, B4077, B4079, B4082, B4088, B4090, B4099, B199, B217, B236, B254, B259, B260, B267,
validate.http.transcode.to_vorbis_and_h264_in_mkv.vorbis_theora_1_ogg:
B4007, B4056, B4084, B4092, B231, B234, B255,
validate.http.playback.change_state_intensive.vorbis_theora_1_ogg:
B4022, B4038, B4039, B4044, B4047, B4048, B4051, B4054, B4057, B4058, B4066, B4071, B4076, B4083, B4084, B4085, B4088, B4094, B4101, B4105, B193, B194, B198, B201, B202, B203, B205, B209, B210, B215, B217, B220, B228, B234, B235, B238, B244, B245, B249, B253, B255, B256, B258, B260, B261, B262, B263, B264, B266, B269, B272, B273,
validate.http.playback.fast_forward.vorbis_theora_1_ogg:
B4032, B4048, B4058, B4062, B4086, B4093, B4094, B4105, B226, B237, B257, B268,
validate.http.transcode.to_rawaudio_and_prores_in_quicktime.vorbis_theora_1_ogg:
B4009, B4047, B4055, B4059, B4061, B4063, B4073, B4079, B4084, B4097, B196, B241, B246,
validate.http.playback.play_15s.vorbis_theora_1_ogg:
B4011, B4014, B4026, B4035, B4039, B4054, B4056, B4060, B4069, B4079, B4082, B209, B215, B253, B263,
Critical error:
Critical error Got error: No valid frames decoded before end of stream -- Debug message: gstvideodecoder.c(1176): gst_video_decoder_sink_event_default (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTheoraDec:theoradec0: no valid frames found
Failure example: https://ci.gstreamer.net/job/GStreamer-master-validate/4022/testReport/junit/validate.http.playback/change_state_intensive/vorbis_theora_1_ogg/
This happens basically only on that vorbis_theora_1_ogg (not vorbis_theora_0_ogg) file when played back over HTTP.
Not investigated yet.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/310giobasesink, tcpclientsink, multisocketsink: Returns flushing on PLAYING->PA...2021-09-24T13:22:22ZBugzilla Migration Usergiobasesink, tcpclientsink, multisocketsink: Returns flushing on PLAYING->PAUSED if it can block in ->render## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#774943)](https://bugzilla.gnome.org/show_bug.cgi?id=774943)**
## Description
giobasesink, tcpclientsink should be re-implemented with non-blocking writes and explicit...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#774943)](https://bugzilla.gnome.org/show_bug.cgi?id=774943)**
## Description
giobasesink, tcpclientsink should be re-implemented with non-blocking writes and explicit polling, otherwise we don't know how much was written.
multisocketsink also needs fixinghttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/309playbin3/decodebin3 fails to play video/x-divx,divxversion=3 files if gstream...2021-09-24T13:22:21ZBugzilla Migration Userplaybin3/decodebin3 fails to play video/x-divx,divxversion=3 files if gstreamer-vaapi is installed## Submitted by Michael Olbrich `@mol`
**[Link to original bug (#774900)](https://bugzilla.gnome.org/show_bug.cgi?id=774900)**
## Description
With gstreamer-vaapi installed, playbin3 fails to play some old divx files (e.g. [1]).
F...## Submitted by Michael Olbrich `@mol`
**[Link to original bug (#774900)](https://bugzilla.gnome.org/show_bug.cgi?id=774900)**
## Description
With gstreamer-vaapi installed, playbin3 fails to play some old divx files (e.g. [1]).
From what I can tell, vaapidecodebin is selected based on the static caps. Caps negotiation then fails at a later step and decodebin3 tries again. However,
vaapidecodebin is not blacklisted so it's selected again in an endless loop.
The old playbin still works: when vaapidecodebin fails it tries the next decoder and succeeds to play the file.
[1] https://samples.mplayerhq.hu/Divx4-bugs/Fight.Club.Trailer.avi
Version: 1.10.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/308glimagesink regression: does not render video since using libxcb2021-09-24T13:22:20ZBugzilla Migration Userglimagesink regression: does not render video since using libxcb## Submitted by Mark Nauwelaerts `@mnauw`
**[Link to original bug (#774809)](https://bugzilla.gnome.org/show_bug.cgi?id=774809)**
## Description
Created attachment 340468
gl: x11 display glx workaround
More precisely, when ru...## Submitted by Mark Nauwelaerts `@mnauw`
**[Link to original bug (#774809)](https://bugzilla.gnome.org/show_bug.cgi?id=774809)**
## Description
Created attachment 340468
gl: x11 display glx workaround
More precisely, when running (gst-launch-1.0) the example pipeline videotestsrc ! glimagesink, then a window is created and shown, but it remains as an outline and no content is ever filled (so whatever is behind the window remains visible).
This happens as of commit 4f6c226bd24ae3ef66bd8f4c17b001444c9b0bf1 (using libxcb in gl/x11), it rendered ok before that. Some additional observations; forcing GST_GL_PLATFORM=egl renders video fine (problem occurs with GST_GL_PLATFORM=glx). Also, upon applying the attached patch, the video also renders fine with GST_GL_PLATFORM=glx. It is not really a fix though, as it knocks out the event handling.
All that is rather puzzling, possibly somehow system-specific and might be dismissed as "lower level problems", but still if someone has additional insight (and solution?) ...
**Patch 340468**, "gl: x11 display glx workaround":
[0001-gl-x11display-workaround-silence-xcb-event-handling.patch](/uploads/4dcd64477fab5b92d3e762e70c28f48d/0001-gl-x11display-workaround-silence-xcb-event-handling.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/307example: playback-test: add support playbin32021-09-24T13:22:19ZBugzilla Migration Userexample: playback-test: add support playbin3## Submitted by Wonchul Lee
**[Link to original bug (#774601)](https://bugzilla.gnome.org/show_bug.cgi?id=774601)**
## Description
Add support playbin3 in the playback-test example to make it easy to test, referred playbin-test.## Submitted by Wonchul Lee
**[Link to original bug (#774601)](https://bugzilla.gnome.org/show_bug.cgi?id=774601)**
## Description
Add support playbin3 in the playback-test example to make it easy to test, referred playbin-test.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/306videorate: Make it possible to only duplicate frames2021-09-24T13:22:19ZBugzilla Migration Uservideorate: Make it possible to only duplicate frames## Submitted by Joe Palmer
**[Link to original bug (#774099)](https://bugzilla.gnome.org/show_bug.cgi?id=774099)**
## Description
Currently there is a option for frames to drop-only. We have a requirement to only duplicate frames wh...## Submitted by Joe Palmer
**[Link to original bug (#774099)](https://bugzilla.gnome.org/show_bug.cgi?id=774099)**
## Description
Currently there is a option for frames to drop-only. We have a requirement to only duplicate frames where there are gaps and never to drop any. With the current set of options, we cannot find a configuration that results in duplicated frames only without any being dropped. It would therefore seem sensible to add an duplicate-only option to compliment drop-only.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/305audiotestsrc: Improvements to the "ticks" waveform2021-09-24T13:22:18ZBugzilla Migration Useraudiotestsrc: Improvements to the "ticks" waveform## Submitted by Carlos Rafael Giani
**[Link to original bug (#774050)](https://bugzilla.gnome.org/show_bug.cgi?id=774050)**
## Description
The ticks waveform can be useful for audio synchronization diagnostics and other cases where ...## Submitted by Carlos Rafael Giani
**[Link to original bug (#774050)](https://bugzilla.gnome.org/show_bug.cgi?id=774050)**
## Description
The ticks waveform can be useful for audio synchronization diagnostics and other cases where the time offset between waveforms is important. However, in its current form, it is too limited, and has problems with discontinuities, which result in severe artifacts when this waveform is output by a DAC.
These patches fix some discontinuities and considerably expand the ticks waveform's flexibility.
They also introduce the notion of a "marker tick"; every Nth tick can have a different amplitude (usually one that is larger than the others). This is useful for combining frequent oscilloscope triggering with large time offset detection. For example, without marker ticks, the tick intervals must not be too small, otherwise the maximum time offset that can be unambiguously detected is quite small (for example, if the interval is 50ms, then no time offset larger than 25ms can be unambiguously recognized). If the tick intervals are too far apart, then no sudden changes can be clearly observed, since the oscilloscope is not updated quickly enough. But with marker ticks, this is not an issue: If there's for example a tick every 100 ms, then the oscilloscope can be triggered every 100 ms. And, if every 20th tick is a marker tick, then time offsets of up to 1 second can be discovered, even though the time between ticks is 100 ms.
The patches also apply some minor cleanup to the audiotestsrc documentation.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/302audiodecoder: Degrade warnings2021-09-24T13:22:16ZBugzilla Migration Useraudiodecoder: Degrade warnings## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773106)](https://bugzilla.gnome.org/show_bug.cgi?id=773106)**
## Description
When doing DTX generation in decoders, they are indeed
producing buffers without having...## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773106)](https://bugzilla.gnome.org/show_bug.cgi?id=773106)**
## Description
When doing DTX generation in decoders, they are indeed
producing buffers without having a corresponding input
buffer, so this code needs to be revisited, and perhaps
need a special method for pushing buffers like this?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/301rtpbasedepayload: Drop gap events before first buffer2021-09-24T13:22:16ZBugzilla Migration Userrtpbasedepayload: Drop gap events before first buffer## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773104)](https://bugzilla.gnome.org/show_bug.cgi?id=773104)**
## Description
Before a gap event is pushed downstream a segment event must be pushed
since the gap ev...## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773104)](https://bugzilla.gnome.org/show_bug.cgi?id=773104)**
## Description
Before a gap event is pushed downstream a segment event must be pushed
since the gap event can cause packet concealment downstream and hence
data flow. Since concealment before receiving any data packets usually
doesn't make any sense, the gap event is not sent downstream.
Alternatively one could generate a default caps and segment event, but
no need to complicate things until it's proven necessary.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/300audioconvert: passthrough conversion causing high CPU load2021-09-24T13:22:16ZBugzilla Migration Useraudioconvert: passthrough conversion causing high CPU load## Submitted by Petr Kulhavy
**[Link to original bug (#772872)](https://bugzilla.gnome.org/show_bug.cgi?id=772872)**
## Description
While measuring the audioconvert plugin performance I found that converting S24LE to S24LE format (i...## Submitted by Petr Kulhavy
**[Link to original bug (#772872)](https://bugzilla.gnome.org/show_bug.cgi?id=772872)**
## Description
While measuring the audioconvert plugin performance I found that converting S24LE to S24LE format (i.e. no change of the format at all) causes superfluous quantization. This results in extra CPU load.
The reason for this peculiar behaviour is that the first and mandatory step in an audio conversion is to unpack the data to either 16 or 32 bits. So 24-bit data is internally expanded to 32-bits. Then in the following if statement the chain_quantize() function logic decides that a quantization is needed:
/* we still want to run the quantization step when reducing bits to get
* the rounding correct */
if (out_int && out_depth < 32
&& convert->current_format == GST_AUDIO_FORMAT_S32)
Obviously, if 24-bits are expanded to 32-bits and then again compacted to 24-bits, no quantization is needed.
Not sure how exactly the if statement should be altered, but shouldn't it also take the in_depth into account (like: ... && in_depth != out_depth)?
My test pipeline:
gst-launch-1.0 audiotestsrc samplesperbuffer=48 ! "audio/x-raw,format=(string)S24LE,rate=(int)48000,channels=(int)2" ! audioconvert ! "audio/x-raw,format=(string)S24LE,rate=(int)48000,channels=(int)2" ! alsasink can-activate-pull=true provide-clock=false buffer-time=8000 slave-method=none blocksize=192
Version: 1.8.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/298videorate: EOS and GAP handling fixes2021-09-24T13:22:15ZBugzilla Migration Uservideorate: EOS and GAP handling fixes## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#772559)](https://bugzilla.gnome.org/show_bug.cgi?id=772559)**
## Description
Created attachment 337149
videorate: fix EOS handling when segment stop is unset
...## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#772559)](https://bugzilla.gnome.org/show_bug.cgi?id=772559)**
## Description
Created attachment 337149
videorate: fix EOS handling when segment stop is unset
videorate only drops GAP events instead of using the opportunity to fill until the start of the gap.
videorate doesn't handle EOS correctly when there is no segment stop set.
patches follow
**Patch 337149**, "videorate: fix EOS handling when segment stop is unset":
[0001-videorate-fix-EOS-handling-when-segment-stop-is-unse.patch](/uploads/d7747bf447877ec06b6c5b677455bfa7/0001-videorate-fix-EOS-handling-when-segment-stop-is-unse.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/297playbin3: avoid plugging a decoder element when the sink handle encoded data2021-09-24T13:22:14ZBugzilla Migration Userplaybin3: avoid plugging a decoder element when the sink handle encoded data## Submitted by Arnaud Vrac `@rawoul`
**[Link to original bug (#772258)](https://bugzilla.gnome.org/show_bug.cgi?id=772258)**
## Description
Hi,
I have an audio sink that can take compressed audio and render it directly. In pla...## Submitted by Arnaud Vrac `@rawoul`
**[Link to original bug (#772258)](https://bugzilla.gnome.org/show_bug.cgi?id=772258)**
## Description
Hi,
I have an audio sink that can take compressed audio and render it directly. In playbin2 no decoder is plugged between the demuxer and the sink, allowing hardware offloading of the audio decoding.
However in playbin3, the fact that the sink can decode audio is ignored and a decoder is plugged in, which is sub-optimal.
### Depends on
* [Bug 769079](https://bugzilla.gnome.org/show_bug.cgi?id=769079)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/296decodebin3-parse: Make it generate pending input streams2021-09-24T13:22:13ZBugzilla Migration Userdecodebin3-parse: Make it generate pending input streams## Submitted by HoonHee Lee
**[Link to original bug (#772230)](https://bugzilla.gnome.org/show_bug.cgi?id=772230)**
## Description
Created attachment 336615
gstdecodebin3-parse: Make it to generate pending input streams
Deal ...## Submitted by HoonHee Lee
**[Link to original bug (#772230)](https://bugzilla.gnome.org/show_bug.cgi?id=772230)**
## Description
Created attachment 336615
gstdecodebin3-parse: Make it to generate pending input streams
Deal All.
When multiple source elements, in such all streams are fed separately,
parsebin is generated by number of streams.
And it is managed by main and other inputs(eg. DecodebinInput) to configure and connect MQ's input slots.
Actually, I have a scenario video and audio stream ES data is feeding separately and 2 of parsebins are generated as well.
But, streams are changed in such audio codec is changed in running time,
pipeline(Playbiin3) is stopped or pending in sometimes.
I reviewed the log with decodebin3 and decodebin3-parsebin.
Sometimes, other input(DecodebinInput for video) removed the input-stream(DecodebinInputStream for old audio) and disconnected to MQ's input slot.
And then, new input stream(DecodebinInputStream for new audio) is not created and connected to MQ's input slot.
At that time, parsebin_buffer_probe for video pad is called early than new audio.
**Attachment 336615**, "gstdecodebin3-parse: Make it to generate pending input streams":
[decodebin3_ng.log](/uploads/6966344d92d80129a040a27a05873fda/decodebin3_ng.log)
Version: 1.9.2