gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2024-01-22T16:13:51Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2749osxaudiosrc drops frames when osxaudiosink misses frames2024-01-22T16:13:51ZBugzilla Migration Userosxaudiosrc drops frames when osxaudiosink misses frames## Submitted by Ilya Konstantinov
**[Link to original bug (#753112)](https://bugzilla.gnome.org/show_bug.cgi?id=753112)**
## Description
To reproduce:
$ gst-launch-1.0 osxaudiosrc ! identity drop-probability=0.1 ! osxaudiosink ...## Submitted by Ilya Konstantinov
**[Link to original bug (#753112)](https://bugzilla.gnome.org/show_bug.cgi?id=753112)**
## Description
To reproduce:
$ gst-launch-1.0 osxaudiosrc ! identity drop-probability=0.1 ! osxaudiosink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstAudioSrcClock
WARNING: from element /GstPipeline:pipeline0/GstOsxAudioSrc:osxaudiosrc0: Can't record audio fast enough
Additional debug info:
gstaudiobasesrc.c(866): GstFlowReturn gst_audio_base_src_create(GstBaseSrc *, guint64, guint, GstBuffer **) (): /GstPipeline:pipeline0/GstOsxAudioSrc:osxaudiosrc0:
Dropped 9261 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.
WARNING: from element /GstPipeline:pipeline0/GstOsxAudioSrc:osxaudiosrc0: Can't record audio fast enough
I don't quite understand why osxaudiosrc drops frames when the *sink* is the one that's not receiving all of the frames. This doesn't happen with fakesink or filesink.
Also, it's "solved" by setting "osxaudiosink sync=0".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/829dashdemux: RepresentationIndex is not used2021-10-20T08:07:50ZBugzilla Migration Userdashdemux: RepresentationIndex is not used## Submitted by Florin Apostol
**[Link to original bug (#752727)](https://bugzilla.gnome.org/show_bug.cgi?id=752727)**
## Description
RepresentationIndex element from SegmentBase is designed to identify a single Segment Index for th...## Submitted by Florin Apostol
**[Link to original bug (#752727)](https://bugzilla.gnome.org/show_bug.cgi?id=752727)**
## Description
RepresentationIndex element from SegmentBase is designed to identify a single Segment Index for the entire representation. But RepresentationIndex is only parsed and not used.
gstadaptivedemux makes an attempt to download a single Segment Index for an entire representation in the gst_adaptive_demux_stream_download_header_fragment function. But the indexUrl and range are not obtained from RepresentationIndex. Instead, they are wrongly obtained from Initilization@SegmentBase and indexRange@SegmentBase.
See also https://bugzilla.gnome.org/show_bug.cgi?id=752718https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/830dashdemux: replace sscanf with strtoul2022-11-10T09:21:09ZBugzilla Migration Userdashdemux: replace sscanf with strtoul## Submitted by Florin Apostol
**[Link to original bug (#752428)](https://bugzilla.gnome.org/show_bug.cgi?id=752428)**
## Description
gstmpdparser.c file uses sscanf(..., "%u", ...) to read numbers from the xml file. sscanf is unabl...## Submitted by Florin Apostol
**[Link to original bug (#752428)](https://bugzilla.gnome.org/show_bug.cgi?id=752428)**
## Description
gstmpdparser.c file uses sscanf(..., "%u", ...) to read numbers from the xml file. sscanf is unable to indicate the fact that the input string was completely parsed or not. For example, for the input "123xyz" the sscanf function will return 1 (it successfully read an integer).
A better function is strtol (and strtoul, etc). This has the ability to provide a pointer to the next unparsed character in string. Using this, we can detect if the original string was valid or not.
The question is how restrictive the parser should be? Where a number is expected in an xml attribute and a "123xyz" is provided, should the parser read and use 123 or it should signal an error? Currently it reads just 123 and no error or warnings are issued (provided it does not need to parse the attribute further than the number).
So, should we make the parser more restrictive or not?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/828dashdemux: only one SegmentList element is supported2022-11-10T09:21:09ZBugzilla Migration Userdashdemux: only one SegmentList element is supported## Submitted by Florin Apostol
**[Link to original bug (#752229)](https://bugzilla.gnome.org/show_bug.cgi?id=752229)**
## Description
The standard specifies that "The Segment list is defined by one or more SegmentList elements".
...## Submitted by Florin Apostol
**[Link to original bug (#752229)](https://bugzilla.gnome.org/show_bug.cgi?id=752229)**
## Description
The standard specifies that "The Segment list is defined by one or more SegmentList elements".
But the implementation supports only 1 element. The SegmentList member of _GstRepresentationNode, _GstAdaptationSetNode, _GstPeriodNode is a pointer to GstSegmentListNode, instead of a list. So, these elements support only 1 instance of SegmentList element. When a second one is detected, the gst_mpdparser_parse_segment_list_node function will free the previous one:
gst_mpdparser_parse_segment_list_node (GstSegmentListNode ** pointer,
....
gst_mpdparser_free_segment_list_node (*pointer);
*pointer = new_segment_list = g_slice_new0 (GstSegmentListNode);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/2936tsdemux: Not able to play HEVC video clip in pull mode2023-08-25T09:25:43ZBugzilla Migration Usertsdemux: Not able to play HEVC video clip in pull mode## Submitted by ris..@..il.com
**[Link to original bug (#750341)](https://bugzilla.gnome.org/show_bug.cgi?id=750341)**
## Description
Not able to play any big buck bunny HEVC video clip using tsdemux from video clip with file format...## Submitted by ris..@..il.com
**[Link to original bug (#750341)](https://bugzilla.gnome.org/show_bug.cgi?id=750341)**
## Description
Not able to play any big buck bunny HEVC video clip using tsdemux from video clip with file format MPEG-TS.
System: Feodra 21 64bit
Video clip URL: http://www.elecard.com/en/download/videos.html
Under Big Buck Bunny - SD, 720p and 1080p HEVC video clip
msg:
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstTSDemux:tsdemux0: Internal data stream error.
Additional debug info:
mpegtsbase.c(1342): mpegts_base_loop (): /GstPipeline:pipeline0/GstTSDemux:tsdemux0:
stream stopped, reason not-linked
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...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/2693asfdemux: add support for trick play in push mode2023-06-20T17:14:05ZBugzilla Migration Userasfdemux: add support for trick play in push mode## Submitted by Rajesh Singh
**[Link to original bug (#749956)](https://bugzilla.gnome.org/show_bug.cgi?id=749956)**
## Description
Current implementation of ASFDemux, does not support the push mode Trick Play.
Trick Play means Fo...## Submitted by Rajesh Singh
**[Link to original bug (#749956)](https://bugzilla.gnome.org/show_bug.cgi?id=749956)**
## Description
Current implementation of ASFDemux, does not support the push mode Trick Play.
Trick Play means Forward(1/2X, 2X, 4X) and Rewind (-1/2X, -2X, -4X).
Version: 1.4.5