gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2021-09-24T11:10:42Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/129implement GstStreamFlags bit to mark forced streams, e.g. forced subtitles2021-09-24T11:10:42ZBugzilla Migration Userimplement GstStreamFlags bit to mark forced streams, e.g. forced subtitles## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#755159)](https://bugzilla.gnome.org/show_bug.cgi?id=755159)**
## Description
there was no way how to pass down information about whether a stream is flagged as "fo...## Submitted by Andreas Frisch `@fraxinas`
**[Link to original bug (#755159)](https://bugzilla.gnome.org/show_bug.cgi?id=755159)**
## Description
there was no way how to pass down information about whether a stream is flagged as "forced". as slomo suggested on irc, i've implemented this to be included in the stream-start event, so a GstSteamFlags definition had to be added.
Version: 1.5.90https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/128memory: add remap operation2023-06-12T13:05:46ZBugzilla Migration Usermemory: add remap operation## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#754826)](https://bugzilla.gnome.org/show_bug.cgi?id=754826)**
## Description
See commit messages
### Blocking
* [Bug 740222](https://bugzilla.gnome.org/show_bug...## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#754826)](https://bugzilla.gnome.org/show_bug.cgi?id=754826)**
## Description
See commit messages
### Blocking
* [Bug 740222](https://bugzilla.gnome.org/show_bug.cgi?id=740222)
* [Bug 759050](https://bugzilla.gnome.org/show_bug.cgi?id=759050)
* [Bug 745372](https://bugzilla.gnome.org/show_bug.cgi?id=745372)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/127basesrc: Test Assertion 'segment->rate == 0.5' failed2021-09-24T11:10:44ZBugzilla Migration Userbasesrc: Test Assertion 'segment->rate == 0.5' failed## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#753365)](https://bugzilla.gnome.org/show_bug.cgi?id=753365)**
## Description
I was running make check over core, and got this one time failure. After running: ...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#753365)](https://bugzilla.gnome.org/show_bug.cgi?id=753365)**
## Description
I was running make check over core, and got this one time failure. After running:
make -C tests/check libs/basesrc.forever
I ended up with:
87%: Checks: 8, Failures: 1, Errors: 0
libs/basesrc.c:598:F:general:basesrc_seek_events_rate_update:0: Assertion 'segment->rate == 0.5' failed
make: Leaving directory '/home/nicolas/Sources/gstreamer-master/gstreamer/tests/check'https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/126queue2: Doesn't push the flush stop on its thread2021-09-24T11:10:45ZBugzilla Migration Userqueue2: Doesn't push the flush stop on its thread## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#753080)](https://bugzilla.gnome.org/show_bug.cgi?id=753080)**
## Description
I have this backtrace where a flush stop event from a demuxer ends push making a sticky s...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#753080)](https://bugzilla.gnome.org/show_bug.cgi?id=753080)**
## Description
I have this backtrace where a flush stop event from a demuxer ends push making a sticky stream-start event be pushed down and then gets stuck in playsink's pad probe. So it causes a deadlock.
I'm attaching a patch that just makes queue2 put the flush-stop in the queue, but I guess the other option would be to make playsink's probe drop stick events and just wait for buffer/gap before continuing.
My test is:
`GST_DEBUG=2 GST_GL_XINITTHREADS=1 DISPLAY=:1 GST_VALIDATE_SCENARIO=change_state_intensive gdb --args gst-validate-1.0 playbin uri=http://127.0.0.1:8079/defaults/ogg/vorbis_theora.1.ogg audio-sink='fakesink sync=true' video-sink='fakesink sync=true' --set-media-info "/home/ocrete/gst-validate/gst-integration-testsuites/medias/defaults/online-streams-infos/http/vorbis_theora.1.ogg.stream_info"`
Here is the stack trace:
```
Thread 5 (Thread 0x7fffd71a3700 (LWP 2553)):
#0 0x00007ffff50a5239 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007ffff53f802f in g_cond_wait (cond=0x7fffc40c8d68, mutex=0x7fffc40c8cf8) at gthread-posix.c:1395
#2 0x00007ffff6290619 in do_probe_callbacks (pad=0x7fffc40c8ce0 [GstProxyPad], info=0x7fffd719f790, defaultval=GST_FLOW_OK) at gstpad.c:3516
#3 0x00007ffff62955f4 in gst_pad_push_event_unchecked (pad=0x7fffc40c8ce0 [GstProxyPad], event=0x7fffc8024810, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM)
at gstpad.c:5031
#4 0x00007ffff6290b97 in push_sticky (pad=0x7fffc40c8ce0 [GstProxyPad], ev=0x7fffd719f890, user_data=0x7fffd719f8f0) at gstpad.c:3651
#5 0x00007ffff6287dd3 in events_foreach (pad=0x7fffc40c8ce0 [GstProxyPad], func=0x7ffff6290a82 <push_sticky>, user_data=0x7fffd719f8f0) at gstpad.c:590
#6 0x00007ffff6290f38 in check_sticky (pad=0x7fffc40c8ce0 [GstProxyPad], event=0x7fffc8024810) at gstpad.c:3707
#7 0x00007ffff6295dfb in gst_pad_push_event (pad=0x7fffc40c8ce0 [GstProxyPad], event=0x7fffc8024810) at gstpad.c:5189
#8 0x00007ffff628eb95 in event_forward_func (pad=0x7fffc40c8ce0 [GstProxyPad], data=0x7fffd719fa30) at gstpad.c:2884
#9 0x00007ffff628e997 in gst_pad_forward (pad=0x7fffc4118530 [GstGhostPad], forward=0x7ffff628ea6e <event_forward_func>, user_data=0x7fffd719fa30)
at gstpad.c:2838
---Type <return> to continue, or q <return> to quit---
#10 0x00007ffff628ed49 in gst_pad_event_default (pad=0x7fffc4118530 [GstGhostPad], parent=0x830160 [GstPlaySink], event=0x7fffc8024810) at gstpad.c:2935
#11 0x00007ffff62967b5 in gst_pad_send_event_unchecked (pad=0x7fffc4118530 [GstGhostPad], event=0x7fffc8024810, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM)
at gstpad.c:5388
#12 0x00007ffff62957fe in gst_pad_push_event_unchecked (pad=0x7fffc4130710 [GstPad], event=0x7fffc8024810, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM)
at gstpad.c:5064
#13 0x00007ffff6290b97 in push_sticky (pad=0x7fffc4130710 [GstPad], ev=0x7fffd719fc30, user_data=0x7fffd719fc90) at gstpad.c:3651
#14 0x00007ffff6287dd3 in events_foreach (pad=0x7fffc4130710 [GstPad], func=0x7ffff6290a82 <push_sticky>, user_data=0x7fffd719fc90) at gstpad.c:590
#15 0x00007ffff6290f38 in check_sticky (pad=0x7fffc4130710 [GstPad], event=0x7fffc8024810) at gstpad.c:3707
#16 0x00007ffff6295dfb in gst_pad_push_event (pad=0x7fffc4130710 [GstPad], event=0x7fffc8024810) at gstpad.c:5189
#17 0x00007fffeb2dc489 in gst_selector_pad_event (pad=0x7fffc40b8e20 [GstSelectorPad], parent=0x7fffc40b6b80 [GstInputSelector], event=0x7fffc8024810)
at gstinputselector.c:632
#18 0x00007ffff7bad778 in gst_validate_pad_monitor_downstream_event_check (pad_monitor=0x7fffcc1609f0 [GstValidatePadMonitor], parent=0x7fffc40b6b80 [GstInputSelector], event=0x7fffc8024810, handler=0x7fffeb2dbdde <gst_selector_pad_event>) at gst-validate-pad-monitor.c:1788
#19 0x00007ffff7bafa1d in gst_validate_pad_monitor_sink_event_func (pad=0x7fffc40b8e20 [GstSelectorPad], parent=0x7fffc40b6b80 [GstInputSelector], event=0x7fffc8024810) at gst-validate-pad-monitor.c:2103
#20 0x00007ffff62967b5 in gst_pad_send_event_unchecked (pad=0x7fffc40b8e20 [GstSelectorPad], event=0x7fffc8024810, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at gstpad.c:5388
#21 0x00007ffff62957fe in gst_pad_push_event_unchecked (pad=0x7fffc41182c0 [GstGhostPad], event=0x7fffc8024810, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM)
at gstpad.c:5064
#22 0x00007ffff6290b97 in push_sticky (pad=0x7fffc41182c0 [GstGhostPad], ev=0x7fffd71a0060, user_data=0x7fffd71a00c0) at gstpad.c:3651
#23 0x00007ffff6287dd3 in events_foreach (pad=0x7fffc41182c0 [GstGhostPad], func=0x7ffff6290a82 <push_sticky>, user_data=0x7fffd71a00c0) at gstpad.c:590
#24 0x00007ffff6290f38 in check_sticky (pad=0x7fffc41182c0 [GstGhostPad], event=0x7fffc8024810) at gstpad.c:3707
#25 0x00007ffff6295dfb in gst_pad_push_event (pad=0x7fffc41182c0 [GstGhostPad], event=0x7fffc8024810) at gstpad.c:5189
#26 0x00007ffff628eb95 in event_forward_func (pad=0x7fffc41182c0 [GstGhostPad], data=0x7fffd71a0200) at gstpad.c:2884
#27 0x00007ffff628e997 in gst_pad_forward (pad=0x7fffd80391e0 [GstProxyPad], forward=0x7ffff628ea6e <event_forward_func>, user_data=0x7fffd71a0200)
at gstpad.c:2838
#28 0x00007ffff628ed49 in gst_pad_event_default (pad=0x7fffd80391e0 [GstProxyPad], parent=0x7fffc41182c0 [GstGhostPad], event=0x7fffc8024810)
at gstpad.c:2935
#29 0x00007ffff62967b5 in gst_pad_send_event_unchecked (pad=0x7fffd80391e0 [GstProxyPad], event=0x7fffc8024810, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM)
at gstpad.c:5388
#30 0x00007ffff62957fe in gst_pad_push_event_unchecked (pad=0x7fffcc007550 [GstDecodePad], event=0x7fffc8024810, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM)
at gstpad.c:5064
#31 0x00007ffff6290b97 in push_sticky (pad=0x7fffcc007550 [GstDecodePad], ev=0x7fffd71a0400, user_data=0x7fffd71a0460) at gstpad.c:3651
#32 0x00007ffff6287dd3 in events_foreach (pad=0x7fffcc007550 [GstDecodePad], func=0x7ffff6290a82 <push_sticky>, user_data=0x7fffd71a0460) at gstpad.c:590
#33 0x00007ffff6290f38 in check_sticky (pad=0x7fffcc007550 [GstDecodePad], event=0x7fffbc0022a0) at gstpad.c:3707
#34 0x00007ffff6295dfb in gst_pad_push_event (pad=0x7fffcc007550 [GstDecodePad], event=0x7fffbc0022a0) at gstpad.c:5189
#35 0x00007ffff628eb95 in event_forward_func (pad=0x7fffcc007550 [GstDecodePad], data=0x7fffd71a05a0) at gstpad.c:2884
#36 0x00007ffff628e997 in gst_pad_forward (pad=0x7fffd8038d40 [GstProxyPad], forward=0x7ffff628ea6e <event_forward_func>, user_data=0x7fffd71a05a0)
at gstpad.c:2838
#37 0x00007ffff628ed49 in gst_pad_event_default (pad=0x7fffd8038d40 [GstProxyPad], parent=0x7fffcc007550 [GstDecodePad], event=0x7fffbc0022a0)
at gstpad.c:2935
#38 0x00007ffff62967b5 in gst_pad_send_event_unchecked (pad=0x7fffd8038d40 [GstProxyPad], event=0x7fffbc0022a0, type=320) at gstpad.c:5388
#39 0x00007ffff62957fe in gst_pad_push_event_unchecked (pad=0x8376b0 [GstPad], event=0x7fffbc0022a0, type=320) at gstpad.c:5064
#40 0x00007ffff6295e22 in gst_pad_push_event (pad=0x8376b0 [GstPad], event=0x7fffbc0022a0) at gstpad.c:5195
#41 0x00007ffff6cd2854 in gst_video_decoder_push_event (decoder=0x7fffcc12b5a0 [GstTheoraDec], event=0x7fffbc0022a0) at gstvideodecoder.c:934
#42 0x00007ffff6cd3f09 in gst_video_decoder_sink_event_default (decoder=0x7fffcc12b5a0 [GstTheoraDec], event=0x7fffbc0022a0) at gstvideodecoder.c:1374
#43 0x00007ffff6cd40f6 in gst_video_decoder_sink_event (pad=0x7fffc4131010 [GstPad], parent=0x7fffcc12b5a0 [GstTheoraDec], event=0x7fffbc0022a0)
at gstvideodecoder.c:1410
#44 0x00007ffff7bad778 in gst_validate_pad_monitor_downstream_event_check (pad_monitor=0x7fffd81319c0 [GstValidatePadMonitor], parent=0x7fffcc12b5a0 [GstTheoraDec], event=0x7fffbc0022a0, handler=0x7ffff6cd401b <gst_video_decoder_sink_event>) at gst-validate-pad-monitor.c:1788
#45 0x00007ffff7bafa1d in gst_validate_pad_monitor_sink_event_func (pad=0x7fffc4131010 [GstPad], parent=0x7fffcc12b5a0 [GstTheoraDec], event=0x7fffbc0022a0) at gst-validate-pad-monitor.c:2103
#46 0x00007ffff62967b5 in gst_pad_send_event_unchecked (pad=0x7fffc4131010 [GstPad], event=0x7fffbc0022a0, type=320) at gstpad.c:5388
#47 0x00007ffff62957fe in gst_pad_push_event_unchecked (pad=0x837230 [GstPad], event=0x7fffbc0022a0, type=320) at gstpad.c:5064
#48 0x00007ffff6295e22 in gst_pad_push_event (pad=0x837230 [GstPad], event=0x7fffbc0022a0) at gstpad.c:5195
#49 0x00007fffeb2e61b6 in gst_multi_queue_sink_event (pad=0x7fffc4130950 [GstPad], parent=0x7fffcc137030 [GstMultiQueue], event=0x7fffbc0022a0)
at gstmultiqueue.c:1792
#50 0x00007ffff7bad778 in gst_validate_pad_monitor_downstream_event_check (pad_monitor=0x7fffd81317f0 [GstValidatePadMonitor], parent=0x7fffcc137030 [GstMultiQueue], event=0x7fffbc0022a0, handler=0x7fffeb2e6041 <gst_multi_queue_sink_event>) at gst-validate-pad-monitor.c:1788
---Type <return> to continue, or q <return> to quit---
#51 0x00007ffff7bafa1d in gst_validate_pad_monitor_sink_event_func (pad=0x7fffc4130950 [GstPad], parent=0x7fffcc137030 [GstMultiQueue], event=0x7fffbc0022a0) at gst-validate-pad-monitor.c:2103
#52 0x00007ffff62967b5 in gst_pad_send_event_unchecked (pad=0x7fffc4130950 [GstPad], event=0x7fffbc0022a0, type=320) at gstpad.c:5388
#53 0x00007ffff62957fe in gst_pad_push_event_unchecked (pad=0x7fffcc141e30 [GstOggPad], event=0x7fffbc0022a0, type=320) at gstpad.c:5064
#54 0x00007ffff6295e22 in gst_pad_push_event (pad=0x7fffcc141e30 [GstOggPad], event=0x7fffbc0022a0) at gstpad.c:5195
#55 0x00007fffd75d7d65 in gst_ogg_demux_send_event (ogg=0x7fffcc11a7c0 [GstOggDemux], event=0x7fffbc0022a0) at gstoggdemux.c:4592
#56 0x00007fffd75ce1e3 in gst_ogg_demux_sink_event (pad=0x7fffc4108060 [GstPad], parent=0x7fffcc11a7c0 [GstOggDemux], event=0x7fffbc0022a0)
at gstoggdemux.c:2322
#57 0x00007ffff7bad778 in gst_validate_pad_monitor_downstream_event_check (pad_monitor=0x7fffcc170200 [GstValidatePadMonitor], parent=0x7fffcc11a7c0 [GstOggDemux], event=0x7fffbc0022a0, handler=0x7fffd75ce0ca <gst_ogg_demux_sink_event>) at gst-validate-pad-monitor.c:1788
#58 0x00007ffff7bafa1d in gst_validate_pad_monitor_sink_event_func (pad=0x7fffc4108060 [GstPad], parent=0x7fffcc11a7c0 [GstOggDemux], event=0x7fffbc0022a0)
at gst-validate-pad-monitor.c:2103
#59 0x00007ffff62967b5 in gst_pad_send_event_unchecked (pad=0x7fffc4108060 [GstPad], event=0x7fffbc0022a0, type=320) at gstpad.c:5388
#60 0x00007ffff62957fe in gst_pad_push_event_unchecked (pad=0x7fffcc10aff0 [GstPad], event=0x7fffbc0022a0, type=320) at gstpad.c:5064
#61 0x00007ffff6295e22 in gst_pad_push_event (pad=0x7fffcc10aff0 [GstPad], event=0x7fffbc0022a0) at gstpad.c:5195
#62 0x00007fffeb3045ac in gst_type_find_element_sink_event (pad=0x7fffc40c0de0 [GstPad], parent=0x86b7b0 [GstTypeFindElement], event=0x7fffbc0022a0)
at gsttypefindelement.c:695
#63 0x00007ffff7bad778 in gst_validate_pad_monitor_downstream_event_check (pad_monitor=0x7fffd81310b0 [GstValidatePadMonitor], parent=0x86b7b0 [GstTypeFindElement], event=0x7fffbc0022a0, handler=0x7fffeb304174 <gst_type_find_element_sink_event>) at gst-validate-pad-monitor.c:1788
#64 0x00007ffff7bafa1d in gst_validate_pad_monitor_sink_event_func (pad=0x7fffc40c0de0 [GstPad], parent=0x86b7b0 [GstTypeFindElement], event=0x7fffbc0022a0) at gst-validate-pad-monitor.c:2103
#65 0x00007ffff62967b5 in gst_pad_send_event_unchecked (pad=0x7fffc40c0de0 [GstPad], event=0x7fffbc0022a0, type=320) at gstpad.c:5388
#66 0x00007ffff62957fe in gst_pad_push_event_unchecked (pad=0x7fffd8038650 [GstProxyPad], event=0x7fffbc0022a0, type=320) at gstpad.c:5064
#67 0x00007ffff6295e22 in gst_pad_push_event (pad=0x7fffd8038650 [GstProxyPad], event=0x7fffbc0022a0) at gstpad.c:5195
#68 0x00007ffff628eb95 in event_forward_func (pad=0x7fffd8038650 [GstProxyPad], data=0x7fffd71a1750) at gstpad.c:2884
#69 0x00007ffff628e997 in gst_pad_forward (pad=0x7fffd8035170 [GstGhostPad], forward=0x7ffff628ea6e <event_forward_func>, user_data=0x7fffd71a1750)
at gstpad.c:2838
#70 0x00007ffff628ed49 in gst_pad_event_default (pad=0x7fffd8035170 [GstGhostPad], parent=0x7fffc4118770 [GstDecodeBin], event=0x7fffbc0022a0)
at gstpad.c:2935
#71 0x00007ffff62967b5 in gst_pad_send_event_unchecked (pad=0x7fffd8035170 [GstGhostPad], event=0x7fffbc0022a0, type=320) at gstpad.c:5388
#72 0x00007ffff62957fe in gst_pad_push_event_unchecked (pad=0x7fffcc10ab70 [GstPad], event=0x7fffbc0022a0, type=320) at gstpad.c:5064
#73 0x00007ffff6295e22 in gst_pad_push_event (pad=0x7fffcc10ab70 [GstPad], event=0x7fffbc0022a0) at gstpad.c:5195
#74 0x00007fffeb2f9c6a in gst_queue2_handle_sink_event (pad=0x7fffcc10a6f0 [GstPad], parent=0x7fffd808ec00 [GstQueue2], event=0x7fffbc0022a0)
at gstqueue2.c:2310
#75 0x00007ffff7bad778 in gst_validate_pad_monitor_downstream_event_check (pad_monitor=0x7fffd8131450 [GstValidatePadMonitor], parent=0x7fffd808ec00 [GstQueue2], event=0x7fffbc0022a0, handler=0x7fffeb2f9490 <gst_queue2_handle_sink_event>) at gst-validate-pad-monitor.c:1788
#76 0x00007ffff7bafa1d in gst_validate_pad_monitor_sink_event_func (pad=0x7fffcc10a6f0 [GstPad], parent=0x7fffd808ec00 [GstQueue2], event=0x7fffbc0022a0)
at gst-validate-pad-monitor.c:2103
#77 0x00007ffff62967b5 in gst_pad_send_event_unchecked (pad=0x7fffcc10a6f0 [GstPad], event=0x7fffbc0022a0, type=320) at gstpad.c:5388
#78 0x00007ffff62957fe in gst_pad_push_event_unchecked (pad=0x7fffc4109920 [GstPad], event=0x7fffbc0022a0, type=320) at gstpad.c:5064
#79 0x00007ffff6295e22 in gst_pad_push_event (pad=0x7fffc4109920 [GstPad], event=0x7fffbc0022a0) at gstpad.c:5195
#80 0x00007fffeb3045ac in gst_type_find_element_sink_event (pad=0x7fffc4130290 [GstPad], parent=0x86b030 [GstTypeFindElement], event=0x7fffbc0022a0)
at gsttypefindelement.c:695
#81 0x00007ffff7bad778 in gst_validate_pad_monitor_downstream_event_check (pad_monitor=0xb065f0 [GstValidatePadMonitor], parent=0x86b030 [GstTypeFindElement], event=0x7fffbc0022a0, handler=0x7fffeb304174 <gst_type_find_element_sink_event>) at gst-validate-pad-monitor.c:1788
#82 0x00007ffff7bafa1d in gst_validate_pad_monitor_sink_event_func (pad=0x7fffc4130290 [GstPad], parent=0x86b030 [GstTypeFindElement], event=0x7fffbc0022a0) at gst-validate-pad-monitor.c:2103
#83 0x00007ffff62967b5 in gst_pad_send_event_unchecked (pad=0x7fffc4130290 [GstPad], event=0x7fffbc0022a0, type=320) at gstpad.c:5388
#84 0x00007ffff62957fe in gst_pad_push_event_unchecked (pad=0x7fffcc10bd70 [GstPad], event=0x7fffbc0022a0, type=320) at gstpad.c:5064
#85 0x00007ffff6295e22 in gst_pad_push_event (pad=0x7fffcc10bd70 [GstPad], event=0x7fffbc0022a0) at gstpad.c:5195
#86 0x00007ffff658a28e in gst_base_src_perform_seek (src=0x86d8d0 [GstSoupHTTPSrc], event=0x7fffb0003980, unlock=1) at gstbasesrc.c:1681
#87 0x00007ffff658b218 in gst_base_src_default_event (src=0x86d8d0 [GstSoupHTTPSrc], event=0x7fffb0003980) at gstbasesrc.c:1990
#88 0x00007ffff658b393 in gst_base_src_event (pad=0x7fffcc10bd70 [GstPad], parent=0x86d8d0 [GstSoupHTTPSrc], event=0x7fffb0003980) at gstbasesrc.c:2042
#89 0x00007ffff7badc19 in gst_validate_pad_monitor_src_event_check (pad_monitor=0xb06420 [GstValidatePadMonitor], parent=0x86d8d0 [GstSoupHTTPSrc], event=0x7fffb0003980, handler=0x7ffff658b327 <gst_base_src_event>) at gst-validate-pad-monitor.c:1873
#90 0x00007ffff7bafd3b in gst_validate_pad_monitor_src_event_func (pad=0x7fffcc10bd70 [GstPad], parent=0x86d8d0 [GstSoupHTTPSrc], event=0x7fffb0003980)
at gst-validate-pad-monitor.c:2121
#91 0x00007ffff62967b5 in gst_pad_send_event_unchecked (pad=0x7fffcc10bd70 [GstPad], event=0x7fffb0003980, type=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM)
at gstpad.c:5388
---Type <return> to continue, or q <return> to quit---
#92 0x00007ffff62957fe in gst_pad_push_event_unchecked (pad=0x7fffc4130290 [GstPad], event=0x7fffb0003980, type=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM)
at gstpad.c:5064
#93 0x00007ffff6295e22 in gst_pad_push_event (pad=0x7fffc4130290 [GstPad], event=0x7fffb0003980) at gstpad.c:5195
#94 0x00007fffeb303be0 in gst_type_find_element_src_event (pad=0x7fffc4109920 [GstPad], parent=0x86b030 [GstTypeFindElement], event=0x7fffb0003980)
at gsttypefindelement.c:518
#95 0x00007ffff7badc19 in gst_validate_pad_monitor_src_event_check (pad_monitor=0x7fffc80a3760 [GstValidatePadMonitor], parent=0x86b030 [GstTypeFindElement], event=0x7fffb0003980, handler=0x7fffeb303b33 <gst_type_find_element_src_event>) at gst-validate-pad-monitor.c:1873
#96 0x00007ffff7bafd3b in gst_validate_pad_monitor_src_event_func (pad=0x7fffc4109920 [GstPad], parent=0x86b030 [GstTypeFindElement], event=0x7fffb0003980)
at gst-validate-pad-monitor.c:2121
#97 0x00007ffff62967b5 in gst_pad_send_event_unchecked (pad=0x7fffc4109920 [GstPad], event=0x7fffb0003980, type=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM)
at gstpad.c:5388
#98 0x00007ffff62957fe in gst_pad_push_event_unchecked (pad=0x7fffcc10a6f0 [GstPad], event=0x7fffb0003980, type=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM)
at gstpad.c:5064
#99 0x00007ffff6295e22 in gst_pad_push_event (pad=0x7fffcc10a6f0 [GstPad], event=0x7fffb0003980) at gstpad.c:5195
#100 0x00007fffeb2fc87c in gst_queue2_handle_src_event (pad=0x7fffcc10ab70 [GstPad], parent=0x7fffd808ec00 [GstQueue2], event=0x7fffb0003980)
at gstqueue2.c:2898
#101 0x00007ffff7badc19 in gst_validate_pad_monitor_src_event_check (pad_monitor=0x7fffd8131620 [GstValidatePadMonitor], parent=0x7fffd808ec00 [GstQueue2], event=0x7fffb0003980, handler=0x7fffeb2fc3d6 <gst_queue2_handle_src_event>) at gst-validate-pad-monitor.c:1873
#102 0x00007ffff7bafd3b in gst_validate_pad_monitor_src_event_func (pad=0x7fffcc10ab70 [GstPad], parent=0x7fffd808ec00 [GstQueue2], event=0x7fffb0003980)
at gst-validate-pad-monitor.c:2121
#103 0x00007ffff62967b5 in gst_pad_send_event_unchecked (pad=0x7fffcc10ab70 [GstPad], event=0x7fffb0003980, type=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM)
at gstpad.c:5388
#104 0x00007ffff62957fe in gst_pad_push_event_unchecked (pad=0x7fffd8035170 [GstGhostPad], event=0x7fffb0003980, type=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM)
at #105 0x00007ffff6295e22 in gst_pad_push_event (pad=0x7fffd8035170 [GstGhostPad], event=0x7fffb0003980) at gstpad.c:5195
#106 0x00007ffff628eb95 in event_forward_func (pad=0x7fffd8035170 [GstGhostPad], data=0x7fffd71a2990) at gstpad.c:2884
#107 0x00007ffff628e997 in gst_pad_forward (pad=0x7fffd8038650 [GstProxyPad], forward=0x7ffff628ea6e <event_forward_func>, user_data=0x7fffd71a2990)
at gstpad.c:2838
#108 0x00007ffff628ed49 in gst_pad_event_default (pad=0x7fffd8038650 [GstProxyPad], parent=0x7fffd8035170 [GstGhostPad], event=0x7fffb0003980)
at gstpad.c:2935
#109 0x00007ffff62967b5 in gst_pad_send_event_unchecked (pad=0x7fffd8038650 [GstProxyPad], event=0x7fffb0003980, type=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM)
at gstpad.c:5388
#110 0x00007ffff62957fe in gst_pad_push_event_unchecked (pad=0x7fffc40c0de0 [GstPad], event=0x7fffb0003980, type=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM)
at gstpad.c:5064
#111 0x00007ffff6295e22 in gst_pad_push_event (pad=0x7fffc40c0de0 [GstPad], event=0x7fffb0003980) at gstpad.c:5195
#112 0x00007fffeb303be0 in gst_type_find_element_src_event (pad=0x7fffcc10aff0 [GstPad], parent=0x86b7b0 [GstTypeFindElement], event=0x7fffb0003980)
at gsttypefindelement.c:518
#113 0x00007ffff7badc19 in gst_validate_pad_monitor_src_event_check (pad_monitor=0x7fffd8131280 [GstValidatePadMonitor], parent=0x86b7b0 [GstTypeFindElement], event=0x7fffb0003980, handler=0x7fffeb303b33 <gst_type_find_element_src_event>) at gst-validate-pad-monitor.c:1873
#114 0x00007ffff7bafd3b in gst_validate_pad_monitor_src_event_func (pad=0x7fffcc10aff0 [GstPad], parent=0x86b7b0 [GstTypeFindElement], event=0x7fffb0003980) at gst-validate-pad-monitor.c:2121
#115 0x00007ffff62967b5 in gst_pad_send_event_unchecked (pad=0x7fffcc10aff0 [GstPad], event=0x7fffb0003980, type=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM)
at gstpad.c:5388
#116 0x00007ffff62957fe in gst_pad_push_event_unchecked (pad=0x7fffc4108060 [GstPad], event=0x7fffb0003980, type=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM)
at gstpad.c:5064
#117 0x00007ffff6295e22 in gst_pad_push_event (pad=0x7fffc4108060 [GstPad], event=0x7fffb0003980) at gstpad.c:5195
#118 0x00007fffd75d9027 in gst_ogg_demux_loop_push (ogg=0x7fffcc11a7c0 [GstOggDemux]) at gstoggdemux.c:4885
#119 0x00007ffff53da0a5 in g_thread_proxy (data=0x7fffcc11fc00) at gthread.c:764
#120 0x00007ffff67cb555 in start_thread (arg=0x7fffd71a3700) at pthread_create.c:333
#121 0x00007ffff50aaf3d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
gstpad.c:5064
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/125test: fdsrc: add tests for duration and uri2021-09-24T11:10:45ZBugzilla Migration Usertest: fdsrc: add tests for duration and uri## Submitted by Prashant Gotarne
**[Link to original bug (#752948)](https://bugzilla.gnome.org/show_bug.cgi?id=752948)**
## Description
Add tests for duration query and uri interface## Submitted by Prashant Gotarne
**[Link to original bug (#752948)](https://bugzilla.gnome.org/show_bug.cgi?id=752948)**
## Description
Add tests for duration query and uri interfacehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/124basesrc: events don't get pushed if basesrc has no pending buffers to send2022-11-10T09:20:45ZBugzilla Migration Userbasesrc: events don't get pushed if basesrc has no pending buffers to send## Submitted by Enrique Ocaña González `@eocanha`
**[Link to original bug (#752815)](https://bugzilla.gnome.org/show_bug.cgi?id=752815)**
## Description
Use case:
In some later stage of the pipeline I want to detect when an app...## Submitted by Enrique Ocaña González `@eocanha`
**[Link to original bug (#752815)](https://bugzilla.gnome.org/show_bug.cgi?id=752815)**
## Description
Use case:
In some later stage of the pipeline I want to detect when an append has been fully processed. Timeouts aren't a very robust solution, and EOS isn't an alternative either (I don't want to reset the pipeline). The best alternative is to send a custom downstream event after the append, signaling that no more data will be fed by now. That event will be detected by a probe later in the pipeline.
Problem:
However, basesrc doesn't emit the custom event until a new chunk of data is appended after the event (but I don't want to do that). The primary reason for not emitting the event is that gst_base_src_loop() is stalled waiting for new buffers in a call to gst_base_src_getrange().
### Depends on
* [Bug 785142](https://bugzilla.gnome.org/show_bug.cgi?id=785142)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/123taglist: update merge logic when one of the input is empty2023-03-17T10:37:28ZBugzilla Migration Usertaglist: update merge logic when one of the input is empty## Submitted by Vineeth
**[Link to original bug (#752362)](https://bugzilla.gnome.org/show_bug.cgi?id=752362)**
## Description
When tag_list_merge is called with either of the input lists empty, right now, a new empty list is being ...## Submitted by Vineeth
**[Link to original bug (#752362)](https://bugzilla.gnome.org/show_bug.cgi?id=752362)**
## Description
When tag_list_merge is called with either of the input lists empty, right now, a new empty list is being created and on top of that the other list is being merged.
But if one of the input is empty, it is supposed to just create a copy of the other as the merged list.
This was added to handle GST_TAG_MERGE_KEEP_ALL and GST_TAG_MERGE_REPLACE_ALL mode during merging.
But these modes should be valid only when both the inputs are not NULL. It doesn't make sense to create a new empty list, just to handle these two modes,
even though NULL is being passed as input.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/122tee: Avoid race condition while forwarding sticky events2021-09-24T11:10:47ZBugzilla Migration Usertee: Avoid race condition while forwarding sticky events## Submitted by Jose Antonio Santos Cadenas
**[Link to original bug (#752213)](https://bugzilla.gnome.org/show_bug.cgi?id=752213)**
## Description
Created attachment 307207
tee: Avoid race condition while forwarding sticky events ...## Submitted by Jose Antonio Santos Cadenas
**[Link to original bug (#752213)](https://bugzilla.gnome.org/show_bug.cgi?id=752213)**
## Description
Created attachment 307207
tee: Avoid race condition while forwarding sticky events
I have found that in some circumstances a source pad receives data without having a segment event, printing this error:
Unexpected critical/warning: gstpad.c:4258:gst_pad_push_data:<tee10:src_1> Got data flow before segment event
It is a race condition, because sink pad did not have segment event while adding the new source pad and it is received before the source pad is added to the tee but after the sticky events are forwarded, so this event is not in the new src pad.
Previous pads are not failing, just the new one. And this happens rarely 1 on 500 or so.
The solution I found is to lock the sink stream while adding the pad and once it is added forward the sticky events. With this patch I can not reproduce the issue.
~~**Patch 307207**~~, "tee: Avoid race condition while forwarding sticky events":
[0001-tee-Avoid-race-condition-while-forwarding-sticky-eve.patch](/uploads/ef2d15a2d1d894967535f7d6088bae6e/0001-tee-Avoid-race-condition-while-forwarding-sticky-eve.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/121ptp: Get required privileges on OS X with a OS X specific mechanism2021-09-24T11:10:47ZBugzilla Migration Userptp: Get required privileges on OS X with a OS X specific mechanism## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#752105)](https://bugzilla.gnome.org/show_bug.cgi?id=752105)**
## Description
+++ This bug was initially created as a clone of [Bug 750367](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#752105)](https://bugzilla.gnome.org/show_bug.cgi?id=752105)**
## Description
+++ This bug was initially created as a clone of [Bug 750367](https://bugzilla.gnome.org/show_bug.cgi?id=750367) +++
setuid root is not the state of the art on OS X either AFAIU, something else should be used. Maybe it should be done via launchd, someone needs to do some research :)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/120dataqueue: Make it understand buffers, segments, gaps2022-11-10T09:20:45ZBugzilla Migration Userdataqueue: Make it understand buffers, segments, gaps## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#751918)](https://bugzilla.gnome.org/show_bug.cgi?id=751918)**
## Description
In practice, every queue in GStreamer is buffers and synchronized events/queries, so it d...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#751918)](https://bugzilla.gnome.org/show_bug.cgi?id=751918)**
## Description
In practice, every queue in GStreamer is buffers and synchronized events/queries, so it doesn't make sense to have a GstDataQueue that tries to abstract them, then re-implement the processing every it's used. As we integrate queues in more elements (like in demuxers), we can reduce duplication.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/119baseparse: Calculates bitrates for the complete stream instead of windowed av...2021-09-24T11:10:48ZBugzilla Migration Userbaseparse: Calculates bitrates for the complete stream instead of windowed average## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#751889)](https://bugzilla.gnome.org/show_bug.cgi?id=751889)**
## Description
See summary. Problem with that is that it will not react properly to bitrate changes cur...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#751889)](https://bugzilla.gnome.org/show_bug.cgi?id=751889)**
## Description
See summary. Problem with that is that it will not react properly to bitrate changes currently.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/118Pull mode element downstream hogs the pad stream lock2021-09-24T11:10:49ZBugzilla Migration UserPull mode element downstream hogs the pad stream lock## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#751637)](https://bugzilla.gnome.org/show_bug.cgi?id=751637)**
## Description
With the example pipeline:
filesrc ! wavparse ! fakesink
wavparse will sw...## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#751637)](https://bugzilla.gnome.org/show_bug.cgi?id=751637)**
## Description
With the example pipeline:
filesrc ! wavparse ! fakesink
wavparse will switch to pull mode, and create a pad task which will pull till EOS. The pad task calls:
task->func (task->user_data);
in a loop, while holding the pad stream lock, which is therefore not released at all until the element goes flushing, stops, etc.
While this goes on, if there is a event going downstream that reaches wavparse (eg, sink-message), the gstpad.c code will lock the stream lock before pushing the event. It will then wait an arbitrary long time before being able to do so.
This proof of concept:
diff --git a/gst/gsttask.c b/gst/gsttask.c
index d9e5697..47d3e6f 100644
--- a/gst/gsttask.c
+++ b/gst/gsttask.c
@@ -329,6 +329,11 @@ gst_task_func (GstTask * task)
}
task->func (task->user_data);
+
+ /* Allow something else to use the lock. Still a lot of contention though */
+ g_rec_mutex_unlock (lock);
+g_usleep (1000);
+ g_rec_mutex_lock (lock);
}
g_rec_mutex_unlock (lock);
shows that this is indeed the problem, as my code works as expected with this bodge in.
There doesn't seem to be any reason why the lock can't be released between calls to the pad task function. A possible fix for this would be passing a condition variable along with the lock, but this would need changing a substantial amount of elements.
Any better way to fix ? Or is this as intended, and the lock really should not be released (why, then ?) ?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/117gst_debug_remove_log_function exposes a potential race condition w. LogFuncEn...2021-09-24T11:10:49ZBugzilla Migration Usergst_debug_remove_log_function exposes a potential race condition w. LogFuncEntry's user_data/notify## Submitted by Heinrich Fink `@heinrich.fink`
**[Link to original bug (#751440)](https://bugzilla.gnome.org/show_bug.cgi?id=751440)**
## Description
In gst/gstinfo.c, gst_debug_remove_with_compare_func copies and leaks the list __l...## Submitted by Heinrich Fink `@heinrich.fink`
**[Link to original bug (#751440)](https://bugzilla.gnome.org/show_bug.cgi?id=751440)**
## Description
In gst/gstinfo.c, gst_debug_remove_with_compare_func copies and leaks the list __log_functions in order to avoid locking in gst_debug_log_valist to make it thread-safe. However, gst_debug_remove_with_compare_func also executes the destroy-notifier on the LogFuncEntry's user_data, and this could actually still be used by a logging action while it is deleted.
To make this fully thread-safe, we could use a reader/writer lock ("shared" mutex), where the gst_debug_log_valist acquires a read-lock, and the add/remove functions of the debug handler acquire a write-lock.
With the current implementation, we should at least document that gst_debug_remove_log_function and gst_debug_remove_log_function_by_date are not thread-safe (with respect to the user-data of installed log functions).https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/116baseparse: drain on stream-start2021-09-24T11:10:50ZBugzilla Migration Userbaseparse: drain on stream-start## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#751105)](https://bugzilla.gnome.org/show_bug.cgi?id=751105)**
## Description
When handling stream-start events, baseparse should drain its current data a...## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#751105)](https://bugzilla.gnome.org/show_bug.cgi?id=751105)**
## Description
When handling stream-start events, baseparse should drain its current data and then reset itself as a new stream is about to start, no data from previous stream should be reused.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/115clock: Add gst_clock_abort_wait() function2021-09-24T11:10:50ZBugzilla Migration Userclock: Add gst_clock_abort_wait() function## Submitted by Carlos Rafael Giani
**[Link to original bug (#750633)](https://bugzilla.gnome.org/show_bug.cgi?id=750633)**
## Description
As mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=749391#c10 , the newly introduced ...## Submitted by Carlos Rafael Giani
**[Link to original bug (#750633)](https://bugzilla.gnome.org/show_bug.cgi?id=750633)**
## Description
As mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=749391#c10 , the newly introduced gst_clock_wait_for_sync() function issues a blocking wait. If this function is used inside elements for example, it is important to be able to abort the wait, for example during a PAUSED->READY state change. A gst_clock_abort_wait() function is needed that aborts the blocking wait.
To that end, also extend the description of gst_clock_wait_for_sync(). It shall return FALSE if either a timeout happened or the wait was aborted.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/114gstchildproxy: some improvements2021-09-24T11:10:51ZBugzilla Migration Usergstchildproxy: some improvements## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#750189)](https://bugzilla.gnome.org/show_bug.cgi?id=750189)**
## Description
The purpose of these patches is to remove redundant code in GESTrackElement,
I can i...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#750189)](https://bugzilla.gnome.org/show_bug.cgi?id=750189)**
## Description
The purpose of these patches is to remove redundant code in GESTrackElement,
I can imagine a lot of use cases for fetching all the elements exposing a
property in a bin aside from that.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/113gstbuffer: _get_merged_memory: support memories that happen to be consecutive2021-09-24T11:10:51ZBugzilla Migration Usergstbuffer: _get_merged_memory: support memories that happen to be consecutive## Submitted by Ilya Konstantinov
**[Link to original bug (#750103)](https://bugzilla.gnome.org/show_bug.cgi?id=750103)**
## Description
Sometimes GstMemory objects might not be in a parent-child hierarchy which allows them to know ...## Submitted by Ilya Konstantinov
**[Link to original bug (#750103)](https://bugzilla.gnome.org/show_bug.cgi?id=750103)**
## Description
Sometimes GstMemory objects might not be in a parent-child hierarchy which allows them to know that they span a single consecutive memory area.
However, when mapped, they end up being perfectly consecutive. For example, this can happen with GstCoreVideoMemory on Apple platforms.
Wouldn't it be nice if _get_merged_memory will recognize such cases and avoid allocating and memcpy'ing a new buffer in such cases?
Does this make sense?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/112gstevent: add new api for parse seek event2021-09-24T11:10:52ZBugzilla Migration Usergstevent: add new api for parse seek event## Submitted by Jimmy Ohn
**[Link to original bug (#748738)](https://bugzilla.gnome.org/show_bug.cgi?id=748738)**
## Description
generally, when we parse seek event using gst_event_parse_seek function, parameter is too many I think....## Submitted by Jimmy Ohn
**[Link to original bug (#748738)](https://bugzilla.gnome.org/show_bug.cgi?id=748738)**
## Description
generally, when we parse seek event using gst_event_parse_seek function, parameter is too many I think.
For example, If we just want to get the rate value from event, we should use like this gst_event_parse_seek(event, NULL, &rate, NULL, NULL, NULL...).
I agree this is minor problem but I think that If we use segment for parsing event, it would be better.
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/111basetransform: old pool incorrectly disabled2022-11-10T09:20:45ZBugzilla Migration Userbasetransform: old pool incorrectly disabled## Submitted by Andreea Fulger
**[Link to original bug (#748590)](https://bugzilla.gnome.org/show_bug.cgi?id=748590)**
## Description
Created attachment 302519
Check if the new pool is the one we are already using
In gst_base...## Submitted by Andreea Fulger
**[Link to original bug (#748590)](https://bugzilla.gnome.org/show_bug.cgi?id=748590)**
## Description
Created attachment 302519
Check if the new pool is the one we are already using
In gst_base_transform_set_allocation, if the new pool is the same as the old one, it still gets deactivated as there is no check on oldpool != pool as it is already done for basesrc.
**Patch 302519**, "Check if the new pool is the one we are already using":
[0001-DEBUG-basetransform-don-t-accidentally-disable-the-p.patch](/uploads/0c525ea26055cff10e46e8b09dc52baa/0001-DEBUG-basetransform-don-t-accidentally-disable-the-p.patch)
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/110registry: System registry cache file2021-09-24T11:10:52ZBugzilla Migration Userregistry: System registry cache file## Submitted by Dan Nicholson
**[Link to original bug (#748452)](https://bugzilla.gnome.org/show_bug.cgi?id=748452)**
## Description
Right now, the first time a user runs a gstreamer program, it's slowed down by generating the regis...## Submitted by Dan Nicholson
**[Link to original bug (#748452)](https://bugzilla.gnome.org/show_bug.cgi?id=748452)**
## Description
Right now, the first time a user runs a gstreamer program, it's slowed down by generating the registry cache file. Gstreamer should be able to try a system registry cache file if the user's cache file doesn't exist. See previous discussion here:
http://lists.freedesktop.org/archives/gstreamer-devel/2015-March/052181.html