GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T14:36:39Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/780hls segfaults2021-09-24T14:36:39ZBugzilla Migration Userhls segfaults## Submitted by Nicola `@drakkan`
**[Link to original bug (#797075)](https://bugzilla.gnome.org/show_bug.cgi?id=797075)**
## Description
I see some crashs using playbin for an hls stream
- crash 1:
```
#0 0x00007fffef3cca...## Submitted by Nicola `@drakkan`
**[Link to original bug (#797075)](https://bugzilla.gnome.org/show_bug.cgi?id=797075)**
## Description
I see some crashs using playbin for an hls stream
- crash 1:
```
#0 0x00007fffef3cca26 in malloc () at /usr/lib/libc.so.6
#1 0x00007fffef453b0f in __vasprintf_chk () at /usr/lib/libc.so.6
#2 0x00007ffff7c54c5a in g_vasprintf () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff7c2e0de in g_strdup_vprintf () at /usr/lib/libglib-2.0.so.0
#4 0x00007ffff7c2e19a in g_strdup_printf () at /usr/lib/libglib-2.0.so.0
#5 0x00007fff657d504e in uri_join (uri1=<optimized out>, uri2=0x7ffed0017015 "3304.ts")
at ../subprojects/gst-plugins-bad/ext/hls/m3u8.c:1111
#6 0x00007fff657d583d in gst_m3u8_update (self=0x7ffed0016db0, data=<optimized out>)
at ../subprojects/gst-plugins-bad/ext/hls/m3u8.c:522
#7 0x00007fff657cf5c9 in gst_hls_demux_update_playlist (demux=demux@entry=0x7ffef00ceec0, update=update@entry=1, err=err@entry=0x0) at ../subprojects/gst-plugins-bad/ext/hls/gsthlsdemux.c:1459
#8 0x00007fff657cfcdf in gst_hls_demux_change_playlist (demux=demux@entry=0x7ffef00ceec0, max_bitrate=<optimized out>, changed=changed@entry=0x7ffee67fb2e4) at ../subprojects/gst-plugins-bad/ext/hls/gsthlsdemux.c:1599
#9 0x00007fff657d0edd in gst_hls_demux_select_bitrate (stream=<optimized out>, bitrate=<optimized out>)
at ../subprojects/gst-plugins-bad/ext/hls/gsthlsdemux.c:1149
#10 0x00007fff657c0c99 in gst_adaptive_demux_stream_select_bitrate (bitrate=<optimized out>, stream=0x7fff1412d830, demux=0x7ffef00ceec0) at ../subprojects/gst-plugins-bad/gst-libs/gst/adaptivedemux/gstadaptivedemux.c:4280
#11 0x00007fff657c0c99 in gst_adaptive_demux_stream_advance_fragment_unlocked (duration=<optimized out>, stream=0x7fff1412d830, demux=0x7ffef00ceec0) at ../subprojects/gst-plugins-bad/gst-libs/gst/adaptivedemux/gstadaptivedemux.c:4232
#12 0x00007fff657c0c99 in gst_adaptive_demux_stream_advance_fragment (demux=demux@entry=0x7ffef00ceec0, stream=stream@entry=0x7fff1412d830, duration=<optimized out>) at ../subprojects/gst-plugins-bad/gst-libs/gst/adaptivedemux/gstadaptivedemux.c:4153
#13 0x00007fff657ce726 in gst_hls_demux_finish_fragment (demux=0x7ffef00ceec0, stream=0x7fff1412d830)
at ../subprojects/gst-plugins-bad/ext/hls/gsthlsdemux.c:953
#14 0x00007fff657b477f in gst_adaptive_demux_eos_handling (stream=stream@entry=0x7fff1412d830)
at ../subprojects/gst-plugins-bad/gst-libs/gst/adaptivedemux/gstadaptivedemux.c:2730
#15 0x00007fff657b4af9 in _src_event (pad=<optimized out>, parent=<optimized out>, event=0x7ffed4003d10)
at ../subprojects/gst-plugins-bad/gst-libs/gst/adaptivedemux/gstadaptivedemux.c:2748
#16 0x00007ffff7dee277 in gst_pad_send_event_unchecked (pad=pad@entry=0x7fff1412acd0, event=event@entry=0x7ffed4003d10, type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5757
#17 0x00007ffff7dee7c4 in gst_pad_push_event_unchecked (pad=pad@entry=0x7fff1404f5b0, event=0x7ffed4003d10, type=type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5402
#18 0x00007ffff7deec34 in push_sticky (pad=pad@entry=0x7fff1404f5b0, ev=ev@entry=0x7ffee67fb600, user_data=user_data@entry=0x7---Type <return> to continue, or q <return> to quit---
ffee67fb670) at ../subprojects/gstreamer/gst/gstevent.h:438
#19 0x00007ffff7dec548 in events_foreach (pad=pad@entry=0x7fff1404f5b0, func=func@entry=0x7ffff7deebe0 <push_sticky>, user_data=user_data@entry=0x7ffee67fb670) at ../subprojects/gstreamer/gst/gstpad.c:608
#20 0x00007ffff7df7b71 in check_sticky (event=0x7ffed4003d10, pad=0x7fff1404f5b0)
at ../subprojects/gstreamer/gst/gstpad.c:3977
#21 0x00007ffff7df7b71 in gst_pad_push_event (pad=pad@entry=0x7fff1404f5b0, event=0x7ffed4003d10)
at ../subprojects/gstreamer/gst/gstpad.c:5533
#22 0x00007ffff7df80f4 in event_forward_func (pad=pad@entry=0x7fff1404f5b0, data=data@entry=0x7ffee67fb770)
at ../subprojects/gstreamer/gst/gstevent.h:438
#23 0x00007ffff7df446e in gst_pad_forward (pad=pad@entry=0x555556151d00, forward=forward@entry=0x7ffff7df8030 <event_forward_func>, user_data=user_data@entry=0x7ffee67fb770) at ../subprojects/gstreamer/gst/gstpad.c:3004
#24 0x00007ffff7df45b5 in gst_pad_event_default (pad=0x555556151d00, parent=<optimized out>, event=0x7ffed4003d10)
at ../subprojects/gstreamer/gst/gstpad.c:3101
#25 0x00007ffff7dee277 in gst_pad_send_event_unchecked (pad=pad@entry=0x555556151d00, event=event@entry=0x7ffed4003d10, type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5757
#26 0x00007ffff7dee7c4 in gst_pad_push_event_unchecked (pad=pad@entry=0x7fff1412a830, event=0x7ffed4003d10, type=type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5402
#27 0x00007ffff7deec34 in push_sticky (pad=pad@entry=0x7fff1412a830, ev=ev@entry=0x7ffee67fb970, user_data=user_data@entry=0x7ffee67fb9e0) at ../subprojects/gstreamer/gst/gstevent.h:438
#28 0x00007ffff7dec548 in events_foreach (pad=pad@entry=0x7fff1412a830, func=func@entry=0x7ffff7deebe0 <push_sticky>, user_data=user_data@entry=0x7ffee67fb9e0) at ../subprojects/gstreamer/gst/gstpad.c:608
#29 0x00007ffff7df7b71 in check_sticky (event=0x7ffed4003d10, pad=0x7fff1412a830)
at ../subprojects/gstreamer/gst/gstpad.c:3977
#30 0x00007ffff7df7b71 in gst_pad_push_event (pad=0x7fff1412a830, event=event@entry=0x7ffed4003d10)
at ../subprojects/gstreamer/gst/gstpad.c:5533
#31 0x00007fff8806626b in gst_queue_push_one (queue=0x7ffee0016010)
at ../subprojects/gstreamer/plugins/elements/gstqueue.c:1455
#32 0x00007fff8806626b in gst_queue_loop (pad=<optimized out>) at ../subprojects/gstreamer/plugins/elements/gstqueue.c:1537
#33 0x00007ffff7e24751 in gst_task_func (task=0x7fff1404c710) at ../subprojects/gstreamer/gst/gsttask.c:328
#34 0x00007ffff7c37bf6 in () at /usr/lib/libglib-2.0.so.0
#35 0x00007ffff7c371ea in () at /usr/lib/libglib-2.0.so.0
#36 0x00007fffef840a9d in start_thread () at /usr/lib/libpthread.so.0
```
crash 2:
```
#0 0x00007fffef4a6667 in __strlen_avx2 () at /usr/lib/libc.so.6
#1 0x00007ffff7c2df54 in g_strdup () at /usr/lib/libglib-2.0.so.0
#2 0x00007fff7d7cff10 in gst_hls_demux_update_fragment_info (stream=0x7ffed000e420)
at ../subprojects/gst-plugins-bad/ext/hls/gsthlsdemux.c:1102
#3 0x00007fff7d7b3ba1 in gst_adaptive_demux_stream_update_fragment_info (demux=demux@entry=0x7fff141aa1f0, stream=stream@entry=0x7ffed000e420) at ../subprojects/gst-plugins-bad/gst-libs/gst/adaptivedemux/gstadaptivedemux.c:4303
#4 0x00007fff7d7bde74 in gst_adaptive_demux_stream_download_loop (stream=0x7ffed000e420)
at ../subprojects/gst-plugins-bad/gst-libs/gst/adaptivedemux/gstadaptivedemux.c:3716
#5 0x00007ffff7e24751 in gst_task_func (task=0x7ffee80c1dd0) at ../subprojects/gstreamer/gst/gsttask.c:328
#6 0x00007ffff7c37bf6 in () at /usr/lib/libglib-2.0.so.0
#7 0x00007ffff7c371ea in () at /usr/lib/libglib-2.0.so.0
#8 0x00007fffef840a9d in start_thread () at /usr/lib/libpthread.so.0
#9 0x00007fffef442a43 in clone () at /usr/lib/libc.so.6
```
the same stream works with no crash in ffplayhttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/115Caught SIGSEGV when check how played video in gst-launch2021-09-24T12:23:14ZBugzilla Migration UserCaught SIGSEGV when check how played video in gst-launch## Submitted by Mikhail Gavrilov `@Mikhail`
**[Link to original bug (#796824)](https://bugzilla.gnome.org/show_bug.cgi?id=796824)**
## Description
$ gst-launch-1.0 --version
gst-launch-1.0 version 1.14.1
GStreamer 1.14.1
http:...## Submitted by Mikhail Gavrilov `@Mikhail`
**[Link to original bug (#796824)](https://bugzilla.gnome.org/show_bug.cgi?id=796824)**
## Description
$ gst-launch-1.0 --version
gst-launch-1.0 version 1.14.1
GStreamer 1.14.1
http://download.fedoraproject.org
$ rpm -qa | grep -i gstreamer | sort
gstreamer1-1.14.1-5.fc29.i686
gstreamer1-1.14.1-5.fc29.x86_64
gstreamer1-debuginfo-1.14.1-5.fc29.x86_64
gstreamer1-debugsource-1.14.1-5.fc29.x86_64
gstreamer1-devel-1.14.1-5.fc29.x86_64
gstreamer1-libav-1.14.1-1.fc29.x86_64
gstreamer1-libav-debuginfo-1.14.1-1.fc29.x86_64
gstreamer1-libav-debugsource-1.14.1-1.fc29.x86_64
gstreamer1-plugins-bad-free-1.14.1-4.fc29.x86_64
gstreamer1-plugins-bad-free-debuginfo-1.14.1-4.fc29.x86_64
gstreamer1-plugins-bad-free-debugsource-1.14.1-4.fc29.x86_64
gstreamer1-plugins-base-1.14.1-3.fc29.i686
gstreamer1-plugins-base-1.14.1-3.fc29.x86_64
gstreamer1-plugins-base-debuginfo-1.14.1-3.fc29.x86_64
gstreamer1-plugins-base-debugsource-1.14.1-3.fc29.x86_64
gstreamer1-plugins-good-1.14.1-3.fc29.x86_64
gstreamer1-plugins-good-debuginfo-1.14.1-3.fc29.x86_64
gstreamer1-plugins-good-debugsource-1.14.1-3.fc29.x86_64
gstreamer1-plugins-good-gtk-1.14.1-3.fc29.x86_64
gstreamer1-plugins-ugly-free-1.14.1-3.fc29.x86_64
gstreamer1-plugins-ugly-free-debuginfo-1.14.1-3.fc29.x86_64
gstreamer1-plugins-ugly-free-debugsource-1.14.1-3.fc29.x86_64
gstreamer1-vaapi-1.14.1-2.fc29.x86_64
gstreamer1-vaapi-debuginfo-1.14.1-2.fc29.x86_64
gstreamer1-vaapi-debugsource-1.14.1-2.fc29.x86_64
PackageKit-gstreamer-plugin-1.1.10-1.fc29.x86_64
$ gst-launch-1.0 playbin uri=file:///home/mikhail/Videos/3D/Metallica.ThroughTheNever\(2013\)3D-halfOU\(Ash61\)Audio-5.1\(MVO.TNT\).mkv
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapipostproc0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayWayland\)\ gldisplaywayland0";
mesa: for the -simplifycfg-sink-common option: may only occur zero or one times!
Got context from element 'vaapipostproc0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayEGL\)\ vaapidisplayegl0";
Redistribute latency...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstPulseSinkClock
ERROR: from element /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:vbin/GstXvImageSink:xvimagesink0: Output window was closed
Additional debug info:
xvimagesink.c(555): gst_xv_image_sink_handle_xevents (): /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:vbin/GstXvImageSink:xvimagesink0
Execution ended after 0:01:08.275317701
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Caught SIGSEGV
```
#0 0x00007f15a23572b2 in __waitpid
#1 0x00007f15a2397287 in g_on_error_stack_trace
#2 0x000055edf3efcebf in fault_spin () at gst-launch.c:103
#3 0x000055edf3efcebf in fault_handler_sighandler (signum=11)
#4 0x00007f15a2357930 in <signal handler called> () at /lib64/libpthread.so.0
#5 0x00007f156a5895e0 in ()
#6 0x00007f157b6e22f6 in pipe_resource_reference (tex=0x0, ptr=0x7f157c0f65c0)
#7 0x00007f157b6e22f6 in vl_compositor_cleanup_state
#8 0x00007f157b6cf8f9 in vlVaTerminate (ctx=<optimized out>) at context.c:387
#9 0x00007f15900d6265 in vaTerminate (dpy=0x7f157c0acc90) at va.c:754
#10 0x00007f158a51ea46 in gst_vaapi_display_destroy
#11 0x00007f158a51ea46 in gst_vaapi_display_finalize
#12 0x00007f15a28a7f79 in g_object_unref (_object=0x55edf612e790)
#13 0x00007f15a2c998b9 in gst_object_unref (object=<optimized out>)
#14 0x00007f15a2c99b20 in gst_object_replace
#15 0x00007f158a51faa9 in gst_vaapi_display_replace
#16 0x00007f158a57489e in gst_vaapi_display_egl_finalize
#17 0x00007f15a28a7f79 in g_object_unref (_object=0x7f157c03a4f0)
#18 0x00007f15a2c998b9 in gst_object_unref (object=<optimized out>)
#19 0x00007f15a2c99b20 in gst_object_replace
#20 0x00007f158a51faa9 in gst_vaapi_display_replace
#21 0x00007f158a52c2c2 in gst_vaapi_video_pool_finalize (pool=0x7f15800557b0)
#22 0x00007f158a524e92 in gst_vaapi_mini_object_free (object=0x7f15800557b0)
#23 0x00007f158a4f7012 in gst_vaapipostproc_destroy (postproc=<optimized out>)
#24 0x00007f158a4f7a3d in gst_vaapipostproc_finalize (object=<optimized out>)
#25 0x00007f15a28a7f79 in g_object_unref (_object=0x7f157c191ea0)
#26 0x00007f15a2c998b9 in gst_object_unref (object=<optimized out>)
#27 0x00007f15a2cd60ea in _gst_message_free (message=0x7f15641082a0)
#28 0x00007f15a23bfb15 in g_list_foreach (list=<optimized out>,
#29 0x00007f15a23bfb3f in g_list_free_full
#30 0x00007f15a2cae287 in gst_bus_set_flushing
#31 0x00007f15a2cee465 in gst_pipeline_change_state
#32 0x00007f1595000e5d in gst_play_bin_change_state
#33 0x00007f15a2cc7902 in gst_element_change_state
#34 0x00007f15a2cc802e in gst_element_set_state_func
#35 0x000055edf3efac08 in main (argc=<optimized out>, argv=<optimized out>)
Spinning. Please run 'gdb gst-launch-1.0 12204' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/491v4l2videodec: trickmode-key-frame hangs on second frame with imx62021-09-24T13:33:08ZBugzilla Migration Userv4l2videodec: trickmode-key-frame hangs on second frame with imx6## Submitted by Michael Tretter `@m.tretter`
**[Link to original bug (#796786)](https://bugzilla.gnome.org/show_bug.cgi?id=796786)**
## Description
Video decoding in trickmode-key-frame fails with GStreamer 1.14.1 on imx6,
because...## Submitted by Michael Tretter `@m.tretter`
**[Link to original bug (#796786)](https://bugzilla.gnome.org/show_bug.cgi?id=796786)**
## Description
Video decoding in trickmode-key-frame fails with GStreamer 1.14.1 on imx6,
because the v4l2videodec sends a STREAMOFF-STREAMON sequence to the V4L2
driver when draining the decoder.
I can reproduce the issue using the following pipeline and scenario:
Pipeline:
gst-validate-1.0 --set-scenario trickmode-seek-fast-forward \
filesrc location=${FILENAME} ! \
h264parse ! v4l2h264dec ! \
waylandsink
Scenario:
description, duration=25.0, seek=true, need-clock-sync=true
seek, playback-time=0.0, rate=8.0, start=0.0, flags=trickmode-key-units+key-unit+flush
wait, duration=10.0
stop
The first frame after the seek event is decoded fine, but CODA decoder hangs
on the second frame and the CODA driver prints a message that SEQ_INIT failed.
The decoder expects an SPS/PPS NAL unit for the initialization, but the
decoder starts with the IDR without sending the SPS/PPS first.
If I set config-interval=-1 on the h264parse to send the SPS/PPS for every
keyframe the decoding works. This only works for lower decoding rates (e.g.
2.0). For higher rates the sink starts to drop frames because the buffers are
too late.
In trickmode-key-frame, the videodecoder drains the decoder after every frame.
The problem is that the v4l2videodec flushes while draining the decoder in
addition to run CMD_STOP, which runs a STREAMOFF-STREAMON sequence. The
STREAMOFF-STREAMON causes the driver to reset/reinitialize the CODA and thus
requiring the SPS/PPS NAL units for a proper initialization.
My understanding is that the STREAMOFF-STREAMON during the drain implies a
seek which requires a resume point for continuing and violates the assumption
that sub-classes should be prepared to handle new data after the drain.
Instead the v4l2videodec should not flush the decoder while draining but use
the CMD_START to restart the decoder once all buffers are drained. I have not
found many users or implementers of CMD_START and I am not sure if this is the
right solution.
Version: 1.14.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/747ksvideosrc: fails to initialize Datapath VisionRGB-E2S2021-09-24T14:36:32ZBugzilla Migration Userksvideosrc: fails to initialize Datapath VisionRGB-E2S## Submitted by bou..@..il.com
**[Link to original bug (#796769)](https://bugzilla.gnome.org/show_bug.cgi?id=796769)**
## Description
Created attachment 372982
debugLevel6
I have a Datapath VisionRGB-E2S capture device.
It ...## Submitted by bou..@..il.com
**[Link to original bug (#796769)](https://bugzilla.gnome.org/show_bug.cgi?id=796769)**
## Description
Created attachment 372982
debugLevel6
I have a Datapath VisionRGB-E2S capture device.
It is installed on windows and works fine using directshow.
I am trying to open its stream through GStreamer, and the provided command by gst-device-monitor-1.0.exe fails with "reason-not-negotiated `<-4>`".
I've added the gst-device-monitor output, and a level 6 debug output.
**Attachment 372982**, "debugLevel6":
[DebugInfo.tar.gz](/uploads/56f0a8ad0c0420d4a0ad21f39c47dd9e/DebugInfo.tar.gz)
Version: 1.14.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/463playbin2 flush doesn't travel upstream2021-09-24T13:24:10ZBugzilla Migration Userplaybin2 flush doesn't travel upstream## Submitted by James
**[Link to original bug (#796620)](https://bugzilla.gnome.org/show_bug.cgi?id=796620)**
## Description
Created attachment 372712
test app to show problem. Can be built to send flush to appsrc or playbin.
...## Submitted by James
**[Link to original bug (#796620)](https://bugzilla.gnome.org/show_bug.cgi?id=796620)**
## Description
Created attachment 372712
test app to show problem. Can be built to send flush to appsrc or playbin.
I have an application that constructs a playbin2 based pipeline. It uses an appsrc element to write TS muxed data in push mode. The application has a need to flush the pipeline when starting playback of a new stream and it does this by sending a flush-start, flush-stop pair of events to the playbin.
We've recently updated from GStreamer 1.4.x to 1.8.3 and found that the appsrc elements aren't receiving the flush events when the playbin is flushed (they did when using 1.4). The particular change that caused this behaviour was introduced in 1.6.1 by https://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/gst/playback/gstplaybin2.c?h=1.6&id=cfb6d6e7b44fedddeb6aa6f0fdb1189541d3d035.
The GStreamer examples and documentation that I've seen state that flush events should be sent to the pipeline and my application has followed this advice. Since this change has been in place for so long I find it hard to believe that this is a bug so I'm looking for advice on whether the application behaviour is correct. I've attempted to reproduce the logic in a test application (see attached) and can confirm it's broken on 1.8.3 and git master. The test app builds a pipeline, pushes a large amount of data, then after 1 second issues a flush. If the flush is sent to the appsrc then all is well, however if it's sent to the playbin then it doesn't travel to the appsrc.
Should playbin/pipeline send the events upstream to the appsrc in push-mode? or should my app always have been sending the flush events to the appsrc?
Thanks
**Attachment 372712**, "test app to show problem. Can be built to send flush to appsrc or playbin.":
[PipelineFlush.c](/uploads/0a1da6df6cc4b4e9b08a67812c42c46d/PipelineFlush.c)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/725kmssink: add support for GBM allocator2021-09-24T14:36:24ZBugzilla Migration Userkmssink: add support for GBM allocator## Submitted by Randy Li (ayaka)
**[Link to original bug (#796493)](https://bugzilla.gnome.org/show_bug.cgi?id=796493)**
## Description
Created attachment 372542
allocator
In the Android, there is a similiar usuage with GPU m...## Submitted by Randy Li (ayaka)
**[Link to original bug (#796493)](https://bugzilla.gnome.org/show_bug.cgi?id=796493)**
## Description
Created attachment 372542
allocator
In the Android, there is a similiar usuage with GPU memory, it use galloc() to allocate and access a memory from GPU.
There is a GBM support in -base, it doesn't include any memory operation.
This patch is verified with ARM MALI GPU library.
~~**Patch 372542**~~, "allocator":
[0003-kms-gbm-add-a-new-gbm-allocator.patch](/uploads/75848bf3817c5c9472e34daa84a30136/0003-kms-gbm-add-a-new-gbm-allocator.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/724avfvideosrc Consuming Too much CPU2021-09-24T14:36:24ZBugzilla Migration Useravfvideosrc Consuming Too much CPU## Submitted by Prafulla Kumar Singh
**[Link to original bug (#796478)](https://bugzilla.gnome.org/show_bug.cgi?id=796478)**
## Description
Compare to videotestsrc, avfvideosrc taking too much CPU.
pipeline with videotestsrc CPU u...## Submitted by Prafulla Kumar Singh
**[Link to original bug (#796478)](https://bugzilla.gnome.org/show_bug.cgi?id=796478)**
## Description
Compare to videotestsrc, avfvideosrc taking too much CPU.
pipeline with videotestsrc CPU use : ~ 28.2%
pipeline with avfvideosrc CPU use : ~ 207.2%
Following are terminal log for reference:
ADFGTECHs-MacBook-Pro-2:iOSGstreamerClient prafullasingh$ ps
PID TTY TIME CMD
1111 ttys000 0:00.49 -bash
12116 ttys000 0:20.14 ./objs/srs -c ./conf/srs.conf
12196 ttys000 0:00.06 tail -f objs/srs.log
14198 ttys002 0:00.46 -bash
22944 ttys002 0:03.17 gst-launch-1.0 videotestsrc is-live=true ! videoconvert ! x264enc tune=zerolatency ! video/x-h264 ! mpegtsmux name=mux ! queu
22733 ttys003 0:00.15 -bash
ADFGTECHs-MacBook-Pro-2:iOSGstreamerClient prafullasingh$ ps -p 22944 -o %cpu,%mem
%CPU %MEM
25.6 0.4
ADFGTECHs-MacBook-Pro-2:iOSGstreamerClient prafullasingh$ ps -p 22944 -o %cpu,%mem
%CPU %MEM
28.2 0.4
ADFGTECHs-MacBook-Pro-2:iOSGstreamerClient prafullasingh$ ps -p 22944 -o %cpu,%mem
%CPU %MEM
28.5 0.4
ADFGTECHs-MacBook-Pro-2:iOSGstreamerClient prafullasingh$ ps
PID TTY TIME CMD
1111 ttys000 0:00.49 -bash
12116 ttys000 0:20.15 ./objs/srs -c ./conf/srs.conf
12196 ttys000 0:00.06 tail -f objs/srs.log
14198 ttys002 0:00.47 -bash
22951 ttys002 0:11.46 gst-launch-1.0 avfvideosrc ! videoconvert ! x264enc tune=zerolatency ! video/x-h264 ! mpegtsmux name=mux ! queue ! udpsink ho
22733 ttys003 0:00.17 -bash
ADFGTECHs-MacBook-Pro-2:iOSGstreamerClient prafullasingh$ ps -p 22951 -o %cpu,%mem
%CPU %MEM
211.1 0.7
ADFGTECHs-MacBook-Pro-2:iOSGstreamerClient prafullasingh$ ps -p 22951 -o %cpu,%mem
%CPU %MEM
207.2 0.7
ADFGTECHs-MacBook-Pro-2:iOSGstreamerClient prafullasingh$ gst-inspect-1.0 --version
gst-inspect-1.0 version 1.14.0
GStreamer 1.14.0
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/39failed to link avmux_spdif link with alsasink for ac3 passthrough2021-09-24T12:52:25ZBugzilla Migration Userfailed to link avmux_spdif link with alsasink for ac3 passthrough## Submitted by Lyon
**[Link to original bug (#796466)](https://bugzilla.gnome.org/show_bug.cgi?id=796466)**
## Description
Hi,
I was trying to realize ac3 audio passthrough via hdmi by a certain pipeline with avmux_spdif.
...## Submitted by Lyon
**[Link to original bug (#796466)](https://bugzilla.gnome.org/show_bug.cgi?id=796466)**
## Description
Hi,
I was trying to realize ac3 audio passthrough via hdmi by a certain pipeline with avmux_spdif.
By pipeline:
"gst-launch-1.0 filesrc location= 5.1_de.ac3 ! ac3parse ! avmux_spdif ! filesink location= ac3.spdif"
I managed to dump out the encapsulated ac3 (iec61958) format.
Then I was trying to link avmux_spdif with alsasink
Noticing avmux_spdif src caps is "application/x-gst-av-spdif", which alsasink not supported, so I modified avmux_spdif src caps with "audio/x-ac3, framed=true"
However seems I still met problem when trying to output the data via alsasink
below is some log with GST_DEBUG=audiobasesink:6,2
Setting pipeline to PAUSED ...
0:00:00.182977808 [335m 3646[00m 0x3c8bb190 [33;01mWARN [00m [00m basesrc gstbasesrc.c:3583:gst_base_src_start_complete:`<filesrc0>`[00m pad not activated yet
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstAc3Parse:ac3parse0.GstPad:src: caps = audio/x-ac3, framed=(boolean)true, rate=(int)48000, channels=(int)6, alignment=(string)frame
/GstPipeline:pipeline0/avmux_spdif:avmux_spdif0.GstPad:audio_0: caps = audio/x-ac3, framed=(boolean)true, rate=(int)48000, channels=(int)6, alignment=(string)frame
0:00:00.186149288 [335m 3646[00m 0x3c867280 [32;01mFIXME [00m [00m basesink gstbasesink.c:3145:gst_base_sink_default_event:`<alsasink0>`[00m stream-start event without group-id. Consider implementing group-id handling in the upstream elements
0:00:00.186471848 [335m 3646[00m 0x3c867280 [37mDEBUG [00m [00m audiobasesink gstaudiobasesink.c:1197:gst_audio_base_sink_preroll:`<alsasink0>`[00m ringbuffer in wrong state
0:00:00.186508208 [335m 3646[00m 0x3c867280 [33;01mWARN [00m [00m audiobasesink gstaudiobasesink.c:1198:gst_audio_base_sink_preroll:`<alsasink0>`[00m error: sink not negotiated.
0:00:00.186702488 [335m 3646[00m 0x3c867280 [37mDEBUG [00m [00m audiobasesink gstaudiobasesink.c:1197:gst_audio_base_sink_preroll:`<alsasink0>`[00m ringbuffer in wrong state
ERROR: from element /GstPipeline:pipeline0/GstAlsaSink:alsasink0: The stream is in the wrong format.
0:00:00.186732608 [335m 3646[00m 0x3c867280 [33;01mWARN [00m [00m audiobasesink gstaudiobasesink.c:1198:gst_audio_base_sink_preroll:`<alsasink0>`[00m error: sink not negotiated.
Additional debug info:
../../../../git/gst-libs/gst/audio/gstaudiobasesink.c(1198): gst_audio_base_sink_preroll (): /GstPipeline:pipeline0/GstAlsaSink:alsasink0:
sink not negotiated.
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Do anyone meet similar issue when trying to use avmux_spdif to passthrough ac3 via alsasink?
Any hint will be appreciated for this issue
Thanks
Lyon
Version: 1.14.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/457Memory keep increase in gst-play-1.02021-09-24T13:24:06ZBugzilla Migration UserMemory keep increase in gst-play-1.0## Submitted by Ung, Teng En
**[Link to original bug (#796449)](https://bugzilla.gnome.org/show_bug.cgi?id=796449)**
## Description
We use gst-play-1.0 to play through a playlist. We notice when it finish current video and continue...## Submitted by Ung, Teng En
**[Link to original bug (#796449)](https://bugzilla.gnome.org/show_bug.cgi?id=796449)**
## Description
We use gst-play-1.0 to play through a playlist. We notice when it finish current video and continue to next video, the RES will increase. Until certain point it just remain there. Here is the command :-
gst-play-1.0 --playlist=test.list
Although the patch we try fix previous issue (https://bugzilla.gnome.org/show_bug.cgi?id=790472).
We just like to know what cause the RES memory keep increasing.
Version: 1.12.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/471id3demux : Does not send segment-start and segment-done message2021-09-24T13:33:02ZBugzilla Migration Userid3demux : Does not send segment-start and segment-done message## Submitted by Baby octopus
**[Link to original bug (#795882)](https://bugzilla.gnome.org/show_bug.cgi?id=795882)**
## Description
I have developed an application to stream a file indefinitely by looping it. For looping, I do a seg...## Submitted by Baby octopus
**[Link to original bug (#795882)](https://bugzilla.gnome.org/show_bug.cgi?id=795882)**
## Description
I have developed an application to stream a file indefinitely by looping it. For looping, I do a segment seek and then catch the SEGMENT_DONE message. However, this approach works for Mp4 and not work for mp3. Digging deeper, I found id3mux does not send these messages
One another issue here is the id3demux is optional for mp3 decoding. Decodebin does not autoplug id3demux for certain mp3 files but directly uses the mpegaudioparse. I'm not really sure which element is to send segment-start and segment-done messages in such a casehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/459progressreport: Progress report message is not reporting percent-double and p...2021-09-24T13:32:58ZBugzilla Migration Userprogressreport: Progress report message is not reporting percent-double and percentage for some files## Submitted by Vinod Kesti `@vinodkesti`
**[Link to original bug (#795003)](https://bugzilla.gnome.org/show_bug.cgi?id=795003)**
## Description
progressreport message pattern is inconsistent with some file
Below are the behaviour...## Submitted by Vinod Kesti `@vinodkesti`
**[Link to original bug (#795003)](https://bugzilla.gnome.org/show_bug.cgi?id=795003)**
## Description
progressreport message pattern is inconsistent with some file
Below are the behaviour.
1. When file processing start progressreport message contains percent-double and percentage
2. After some time percentage details are missing in the message.
3. This issue is observed when system is loaded with multiple file processing.
Further analyses and found that issue comes when gst_pad_peer_query_duration (sink_pad, format, &total) function returns total = -1
I tried debugging but not able to figure out which element responds to the query.
Can some one help me to give pointer where the problem is
~ Vinod
Version: 1.13.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/451[souphttpsrc] TLS/SSL support not available on Win322021-09-24T13:32:55ZBugzilla Migration User[souphttpsrc] TLS/SSL support not available on Win32## Submitted by Tao
**[Link to original bug (#794425)](https://bugzilla.gnome.org/show_bug.cgi?id=794425)**
## Description
Hello,
It's my first bug report on gnome, so please don't blame me. This bug report is a followup of htt...## Submitted by Tao
**[Link to original bug (#794425)](https://bugzilla.gnome.org/show_bug.cgi?id=794425)**
## Description
Hello,
It's my first bug report on gnome, so please don't blame me. This bug report is a followup of https://github.com/ua-i2cat/gst-unity-bridge/issues/36
My goal is to play live HLS stream in unity, for this I use GStreamer Unity3D Bridge. This library obviously rely on GStreamer. But gstreamer looks to be unable to perform an HTTPS request with following message:
souphttpsrc gstsouphttpsrc.c:1279:gst_soup_http_src_parse_status:`<souphttpsrc2>` error: TLS/SSL support not available; install glib-networking (6), URL: https://protectedurl/forthisbugreport, Redirect to: (NULL)
The old discussion on gstreamer dev mailing list http://gstreamer-devel.966125.n4.nabble.com/Queries-about-libgstsouphttpsrc-td4667605.html suggests to simply add libgiognutls.dll to my project, but it did not fix my problem. Notice I also tried to put libgiognutls.dll in windows system32 dir.
This bug is reproducible with GStreamer 1.13.91.
Kind regards,
Laurent.
Version: 2.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/423missing vaapipostproc causes gstreamer crash in glupload2021-09-24T13:23:36ZBugzilla Migration Usermissing vaapipostproc causes gstreamer crash in glupload## Submitted by Vavooon
**[Link to original bug (#794080)](https://bugzilla.gnome.org/show_bug.cgi?id=794080)**
## Description
In some cases gst-launch crashes when I'm trying to display video without X11 using kmssink or glimagesin...## Submitted by Vavooon
**[Link to original bug (#794080)](https://bugzilla.gnome.org/show_bug.cgi?id=794080)**
## Description
In some cases gst-launch crashes when I'm trying to display video without X11 using kmssink or glimagesink.
Local video plays well (pipeline is
gst-launch-1.0 filesrc location=bbb_sunflower_1080p_30fps_normal.mp4 ! decodebin ! glupload ! glimagesink
) however, when I'm trying to play RTSP stream using
gst-launch-1.0 udpsrc port=9001 ! application/x-rtp, encoding-name=H264 ! rtph264depay ! h264parse ! vaapih264dec low-latency=true ! videoconvert ! glupload ! glimagesink
it fails with following message:
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayGBM\)\ gldisplaygbm0";
Got context from element 'vaapidecode_h264-0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayDRM\)\ vaapidisplaydrm1";
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
Caught SIGSEGV
And here's the stack:
Thread 5 "gstglcontext" received signal SIGSEGV, Segmentation fault.
```
[Switching to Thread 0x7fffde651700 (LWP 2656)]
__memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:491
491 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) bt full
#0 __memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:491
No locals.
#1 0x00007fffe96f87cf in memcpy (__len=3686400, __src=<optimized out>, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
No locals.
#2 gst_gl_buffer_upload_cpu_write (info=<optimized out>, size=3686400, mem=0x7fffd55a9470) at gstglbuffer.c:195
gl_map_flags = 2
gl = 0x555555c25950
data = <optimized out>
#3 _gl_buffer_map (mem=0x7fffd55a9470, info=<optimized out>, size=3686400) at gstglbuffer.c:212
gl = 0x555555c25950
#4 0x00007fffe96f7749 in _map_data_gl (context=<optimized out>, transfer=0x7fffde650b90) at gstglbasememory.c:277
alloc_class = 0x555555b43930
mem = 0x7fffd55a9470
info = 0x7fffde650c00
prev_map_flags = 0
prev_gl_map_count = 0
__func__ = "_map_data_gl"
__PRETTY_FUNCTION__ = "_map_data_gl"
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/420gstclockoverlay: Add ability to specify which time to be displayed by GstCloc...2021-09-24T13:23:35ZBugzilla Migration Usergstclockoverlay: Add ability to specify which time to be displayed by GstClockOverlay## Submitted by Abhinav
**[Link to original bug (#793683)](https://bugzilla.gnome.org/show_bug.cgi?id=793683)**
## Description
Created attachment 368688
Patch for adding ability to specify time to be displayed by GstClockOverlay ...## Submitted by Abhinav
**[Link to original bug (#793683)](https://bugzilla.gnome.org/show_bug.cgi?id=793683)**
## Description
Created attachment 368688
Patch for adding ability to specify time to be displayed by GstClockOverlay
GstClockOverlay presently displays buffer arrival time as default. In certain scenarios, users would like to display buffer's timestamp, rather than buffer arrival time - to avoid any gaps caused by latency between frame source and clockoverlay element in pipeline.
I propose to add property called "time-mode", where users should be able to specify what time to show. So other than current default, there can be another option for time-mode say "buffer-time", to indicate that clockoverlay will be using buffer's time for display.
Example element configuration can look like following :
clockoverlay halignment=right valignment=bottom time-format="%Y-%m-%d %H:%M:%S" time-mode=1
Where time-mode=1 represents "buffer-time".
Attached is the implementation for the same.
Note: GstTimeOverlay uses buffer time, but that doesn't have capability to display in clock format. Since clockoverlay is used to display text in clock format, it was found more suitable for said requirement.
**Patch 368688**, "Patch for adding ability to specify time to be displayed by GstClockOverlay":
[0001-gstclockoverlay-add-time-mode-property-to-specify-wh.patch](/uploads/df1e6b1c23d46b7b913d6173e0e8a506/0001-gstclockoverlay-add-time-mode-property-to-specify-wh.patch)
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/655Crashing on iOS: [ALAssetRepresentation release]: message sent to deallocated...2021-09-24T14:36:05ZBugzilla Migration UserCrashing on iOS: [ALAssetRepresentation release]: message sent to deallocated instance, [GstAssetsLibrary .cxx_destruct] XCode 9.2, iOS 11.2 (15C107)## Submitted by Louis Le
**[Link to original bug (#793383)](https://bugzilla.gnome.org/show_bug.cgi?id=793383)**
## Description
I'm stuck on crashing issue: message sent to deallocated instance zombie object with GStreamer tutorial ...## Submitted by Louis Le
**[Link to original bug (#793383)](https://bugzilla.gnome.org/show_bug.cgi?id=793383)**
## Description
I'm stuck on crashing issue: message sent to deallocated instance zombie object with GStreamer tutorial project for iOS with this version of XCode, the app crashes when trying to unref the player or pipeline after playing a AVI file saved in Camera Roll using ALAsset with prefix:
assets-library://asset/asset.AVI?id=ID_OF_AVI_FILE&ext=AVI.
Crash point: typefind:sink -> [GstAssetsLibrary .cxx_destruct]
Crash callStackSymbols
`<_NSCallStackArray 0x604000452180>`(
```
0 ??? 0x00000001226dbf1c 0x0 + 4872584988,
1 Tutorial 5 0x0000000103211300 main + 0,
2 libobjc.A.dylib 0x000000010bbb6912 _ZL27object_cxxDestructFromClassP11objc_objectP10objc_class + 127,
3 libobjc.A.dylib 0x000000010bbc21a4 objc_destructInstance + 124,
4 libobjc.A.dylib 0x000000010bbc21db object_dispose + 22,
5 AssetsLibrary 0x00000001088a6acd -[ALAssetsLibrary dealloc] + 98,
6 libobjc.A.dylib 0x000000010bbcca2e _ZN11objc_object17sidetable_releaseEb + 202,
7 libobjc.A.dylib 0x000000010bbcd178 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 860,
8 libobjc.A.dylib 0x000000010bbce31b _ZN12_GLOBAL__N_119AutoreleasePoolPage11tls_deallocEPv + 127,
9 libsystem_pthread.dylib 0x000000010ca0f27e _pthread_tsd_cleanup + 534,
10 libsystem_pthread.dylib 0x000000010ca0efbd _pthread_exit + 79,
11 libsystem_pthread.dylib 0x000000010ca0d6cc pthread_sigmask + 0,
12 libsystem_pthread.dylib 0x000000010ca0d56d _pthread_body + 0,
13 libsystem_pthread.dylib 0x000000010ca0cc5d thread_start + 13
)
```
>https://github.com/sdroege/gst-player
>https://github.com/GStreamer/gst-docs/tree/master/examples/tutorials/xcode%20iOS
Version: 1.12.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/416GStreamer crashes when volume is set to 0 for raw PCM audio data with sink ti...2021-09-24T13:23:31ZBugzilla Migration UserGStreamer crashes when volume is set to 0 for raw PCM audio data with sink timestamp sync turned off## Submitted by Andrei Mikheev
**[Link to original bug (#793081)](https://bugzilla.gnome.org/show_bug.cgi?id=793081)**
## Description
Our raw PCM data does not have timestamps for the pipeline and it causes volume plugin to crash wi...## Submitted by Andrei Mikheev
**[Link to original bug (#793081)](https://bugzilla.gnome.org/show_bug.cgi?id=793081)**
## Description
Our raw PCM data does not have timestamps for the pipeline and it causes volume plugin to crash with messages complaining about a timestamp expected when we set the volume to 0 or mute. Note that we use autoaudiosink with "sync=false" option.
How to reproduce:
gst-launch-1.0 -v filesrc location=rawpcm.wav ! decodebin ! queue ! audioconvert ! volume volume=0 ! autoaudiosink sync=false
The version of this with volume set to non-zero value actually works:
gst-launch-1.0 -v filesrc location=rawpcm.wav ! decodebin ! queue ! audioconvert ! volume volume=1 ! autoaudiosink sync=false
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/432Regression? video-surveilance camera feed, h264 keyframes not identified, spl...2021-09-24T13:32:49ZBugzilla Migration UserRegression? video-surveilance camera feed, h264 keyframes not identified, splitmuxsink doesn't split due to infinite GOP## Submitted by cJ-..@..oub.eu
**[Link to original bug (#792336)](https://bugzilla.gnome.org/show_bug.cgi?id=792336)**
## Description
This was working prior to a gstreamer upgrade (prior: 1.8.3 or 1.10.4, current: 1.12.3).
Runn...## Submitted by cJ-..@..oub.eu
**[Link to original bug (#792336)](https://bugzilla.gnome.org/show_bug.cgi?id=792336)**
## Description
This was working prior to a gstreamer upgrade (prior: 1.8.3 or 1.10.4, current: 1.12.3).
Running the pipeline:
rtspsrc ! rtph264depay ! h264parse ! identity silent=false ! splitmuxsink name=sink max-size-time=10000000000 location=video%03d.mp4
Now, splitmuxsink doesn't split.
Using ffmpeg to capture the RTSP feed to mp4 without transcoding, then processing the mp4 with gstreamer doesn't cause issues.
Current:
/GstPipeline:pipeline0/GstSplitMuxSink:sink/GstQueue:queue0: max-size-buffers = 252
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (189112 bytes, dts: none, pts: 0:00:10.091041225, duration: none, offset: -1, offset_end: -1, flags: 00000000 , meta: none) 0x7f87683342b0
0:00:10.209103770 31069 0x7f876805e450 LOG splitmuxsink gstsplitmuxsink.c:1368:handle_mq_input:<queue0:sink> Fired probe type 0x1040
0:00:10.209162465 31069 0x7f876805e450 LOG splitmuxsink gstsplitmuxsink.c:1379:handle_mq_input:<queue0:sink> Event tag event: 0x7f874c018650, time 99:99:99.999999999, seq-num 711, GstTagList-stream, taglist=(taglist)"taglist\,\ video-codec\=\(string\)\"H.264\\\ \\\(Baseline\\\ Profile\\\)\"\,\ minimum-bitrate\=\(uint\)6787600\,\ maximum-bitrate\=\(uint\)37822400\,\ bitrate\=\(uint\)8482734\;";
0:00:10.209255141 31069 0x7f876805e450 LOG splitmuxsink gstsplitmuxsink.c:1368:handle_mq_input:<queue0:sink> Fired probe type 0x1010
0:00:10.209285276 31069 0x7f876805e450 LOG splitmuxsink gstsplitmuxsink.c:1468:handle_mq_input:<queue0:sink> Buffer TS is 0:00:10.000000000
0:00:10.209321125 31069 0x7f876805e450 LOG splitmuxsink gstsplitmuxsink.c:1482:handle_mq_input:<queue0:sink> Buffer running TS is +0:00:10.000000000
0:00:10.209354220 31069 0x7f876805e450 LOG splitmuxsink gstsplitmuxsink.c:1496:handle_mq_input:<queue0:sink> in running time now +0:00:10.091041225
0:00:10.209386101 31069 0x7f876805e450 DEBUG splitmuxsink gstsplitmuxsink.c:1523:handle_mq_input:<queue0:sink> Buf TS +0:00:10.091041225 total GOP bytes 10456720
0:00:10.209421337 31069 0x7f876805e450 LOG splitmuxsink gstsplitmuxsink.c:1619:handle_mq_input:<queue0:sink> Returning to queue buffer buffer: 0x7f87682a6e40, pts 99:99:99.999999999, dts 0:00:10.000000000, dur 0:00:00.040000000, size 189112, offset 10456720, offset_end none, flags 0x0 run ts +0:00:10.091041225
0:00:10.209476947 31069 0x7f876805e450 DEBUG splitmuxsink gstsplitmuxsink.c:1680:handle_q_overrun:`<queue0>` Queue reported overrun with 0 keyframes and 0 cmds enqueued
0:00:10.209515002 31069 0x7f876805e450 DEBUG splitmuxsink gstsplitmuxsink.c:1708:handle_q_overrun:`<queue0>` Queue overflowed and needs enlarging. Growing to 253 buffers
/GstPipeline:pipeline0/GstSplitMuxSink:sink/GstQueue:queue0: max-size-buffers = 253
Prior:
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (188750 bytes, dts: none, pts: 0:00:20.120181650, duration: none, offset: -1, offset_end: -1, flags: 00000000 ) 0x7f638832a240
0:00:20.227243100 11185 0x7f63880314f0 LOG splitmuxsink gstsplitmuxsink.c:1072:handle_mq_input:<multiqueue:sink_0> Fired probe type 0x1010
0:00:20.227269007 11185 0x7f63880314f0 LOG splitmuxsink gstsplitmuxsink.c:1131:handle_mq_input:<multiqueue:sink_0> Buffer TS is 0:00:20.000000000
0:00:20.227288042 11185 0x7f63880314f0 LOG splitmuxsink gstsplitmuxsink.c:1145:handle_mq_input:<multiqueue:sink_0> Buffer running TS is +0:00:20.000000000
0:00:20.227303696 11185 0x7f63880314f0 LOG splitmuxsink gstsplitmuxsink.c:1159:handle_mq_input:<multiqueue:sink_0> in running time now +0:00:20.120181650
0:00:20.227318269 11185 0x7f63880314f0 DEBUG splitmuxsink gstsplitmuxsink.c:1180:handle_mq_input:<multiqueue:sink_0> Buf TS +0:00:20.120181650 total in_bytes 21243668
0:00:20.227341942 11185 0x7f63880314f0 INFO splitmuxsink gstsplitmuxsink.c:1200:handle_mq_input:<multiqueue:sink_0> Have keyframe with running time +0:00:20.120181650
0:00:20.227372698 11185 0x7f63880314f0 LOG splitmuxsink gstsplitmuxsink.c:959:check_completed_gop:`<sink>` Checking GOP collected, Max in running time +0:00:20.120181650 ctx 0x7bf3a0
0:00:20.227400258 11185 0x7f63880314f0 LOG splitmuxsink gstsplitmuxsink.c:967:check_completed_gop:`<sink>` Context 0x7bf3a0 (src pad <multiqueue:src_0>) TS +0:00:20.120181650 EOS 0
0:00:20.227418041 11185 0x7f63880314f0 DEBUG splitmuxsink gstsplitmuxsink.c:981:check_completed_gop:`<sink>` Collected GOP is complete. Processing (ctx 0x7bf3a0)
0:00:20.227428282 11185 0x7f63880314f0 LOG splitmuxsink gstsplitmuxsink.c:899:handle_gathered_gop:`<sink>` mq at TS +0:00:10.040000000 bytes 11000255
0:00:20.227447285 11185 0x7f63880314f0 INFO splitmuxsink gstsplitmuxsink.c:913:handle_gathered_gop:`<sink>` mq overflowed since last, draining out. max out TS is +0:00:15.120181650
0:00:20.227461928 11185 0x7f63880314f0 LOG splitmuxsink gstsplitmuxsink.c:1243:handle_mq_input:<multiqueue:sink_0> Sending splitmuxsink-unblock event
0:00:20.227485016 11185 0x7f63880314f0 LOG splitmuxsink gstsplitmuxsink.c:1072:handle_mq_input:<multiqueue:sink_0> Fired probe type 0x1040
0:00:20.227489094 11185 0x7b4f70 INFO splitmuxsink gstsplitmuxsink.c:600:complete_or_wait_on_out:<multiqueue:src_0> Woken for new max running time +0:00:15.120181650
0:00:20.227532716 11185 0x7b4f70 LOG splitmuxsink gstsplitmuxsink.c:567:complete_or_wait_on_out:<multiqueue:src_0> Checking running time +0:00:15.120181650 against max +0:00:15.120181650
0:00:20.227555821 11185 0x7b4f70 INFO splitmuxsink gstsplitmuxsink.c:547:send_eos:`<sink>` Sending EOS on <muxer:video_0>
Version: 1.12.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/412appsrc: uncertainty moment in the documentation2021-09-24T13:23:26ZBugzilla Migration Userappsrc: uncertainty moment in the documentation## Submitted by Aleksandr Slobodeniuk
**[Link to original bug (#792265)](https://bugzilla.gnome.org/show_bug.cgi?id=792265)**
## Description
About the ownership of the buffer, when pushing it to appsrc.
https://gstreamer.freede...## Submitted by Aleksandr Slobodeniuk
**[Link to original bug (#792265)](https://bugzilla.gnome.org/show_bug.cgi?id=792265)**
## Description
About the ownership of the buffer, when pushing it to appsrc.
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-appsrc.html#gst-app-src-push-buffer
Function takes ownership, but signal doesn't.
It was tricky, because I didn't find the documentation for signal in the web.
But in appsrc's code it exists:
/**
* GstAppSrc::push-buffer:
* @appsrc: the appsrc
* @buffer: a buffer to push
*
* Adds a buffer to the queue of buffers that the appsrc element will
* push to its source pad. This function does not take ownership of the
* buffer so the buffer needs to be unreffed after calling this function.
*
And the web-page only says:
----
The main way of handing data to the appsrc element is by calling the gst_app_src_push_buffer() method or by emitting the push-buffer action signal.
----
But gst_app_src_push_buffer
is not a signal handler for "push-buffer", that's what's tricky.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/428flacparse: duration is not correct for 24bit depth output.2021-09-24T13:32:48ZBugzilla Migration Userflacparse: duration is not correct for 24bit depth output.## Submitted by Lyon
**[Link to original bug (#791975)](https://bugzilla.gnome.org/show_bug.cgi?id=791975)**
## Description
When I'm tried with one 24bit depth flac file and find that the duration got is 8'09s, however this audio ac...## Submitted by Lyon
**[Link to original bug (#791975)](https://bugzilla.gnome.org/show_bug.cgi?id=791975)**
## Description
When I'm tried with one 24bit depth flac file and find that the duration got is 8'09s, however this audio actual duration is 5'09''
Some player on PC also report 8'09", but VLC reported the correct duration.
I'm wondering if this is related to the 24bit(3 byte) depth, seems I didn't find it use bps to deal with the duration
Version: 1.12.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/641h265parse: Messes up timestamps for byte-stream2021-09-24T14:36:01ZBugzilla Migration Userh265parse: Messes up timestamps for byte-stream## Submitted by Matej `@Knopp`
**[Link to original bug (#791495)](https://bugzilla.gnome.org/show_bug.cgi?id=791495)**
## Description
It happens when previous frame has trailing zero. Parser split frame too early, leaving trailing z...## Submitted by Matej `@Knopp`
**[Link to original bug (#791495)](https://bugzilla.gnome.org/show_bug.cgi?id=791495)**
## Description
It happens when previous frame has trailing zero. Parser split frame too early, leaving trailing zeros as prefix for new frame, which results in messed up timestamps.
Caused by following code in gst_h265_parser_identify_nalu
/* Mini performance improvement:
* We could have a way to store how many 0s were skipped to avoid
* parsing them again on the next NAL */
while (off2 > 0 && data[nalu->offset + off2 - 1] == 00)
off2--;
Annex B does says that there should be zero byte before AU startcode, however it also says that during parsing the zero byte should be discarded. So maybe determining the timestamp from zero byte is not a very good idea.
The stream already parsed by FFMPEG HEVC parser, which seems to leave zero byte trailing, but that doesn't mean such files can't be encountered in the wild.
Btw. Why's there loop? Why skipping more than 1 zero byte? Doesn't that just increases chance of messed up timestamps?