GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2023-04-03T13:20:14Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/22Better handling of blacklisted plugins: re-scan occasionally, store reason fo...2023-04-03T13:20:14ZBugzilla Migration UserBetter handling of blacklisted plugins: re-scan occasionally, store reason for blacklisting## Submitted by Tim Müller `@tpm`
**[Link to original bug (#648010)](https://bugzilla.gnome.org/show_bug.cgi?id=648010)**
## Description
+++ This bug was initially created as a clone of [Bug 503675](https://bugzilla.gnome.org/show_b...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#648010)](https://bugzilla.gnome.org/show_bug.cgi?id=648010)**
## Description
+++ This bug was initially created as a clone of [Bug 503675](https://bugzilla.gnome.org/show_bug.cgi?id=503675) +++
`<__tim>` nekohayo, your registry file is full of BLACKLISTED. The problem isn't
registry file writing or parsing, but that plugins get blacklisted for some
reason
`<nekohayo>` When does blacklisting occur?
`<__tim>` nekohayo, when an error occurs when loading the plugin, usually a
missing symbol or library or somesuch
`<nekohayo>` videomixer was indeed on the gst-inspect blacklist
`<__tim>` are you sometimes downgrading versions of core or gst-plugins-base?
`<nekohayo>` no, not that I know of. Downgrading was downright impossible in
ubuntu, and I haven't used downgrade in fedora yet
`<__tim>` GStreamer installed in different prefixes?
`<nekohayo>` currently this machine is using the official gstreamer packages from
fedora + rpmfusion
`<nekohayo>` I'm wondering why those blacklisted plugins are never "re-scanned"
by gstreamer
`<__tim>` that's a fair question I guess. But when would one rescan them? You
don't want to do it every time. So once an hour? once a day? once a week?
`<nekohayo>` what if they were rescanned when apps try to access them? like when
pitivi tries to use videomixer (on top of your approach of rescanning
periodically maybe)
`<__tim>` interesting, maybe one could do something clever there
`<__tim>` ideally we'd store the reason for the blacklisting as well
`<ocrete>` arent they rechecked if the file changes already ?
`<thaytan>` the plugins are rescanned if they change
`<__tim>` but if they don't change ...
`<thaytan>` but if they failed because some underlying lib was broken and then
fixed, that's not detected
`<__tim>` right
`<ocrete>` hmm interesting point
`<thaytan>` storing the reason for the blacklisting is probably hard
`<ocrete>` also check if ld.so.cache has changed ?
`<thaytan>` since it's usually just 'failed to g_module_open() because of an
unresolved symbol'
`<ocrete>` and ignore blacklists if ld.so.cache has changed (and rescan)
`<__tim>` thaytan, it doesn't mention the symbol? I think it does..
`<ds>` if the so fails to load, there isn't much overhead trying to load every
time
`<ocrete>` that said, doesnt help if one use using LD_LIBRARY_PATH
`<thaytan>` ds: except for forking the scanner process to re-check an otherwise
clean registry
`<ds>` oooh, maybe recheck blacklisted plugins whenever the scanner is run, but
not run the scanner just for blacklisted plugins. Although, also mark potential
crasher blacklist plugins
### See also
* http://bugs.debian.org/867574https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/21basesrc: - fails to send updated segment event when duration changes2023-05-15T18:28:48ZBugzilla Migration Userbasesrc: - fails to send updated segment event when duration changes## Submitted by Thomas
**[Link to original bug (#647940)](https://bugzilla.gnome.org/show_bug.cgi?id=647940)**
## Description
The issue in [Bug 345929](https://bugzilla.gnome.org/show_bug.cgi?id=345929) still stands: if you try to p...## Submitted by Thomas
**[Link to original bug (#647940)](https://bugzilla.gnome.org/show_bug.cgi?id=647940)**
## Description
The issue in [Bug 345929](https://bugzilla.gnome.org/show_bug.cgi?id=345929) still stands: if you try to play a file that is currently being written to (downloaded or created via recording for example) totem will only play up to the portion that was available at file open time.
The user story here is that I try to watch something on a laptop that is on remote machine (SSH). The network is a WLAN with random connectivity issues. If I try to watch the movie direcetly via gvfs, totem won't buffer enough data to cover a small drop in connectivity and will have trouble to resume playing when the connection is back up (it will load the network to the max and the video will lag behind the audio). If I try to download to disk and just watch the growing on-disk file (doing manual buffering, so to say), the bug mentioned here kicks in and I'd have to constantly restart the movie and skip to the part I haven't seen yet.
As a point of comparison, VLC is able to just keep playing if it notices that the file grew since it opened it.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/20flushing seek to reverse playback direction changes frame2023-05-15T18:28:47ZBugzilla Migration Userflushing seek to reverse playback direction changes frame## Submitted by Andy Wingo Wingo `@wingo`
**[Link to original bug (#645531)](https://bugzilla.gnome.org/show_bug.cgi?id=645531)**
## Description
Steps to reproduce:
1. Open any video file in ./seek 16 file:///....
I was ab...## Submitted by Andy Wingo Wingo `@wingo`
**[Link to original bug (#645531)](https://bugzilla.gnome.org/show_bug.cgi?id=645531)**
## Description
Steps to reproduce:
1. Open any video file in ./seek 16 file:///....
I was able to reproduce this problem with MPEG4 video and AAC audio in an MPEG4 container, and with the pitivi 0.13.1-final.ogv movie, so it should be general.
2. Play forward until there is a scene with some movement, so you can tell if the frame changes or not. Hit pause.
3. Go to the "rate" box, add a minus sign before the 1.000, and hit enter.
Expected results:
The showed frame does not change.
Actual result:
The frame changes to the next one in the new play direction.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/19Macro to check check mutability in set_property functions2023-05-15T18:28:47ZBugzilla Migration UserMacro to check check mutability in set_property functions## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#644776)](https://bugzilla.gnome.org/show_bug.cgi?id=644776)**
## Description
Now that we have GST_PARAM_MUTABLE_*, we should add a way to enforce them.
I suggest...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#644776)](https://bugzilla.gnome.org/show_bug.cgi?id=644776)**
## Description
Now that we have GST_PARAM_MUTABLE_*, we should add a way to enforce them.
I suggest having a macro like the following and putting it as the first line of the set_property() function in the various elements after adding the mutability flags.
#define GST_PARAM_CHECK_MUTABILITY(element, pspec) G_STMT_START { \
GstState state; \
\
g_return_if_fail ((element) != NULL && GST_IS_ELEMENT (element)); \
GST_OBJECT_LOCK (element); \
state = GST_STATE (element); \
GST_OBJECT_UNLOCK (element); \
g_return_if_fail (state == GST_STATE_PLAYING || \
(pspec)->flags & GST_PARAM_MUTABLE_PLAYING); \
g_return_if_fail (state >= GST_STATE_PAUSED || \
(pspec)->flags & GST_PARAM_MUTABLE_PAUSED); \
g_return_if_fail (state >= GST_STATE_READY || \
(pspec)->flags & GST_PARAM_MUTABLE_READY); \
} G_STMT_END
We may want to have a version that doesn't release the object lock if the paramspec is mutable above NULL, since I guess for many cases, we'd want to make the change atomic, but that means being a little more clever (and maybe we want to use GST_ERROR_OBJECT() instead of g_warning .. maybe g_critical?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/18tee: needs to aggregate QoS THROTTLE events from all source branches2023-05-15T18:28:47ZBugzilla Migration Usertee: needs to aggregate QoS THROTTLE events from all source branches## Submitted by Yongnian
**[Link to original bug (#638891)](https://bugzilla.gnome.org/show_bug.cgi?id=638891)**
## Description
There might be many cases that some window is invisible
(for example other window is in full screen)...## Submitted by Yongnian
**[Link to original bug (#638891)](https://bugzilla.gnome.org/show_bug.cgi?id=638891)**
## Description
There might be many cases that some window is invisible
(for example other window is in full screen), its related sink elements are still busy in rendering and upstream elements are busy in processing and decoding. Here a new event type "QOS_OBSCURED" is introduced.
The UI toolkit (Gtk+, Qt) already keeps track of windows status information: visible or invisible etc. So it would be straightforward to extend the GstVideoSink class to have a property that encourages degraded rendering. When such property is set, the "QOS_OBSCURED" event is pushed to upstream elements for handling: degraded quality for less resources.
And, for bonus points, as there is a trend in the industry toward stream switching for video over the internet, such event could be used to select appropriate media info in future.
After discussion with David Schleef (ds@entropywave.com) and Halley Zhao (halley.zhao@intel.com), the patches (based on version 0.10.28) for such mechanism are ready for video rendering degradation when it is invisible. They include below changes:
1. gstquark.h/gstquark.c: new quark string
2. gstevent.h/gstevent.c: new QoS event
3. gstvideosink.c: generate new QoS event when it encourages degraded rendering
3. gsttee.c: degrade handling rate when it receives degraded rendering requesthttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/17RFC: operation hints for GstElement2023-05-15T18:28:47ZBugzilla Migration UserRFC: operation hints for GstElement## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#634687)](https://bugzilla.gnome.org/show_bug.cgi?id=634687)**
## Description
[Bug 564749](https://bugzilla.gnome.org/show_bug.cgi?id=564749) mostly blocks on the GstTa...## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#634687)](https://bugzilla.gnome.org/show_bug.cgi?id=634687)**
## Description
[Bug 564749](https://bugzilla.gnome.org/show_bug.cgi?id=564749) mostly blocks on the GstTagReaderIface. An alternative would be to have a set of hint-flags on GstElement. Those flags can be set on the pipeline, individual bins and even elements. Bins could propagate the hints to new children and hint-changes to existing children.
The purpose of the hints is to specify the intended use case a bit more to give elements a chances for optimization. Right now gstreamer elements prepare to support everything.
Some use cases
1) quickly play something from start to end
- no need for metadata
- no seeking/no playback rate changes
- no mucking with the pipeline at all until eos
2) quick metadata reading
- no prerolling
- no seektable building
3) no caps changes (video in fullscreen)
- quicker pad_alloc or even no need to check for caps changes in basetransform
No proposal for a set of hints yet :/
### Blocking
* [Bug 532307](https://bugzilla.gnome.org/show_bug.cgi?id=532307)
* [Bug 564749](https://bugzilla.gnome.org/show_bug.cgi?id=564749)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/16bin: set_state to PLAYING of non-toplevel bin might stop at PAUSED2023-05-15T18:28:47ZBugzilla Migration Userbin: set_state to PLAYING of non-toplevel bin might stop at PAUSED## Submitted by Mark Nauwelaerts `@mnauw`
**[Link to original bug (#632782)](https://bugzilla.gnome.org/show_bug.cgi?id=632782)**
## Description
... particularly if NO_PREROLL element present in bin.
Since NO_PREROLL "eats" any...## Submitted by Mark Nauwelaerts `@mnauw`
**[Link to original bug (#632782)](https://bugzilla.gnome.org/show_bug.cgi?id=632782)**
## Description
... particularly if NO_PREROLL element present in bin.
Since NO_PREROLL "eats" any ASYNC, occurrence of the former tends to trigger a "fake async-done" to counter the latter, see e.g. gst_bin_add_func when adding a NO_PREROLL element, or decodebin2 change_state function forcing async_done upon NO_PREROLL state change of bin.
In any case, bin_handle_async_done is triggered, which (silently) ignores further state change to PLAYING assuming that (some) parent will take care of it later on. While that is the case in "normal" state changes, it need not be so in more "advanced/dynamic" custom bin scenarios (decodebin2, etc etc), depending on whether parents already reached PLAYING earlier or other ASYNC_START are pending somewhere else. Specific cases are in e.g. [bug 628214](https://bugzilla.gnome.org/show_bug.cgi?id=628214) or [bug 632656](https://bugzilla.gnome.org/show_bug.cgi?id=632656).
As such, this may be intended behaviour, but it might need some tweaking or some warning/documentation indicating that a good old _set_state (..., PLAYING) needs some caution as it may "fail" silently and would have to be replaced by _set_state (..., PAUSED) followed by _set_state (..., PLAYING).https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/15[API] seeking: need API to do pseudo-accurate seeking when keyframe seeking i...2024-01-10T10:54:57ZBugzilla Migration User[API] seeking: need API to do pseudo-accurate seeking when keyframe seeking is too coarse## Submitted by Benjamin Otte `@company`
**[Link to original bug (#619788)](https://bugzilla.gnome.org/show_bug.cgi?id=619788)**
## Description
Totem currently does keyframe seeking of videos. However, videos exist that only contain...## Submitted by Benjamin Otte `@company`
**[Link to original bug (#619788)](https://bugzilla.gnome.org/show_bug.cgi?id=619788)**
## Description
Totem currently does keyframe seeking of videos. However, videos exist that only contain a single keyframe at the beginning of the file. For these files, every seek will result in Totem restarting the file.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/14[API] add chunk writer2024-03-12T17:10:50ZBugzilla Migration User[API] add chunk writer## Submitted by Mark Nauwelaerts `@mnauw`
**[Link to original bug (#619292)](https://bugzilla.gnome.org/show_bug.cgi?id=619292)**
## Description
Bytewriting typically involves nested structures with sizes recorded in the bytestream ...## Submitted by Mark Nauwelaerts `@mnauw`
**[Link to original bug (#619292)](https://bugzilla.gnome.org/show_bug.cgi?id=619292)**
## Description
Bytewriting typically involves nested structures with sizes recorded in the bytestream (e.g. avi chunks, qt atoms, ebml elements, jpeg markers, etc). Additional proposed API aids in tracking nested structures positions and sizes,
which could be used in any of the above cases, rather than coming up with yet another home made on in each case separately.
Evidently, some variations on the proposed are possible, e.g. using a separate (inherited) type for this (GstByteWriterStack or so).
### Blocking
* [Bug 619293](https://bugzilla.gnome.org/show_bug.cgi?id=619293)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/13configurable user agent for network elements2024-01-10T10:54:55ZBugzilla Migration Userconfigurable user agent for network elements## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#614558)](https://bugzilla.gnome.org/show_bug.cgi?id=614558)**
## Description
Some streaming servers tune their replies based on the user-agent they received.
For tha...## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#614558)](https://bugzilla.gnome.org/show_bug.cgi?id=614558)**
## Description
Some streaming servers tune their replies based on the user-agent they received.
For that purpose souphttpsrc has "user-agent" and even "extra-headers" properties. rtspsrc does not have any of this (yet).
Also this mechanism would require the application to set it, while I wonder if it makes sense to have a configure flag to set the user-agent (and put that into gstconfig.h). if the configure is not given we use "GStreamer/0.10". Having a more detailed version (including base and ev. the plugin in use) would need to be build differently.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/12queue: add burst/batch feature to reduce writer wakeups and context switches2024-01-10T10:54:55ZBugzilla Migration Userqueue: add burst/batch feature to reduce writer wakeups and context switches## Submitted by Venkat
**[Link to original bug (#613827)](https://bugzilla.gnome.org/show_bug.cgi?id=613827)**
## Description
When I use max-size-buffers and min-threshold-buffers values as parameters to QUEUE in gstreamer pipe line...## Submitted by Venkat
**[Link to original bug (#613827)](https://bugzilla.gnome.org/show_bug.cgi?id=613827)**
## Description
When I use max-size-buffers and min-threshold-buffers values as parameters to QUEUE in gstreamer pipe line, Its not waiting it is not waiting until it reach min-threshold-buffers. Currently queue fills the buffer as the buffer empty. It is not able to perform the requirement of waiting until it all buffers empty.
The changes needed found in gstqueue.c at gstreamer/plugins/elements/
function:gst_queue_chain (GstPad * pad, GstBuffer * buffer)
/* don't leak. Instead, wait for space to be available */
do {
/* for as long as the queue is filled, ait until min-threshold-buffers reaches. */
GST_QUEUE_WAIT_DEL_CHECK (queue, out_flushing);
} while (!gst_queue_is_empty(queue));
and
Need changes in gst_queue_is_empty function to satisfy all the conditions. I am not sure all the conditions (need some evaluation in this)
static gboolean gst_queue_is_empty (GstQueue * queue)
{
if (queue->queue->length == 0)
return TRUE;
if ((queue->cur_level.buffers == 0) || (queue->cur_level.bytes == 0) || (queue->cur_level.time == 0) )
return TRUE;
if (( queue->min_threshold.buffers == 0 &&
queue->cur_level.buffers `< queue->`max_size.buffers) ||
(queue->min_threshold.bytes == 0 &&
queue->cur_level.bytes `< queue->`max_size.bytes) ||
(queue->min_threshold.time == 0 &&
queue->cur_level.time `< queue->`max_size.time)) &&
!gst_queue_is_filled (queue)
return TRUE;
/* It is possible that a max size is reached before all min thresholds are.
* Therefore, only consider it empty if it is not filled. */
return ((queue->min_threshold.buffers > 0 &&
queue->cur_level.buffers `< queue->`min_threshold.buffers) ||
(queue->min_threshold.bytes > 0 &&
queue->cur_level.bytes `< queue->`min_threshold.bytes) ||
(queue->min_threshold.time > 0 &&
queue->cur_level.time `< queue->`min_threshold.time)) &&
!gst_queue_is_filled (queue);
}https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/10[API] buffer size query or indication from audio encoders to upstream how man...2024-01-10T10:54:55ZBugzilla Migration User[API] buffer size query or indication from audio encoders to upstream how many samples to produce per buffer## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#572973)](https://bugzilla.gnome.org/show_bug.cgi?id=572973)**
## Description
It would be useful if (audio) encoders could send a buffer-size-request event upstream. So...## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#572973)](https://bugzilla.gnome.org/show_bug.cgi?id=572973)**
## Description
It would be useful if (audio) encoders could send a buffer-size-request event upstream. Sources can use that to configure the size of the buffers that they will send in push mode. Basesource can implement that and configure the "blocksize" property.
It would free encoders from using the adapter.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/9registry: don't copy strings when reading the cache2024-01-10T10:54:55ZBugzilla Migration Userregistry: don't copy strings when reading the cache## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#558674)](https://bugzilla.gnome.org/show_bug.cgi?id=558674)**
## Description
There are some enhancement idea about the gstreamer registry described in [Bug 359653](htt...## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#558674)](https://bugzilla.gnome.org/show_bug.cgi?id=558674)**
## Description
There are some enhancement idea about the gstreamer registry described in [Bug 359653](https://bugzilla.gnome.org/show_bug.cgi?id=359653)#c35 and [Bug 359653](https://bugzilla.gnome.org/show_bug.cgi?id=359653)#c36. This is an attempt to do it.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/8sparse file support2024-01-10T10:54:54ZBugzilla Migration Usersparse file support## Submitted by Rang Glerry
**[Link to original bug (#554055)](https://bugzilla.gnome.org/show_bug.cgi?id=554055)**
## Description
movies, which aren't complete (e.g. movies as torrent), are playable in totem. empty spaces should be...## Submitted by Rang Glerry
**[Link to original bug (#554055)](https://bugzilla.gnome.org/show_bug.cgi?id=554055)**
## Description
movies, which aren't complete (e.g. movies as torrent), are playable in totem. empty spaces should been automatically skipped to avoid long pauses.
Other information:https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/6Better flow / negotiation error reporting2024-01-10T10:54:54ZBugzilla Migration UserBetter flow / negotiation error reporting## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#350545)](https://bugzilla.gnome.org/show_bug.cgi?id=350545)**
## Description
Durinf development one often gets:
basesrc( 1083) gstbasesrc.c(1698):gst_base_src_sta...## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#350545)](https://bugzilla.gnome.org/show_bug.cgi?id=350545)**
## Description
Durinf development one often gets:
basesrc( 1083) gstbasesrc.c(1698):gst_base_src_start:`<v4l2src0>` error: Could not negotiate format
WARN (0x19000 - 0:00:07.850402000) basesrc( 1083) gstbasesrc.c(1698):gst_base_src_start:`<v4l2src0>` error: Check your filtered caps, if any
This definitely need fixing. There is no point that deverlopers spend years reading GST_DEBUG="GST_CAPS:4" output to figure the problem. If format cannot be negotiated then a reason *must* be given.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/5[API] query tag setters (and getters?) for supported tags2024-01-29T10:18:30ZBugzilla Migration User[API] query tag setters (and getters?) for supported tags## Submitted by René Stadler `@cymacs`
**[Link to original bug (#345352)](https://bugzilla.gnome.org/show_bug.cgi?id=345352)**
## Description
There is currently no way to find out if a particular pipeline will be able to write out a...## Submitted by René Stadler `@cymacs`
**[Link to original bug (#345352)](https://bugzilla.gnome.org/show_bug.cgi?id=345352)**
## Description
There is currently no way to find out if a particular pipeline will be able to write out all meta data tags that are passed to it. Meta data can be silently lost currently, for example if an app allows user-supplied backends (to support arbitrary output formats, of which not all might have support for all types of meta data).
Another use case applies to using analyzers like TRM (musicbrainz fingerprinting) or ReplayGain. Applications could disable such extra processing if the results cannot be saved in the output.
Current state of affairs seems to be that encoders/muxers silently ignore any unsupported tags they encounter during iteration of passed tag lists.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2elementfactory: add support for translated names2024-01-29T10:18:19ZBugzilla Migration Userelementfactory: add support for translated names## Submitted by Takao Fujiwara
**[Link to original bug (#154054)](https://bugzilla.gnome.org/show_bug.cgi?id=154054)**
## Description
gnome-volume-control has unlocalized labels with ALSA drivers.
To reproduce:
1. Enable alsa...## Submitted by Takao Fujiwara
**[Link to original bug (#154054)](https://bugzilla.gnome.org/show_bug.cgi?id=154054)**
## Description
gnome-volume-control has unlocalized labels with ALSA drivers.
To reproduce:
1. Enable alsa driver for the sound.
2. Invoke gnome-volume-control
Then several labels are not localized.
I could find the labels in alsa module but it is not internationalized.
So I hacked the strings and attach the patch.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1GstArray subtraction not implemented2024-01-29T10:18:15ZBugzilla Migration UserGstArray subtraction not implemented## Submitted by David Schleef Schleef `@ds`
**[Link to original bug (#147931)](https://bugzilla.gnome.org/show_bug.cgi?id=147931)**
## Description
test in patch fails.## Submitted by David Schleef Schleef `@ds`
**[Link to original bug (#147931)](https://bugzilla.gnome.org/show_bug.cgi?id=147931)**
## Description
test in patch fails.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/500Add support for pre-multiplied ARGB, BGRA, AYUV, etc.2021-09-24T13:24:32ZBugzilla Migration UserAdd support for pre-multiplied ARGB, BGRA, AYUV, etc.## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#797343)](https://bugzilla.gnome.org/show_bug.cgi?id=797343)**
## Description
See summary## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#797343)](https://bugzilla.gnome.org/show_bug.cgi?id=797343)**
## Description
See summaryhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/499Potential Error Case is Ignored by GstAudioRingBuffer2021-09-24T13:24:32ZBugzilla Migration UserPotential Error Case is Ignored by GstAudioRingBuffer## Submitted by Andrew
**[Link to original bug (#797334)](https://bugzilla.gnome.org/show_bug.cgi?id=797334)**
## Description
In trying to debug issues behind [Bug 797329](https://bugzilla.gnome.org/show_bug.cgi?id=797329) (https://...## Submitted by Andrew
**[Link to original bug (#797334)](https://bugzilla.gnome.org/show_bug.cgi?id=797334)**
## Description
In trying to debug issues behind [Bug 797329](https://bugzilla.gnome.org/show_bug.cgi?id=797329) (https://bugzilla.gnome.org/show_bug.cgi?id=797329) it was discovered that an error case seems to be completely ignored by the GstAudioRingBuffer.
default_commit 'skips' the writing of a segment to the output buffer when the read pointers has surpassed the write pointer (diff < 0), but still advances the write pointer by the segment size. The intention appearing to be that this should advance the write pointer a segment ahead of the read pointer, and allow the next segment to write.
The issue is that default_commit's return indicates that the full segment was written, and fails to track this error internally. Thus, the potential error state were the write pointer never catches up to the read pointer (and the rendering is for all intents broken), appears to be undetectable.
* Due to no internal error tracking GstAudioRingBuffer will have no idea that it has skipped the millionth segment in a row.
* Due to GstAudioRingBuffer indicating by it's return that full segment was written and advancing the write pointer, higher level elements appear to have no way of knowing a segment was drop. Thus they appear to have no way of tracking how many segments have been successively dropped, and detecting if this exceeds an error threshold.
I am sure that the error state is a rare one, and in this case caused by an unrelated issue. However never detecting an error state in the pipeline seems bad.
### See also
* [Bug 797329](https://bugzilla.gnome.org/show_bug.cgi?id=797329)