gst-plugins-base issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues2021-09-24T13:26:04Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/803video-convert: Add fast-paths to v210 and maybe more fast-paths from v2102021-09-24T13:26:04ZSebastian Drögevideo-convert: Add fast-paths to v210 and maybe more fast-paths from v210See https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/775 . v210 is expensive and slow otherwise.See https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/775 . v210 is expensive and slow otherwise.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/802Frame drop combining three videos in a compositor2021-09-24T13:26:03ZJosh MatthewsFrame drop combining three videos in a compositorHere's the pipeline:
```
gst-launch-1.0 \
compositor name=vmixer sink_1::xpos=1910 sink_1::ypos=1080 sink_2::xpos=1910 sink_3::ypos=1080 ! videoconvert ! videorate ! autovideosink \
filesrc location=/Users/jdm/Documents/VID_20200...Here's the pipeline:
```
gst-launch-1.0 \
compositor name=vmixer sink_1::xpos=1910 sink_1::ypos=1080 sink_2::xpos=1910 sink_3::ypos=1080 ! videoconvert ! videorate ! autovideosink \
filesrc location=/Users/jdm/Documents/VID_20200709_201158.mp4 ! decodebin name=demux1 ! queue2 ! videoconvert ! videoscale ! videoflip method=vertical-flip ! videorate ! vmixer. \
filesrc location=/Users/jdm/Documents/babyfaceovertroubledwater.mov ! decodebin name=demux3 ! queue2 ! videoconvert ! videoscale ! videorate ! vmixer. \
filesrc location=/Users/jdm/Documents/bridgeoverstubbledwater.mp4 ! decodebin name=demux2 ! queue2 ! videoconvert ! videoscale ! videorate ! vmixer. \
```
Videos:
* https://www.joshmatthews.net/babyfaceovertroubledwater.MOV
* https://www.joshmatthews.net/bridgeoverstubbledwater.mp4
* https://www.joshmatthews.net/VID_20200723_203606.mp4
Under macOS, when I run this there is intermittently a noticeable frame drop at the start of the pipeline. This seems to be affected by differences in timing, and different settings of GST_DEBUG seem to make it more or less frequent. [This]([droplog4](/uploads/da8cc5f836230be8fd16860a0add48b0/droplog4)) is a log with GST_DEBUG=4. GST_DEBUG=6 makes constant frame drops occur throughout the video; it's not clear to me if that's expected behaviour or not.
When discussing this on IRC, I mentioned that adding `video/x-raw,framerate=60/1` to the pipeline before the `autovideosink` made the drop disappear, but I have since reproduced the drop with that element present.
This seems much easier to reproduce when not redirecting stdout to a file, for some reason.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/797Pipeline with audiomixer won't play unless GST_DEBUG=6 or GST_DEBUG=5 is present2021-09-24T13:26:02ZJosh MatthewsPipeline with audiomixer won't play unless GST_DEBUG=6 or GST_DEBUG=5 is presentContinuing from the fun in #795, I have the following pipeline on macOS with https://joshmatthews.net/bridgeoverstubbledwater.mp4 and https://joshmatthews.net/whiskerstroubled2.mov:
```
gst-launch-1.0 audiomixer name=amixer ! audioconver...Continuing from the fun in #795, I have the following pipeline on macOS with https://joshmatthews.net/bridgeoverstubbledwater.mp4 and https://joshmatthews.net/whiskerstroubled2.mov:
```
gst-launch-1.0 audiomixer name=amixer ! audioconvert ! audioresample ! autoaudiosink \
filesrc location=/Users/jdm/Documents/whiskerstroubled2.mov ! decodebin ! audioconvert ! audioresample ! amixer. \
filesrc location=/Users/jdm/Documents/bridgeoverstubbledwater.mp4 ! decodebin ! audioconvert ! audioresample ! amixer.
```
When I launch this pipeline, it doesn't start playing. GST_DEBUG=3 shows:
```
[gst-master] bash-3.2$ GST_DEBUG=3 ~/mix2.sh
Setting pipeline to PAUSED ...
0:00:00.067266000 62956 0x7fe3de81b180 WARN aggregator gstaggregator.c:1946:gst_aggregator_query_latency_unlocked:<amixer> Latency query failed
0:00:00.067288000 62956 0x7fe3dd615af0 WARN basesrc gstbasesrc.c:3688:gst_base_src_start_complete:<filesrc1> pad not activated yet
0:00:00.067472000 62956 0x7fe3dd615af0 WARN basesrc gstbasesrc.c:3688:gst_base_src_start_complete:<filesrc0> pad not activated yet
Pipeline is PREROLLING ...
0:00:00.080537000 62956 0x7fe3de81b2a0 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type .xyz
0:00:00.080554000 62956 0x7fe3de81b2a0 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type keys
0:00:00.080562000 62956 0x7fe3de81b2a0 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type ....
0:00:00.080567000 62956 0x7fe3de81b2a0 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type ....
0:00:00.080580000 62956 0x7fe3de81b2a0 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type pasp
0:00:00.080538000 62956 0x7fe3de81b300 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type pasp
0:00:00.080628000 62956 0x7fe3de81b2a0 WARN qtdemux qtdemux.c:3057:qtdemux_parse_trex:<qtdemux1> failed to find fragment defaults for stream 1
0:00:00.080643000 62956 0x7fe3de81b300 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type keys
0:00:00.080651000 62956 0x7fe3de81b300 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type ....
0:00:00.080655000 62956 0x7fe3de81b300 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type ....
0:00:00.080660000 62956 0x7fe3de81b300 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type keys
0:00:00.080664000 62956 0x7fe3de81b300 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type ....
0:00:00.080710000 62956 0x7fe3de81b2a0 WARN qtdemux qtdemux.c:3057:qtdemux_parse_trex:<qtdemux1> failed to find fragment defaults for stream 2
0:00:00.080736000 62956 0x7fe3de81b300 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type ....
0:00:00.080765000 62956 0x7fe3de81b300 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type ....
0:00:00.080772000 62956 0x7fe3de81b300 WARN qtdemux qtdemux_types.c:245:qtdemux_type_get: unknown QuickTime node type ....
0:00:00.080817000 62956 0x7fe3de81b300 WARN qtdemux qtdemux.c:3057:qtdemux_parse_trex:<qtdemux0> failed to find fragment defaults for stream 1
0:00:00.080881000 62956 0x7fe3de81b300 WARN qtdemux qtdemux.c:3057:qtdemux_parse_trex:<qtdemux0> failed to find fragment defaults for stream 2
0:00:00.088083000 62956 0x7fe3de81b300 FIXME videodecoder gstvideodecoder.c:1049:gst_video_decoder_drain_out:<vtdechw0> Sub-class should implement drain()
Redistribute latency...
0:00:00.121603000 62956 0x7fe3de81b2a0 FIXME videodecoder gstvideodecoder.c:1049:gst_video_decoder_drain_out:<vtdechw1> Sub-class should implement drain()
Redistribute latency...
0:00:00.126470000 62956 0x7fe3de81b300 FIXME videodecoder gstvideodecoder.c:1049:gst_video_decoder_drain_out:<vtdechw0> Sub-class should implement drain()
0:00:00.128649000 62956 0x7fe3de81b2a0 FIXME videodecoder gstvideodecoder.c:1049:gst_video_decoder_drain_out:<vtdechw1> Sub-class should implement drain()
0:00:00.141304000 62956 0x7fe3de81b180 WARN aggregator gstaggregator.c:1946:gst_aggregator_query_latency_unlocked:<amixer> Latency query failed
Redistribute latency...
0:00:00.157926000 62956 0x7fe3de81b360 WARN GST_PADS gstpad.c:4303:gst_pad_peer_query:<audioresample2:src> could not send sticky events
```
However, trying to get a GST_DEBUG=5 or GST_DEBUG=6 log causes the pipeline to play as expected; any lower level plays nothing. Looks like there's some kind of timing race that the extra logging happens to work around?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/796glimagesink/GstVideoOverlay issue on macOS2023-04-08T13:59:33ZIsaac Lightburnisaac@openkj.orgglimagesink/GstVideoOverlay issue on macOSHaving a weird issue on macOS with the video overlay functionality and glimagesink.
On Linux using either xvimagesink or glimagesink or on Windows with d3dvideosink the same code works fine every time, video is output overlayed on the w...Having a weird issue on macOS with the video overlay functionality and glimagesink.
On Linux using either xvimagesink or glimagesink or on Windows with d3dvideosink the same code works fine every time, video is output overlayed on the window ID as set using gst_video_overlay_set_window_handle. (It's a Qt widget, just for reference)
On macOS, using glimagesink, sometimes a new window is created regardless of what's set via the set window handle function. I normally just call it while the pipeline state is still NULL before setting it to playing, though I checked to see if a message matching gst_is_video_overlay_prepare_window_handle was showing up in my sync message handler that I needed to respond to, but it isn't.
I did notice that in the instances when it shows a new window, gstreamer logs "Output window was closed" from the glimagesink element, though the winid is still valid, the window is open and visible, and the overlay will work on subsequent plays via the same pipeline (no pipeline or element unref/creation or linkage changes between plays) outputting to the same window ID. Not sure why gstreamer thinks that the winID has gone away sometimes when it hasn't, but that seems to be what's triggering it. Seems to happen around every 5th play on average, sometimes more, sometimes less.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/793uridecodebin segfault (race condition).2021-09-24T13:26:01ZMarc Leemanuridecodebin segfault (race condition).I am debugging an application that uses GStreamer for decoding video (1.16.2). Intermittently, there is a segmentation fault that happens when a pipeline is being set to NULL. The backtrace seems to point to decodebin when it is cleaning...I am debugging an application that uses GStreamer for decoding video (1.16.2). Intermittently, there is a segmentation fault that happens when a pipeline is being set to NULL. The backtrace seems to point to decodebin when it is cleaning up the spawned pads (there should only be one exposed though).
```
--Type <RET> for more, q to quit, c to continue without paging--
Thread 1 "televic-hmi-gui" received signal SIGSEGV, Segmentation fault.
0x00007ffff7c4630d in g_type_check_instance_is_fundamentally_a () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
(gdb) bt
#0 0x00007ffff7c4630d in g_type_check_instance_is_fundamentally_a () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1 0x00007ffff7c23cce in g_object_ref () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#2 0x00007ffff7c9b5e7 in gst_object_ref () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#3 0x00007ffff7ce6e1f in gst_pad_get_peer () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#4 0x00007ffff7cc6995 in gst_element_remove_pad () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#5 0x00007ffff6009ccd in () at /lib/x86_64-linux-gnu/libffi.so.7
#6 0x00007ffff600925a in () at /lib/x86_64-linux-gnu/libffi.so.7
#7 0x00007ffff7c1f7fc in g_cclosure_marshal_generic () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8 0x00007ffff7c1efd2 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9 0x00007ffff7c32784 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x00007ffff7c3d54f in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x00007ffff7c3dedf in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#12 0x00007ffff7cc6a38 in gst_element_remove_pad () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#13 0x00007fffe81b400c in gst_decode_chain_free_internal (chain=0x7fff000269f0, hide=1) at gstdecodebin2.c:3445
#14 0x00007fffe81b413a in gst_decode_group_free_internal (group=0x7fff30002940, hide=1) at gstdecodebin2.c:3599
#15 0x00007fffe81b3a44 in gst_decode_chain_free_internal (chain=0x7fff700928c0, hide=1) at gstdecodebin2.c:3358
#16 0x00007fffe81b4e64 in gst_decode_bin_change_state (element=0x55555684c5f0 [GstElement|decodebin69], transition=<optimized out>) at gstdecodebin2.c:5458
#17 0x00007ffff7cc99be in gst_element_change_state () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#18 0x00007ffff7cca0de in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#19 0x00007ffff7ca6c37 in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#20 0x00007fffe81ca40a in gst_uri_decode_bin_change_state (element=0x7fff58067d30 [GstElement|uridecodebin41], transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gsturidecodebin.c:2814
#21 0x00007ffff7cc99be in gst_element_change_state () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#22 0x00007ffff7cc9ba5 in gst_element_change_state () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#23 0x00007ffff7cca0de in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#24 0x00007ffff7ca6c37 in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#25 0x00007ffff7cc99be in gst_element_change_state () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#26 0x00007ffff7cca0de in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#27 0x00007ffff7ca6c37 in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#28 0x00007ffff7cc99be in gst_element_change_state () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#29 0x00007ffff7cca0de in () at /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#30 0x0000555555604bcc in GStreamerWidget::kickPipeline() (this=this@entry=0x555555fc0700) at Widgets/gstreamerwidget.cpp:960
#31 0x0000555555604d38 in GStreamerWidget::monitorPipeline() (this=0x555555fc0700) at Widgets/gstreamerwidget.cpp:600
#32 0x00005555556757e6 in GStreamerWidget::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=<optimized out>, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>)
at moc_gstreamerwidget.cpp:99
#33 0x00007ffff6935730 in () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#34 0x00007ffff693931a in QTimer::timeout(QTimer::QPrivateSignal) () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#35 0x00007ffff692d635 in QObject::event(QEvent*) () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#36 0x00007ffff75b2ccf in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#37 0x00007ffff75bbe10 in QApplication::notify(QObject*, QEvent*) () at /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#38 0x0000555555677738 in QMyApplication::notify(QObject*, QEvent*) (this=<optimized out>, receiver=0x555555fc49b0, event=0x7fffffffd5e0) at QMyApplication.h:18
#39 0x00007ffff6900d02 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#40 0x00007ffff6956cc0 in QTimerInfoList::activateTimers() () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#41 0x00007ffff695757c in () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#42 0x00007ffff7b355fd in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#43 0x00007ffff7b35880 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#44 0x00007ffff7b3590f in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#45 0x00007ffff695790b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#46 0x00007ffff68ff89b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#47 0x00007ffff6907672 in QCoreApplication::exec() () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#48 0x000055555559a205 in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at main.cpp:264
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/792linking error when compositor/glvidemixer connected to videoscale with caps2021-09-24T13:26:00ZWojciech Kapsalinking error when compositor/glvidemixer connected to videoscale with capsThe following code sometimes causes an error: "pausing after gst_pad_push() = not-linked". ~5-10% fail chance.
Without "compositor" everything works fine.
Ubuntu 20.04, gstreamer 1.16.2 and current master (gst-uninstaled).
Build ...The following code sometimes causes an error: "pausing after gst_pad_push() = not-linked". ~5-10% fail chance.
Without "compositor" everything works fine.
Ubuntu 20.04, gstreamer 1.16.2 and current master (gst-uninstaled).
Build using: ```libtool --mode=link gcc `pkg-config --cflags --libs gstreamer-1.0` -o myprog main.cpp```
[main.cpp](/uploads/e1f7dd8c70eb46da3c2761e931da4886/main.cpp) [GST_DEBUG_6_log.txt](/uploads/6ddb2d7cd8f5a3e0ff96eefed0fab332/log.txt)
```
#include <thread>
#include <gst/gst.h>
GstPadProbeReturn callback(GstPad* srcpad, GstPadProbeInfo* info, void* pipe){
gst_pad_remove_probe (srcpad, GST_PAD_PROBE_INFO_ID (info));
GstElement* identity = gst_element_factory_make("identity", nullptr);
gst_object_ref(identity);
gst_bin_add(GST_BIN(pipe), identity);
gst_element_sync_state_with_parent(identity);
GstPad* sink = gst_pad_get_peer(srcpad);
gst_pad_unlink(srcpad, sink);
GstPad* identity_sink = gst_element_get_static_pad(identity, "sink");
GstPad* identity_src = gst_element_get_static_pad(identity, "src");
gst_pad_link(identity_src, sink);
gst_pad_link(srcpad, identity_sink);
return GST_PAD_PROBE_REMOVE;
}
int main()
{
gst_init(nullptr, nullptr);
GstElement* video_pipe = gst_parse_launch("videotestsrc is-live=true ! video/x-raw,width=500,height=500 ! videoscale ! video/x-raw,width=200,height=200 ! compositor ! ximagesink", NULL);
gst_element_set_state(video_pipe, GST_STATE_PLAYING);
std::this_thread::sleep_for(std::chrono::seconds(2));
GstElement* capsfilter = gst_bin_get_by_name(GST_BIN(video_pipe), "capsfilter0");
GstPad* src = gst_element_get_static_pad(capsfilter, "src");
gst_pad_add_probe(src, GST_PAD_PROBE_TYPE_IDLE, callback, video_pipe, nullptr);
std::this_thread::sleep_for(std::chrono::seconds(2));
}
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/786linking error when input stream connected to glvideomixer will change2021-09-24T13:25:59ZWojciech Kapsalinking error when input stream connected to glvideomixer will changewhen:
when adding passthrou element(identity) to pipeline between queue and proxysink.
only happening when TestSrc resolution do not match capsfilter resolution insterted after videoscale in mixer_pipe.
what:
linking error while lin...when:
when adding passthrou element(identity) to pipeline between queue and proxysink.
only happening when TestSrc resolution do not match capsfilter resolution insterted after videoscale in mixer_pipe.
what:
linking error while linking passthrou element(identity) with queue and proxysink on callback.
what happening:
```
0:00:06.075719729 74767 0x7f7dc0002360 INFO GST_PADS gstpad.c:2434:gst_pad_link_prepare: caps are incompatible
0:00:06.075800353 74767 0x7f7dc0002360 INFO GST_PADS gstpad.c:2527:gst_pad_link_full: link between identity0:src and proxysink0:sink failed: no common format
```
when using compositor not glvideomixer same code works
expected:
there should be possible to add passthru element like indetity despite resolution difference. videoscale present.
glvideomixer should behave like compositor.
additional info:
The following code will fail when resolution on the capsfilter (mixer_pipe) is different then resolution on the videotestsrc (video_pipe). Comments in the source code included.
In case with the glvideomixer there is a unlinked proxysink element visible on the dot file.
Everything works fine with the compositor but fails with glvideomixer.
Build command: libtool --mode=link gcc `pkg-config --cflags --libs gstreamer-1.0` -o myprog main.cpp
[main.cpp](/uploads/04af400ffb6395b1fa69251bae0a946b/main.cpp)
[GST_DEBUG_4_log.out](/uploads/2f066804dbe5a6ffb35529fc97f8bc6f/GST_DEBUG_4_log.out)
[dot.tar.xz](/uploads/8696c1414a42a2d562bd200b9db54d49/dot.tar.xz)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/782glimagesink cause gtk-play pop up menu disseapear.2021-09-24T13:25:59ZUng, Teng Englimagesink cause gtk-play pop up menu disseapear.When we try to bring up the ranking of glimagesink to PRIMARY + 3. Under X11 with matchbox session, the gtk-play will not show up the pop up menu anymore when we try to right click the mouse.
We build the gstreamer with -Dgl_platform='...When we try to bring up the ranking of glimagesink to PRIMARY + 3. Under X11 with matchbox session, the gtk-play will not show up the pop up menu anymore when we try to right click the mouse.
We build the gstreamer with -Dgl_platform='egl' on meson.
And attach the debug.log with gl* messages.[debug.log](/uploads/6b37c40ae3c5d967d22ec161ab1fb76a/debug.log)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/779audio-meta: Transform function causes critical warnings when partially copyin...2021-09-24T13:25:58ZSebastian Drögeaudio-meta: Transform function causes critical warnings when partially copying buffersCan be reproduced with the following pipeline (before https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1363)
```sh
gst-launch-1.0 audiotestsrc ! audio/x-raw,channels=2,layout=non-interleaved ! audiobuffersplit !...Can be reproduced with the following pipeline (before https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1363)
```sh
gst-launch-1.0 audiotestsrc ! audio/x-raw,channels=2,layout=non-interleaved ! audiobuffersplit ! audioconvert ! fakesink
```
This is of course wrong because `audiobuffersplit` does not support non-interleaved audio yet, but correct adapter usage shouldn't cause critical warnings even if it's corrupting the data.
```
** (gst-launch-1.0:507356): CRITICAL **: 09:47:33.647: GstAudioMeta properties would cause out-of-bounds memory access on the buffer: max_offset 2048, samples 1024, bps 2, buffer size 3528
Thread 2 "audiotestsrc0:s" received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0x7ffff7354700 (LWP 507361)]
_g_log_abort (breakpoint=1) at ../../../glib/gmessages.c:554
(gdb) bt
#0 _g_log_abort (breakpoint=1) at ../../../glib/gmessages.c:554
#1 0x00007ffff7d1f869 in g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7ffff7353670) at ../../../glib/gmessages.c:1373
#2 0x00007ffff7d1fa2f in g_log
(log_domain=log_domain@entry=0x0, log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff7575748 "GstAudioMeta properties would cause out-of-bounds memory access on the buffer: max_offset %lu, samples %lu, bps %u, buffer size %lu") at ../../../glib/gmessages.c:1415
#3 0x00007ffff755e03e in gst_buffer_add_audio_meta (buffer=0x5555557d66c0 [GstBuffer], info=0x7ffff000e0b0, samples=<optimized out>, offsets=0x7ffff000e200) at gstaudiometa.c:449
#4 0x00007ffff755e07b in gst_audio_meta_transform (buffer=<optimized out>, type=<optimized out>, data=<optimized out>, meta=<optimized out>, dest=<optimized out>) at gstaudiometa.c:342
#5 gst_audio_meta_transform (dest=<optimized out>, meta=<optimized out>, buffer=<optimized out>, type=<optimized out>, data=<optimized out>) at gstaudiometa.c:334
#6 0x00007ffff7e8dce2 in gst_buffer_copy_into
(size=3528, offset=0, flags=(GST_BUFFER_COPY_FLAGS | GST_BUFFER_COPY_TIMESTAMPS | GST_BUFFER_COPY_META | GST_BUFFER_COPY_MEMORY), src=<optimized out>, dest=0x5555557d66c0 [GstBuffer]) at gstbuffer.c:678
#7 gst_buffer_copy_into
(dest=0x5555557d66c0 [GstBuffer], src=<optimized out>, flags=(GST_BUFFER_COPY_FLAGS | GST_BUFFER_COPY_TIMESTAMPS | GST_BUFFER_COPY_META | GST_BUFFER_COPY_MEMORY), offset=0, size=<optimized out>) at gstbuffer.c:527
#8 0x00007ffff7e8f098 in gst_buffer_copy_region
(buffer=0x5555557d65a0 [GstBuffer], flags=flags@entry=(GST_BUFFER_COPY_FLAGS | GST_BUFFER_COPY_TIMESTAMPS | GST_BUFFER_COPY_META | GST_BUFFER_COPY_MEMORY), offset=0, size=size@entry=3528) at gstbuffer.c:2119
#9 0x00007ffff74a7537 in gst_adapter_get_buffer (adapter=adapter@entry=0x5555557d6000 [GstAdapter], nbytes=nbytes@entry=3528) at gstadapter.c:995
#10 0x00007ffff74a7612 in gst_adapter_take_buffer (adapter=0x5555557d6000 [GstAdapter], nbytes=nbytes@entry=3528) at gstadapter.c:1076
#11 0x00007ffff75c191a in gst_audio_buffer_split_output
(self=self@entry=0x5555557d4030 [GstAudioBufferSplit|audiobuffersplit0], force=force@entry=0, rate=rate@entry=44100, bpf=bpf@entry=4, samples_per_buffer=samples_per_buffer@entry=882) at gstaudiobuffersplit.c:379
#12 0x00007ffff75c31ad in gst_audio_buffer_split_sink_chain (pad=<optimized out>, parent=0x5555557d4030 [GstAudioBufferSplit|audiobuffersplit0], buffer=0x5555557d65a0 [GstBuffer])
at gstaudiobuffersplit.c:679
#13 0x00007ffff7ec5b0f in gst_pad_chain_data_unchecked (pad=pad@entry=0x5555557d2400 [GstPad|sink], type=type@entry=4112, data=data@entry=0x5555557d65a0) at gstpad.c:4327
#14 0x00007ffff7ec7b71 in gst_pad_push_data (pad=pad@entry=0x5555557d31e0 [GstPad|src], type=type@entry=4112, data=data@entry=0x5555557d65a0) at gstpad.c:4583
#15 0x00007ffff7ece823 in gst_pad_push (pad=0x5555557d31e0 [GstPad|src], buffer=0x5555557d65a0 [GstBuffer]) at gstpad.c:4702
#16 0x00007ffff74da750 in gst_base_transform_chain (pad=<optimized out>, parent=0x5555557e6350 [GstCapsFilter|capsfilter0], buffer=<optimized out>) at gstbasetransform.c:2330
#17 0x00007ffff7ec5b0f in gst_pad_chain_data_unchecked (pad=pad@entry=0x5555557d2f90 [GstPad|sink], type=type@entry=4112, data=data@entry=0x5555557d65a0) at gstpad.c:4327
#18 0x00007ffff7ec7b71 in gst_pad_push_data (pad=pad@entry=0x5555557d21b0 [GstPad|src], type=type@entry=4112, data=data@entry=0x5555557d65a0) at gstpad.c:4583
#19 0x00007ffff7ece823 in gst_pad_push (pad=pad@entry=0x5555557d21b0 [GstPad|src], buffer=0x5555557d65a0 [GstBuffer]) at gstpad.c:4702
#20 0x00007ffff74d6345 in gst_base_src_loop (pad=0x5555557d21b0 [GstPad|src]) at gstbasesrc.c:2974
#21 0x00007ffff7efc2cf in gst_task_func (task=0x5555557d6170 [GstTask|audiotestsrc0:src]) at gsttask.c:328
#22 0x00007ffff7d41d94 in g_thread_pool_thread_proxy (data=<optimized out>) at ../../../glib/gthreadpool.c:354
#23 0x00007ffff7d4152d in g_thread_proxy (data=0x555555560aa0) at ../../../glib/gthread.c:807
#24 0x00007ffff7caff27 in start_thread (arg=<optimized out>) at pthread_create.c:479
#25 0x00007ffff7be131f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
CC @gkiagiahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/778audio/videodecoder: Reconsider max-errors default value2021-09-24T13:25:57ZSebastian Drögeaudio/videodecoder: Reconsider max-errors default valueThe following discussion from !720 should be addressed:
- [ ] @ndufresne started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/720#note_546465): (+1 comment)
> Overtime, this internal fe...The following discussion from !720 should be addressed:
- [ ] @ndufresne started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/720#note_546465): (+1 comment)
> Overtime, this internal feature has cause a lot more harm then good. At least in live pipeline, giving up rather then skipping is always the wrong choice, so it's nice that it can be configured through properties too, but shall we reconsider the default value ?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/776gstaudiobasesrc: skew handling if we are ahead of ringbuffer missing2021-09-24T13:25:56ZDanny Smithgstaudiobasesrc: skew handling if we are ahead of ringbuffer missingIn our pipeline ( "audio hw" -> alsasrc -> .. -> udpsink ) we are taking samples from the audio interface and transmitting them using RTP.
The audio codec clock and pipeline clock are not derived from the same clock and thus have a diff...In our pipeline ( "audio hw" -> alsasrc -> .. -> udpsink ) we are taking samples from the audio interface and transmitting them using RTP.
The audio codec clock and pipeline clock are not derived from the same clock and thus have a differing view on the sample rate.
This introduces skew and if the skew is positive i.e. the audio codec is running slower than the pipeline clock it works as expected. If the codec clock is running slightly faster than the pipeline clock, buffers start accumulating in the pipeline and after a while no audio is rendered.
We are using the default slave method "GST_AUDIO_BASE_SRC_SLAVE_SKEW". When looking at the code we can see that the case where segment_skew is positive is handled (segment_skew >= ringbuffer->spec.segtotal) but not the case where the segment_skew is negative.
Should this be addressed or is there another way to handle this case in the pipeline?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/775glwindow_win32: Possible deadlock when drawing on external HWND2021-09-24T13:25:56ZSeungha Yangseungha@centricular.comglwindow_win32: Possible deadlock when drawing on external HWNDWhen [subclassing](https://docs.microsoft.com/en-us/windows/win32/winmsg/about-window-procedures#window-procedure-subclassing) is used and also if parent window and child window are running on different thread, we should be careful to im...When [subclassing](https://docs.microsoft.com/en-us/windows/win32/winmsg/about-window-procedures#window-procedure-subclassing) is used and also if parent window and child window are running on different thread, we should be careful to implement that as it has a chance to cause deadlock in any cases (i.e., parent window thread and child window thread are waiting each other)
In case of d3d11videosink, we avoided the issue by creating child window on parent window's thread so it would not cause thread issue. And d3dvideosink will be running on external window's thread so it's deadlock free.
We need to investigate how to avoid such deadlock with glimagesink on Windows.
Some references
- https://docs.microsoft.com/en-us/windows/win32/procthread/creating-windows-in-threads
- https://stackoverflow.com/questions/41337948/how-to-display-a-modal-dialog-window-from-another-process
- https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1299https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/772Audio stuttering with pulseaudio , debug reports pulse pulsesink.c:702 ...Got...2021-09-24T13:25:55ZMarius CirstaAudio stuttering with pulseaudio , debug reports pulse pulsesink.c:702 ...Got underflow I am playing a stream with pulseaudio like this:
gst-launch-1.0 playbin -v --gst-fatal-warnings --gst-debug-level=4 uri=https://edge214.rcs-rds.ro/V4-3036850-beb1b900f18955083bcd7cb147a0bba4-1495840202-0-1591903019-4-digi24/digi24/... I am playing a stream with pulseaudio like this:
gst-launch-1.0 playbin -v --gst-fatal-warnings --gst-debug-level=4 uri=https://edge214.rcs-rds.ro/V4-3036850-beb1b900f18955083bcd7cb147a0bba4-1495840202-0-1591903019-4-digi24/digi24/digi24-abr.m3u8
Unfortunately the stream has some location restrictions so you might not be able to get it to play. From time to time, randomly I have 1-2 seconds when the audio is not playing but it recovers. At exactly that time the debug reports error in the console :
0:04:32.827319214 14791 0x55a32c1a1b30 WARN pulse pulsesink.c:702:gst_pulsering_stream_underflow_cb:<pulsesink1> Got underflow
It then recovers and plays normally until it happens again.
I've attached the full output from the console.
I am using Manjaro Linux with versions:
gstreamer: 1.16.2-2
pulseaudio: 13.0-3
I can probably work around this by using ALSA output but I still think it should work. Playing the same stream with mplayer ( or mpv ) [gstLog.txt](/uploads/d9c596739f0addb1033a5748a2f1210d/gstLog.txt)works without any audio interruptions.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/770opus: Multichannel audio not correctly reordered2022-07-11T23:20:58ZIgnazioopus: Multichannel audio not correctly reorderedWhen we try to encode and then decode a 7.1 multichannel audio stream with opus the order of the decoded channels is not the original one.
The issue can be reproduced on both Windows and Linux by comparing the audio reproduced on a 7.1 ...When we try to encode and then decode a 7.1 multichannel audio stream with opus the order of the decoded channels is not the original one.
The issue can be reproduced on both Windows and Linux by comparing the audio reproduced on a 7.1 audio device using the subsequent pipelines and this sample wav file: https://www2.iis.fraunhofer.de/AAC/7.1auditionOutLeader%20v2.wav
`
gst-launch-1.0 -vv -m filesrc location=sample_7_1.wav ! decodebin ! audioconvert ! autoaudiosink
`
`
gst-launch-1.0 -vv -m filesrc location=sample_7_1.wav ! decodebin ! audioconvert ! opusenc bitrate=128000 ! queue ! opusdec ! audioconvert ! autoaudiosink
`
When opusenc + opusdec are used the source channels are played in this order:
- Front-Left: OK
- Front-Right: OK
- Front-Central -> Sise-Left Speaker
- LFE -> Side-Right Speaker
- Rear-Left -> Front-Central Speaker
- Rear-Right -> Subwoofer
- Side-Left -> Rear-Left Speaker
- Side-Right -> Rear-Right Speaker
According the encoder's caps the 8 channel mapping is `<0, 6, 1, 4, 5, 2, 3, 7>` which corresponds to map the
`{FL, FR, RL, RR, SL, SR, FC, LFE}` encoded channels to the vorbis order `{FL, FC, FR, SL, SR, RL, RR, LFE}`.
The issue seem not raised with 6 channels
However during some tests we were able to play the channels in the correct speakers by using the `<0, 4, 1, 2, 3, 6, 7, 5>` mapping.
Our suspect is that opusenc is encoding the channels in an unexpected order like `{FL, FR, SL, SR, FC, LFE, RL, RR}`.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/769basetextoverlay blocks on text pad when 'silent' property is true2021-09-24T13:25:54ZChris Ayoupbasetextoverlay blocks on text pad when 'silent' property is trueIf the `silent` property is set to true, basetextoverlay simply pushes video buffers (https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/ext/pango/gstbasetextoverlay.c#L2795) and `gst_base_text_overlay_pop_text()` ne...If the `silent` property is set to true, basetextoverlay simply pushes video buffers (https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/ext/pango/gstbasetextoverlay.c#L2795) and `gst_base_text_overlay_pop_text()` never gets called. As a result, when buffers are being fed to the `text_sink`, `gst_base_text_overlay_text_chain()` blocks forever as an existing buffer never got consumed (https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/ext/pango/gstbasetextoverlay.c#L2671-2681 ).
I wasn't expecting this to happen (until I read the code, of course). I expected the text to continue to be consumed silently. Is this intentional behaviour?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/768Oggdemux seeking fail with theora2021-09-24T13:25:54ZEdward HerveyOggdemux seeking fail with theoraThis is the major reason the theora rtsp validate tests fail
In a nutshell:
* Seek to a position via rtsp-server
* oggdemux in rtsp-server has an off-by-one error in where the keyframe *really* is
* oggdemux outputs a wrong (off by one ...This is the major reason the theora rtsp validate tests fail
In a nutshell:
* Seek to a position via rtsp-server
* oggdemux in rtsp-server has an off-by-one error in where the keyframe *really* is
* oggdemux outputs a wrong (off by one frame duration) segment start value
* oggdemux starts outputting from the page containing that (off by one) keyframe
* payloader (rightfully) doesn't set any PTS
* udpsink (rightfully) drops the out-of-segment buffer
This ends up in having to wait a long time for the next keyframe to arrive, even potentially locking the player client-side (audio arrives, but video never arrives before maximum buffering).
Note that one wouldn't see this issue with regular (non-rtsp) playback because the demuxer would (almost all the time) output from the proper page, so the decoder would still have the data (even though it would end up clipping that first frame).
I've lost my sanity trying to figure out what would cause that off-by-one error, someone else please look into it.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/767Move GstPlanarAudioAdapter to -base2021-09-24T13:25:54ZSebastian DrögeMove GstPlanarAudioAdapter to -baseCC @gkiagia
Open questions/issues (please add more)
* [ ] Should it also work for interleaved audio? IMHO yes but it currently doesn't, we would need a different name then (`GstAudioAdapter`)
* [ ] `GstMapFlags` usage is weird: if no w...CC @gkiagia
Open questions/issues (please add more)
* [ ] Should it also work for interleaved audio? IMHO yes but it currently doesn't, we would need a different name then (`GstAudioAdapter`)
* [ ] `GstMapFlags` usage is weird: if no write-mapping is requested this does only shallow copies of buffers. But always doing that would simply cause the deep-copy of the memory to happen on write-mapping so that's exactly the same overall. What is the rationale here?
* [ ] Use a `GQueue` or other more optimal data structure (`g_slist_append()` and counting list length manually is not great)
Otherwise looks fine to me at least.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/765audioresample: add OpenPOWER ppc64 support2021-09-24T13:25:53ZDaniel Pocockaudioresample: add OpenPOWER ppc64 supportaudioresample includes some custom assembly
There is growing interest in the OpenPOWER architecture.
IBM is currently offering bounties to developers who will port free software projects to OpenPOWER
Providing an implementation of the...audioresample includes some custom assembly
There is growing interest in the OpenPOWER architecture.
IBM is currently offering bounties to developers who will port free software projects to OpenPOWER
Providing an implementation of the code for OpenPOWER ISA appears to be a good idea for a bounty
Alternatively, could the custom assembly be managed as part of liborc?
A bounty was offered for similar work in ffmpeg libswscale and a developer has provided a solution for that
https://www.bountysource.com/issues/34315232-power8-vsx-vectorization-libswscale-input-c
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1585056463-7934-1-git-send-email-pestov.vyach@yandex.ru/https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/763videoconvert: disregards downstream preferences for the format2021-09-24T13:25:53ZMathieu Duponchellevideoconvert: disregards downstream preferences for the formatWith such a pipeline:
```
src ! videoconvert ! glupload ! glcolorconvert ! filter_element_expecting_BGRA
```
Videoconvert gets to fixate these caps:
```
video/x-raw, format=BGRA; video/x-raw, format = {all, the, formats, glcolorconver...With such a pipeline:
```
src ! videoconvert ! glupload ! glcolorconvert ! filter_element_expecting_BGRA
```
Videoconvert gets to fixate these caps:
```
video/x-raw, format=BGRA; video/x-raw, format = {all, the, formats, glcolorconvert, supports}
```
When fixating however, videoconvert ignores the higher preference level expressed by having two separate structures in the caps, as it simply flattens all the pixel formats and picks one according to its scoring heuristic.
Ideally, videoconvert should consider each structure independently, unclear however whether this will break existing scenarios.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/761gldeinterlace: does not mention interlace-mode on its src pad2021-09-24T13:25:53ZRussel Windergldeinterlace: does not mention interlace-mode on its src padThe deinterlace element, and indeed many other elements, state what the interlace-mode is on the src pad. It seems that the gldeinterlace element does not given the evidence of a pipeline diagram that includes a gldeinterlace element.The deinterlace element, and indeed many other elements, state what the interlace-mode is on the src pad. It seems that the gldeinterlace element does not given the evidence of a pipeline diagram that includes a gldeinterlace element.