GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T13:25:54Zhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/806appsrc does not negotiate caps and start stream until data is pushed2021-09-24T13:26:04ZAlex Hoenigappsrc does not negotiate caps and start stream until data is pushedIf you have multiple appsrc elements - one for video and one for KLV - and you push a video frame first, everything works properly. But if you push a KLV buffer first, you get the following errors:
- Sink pad caps were not set before pu...If you have multiple appsrc elements - one for video and one for KLV - and you push a video frame first, everything works properly. But if you push a KLV buffer first, you get the following errors:
- Sink pad caps were not set before pushing
- Could not create handler for stream
- Sticky event misordering, got 'segment' before 'stream-start'
- Sticky event misordering, got 'segment' before 'caps'
This can be worked-around in some cases by pushing a buffer of size 0 through the video appsrc firsthttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/808gldifferrencematte: Doesn't load new bg pixmap in texture2021-09-24T13:26:05ZPhilippe Normandgldifferrencematte: Doesn't load new bg pixmap in textureIn this branch I've started a few fixes for `gldifferencematte`: https://gitlab.freedesktop.org/philn/gst-plugins-base/-/commits/gl-diff-matte
However I wonder if there's an issue with the shaders. This pipeline `gst-launch-1.0 videotes...In this branch I've started a few fixes for `gldifferencematte`: https://gitlab.freedesktop.org/philn/gst-plugins-base/-/commits/gl-diff-matte
However I wonder if there's an issue with the shaders. This pipeline `gst-launch-1.0 videotestsrc pattern=green ! glupload ! gldifferencematte location=/home/phil/Pictures/green-screen.png ! gtkglsink` outputs all blue, but I think it should render black, if I understood the differencematte concepts right... :)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/812audioaggregator: audio aggregator subclasses might produce choppy sounds2021-09-24T13:26:05ZSeungha Yangseungha@centricular.comaudioaggregator: audio aggregator subclasses might produce choppy soundsFollow-up from "WIP: livevideorate, liveaudiorate: Add a new videorate and audiorate elements based on aggregator"
The following discussion from !1514 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop....Follow-up from "WIP: livevideorate, liveaudiorate: Add a new videorate and audiorate elements based on aggregator"
The following discussion from !1514 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1514#note_599526): (+2 comments)
> Why is this not also a problem with `audiomixer`?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/816gl: rpi bcm_host dependency of gstgl is not automatically passed to dependent...2021-09-24T13:26:06ZRoman Valovgl: rpi bcm_host dependency of gstgl is not automatically passed to dependent binariesHi,
I'm cross-compiling GStreamer 1.18 for RPi board using sysroot directory.
In order to do that I'm using following stanzas in my cross-file:
```
...
[properties]
sys_root = '/opt/rpi/sysroot/'
pkg_config_libdir = ['/opt/rpi/sysroot...Hi,
I'm cross-compiling GStreamer 1.18 for RPi board using sysroot directory.
In order to do that I'm using following stanzas in my cross-file:
```
...
[properties]
sys_root = '/opt/rpi/sysroot/'
pkg_config_libdir = ['/opt/rpi/sysroot/usr/lib/pkgconfig/', '/opt/rpi/sysroot/usr/share/pkgconfig/', '/opt/rpi/sysroot/usr/lib/arm-linux-gnueabihf/pkgconfig/', '/opt/rpi/sysroot/opt/vc/lib/pkgconfig/']
...
```
The `.../opt/vc/lib/pkgconfig/` entry in cross-file lets [meson.build](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/gst-libs/gst/gl/meson.build) to detect `bcm_host` library and link against it.
However `bcm_host` dependency is not explicitly passed to gstgl-dependent binaries.
Some of them check for `bcm_host_dep` explicitly, i.e. [opengl](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/ext/gl/meson.build) and [omx](https://gitlab.freedesktop.org/gstreamer/gst-omx/-/blob/master/examples/egl/meson.build).
But the approach used doesn't scale well and there are bunch of examples that failed to built due to missing `bcm_host` on link stage, i.e [3dvideo](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/tests/examples/gl/gtk/3dvideo/meson.build):
```
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: warning: libbcm_host.so, needed by subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0, not found (try using -rpath or -rpath-link)
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0: undefined reference to `vc_dispmanx_display_open'
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0: undefined reference to `vc_dispmanx_element_remove'
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0: undefined reference to `graphics_get_display_size'
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0: undefined reference to `vc_dispmanx_display_close'
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0: undefined reference to `vc_dispmanx_update_submit_sync'
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0: undefined reference to `vc_dispmanx_element_add'
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0: undefined reference to `vc_dispmanx_element_change_attributes'
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0: undefined reference to `vc_dispmanx_update_start'
collect2: error: ld returned 1 exit status
```
I've ended up with the patch: [bcm_host_dep.patch](/uploads/8109ac3f5154e87874e6d75fef344335/bcm_host_dep.patch) but I'm not sure it that's a best solution.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/819alsasink/audiobasesink: Always drops very first sample2021-09-24T13:26:07ZMatus Gajdosalsasink/audiobasesink: Always drops very first sampleWhen playing a 44.1 kHz MP3 file using pipeline:
```gst-launch-1.0 filesrc location="audio.mp3" ! mpegaudioparse ! mpg123audiodec ! audioconvert ! alsasink```
I noticed that it always drops the first sample:
```0:00:00.069347375 6832 0...When playing a 44.1 kHz MP3 file using pipeline:
```gst-launch-1.0 filesrc location="audio.mp3" ! mpegaudioparse ! mpg123audiodec ! audioconvert ! alsasink```
I noticed that it always drops the first sample:
```0:00:00.069347375 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:1897:gst_audio_base_sink_render:<alsasink0> time 0:00:00.000000000, start 0:00:00.000000000, samples 1152
0:00:00.069389500 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:1934:gst_audio_base_sink_render:<alsasink0> sync-offset +0:00:00.000000000, render-delay 0:00:00.000000000, ts-offset +0:00:00.000000000
0:00:00.069426250 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:1997:gst_audio_base_sink_render:<alsasink0> running: start 0:00:00.000000000 - stop 0:00:00.026122448
0:00:00.069461125 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2039:gst_audio_base_sink_render:<alsasink0> final timestamps: start 0:00:00.000000000 - stop 0:00:00.026122448
0:00:00.069487000 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2080:gst_audio_base_sink_render:<alsasink0> Clipped start: 1151/1152 samples
0:00:00.069506125 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2103:gst_audio_base_sink_render:<alsasink0> resync after discont/resync
New clock: GstAudioSinkClock
0:00:00.069530375 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2138:gst_audio_base_sink_render:<alsasink0> rendering at 0 1151/1151
0:00:00.069632000 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2150:gst_audio_base_sink_render:<alsasink0> wrote 1151 of 1151
0:00:00.069659875 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2181:gst_audio_base_sink_render:<alsasink0> next sample expected at 1151
```
The same happens if I play a flac file using pipeline:
```gst-launch-1.0 uridecodebin uri="file:///tmp/audio.flac" ! audioconvert ! alsasink```
Log:
```0:00:00.081520750 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:1897:gst_audio_base_sink_render:<alsasink0> time 0:00:00.000000000, start 0:00:00.000000000, samples 4096
0:00:00.081562125 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:1934:gst_audio_base_sink_render:<alsasink0> sync-offset +0:00:00.000000000, render-delay 0:00:00.000000000, ts-offset +0:00:00.000000000
0:00:00.081596250 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:1997:gst_audio_base_sink_render:<alsasink0> running: start 0:00:00.000000000 - stop 0:00:00.085333333
0:00:00.081631250 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2039:gst_audio_base_sink_render:<alsasink0> final timestamps: start 0:00:00.000000000 - stop 0:00:00.085333333
0:00:00.081656000 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2080:gst_audio_base_sink_render:<alsasink0> Clipped start: 4095/4096 samples
0:00:00.081675000 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2103:gst_audio_base_sink_render:<alsasink0> resync after discont/resync
0:00:00.081698750 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2138:gst_audio_base_sink_render:<alsasink0> rendering at 0 4095/4095
0:00:00.081749875 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2150:gst_audio_base_sink_render:<alsasink0> wrote 4095 of 4095
0:00:00.081773875 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2181:gst_audio_base_sink_render:<alsasink0> next sample expected at 4095
```
I think the problem causes converting samples to time and back cutting off the fractional part.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/820video-convert: Add fast paths from/to NV122021-09-24T13:26:07ZSebastian Drögevideo-convert: Add fast paths from/to NV12It's a quite common format nowadays, on the level of I420, and we should probably add a few more fast paths for it. Like one between I420 and NV12, but maybe also all the others we already have for I420.It's a quite common format nowadays, on the level of I420, and we should probably add a few more fast paths for it. Like one between I420 and NV12, but maybe also all the others we already have for I420.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/821compositor: significant color issues with "special" resizing parameters2021-09-24T13:26:07ZNazar Mokrynskyicompositor: significant color issues with "special" resizing parametersConsider this example:
```
gst-launch-1.0 compositor name=comp background=transparent \
sink_1::width=906 sink_1::height=509 sink_1::xpos=36 sink_1::ypos=285 \
sink_2::width=906 sink_2::height=508 sink_2::xpos=978 sink_2::ypos=28...Consider this example:
```
gst-launch-1.0 compositor name=comp background=transparent \
sink_1::width=906 sink_1::height=509 sink_1::xpos=36 sink_1::ypos=285 \
sink_2::width=906 sink_2::height=508 sink_2::xpos=978 sink_2::ypos=285 ! \
videoconvert ! video/x-raw,width=1920,height=1080 ! autovideosink \
videotestsrc pattern=white ! video/x-raw,width=1920,height=1080,format=ARGB ! comp. \
videotestsrc pattern=white ! video/x-raw,width=1920,height=1080,format=I420 ! comp. \
videotestsrc pattern=white ! video/x-raw,width=360,height=202,format=I420 ! comp.
```
Expectation here is to get completely white image, since we draw 2 white rectangles on top of white background. In reality though left rectangle is a bit grey-ish and right while similarly gray-ish has red line on top of it:
<details>
![Знімок_екрана_з_2020-09-16_22-44-07](/uploads/8b8d8ad6b0715bb346cbac9fea5e2214/Знімок_екрана_з_2020-09-16_22-44-07.png)
</details>
Something isn't right for sure. In understand that compositor doesn't have anti-aliasing support, but this is really severe artifacting.
Happens on `1.18` stable and happened to me on `master` long before that.