GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T15:42:41Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/868wasapisrc and wasapisink segfault in `_delay()` when exclusive=true low-laten...2021-09-24T15:42:41ZNirbheek Chauhannirbheek.chauhan@gmail.comwasapisrc and wasapisink segfault in `_delay()` when exclusive=true low-latency=trueThis is not a regression. The workaround is to use `provide-clock=false` when using both `exclusive=true` and `low-latency=true`. This is also why I didn't notice it in my testing many months ago.
The segfault seems to be caused due to ...This is not a regression. The workaround is to use `provide-clock=false` when using both `exclusive=true` and `low-latency=true`. This is also why I didn't notice it in my testing many months ago.
The segfault seems to be caused due to calling `IAudioClient_GetCurrentPadding()` from a thread that's not the main thread in which COM has been initialized. See also: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/128.Nirbheek Chauhannirbheek.chauhan@gmail.comNirbheek Chauhannirbheek.chauhan@gmail.comhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/871Compositor segfault with transparent background2021-03-02T00:08:37ZNazar MokrynskyiCompositor segfault with transparent background```
#0 __memset_avx2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:192
#1 0x00007fe1128faff1 in memset (__len=640, __ch=0, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:...```
#0 __memset_avx2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:192
#1 0x00007fe1128faff1 in memset (__len=640, __ch=0, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:71
#2 _draw_background (composite=<synthetic pointer>, y_end=<optimized out>, y_start=360, outframe=0x7fdfd0bc91d0, comp=0x7fe040088590 [GstCompositor|compositor_1]) at ../gst/compositor/compositor.c:1155
#3 blend_pads (comp=0x7fdfd0bc9130) at ../gst/compositor/compositor.c:1175
#4 0x00007fe1128fb187 in gst_parallelized_task_thread_func (data=0x7fdfc4004eb8) at ../gst/compositor/compositor.c:901
#5 0x00007fe1149a81b1 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007fe1147ff590 in start_thread (arg=0x7fdfc3ae9640) at pthread_create.c:463
#7 0x00007fe1145d4223 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
Pipeline is similar in its mechanics to this:
```
gst-launch-1.0 videotestsrc is-live=true ! video/x-raw,width=1280,height=720,format=I420 ! \
compositor background=transparent ! \
compositor background=black ! video/x-raw,format=BGRA ! \
videoconvert ! video/x-raw,framerate=30/1,format=I420 ! \
fakesink
```
However, I can't reproduce it with gst-launch for some reason.
Changing `background=transparent` to `background=black` on the first compositor fixes the issue.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/869qt: Build fails2021-03-30T09:07:07ZVivia Nikolaidouqt: Build fails```
FAILED: subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/gstqtoverlay.cc.o
c++ -Isubprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p -Isubprojects/gst-plugins-good/ext/qt -I../subprojects/gst-plugins-good/ext/qt -Isubprojects/gs...```
FAILED: subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/gstqtoverlay.cc.o
c++ -Isubprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p -Isubprojects/gst-plugins-good/ext/qt -I../subprojects/gst-plugins-good/ext/qt -Isubprojects/gst-plugins-good -I../subprojects/gst-plugins-good -I../subprojects/gst-plugins-good/gst-libs -Isubprojects/gstreamer -I../subprojects/gstreamer -Isubprojects/gst-plugins-base/gst-libs -I../subprojects/gst-plugins-base/gst-libs -Isubprojects/gstreamer/libs -I../subprojects/gstreamer/libs -Isubprojects/orc -I../subprojects/orc -Isubprojects/gl-headers/abyss -I../subprojects/gl-headers/abyss -Isubprojects/gl-headers/wglext -I../subprojects/gl-headers/wglext -Isubprojects/gstreamer/gst -Isubprojects/gst-plugins-base/gst-libs/gst/video -Isubprojects/gstreamer/libs/gst/base -Isubprojects/gst-plugins-base/gst-libs/gst/gl -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtQml -I/usr/include/x86_64-linux-gnu/qt5/QtNetwork -I/usr/include/x86_64-linux-gnu/qt5/QtQuick -I/usr/include/x86_64-linux-gnu/qt5/QtQmlModels -I/usr/include/x86_64-linux-gnu/qt5/QtX11Extras -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++11 -O2 -g -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Winit-self -Wmissing-include-dirs -Wno-multichar -Wvla -Wpointer-arith -fPIC -DQT_X11EXTRAS_LIB -DQT_QUICK_LIB -DQT_GUI_LIB -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -pthread -DHAVE_CONFIG_H -DHAVE_QT_QPA_HEADER '-DQT_QPA_HEADER=<5.15.2/QtGui/qpa/qplatformnativeinterface.h>' -DHAVE_QT_X11 -DHAVE_QT_EGLFS -MD -MQ subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/gstqtoverlay.cc.o -MF subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/gstqtoverlay.cc.o.d -o subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/gstqtoverlay.cc.o -c ../subprojects/gst-plugins-good/ext/qt/gstqtoverlay.cc
In file included from ../subprojects/gstreamer/gst/gstbin.h:27,
from ../subprojects/gstreamer/gst/gst.h:35,
from ../subprojects/gst-plugins-good/ext/qt/gstqtelements.h:23,
from ../subprojects/gst-plugins-good/ext/qt/gstqtoverlay.cc:82:
../subprojects/gst-plugins-good/ext/qt/gstqtoverlay.cc: In function ‘gboolean gst_element_register_qmlgloverlay(GstPlugin*)’:
../subprojects/gst-plugins-good/ext/qt/gstqtoverlay.cc:136:5: error: ‘ret’ was not declared in this scope
136 | ret |= qt5_element_init (plugin);
| ^~~
../subprojects/gstreamer/gst/gstelement.h:120:105: note: in definition of macro ‘GST_ELEMENT_REGISTER_DEFINE_WITH_CODE’
120 | #define GST_ELEMENT_REGISTER_DEFINE_WITH_CODE(e, e_n, r, t, _c_) _GST_ELEMENT_REGISTER_DEFINE_BEGIN(e) {_c_;} _GST_ELEMENT_REGISTER_DEFINE_END(e_n, r, t)
| ^~~
../subprojects/gst-plugins-good/ext/qt/gstqtoverlay.cc:138:41: note: in expansion of macro ‘_do_init’
138 | GST_RANK_NONE, GST_TYPE_QT_OVERLAY, _do_init);
| ^~~~~~~~
[1884/4260] Compiling C++ object subprojects/gs...ins-good/ext/qt/libgstqmlgl.so.p/gstqtsink.cc.o
FAILED: subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/gstqtsink.cc.o
c++ -Isubprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p -Isubprojects/gst-plugins-good/ext/qt -I../subprojects/gst-plugins-good/ext/qt -Isubprojects/gst-plugins-good -I../subprojects/gst-plugins-good -I../subprojects/gst-plugins-good/gst-libs -Isubprojects/gstreamer -I../subprojects/gstreamer -Isubprojects/gst-plugins-base/gst-libs -I../subprojects/gst-plugins-base/gst-libs -Isubprojects/gstreamer/libs -I../subprojects/gstreamer/libs -Isubprojects/orc -I../subprojects/orc -Isubprojects/gl-headers/abyss -I../subprojects/gl-headers/abyss -Isubprojects/gl-headers/wglext -I../subprojects/gl-headers/wglext -Isubprojects/gstreamer/gst -Isubprojects/gst-plugins-base/gst-libs/gst/video -Isubprojects/gstreamer/libs/gst/base -Isubprojects/gst-plugins-base/gst-libs/gst/gl -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtQml -I/usr/include/x86_64-linux-gnu/qt5/QtNetwork -I/usr/include/x86_64-linux-gnu/qt5/QtQuick -I/usr/include/x86_64-linux-gnu/qt5/QtQmlModels -I/usr/include/x86_64-linux-gnu/qt5/QtX11Extras -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++11 -O2 -g -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Winit-self -Wmissing-include-dirs -Wno-multichar -Wvla -Wpointer-arith -fPIC -DQT_X11EXTRAS_LIB -DQT_QUICK_LIB -DQT_GUI_LIB -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -pthread -DHAVE_CONFIG_H -DHAVE_QT_QPA_HEADER '-DQT_QPA_HEADER=<5.15.2/QtGui/qpa/qplatformnativeinterface.h>' -DHAVE_QT_X11 -DHAVE_QT_EGLFS -MD -MQ subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/gstqtsink.cc.o -MF subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/gstqtsink.cc.o.d -o subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/gstqtsink.cc.o -c ../subprojects/gst-plugins-good/ext/qt/gstqtsink.cc
In file included from ../subprojects/gstreamer/gst/gstbin.h:27,
from ../subprojects/gstreamer/gst/gst.h:35,
from ../subprojects/gst-plugins-good/ext/qt/gstqtelements.h:23,
from ../subprojects/gst-plugins-good/ext/qt/gstqtsink.cc:75:
../subprojects/gst-plugins-good/ext/qt/gstqtsink.cc: In function ‘gboolean gst_element_register_qmlglsink(GstPlugin*)’:
../subprojects/gst-plugins-good/ext/qt/gstqtsink.cc:139:5: error: ‘ret’ was not declared in this scope
139 | ret |= qt5_element_init (plugin);
| ^~~
../subprojects/gstreamer/gst/gstelement.h:120:105: note: in definition of macro ‘GST_ELEMENT_REGISTER_DEFINE_WITH_CODE’
120 | #define GST_ELEMENT_REGISTER_DEFINE_WITH_CODE(e, e_n, r, t, _c_) _GST_ELEMENT_REGISTER_DEFINE_BEGIN(e) {_c_;} _GST_ELEMENT_REGISTER_DEFINE_END(e_n, r, t)
| ^~~
../subprojects/gst-plugins-good/ext/qt/gstqtsink.cc:141:38: note: in expansion of macro ‘_do_init’
141 | GST_RANK_NONE, GST_TYPE_QT_SINK, _do_init);
| ^~~~~~~~
[1885/4260] Compiling C++ object subprojects/gs...gins-good/ext/qt/libgstqmlgl.so.p/gstqtsrc.cc.o
FAILED: subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/gstqtsrc.cc.o
c++ -Isubprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p -Isubprojects/gst-plugins-good/ext/qt -I../subprojects/gst-plugins-good/ext/qt -Isubprojects/gst-plugins-good -I../subprojects/gst-plugins-good -I../subprojects/gst-plugins-good/gst-libs -Isubprojects/gstreamer -I../subprojects/gstreamer -Isubprojects/gst-plugins-base/gst-libs -I../subprojects/gst-plugins-base/gst-libs -Isubprojects/gstreamer/libs -I../subprojects/gstreamer/libs -Isubprojects/orc -I../subprojects/orc -Isubprojects/gl-headers/abyss -I../subprojects/gl-headers/abyss -Isubprojects/gl-headers/wglext -I../subprojects/gl-headers/wglext -Isubprojects/gstreamer/gst -Isubprojects/gst-plugins-base/gst-libs/gst/video -Isubprojects/gstreamer/libs/gst/base -Isubprojects/gst-plugins-base/gst-libs/gst/gl -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtQml -I/usr/include/x86_64-linux-gnu/qt5/QtNetwork -I/usr/include/x86_64-linux-gnu/qt5/QtQuick -I/usr/include/x86_64-linux-gnu/qt5/QtQmlModels -I/usr/include/x86_64-linux-gnu/qt5/QtX11Extras -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++11 -O2 -g -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Winit-self -Wmissing-include-dirs -Wno-multichar -Wvla -Wpointer-arith -fPIC -DQT_X11EXTRAS_LIB -DQT_QUICK_LIB -DQT_GUI_LIB -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -pthread -DHAVE_CONFIG_H -DHAVE_QT_QPA_HEADER '-DQT_QPA_HEADER=<5.15.2/QtGui/qpa/qplatformnativeinterface.h>' -DHAVE_QT_X11 -DHAVE_QT_EGLFS -MD -MQ subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/gstqtsrc.cc.o -MF subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/gstqtsrc.cc.o.d -o subprojects/gst-plugins-good/ext/qt/libgstqmlgl.so.p/gstqtsrc.cc.o -c ../subprojects/gst-plugins-good/ext/qt/gstqtsrc.cc
In file included from ../subprojects/gstreamer/gst/gstbin.h:27,
from ../subprojects/gstreamer/gst/gst.h:35,
from ../subprojects/gst-plugins-good/ext/qt/gstqtelements.h:23,
from ../subprojects/gst-plugins-good/ext/qt/gstqtsrc.cc:30:
../subprojects/gst-plugins-good/ext/qt/gstqtsrc.cc: In function ‘gboolean gst_element_register_qmlglsrc(GstPlugin*)’:
../subprojects/gst-plugins-good/ext/qt/gstqtsrc.cc:81:5: error: ‘ret’ was not declared in this scope
81 | ret |= qt5_element_init (plugin);
| ^~~
../subprojects/gstreamer/gst/gstelement.h:120:105: note: in definition of macro ‘GST_ELEMENT_REGISTER_DEFINE_WITH_CODE’
120 | #define GST_ELEMENT_REGISTER_DEFINE_WITH_CODE(e, e_n, r, t, _c_) _GST_ELEMENT_REGISTER_DEFINE_BEGIN(e) {_c_;} _GST_ELEMENT_REGISTER_DEFINE_END(e_n, r, t)
| ^~~
../subprojects/gst-plugins-good/ext/qt/gstqtsrc.cc:83:37: note: in expansion of macro ‘_do_init’
83 | GST_RANK_NONE, GST_TYPE_QT_SRC, _do_init);
| ^~~~~~~~
[1888/4260] Compiling C++ object subprojects/gs...gins-good/ext/qt/libgstqmlgl.so.p/qtwindow.cc.o
ninja: build stopped: subcommand failed.
```
Broken since https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/876https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/870Bundle libusrsctp with the plugin2020-10-14T13:36:32ZSebastian DrögeBundle libusrsctp with the pluginCC @ystreet
I think no sane distro would package libusrsctp and Debian definitely does not. Also e.g. Firefox and Chrome are bundling the code too.
There's probably also no API stability guarantee at all for it, and by bundling the co...CC @ystreet
I think no sane distro would package libusrsctp and Debian definitely does not. Also e.g. Firefox and Chrome are bundling the code too.
There's probably also no API stability guarantee at all for it, and by bundling the code we would also get around some of the problems with the library: global state shared between different users of the library.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/874dispmanx origin isn't updated with window_resize2021-03-02T16:08:42ZAlexander Vandenbulckedispmanx origin isn't updated with window_resizeIssue introduced by the resolution of #849. When the render rectangle is called with `glimagesink render-rectangle="<230,230,640,480>"`, the origin of the render rectangle isn't adjusted but remains in the center of the screen.
This is ...Issue introduced by the resolution of #849. When the render rectangle is called with `glimagesink render-rectangle="<230,230,640,480>"`, the origin of the render rectangle isn't adjusted but remains in the center of the screen.
This is due to the following snippet:
```
static void
_set_render_rectangle (gpointer data)
{
struct SetRenderRectangle *render = data;
GST_LOG_OBJECT (render->window_egl, "setting render rectangle %i,%i+%ix%i",
render->rect.x, render->rect.y, render->rect.w, render->rect.h);
window_resize (render->window_egl, render->rect.w, render->rect.h, TRUE);
render->window_egl->render_rect = render->rect;
}
```
By setting the `render_rect` _after_ calling window_resize, the resize defaults to the dp_width and dp_height to determine the `x` and `y` value of the render rectangle origin. However, it should be determined by the render rectangle. Since, during execution of `window_resize` the `render_rect` is missing it wrongly evaluates the following:
```
/* If there is no render rectangle, center the width*height frame
* inside dp_width*dp_height */
if (window_egl->render_rect.w <= 0 || window_egl->render_rect.h <= 0) {
GstVideoRectangle dst;
dst.w = window_egl->dp_width;
dst.h = window_egl->dp_height;
dst.x = dst.y = 0;
gst_video_sink_center_rect (src, dst, &res, FALSE);
} else {
gst_video_sink_center_rect (src, window_egl->render_rect, &res, FALSE);
}
```
which causes the unchanged origin.
Assigning the render rectangle _before_ calling `window_resize` fixes the issue.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/872webrtc - syntax error in generated SDP anwer2019-01-19T13:42:52ZPeter Gertenwebrtc - syntax error in generated SDP anwerI am trying to establish a WebRTC connection to Janus gateway. Janus creates the SDP offer. If using only a video stream, everything works. If the SDP offer contains a video and a datachannel, gstreamer webrtc produces a SDP answer with ...I am trying to establish a WebRTC connection to Janus gateway. Janus creates the SDP offer. If using only a video stream, everything works. If the SDP offer contains a video and a datachannel, gstreamer webrtc produces a SDP answer with syntax error as well as missing parts for the datachannel description.
Syntax error in line 17 of sdp_answer.txt
[sdp_offer.txt](/uploads/fa7c84cc9d59192da94e420f3c3b1dce/sdp_offer.txt)
[sdp_answer.txt](/uploads/be74f8e3c17abf735d264c0f0905494e/sdp_answer.txt)
GStreamer 1.14.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/872v4l2videodec: handle video frame list increasing.2022-02-28T15:21:59ZKevin Songv4l2videodec: handle video frame list increasing.Below code in gstvideodecoder.c indicate video frame list increasing. h264parser will output field by field for interlace stream. The video frame list will increase when playback. How to drop the video frame list for interlaced video?
`...Below code in gstvideodecoder.c indicate video frame list increasing. h264parser will output field by field for interlace stream. The video frame list will increase when playback. How to drop the video frame list for interlaced video?
```
if (priv->frames.length > 10) {
GST_DEBUG_OBJECT (decoder, "decoder frame list getting long: %d frames,"
"possible internal leaking?", priv->frames.length);
}
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/875HDR10 CLL metadata is allowed to change2022-06-20T13:13:59ZValZapodHDR10 CLL metadata is allowed to changeContrary to popular belief HDR10 static metadata can change per segment on seamless branching Blu-rays (ripping of which was also very broken due to wrong TrueHD duplicated frames deletion on segment border) and it is also allowed to cha...Contrary to popular belief HDR10 static metadata can change per segment on seamless branching Blu-rays (ripping of which was also very broken due to wrong TrueHD duplicated frames deletion on segment border) and it is also allowed to change in mp4. As ffmpeg mail says (right now [last HDR metadata patches](https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=3373) are being accepted):
https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg108319.html
> in that some formats allow use to set it on frame,
> some on the stream, some on the container
> I notice that color data can be set per frame and per stream already
> and I don’t fully understand how these interact if converting between data in
> frame (e.g HEVC SEI in stream in hev1) or data in header (e.g. MOV mdcv tag or
> HEVC SEI in hvc1 format).
And this is correct. Free CTA-861-G (and now -H) standard mandate that and I quote:
> If the Source supports the transmission of the Dynamic Range and Mastering InfoFrame and if it
> determines that the Sink is capable of receiving that information, the Source shall send the Dynamic
> Range and Mastering InfoFrame **once per Video Field**
What that means is that it is allowed to change and display should be fast enough to change it on the fly.
In fact there is a sample from "In the Heart of the Sea" movie https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/uploads/16c628c535865d7282a48317064345a2/out.mp4 that utilizes that.
It can cause all kind of issues for you. mpv does support it and so does MadVR.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/873fdkaacdec: Failed to build using fdk-aac < 0.1.42019-01-25T20:52:25ZYeongjin Jeonggingerbk247@gmail.comfdkaacdec: Failed to build using fdk-aac < 0.1.4With the old versions fdk-aac < 0.1.4 installed, compilation of the fdkaac plugin from git master fails with the following error:
```bash
gstfdkaacdec.c:154:41: error: ‘AAC_PCM_MAX_OUTPUT_CHANNELS’ undeclared (first use in this function...With the old versions fdk-aac < 0.1.4 installed, compilation of the fdkaac plugin from git master fails with the following error:
```bash
gstfdkaacdec.c:154:41: error: ‘AAC_PCM_MAX_OUTPUT_CHANNELS’ undeclared (first use in this function)
err = aacDecoder_SetParam (self->dec, AAC_PCM_MAX_OUTPUT_CHANNELS, 0);
^
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/876Out-of-bounds read in tag parsing2021-06-02T22:20:48ZNatalie SilvanovichOut-of-bounds read in tag parsingThe attached file causes an out-of-bounds read when played with gstreamer. This bug probably doesn't have serious security consequences, but filing it as a confidential issue just in case. A stack trace is below.
```
==3263091==ERROR: A...The attached file causes an out-of-bounds read when played with gstreamer. This bug probably doesn't have serious security consequences, but filing it as a confidential issue just in case. A stack trace is below.
```
==3263091==ERROR: AddressSanitizer: SEGV on unknown address 0x629000080000 (pc 0x7f51cfd1918c bp 0x7f51c6e338cc sp 0x7f51c6e33860 T6)
==3263091==The signal is caused by a READ memory access.
#0 0x7f51cfd1918c in id3v2_ununsync_data /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-base/gst-libs/gst/tag/id3v2.c:161:11
#1 0x7f51cfd1b177 in id3v2_parse_frame /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-base/gst-libs/gst/tag/id3v2frames.c:137:17
#2 0x7f51cfd19b16 in id3v2_frames_to_tag_list /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-base/gst-libs/gst/tag/id3v2.c:598:11
#3 0x7f51cfd19b16 in gst_tag_list_from_id3v2_tag /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-base/gst-libs/gst/tag/id3v2.c:261:3
#4 0x7f51c8a2a65a in gst_id3demux_parse_tag /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-good/gst/id3demux/gstid3demux.c:181:13
#5 0x7f51cfd13354 in gst_tag_demux_pull_start_tag /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-base/gst-libs/gst/tag/gsttagdemux.c:1266:17
#6 0x7f51cfd13354 in gst_tag_demux_element_find /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-base/gst-libs/gst/tag/gsttagdemux.c:1328:9
#7 0x7f51cfd14464 in gst_tag_demux_element_loop /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-base/gst-libs/gst/tag/gsttagdemux.c:1452:13
#8 0x7f51cfc5edfe in gst_task_func /usr/local/google/home/natashenka/gst-build/build/../subprojects/gstreamer/gst/gsttask.c:384:5
#9 0x7f51cd19b973 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7b973)
#10 0x7f51cd19b08c (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7b08c)
#11 0x7f51cd07fea6 in start_thread nptl/pthread_create.c:477:8
#12 0x7f51ccdbbdee in clone misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /usr/local/google/home/natashenka/gst-build/build/../subprojects/gst-plugins-base/gst-libs/gst/tag/id3v2.c:161:11 in id3v2_ununsync_data
Thread T6 (id3demux0:sink) created by T4 (typefind:sink) here:
#0 0x4c0e0a in pthread_create (/usr/local/google/home/natashenka/Downloads/video/video+0x4c0e0a)
#1 0x7f51cd1c2fc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0xa2fc0)
Thread T4 (typefind:sink) created by T0 here:
#0 0x4c0e0a in pthread_create (/usr/local/google/home/natashenka/Downloads/video/video+0x4c0e0a)
#1 0x7f51cd1c2fc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0xa2fc0)
```
![seg](/uploads/086d01c9b66ffe1b9f1cd542708d184a/seg.mp3)Tim-Philipp Müllertim@centricular.comTim-Philipp Müllertim@centricular.comhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/877Application linking error for gstreamer variables from gtkwebkit library2022-04-08T11:48:56ZDonia AbrahamApplication linking error for gstreamer variables from gtkwebkit libraryBuild fails because of following error
```
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libwebkit2gtk-4.0.so: undefined reference to GST_CAT_DEFAULT'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64...Build fails because of following error
```
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libwebkit2gtk-4.0.so: undefined reference to GST_CAT_DEFAULT'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libwebkit2gtk-4.0.so: undefined reference to _gst_debug_min'
```
Expected behavior
Build successful.
Other information
Linux version - 20.04
Gstreamer 1.18.3 - built from scratch on the PC using Meson
gtk-webkit - installed by apt get
Trying to build application against Linux 20.04 with latest Gstreamer and GTKWebkit.Downloaded, build and installed gstreamer,apt installed libwebkit2gtk-4.0 and libgtk-4.0-dev
Linker error from gst variables.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/875IPv6 on rtspsrc/gstmultiudpsink: Invalid address family (got 10)2023-07-08T09:50:09ZalexzorinIPv6 on rtspsrc/gstmultiudpsink: Invalid address family (got 10)Hi!
I am hitting what appears to be an issue with the way `rtspsrc` sets up the pipeline when IPv6 addresses are involved.
I haven't seen any similar reports so I'm thinking it might be a confluence of issues triggered by the specific...Hi!
I am hitting what appears to be an issue with the way `rtspsrc` sets up the pipeline when IPv6 addresses are involved.
I haven't seen any similar reports so I'm thinking it might be a confluence of issues triggered by the specific IP camera (DH-IPC-HFW1431SP-0280B) I am using, so I have also attached the RTSP pcap at the end of this issue.
The problem may be most simply reproduced with:
gst-launch-1.0 --gst-debug=3 rtspsrc "location=rtsp://user:pass@[aaaa:bbbb:cccc:dddd:aaaa:bbbb:cccc:dddd]:554" ! fakesink
the resulting output is:
$ sudo gst-launch-1.0 --gst-debug=3 rtspsrc "location=rtsp://user:pass@[aaaa:bbbb:cccc:dddd:aaaa:bbbb:cccc:dddd]:554" ! fakesink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://user:pass@[aaaa:bbbb:cccc:dddd:aaaa:bbbb:cccc:dddd]:554
Progress: (open) Retrieving server options
Progress: (open) Retrieving media info
Progress: (request) SETUP stream 0
0:00:01.352701421 627027 0x556a170d8b60 WARN multiudpsink gstmultiudpsink.c:1285:gst_multiudpsink_configure_client:<udpsink1> error: Invalid address family (got 10)
0:00:01.352742723 627027 0x556a170d8b60 WARN basesink gstbasesink.c:5367:gst_base_sink_change_state:<udpsink1> error: Failed to start
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
0:00:01.353009239 627027 0x556a174bc2c0 WARN multiudpsink gstmultiudpsink.c:1285:gst_multiudpsink_configure_client:<udpsink1> error: Invalid address family (got 10)
0:00:01.353050639 627027 0x556a174bc2c0 WARN basesink gstbasesink.c:5367:gst_base_sink_change_state:<udpsink1> error: Failed to start
0:00:01.353080450 627027 0x556a174bc2c0 WARN bin gstbin.c:2832:reset_state:<udpsink1> Failed to switch back down to PAUSED
0:00:01.353103012 627027 0x556a174bc2c0 WARN multiudpsink gstmultiudpsink.c:1285:gst_multiudpsink_configure_client:<udpsink0> error: Invalid address family (got 10)
0:00:01.353124368 627027 0x556a174bc2c0 WARN basesink gstbasesink.c:5367:gst_base_sink_change_state:<udpsink0> error: Failed to start
0:00:01.353149217 627027 0x556a174bc2c0 WARN bin gstbin.c:2832:reset_state:<udpsink0> Failed to switch back down to PAUSED
0:00:01.353355490 627027 0x556a174bc2c0 WARN bin gstbin.c:2832:reset_state:<rtspsrc0> Failed to switch back down to PAUSED
ERROR: pipeline doesn't want to play.
ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSink:udpsink1: Could not get/set settings from/on resource.
Additional debug info:
gstmultiudpsink.c(1285): gst_multiudpsink_configure_client (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSink:udpsink1:
Invalid address family (got 10)
Setting pipeline to NULL ...
Freeing pipeline ...
Unredacted pcap between GStreamer and the IP camera (don't mind the password): [rtsp.pcapng](/uploads/ebe5f2b97aa807caa6af7b0eb43fc432/rtsp.pcapng)
I am hitting this in `libgstreamer-plugins-good1.0-0:amd64==1.16.2-1ubuntu2` as well as `1.19 (git)` [from Docker](https://hub.docker.com/r/restreamio/gstreamer).
Thanks very much! Please let me know if there's any other information you might need.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/876Memory leak with curlhttpsrc and adaptivedemux2019-02-19T18:50:19Zgurram sandeep ReddyMemory leak with curlhttpsrc and adaptivedemuxI have a pipeline to play DASH content. I have replaced souphttpsrc with curlhttpsrc but observed memory leaks with curlhttpsrc and adaptivedemux. The pipeline will be created only once and mpd data will be updated on url change(channel...I have a pipeline to play DASH content. I have replaced souphttpsrc with curlhttpsrc but observed memory leaks with curlhttpsrc and adaptivedemux. The pipeline will be created only once and mpd data will be updated on url change(channel Zap). Valgrind shows the leaks as below
* ==2989== 243 bytes in 18 blocks are definitely lost in loss record 7,766 of 8,397
* ==2989== at 0x483E590: malloc (vg_replace_malloc.c:299)
* ==2989== by 0x5058E7F: vasprintf (vasprintf.c:73)
* ==2989== by 0x4D6F28B: g_vasprintf (gprintf.c:316)
* ==2989== by 0x4D4D113: g_strdup_vprintf (gstrfuncs.c:514)
* ==2989== by 0x4D4D137: g_strdup_printf (gstrfuncs.c:540)
* ==2989== by 0x4BC2F57: gst_object_set_name_default (gstobject.c:546)
* ==2989== by 0x4BC2F57: gst_object_set_name (gstobject.c:609)
* ==2989== by 0x51641A7: object_set_property (gobject.c:1421)
* ==2989== by 0x51647B7: g_object_new_internal (gobject.c:1815)
* ==2989== by 0x516618F: g_object_newv (gobject.c:1928)
* ==2989== by 0x5166803: g_object_new (gobject.c:1621)
* ==2989== by 0x4BF790F: gst_element_factory_create (gstelementfactory.c:372)
* ==2989== by 0x4C534AB: gst_element_make_from_uri (gsturi.c:660)
* ==2989== by 0xBEEA1EB: gst_adaptive_demux_stream_update_source (gstadaptivedemux.c:2944)
* ==2989== by 0xBEEA1EB: gst_adaptive_demux_stream_download_uri (gstadaptivedemux.c:3097)
* ==2989== by 0xBEEC42B: gst_adaptive_demux_stream_download_header_fragment (gstadaptivedemux.c:3259)
* ==2989== by 0xBEEC42B: gst_adaptive_demux_stream_download_fragment (gstadaptivedemux.c:3314)
* ==2989== by 0xBEEC42B: gst_adaptive_demux_stream_download_loop (gstadaptivedemux.c:3739)
* ==2989== by 0x4C4C867: gst_task_func (gsttask.c:332)
* ==2989== by 0x4D55C2F: g_thread_pool_thread_proxy (gthreadpool.c:307)
* ==2989== by 0x4D553CF: g_thread_proxy (gthread.c:780)
* ==2989== by 0x4B805D7: start_thread (pthread_create.c:335)
* ==2989== by 0x50A2101: ??? (clone.S:86)
* =2989== 16,220 (720 direct, 15,500 indirect) bytes in 45 blocks are definitely lost in loss record 8,363 of 8,397
* ==2989== at 0x483E590: malloc (vg_replace_malloc.c:299)
* ==2989== by 0x4D398A7: g_malloc (gmem.c:94)
* ==2989== by 0x4D4BCBB: g_slice_alloc (gslice.c:1025)
* ==2989== by 0x4C3E1F3: gst_structure_new_id_empty_with_size (gststructure.c:147)
* ==2989== by 0x4C3FFAB: gst_structure_new_valist (gststructure.c:283)
* ==2989== by 0x4C3FFDF: gst_structure_new (gststructure.c:255)
* ==2989== by 0xD8ACE8F: gst_curl_http_src_handle_response (gstcurlhttpsrc.c:1179)
* ==2989== by 0xD8ACE8F: gst_curl_http_src_create (gstcurlhttpsrc.c:818)
* ==2989== by 0xBDC6DF7: gst_base_src_get_range (gstbasesrc.c:2512)
* ==2989== by 0xBDC8563: gst_base_src_loop (gstbasesrc.c:2836)
* ==2989== by 0x4C4C867: gst_task_func (gsttask.c:332)
* ==2989== by 0x4D55C2F: g_thread_pool_thread_proxy (gthreadpool.c:307)
* ==2989== by 0x4D553CF: g_thread_proxy (gthread.c:780)
* ==2989== by 0x4B805D7: start_thread (pthread_create.c:335)
* ==2989== by 0x50A2101: ??? (clone.S:86)
Valgrind didn't reported curlhttpsrc leak when I freed http_headers. But adaptivedemux leaks are still reported.
[vg.log](/uploads/f705fd96dece5d86208fb430d02e5575/vg.log)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/876rtpjitterbuffer: Waiting on timers during EOS handling can deadlock2022-11-14T10:06:34ZSebastian Drögertpjitterbuffer: Waiting on timers during EOS handling can deadlockThis is related to https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/608 .
What happens is the following:
* The streaming thread waits on the timers
```cpp
if (type == ITEM_TYPE_EVENT && outevent &&
G...This is related to https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/608 .
What happens is the following:
* The streaming thread waits on the timers
```cpp
if (type == ITEM_TYPE_EVENT && outevent &&
GST_EVENT_TYPE (outevent) == GST_EVENT_EOS) {
g_assert (priv->eos);
while (rtp_timer_queue_length (priv->timers) > 0) {
/* Stopping timers */
unschedule_current_timer (jitterbuffer);
JBUF_WAIT_TIMER (priv);
}
}
```
* `gst_rtp_jitter_buffer_flush_start()` does **not** cause any flushing or anything of the timers. Doing `JBUF_SIGNAL_TIMER` would not be sufficient (would still be racy) because nothing is making sure that the timers are actually flushed away. Maybe code similar to the `GST_STATE_CHANGE_PAUSED_TO_READY` handling would be needed, together with actually starting the timers again later.
This then causes the streaming thread to wait there, the timer thread to wait on the same condition variable in `wait_next_timeout`, and the flushing thread to wait forever for the streaming thread to shut down.
----
The timer condition variable handling (and also others) seems also rather fragile. Especially for the timer we have two threads waiting for the same condition variable and there is only ever a `g_cond_signal()`.
For this and the other condition variables it seems like they're sometimes missing a loop to protect against spurious wakeups and also are sometimes missing an actual condition they check before/after being woken up.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1570rtpjitterbuffer: Waiting on timers during EOS handling can deadlock2023-10-10T05:57:31ZSebastian Drögertpjitterbuffer: Waiting on timers during EOS handling can deadlockThis is related to https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/608 .
What happens is the following:
* The streaming thread waits on the timers
```cpp
if (type == ITEM_TYPE_EVENT && outevent &&
G...This is related to https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/608 .
What happens is the following:
* The streaming thread waits on the timers
```cpp
if (type == ITEM_TYPE_EVENT && outevent &&
GST_EVENT_TYPE (outevent) == GST_EVENT_EOS) {
g_assert (priv->eos);
while (rtp_timer_queue_length (priv->timers) > 0) {
/* Stopping timers */
unschedule_current_timer (jitterbuffer);
JBUF_WAIT_TIMER (priv);
}
}
```
* `gst_rtp_jitter_buffer_flush_start()` does **not** cause any flushing or anything of the timers. Doing `JBUF_SIGNAL_TIMER` would not be sufficient (would still be racy) because nothing is making sure that the timers are actually flushed away. Maybe code similar to the `GST_STATE_CHANGE_PAUSED_TO_READY` handling would be needed, together with actually starting the timers again later.
This then causes the streaming thread to wait there, the timer thread to wait on the same condition variable in `wait_next_timeout`, and the flushing thread to wait forever for the streaming thread to shut down.
----
The timer condition variable handling (and also others) seems also rather fragile. Especially for the timer we have two threads waiting for the same condition variable and there is only ever a `g_cond_signal()`.
For this and the other condition variables it seems like they're sometimes missing a loop to protect against spurious wakeups and also are sometimes missing an actual condition they check before/after being woken up.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/877curlhttpsrc: Delay in playback start with DASH compared to souphttpsrc2021-10-20T07:33:26Zgurram sandeep Reddycurlhttpsrc: Delay in playback start with DASH compared to souphttpsrcI have created a pipeline to play DASH content . Initially the pipeline used souphttpsrc ,now I have replaced it with curlhttpsrc. With curlhttpsrc ,I have observed delay in playback start . When I debugged curlhttpsrc , I found the http...I have created a pipeline to play DASH content . Initially the pipeline used souphttpsrc ,now I have replaced it with curlhttpsrc. With curlhttpsrc ,I have observed delay in playback start . When I debugged curlhttpsrc , I found the http requests are queued and select system call with a timeout of 1s . When I reduced the timeout to 50ms ,I observed same delay as souphttpsrc. Is timeout causing this delay or the delay is due to something else?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/881audioconvert: unable to set property 'mix-matrix'2021-03-17T13:42:36ZStéphane Cerveauscerveau@igalia.comaudioconvert: unable to set property 'mix-matrix'parse launch does not support mix-matrix syntax anymore.
```
$ gst-launch-1.0 audiotestsrc ! audio/x-raw, channels=4 ! audioconvert mix-matrix="<<(float)1.0, (float)0.0, (float)0.0, (float)0.0>, <(float)0.0, (float)1.0, (float)0.0, (flo...parse launch does not support mix-matrix syntax anymore.
```
$ gst-launch-1.0 audiotestsrc ! audio/x-raw, channels=4 ! audioconvert mix-matrix="<<(float)1.0, (float)0.0, (float)0.0, (float)0.0>, <(float)0.0, (float)1.0, (float)0.0, (float)0.0>>" ! audio/x-raw,channels=2 ! autoaudiosink
```
Getting:
```
GST_PIPELINE subprojects/gstreamer/gst/parse/grammar.y:453:gst_parse_element_set: could not set property "mix-matrix" in element "audioconvert0" to "<<(float)1.0, (float)0.0, (float)0.0, (float)0.0>, <(float)0.0, (float)1.0, (float)0.0, (float)0.0>>"
```
Working with 1.18https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/879broken element template2023-10-28T02:13:07ZDenisbroken element templateGStreamer Plugin Writer’s Guide refers to gst-plugins-bad/tools/gst-element-maker as to a modern approach to generate skeleton for plugin. It works properly for **basetransform** but fails for **element**. It produces a lot of errors beg...GStreamer Plugin Writer’s Guide refers to gst-plugins-bad/tools/gst-element-maker as to a modern approach to generate skeleton for plugin. It works properly for **basetransform** but fails for **element**. It produces a lot of errors beginning from gsttest.c:61:8: error: unknown type name ‘GstIndex’.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/879v4l2src: Doesn't Stop After Device Removed2021-04-21T14:34:48ZAntonin Roussetv4l2src: Doesn't Stop After Device RemovedThis follows [777354](https://bugzilla.gnome.org/show_bug.cgi?id=777354).
I have some new insights showing that this might be related to gstreamer and not the kernel.
I use two same cameras on `/dev/video0` and `/dev/video1`, but gstrea...This follows [777354](https://bugzilla.gnome.org/show_bug.cgi?id=777354).
I have some new insights showing that this might be related to gstreamer and not the kernel.
I use two same cameras on `/dev/video0` and `/dev/video1`, but gstreamer only stops after `/dev/video0` is disconnected.
I attach the result of `GST_DEBUG="2,v4l2*:6" gst-launch-1.0 v4l2src device=/dev/video${i} ! fakesink 2> video${i}-gst.log` for `i=0,1`. For `video1`, I CTRL-C after 2 minutes.
[video0-v4l2.txt](/uploads/e4abe800724c826548a4d55034c441bd/video0-v4l2.txt)
[video0-udev.txt](/uploads/6e8da2dd7906a24526c2e9b63c9552b6/video0-udev.txt)
[video0-gst.log](/uploads/7ce2f1814b7bd1e4bc61a1b31d8f1cad/video0-gst.log)
[video1-v4l2.txt](/uploads/3bf5e470f33847c0d08da7967b3132b8/video1-v4l2.txt)
[video1-udev.txt](/uploads/b9740564d6a6fed19fade756041b12db/video1-udev.txt)
[video1-gst.log](/uploads/50defd07e8786ca9c93f0c9adf9df944/video1-gst.log)
`ffmpeg -i /dev/video${i}` stops as intended.
Bug is still present in _GStreamer 1.19.0_https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/882Deadlock stopping alsa audiosink2021-04-08T08:14:31ZDoug NazarDeadlock stopping alsa audiosinkI've occasionally had my app deadlock. The main thread is waiting for the alsasink thread to finish but the alsasink thread is stuck in the loop at https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/ext/alsa/gstalsas...I've occasionally had my app deadlock. The main thread is waiting for the alsasink thread to finish but the alsasink thread is stuck in the loop at https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/ext/alsa/gstalsasink.c#L1069 and is not making any progress since alsa is paused and `snd_pcm_writei()` returns 0 if it's in `SND_PCM_STATE_PAUSED`.
I've been staring at the logic and I can't find anything that synchronizes between the sink thread and pausing. If the sink thread passes the `gst_audio_ring_buffer_prepare_read()` check in https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/gst-libs/gst/audio/gstaudiosink.c#L236, but another thread calls `gst_alsasink_pause()` before `snd_pcm_writei()` it can get into an infinite loop. The locking that happens at the ring buffer level doesn't impact the locking at the gstalsasink.
I've debugged this with 1.18.3 but a quick scan of 1.18.4 & HEAD doesn't show anything that I think will impact this.
I'm currently running with the following patch, which doesn't trigger during normal usage, but does allow it to recover. I'm not sure if it's the correct way to solve this issue. Perhaps the audioring should ensure it's out of the write loop before calling the next layer on pause.
```
diff -ru gst-plugins-base-1.18.3/ext/alsa/gstalsasink.c /var/tmp/portage/media-libs/gst-plugins-base-1.18.3/work/gst-plugins-base-1.18.3/ext/alsa/gstalsasink.c
--- gst-plugins-base-1.18.3/ext/alsa/gstalsasink.c 2021-01-13 16:07:13.997253000 -0500
+++ /var/tmp/portage/media-libs/gst-plugins-base-1.18.3/work/gst-plugins-base-1.18.3/ext/alsa/gstalsasink.c 2021-03-13 18:11:26.729060020 -0500
@@ -1068,6 +1068,14 @@
goto write_error;
}
continue;
+ } else if (err == 0 && alsa->hw_support_pause) {
+ /* We might be paused, if so, just bail */
+ snd_pcm_state_t state;
+
+ state = snd_pcm_state (alsa->handle);
+ GST_WARNING_OBJECT (asink, "TMPDBG: pause check. state = %i", state);
+ if (state == SND_PCM_STATE_PAUSED)
+ break;
}
ptr += snd_pcm_frames_to_bytes (alsa->handle, err);
diff -ru gst-plugins-base-1.18.3/gst-libs/gst/audio/gstaudiosink.c /var/tmp/portage/media-libs/gst-plugins-base-1.18.3/work/gst-plugins-base-1.18.3/gst-libs/gst/audio/gstaudiosink.c
--- gst-plugins-base-1.18.3/gst-libs/gst/audio/gstaudiosink.c 2021-01-13 16:07:14.021253000 -0500
+++ /var/tmp/portage/media-libs/gst-plugins-base-1.18.3/work/gst-plugins-base-1.18.3/gst-libs/gst/audio/gstaudiosink.c 2021-03-15 15:03:21.496837689 -0400
@@ -254,7 +254,12 @@
GST_DEBUG_FUNCPTR_NAME (writefunc),
(errno > 1 ? g_strerror (errno) : "unknown"), left, written);
break;
+ } else if (written == 0 && G_UNLIKELY (g_atomic_int_get (&buf->state) !=
+ GST_AUDIO_RING_BUFFER_STATE_STARTED)) {
+ GST_WARNING_OBJECT (sink, "TMPDBG: started check.");
+ break;
}
+
left -= written;
readptr += written;
} while (left > 0);
```