gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2022-04-07T06:00:01Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/97allocation query: Add API to increase and update the minimum require buffers2022-04-07T06:00:01ZBugzilla Migration Userallocation query: Add API to increase and update the minimum require buffers## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#746212)](https://bugzilla.gnome.org/show_bug.cgi?id=746212)**
## Description
As it goes, the minimum buffers in an allocation pool has a special meaning. It rep...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#746212)](https://bugzilla.gnome.org/show_bug.cgi?id=746212)**
## Description
As it goes, the minimum buffers in an allocation pool has a special meaning. It represent the minimum amount of buffers required in order for a segment of a pipeline to function. Element that retain buffers must update this value in order to ensure the pool will function.
Unfortunately this value is not exposed globally, but rather per allocation pool. This means that to update/increase this value, one need to iterate over the pool list, remove pool which have a maximum too small and update minimum. In order to make this task easier, we could add utilities in the core API. Currently this is implemented by videorate only, but queues with minimum threshold should implement that too, deinterlace element, and many others may also need to do so.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/96queue2: incorrect current-level-time reported after seek (with packetized data)2018-11-05T08:29:36ZBugzilla Migration Userqueue2: incorrect current-level-time reported after seek (with packetized data)## Submitted by Aleksander Wabik
**[Link to original bug (#744587)](https://bugzilla.gnome.org/show_bug.cgi?id=744587)**
## Description
Created attachment 296913
The testcase
Steps to reproduce the bug:
1) Have a queue2 ...## Submitted by Aleksander Wabik
**[Link to original bug (#744587)](https://bugzilla.gnome.org/show_bug.cgi?id=744587)**
## Description
Created attachment 296913
The testcase
Steps to reproduce the bug:
1) Have a queue2 element,
2) Send SEGMENT (GST_FORMAT_TIME) event with non-zero start/position/time.
3) Start pushing buffers with PTSes starting at 0 to the queue.
Effects:
1) As soon the queue obtains buffers with valid in-segment PTS, it reports buffered time level correctly,
2) As soon the queue pushes first buffer with PTS < segment.start to the srcpad, the queue stops reporting buffered time level correctly, it reports 0 buffered.
This is caused by rewriting src_segment.position with buffer's PTS, and then gst_segment_to_running_time() returns GST_CLOCK_TIME_NONE.
At this point, if we have a very fast source element, and a very slow decoder, the decoder may block on the first frame (with PTS below segment start) for quite a long time (especially if it's a software decoder decoding 1080p HEVC or VP9 frame). In this time, the queue reports current-level-time == 0, and what's worse, if the queue has buffer & byte limits 0, and only the time limit set, fast source may push megabytes of data, tens of seconds of data, even though the limit may be 0.5 seconds. The queue will not block, as it thinks it's 0% filled.
Additional bug (fixed by the same fix): some streams have non-monotonic PTSes. Push buffer with PTS=1s, duration=1s, and then push buffer with PTS=0s, duration=1s. The queue has now 2 seconds of data buffered, but it will report only one second.
I am attaching the extended unit tests for queue2 element that demonstrate both these problems.
~~**Patch 296913**~~, "The testcase":
[patch1-queue2-testcase.patch](/uploads/45ddd0f507d0096b9ec0cbeea377265c/patch1-queue2-testcase.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/95baseparse: no duration set on buffers2022-11-10T09:20:45ZBugzilla Migration Userbaseparse: no duration set on buffers## Submitted by Aleksander Wabik
**[Link to original bug (#744399)](https://bugzilla.gnome.org/show_bug.cgi?id=744399)**
## Description
Bug summary:
1) have a source that outputs packetised h264 data with proper DTS, PTS and DURAT...## Submitted by Aleksander Wabik
**[Link to original bug (#744399)](https://bugzilla.gnome.org/show_bug.cgi?id=744399)**
## Description
Bug summary:
1) have a source that outputs packetised h264 data with proper DTS, PTS and DURATION set on buffers, but no framerate in the caps,
2) seek to such a place that the key frame is several seconds before the seek position,
3) the baseparse resets DURATION on the buffers, output of the baseparse does not contain DURATION
4) the gstvideodecoder, because of the lack of duration and lack of framerate, will incorrectly clip the buffers to segment, making the key frame's PTS equal to segment start
5) the sink prerolls the key frame instead of dropping it.
6) additional damage in PAUSED state: queue still thinks that it has 0% buffered, because time of the last output buffer was outside of the segment.
I am sorry for not providing any testcase - I'm working on a proprietary player, and playing very specific streams, I was not able yet to plug in gdppay for dumping data :( Please verify if what I write here makes sense, I hope that even without a testcase this analysis is clear. If I manage, I'll add some test case later.
The whole pipeline looks like this:
custom_source ! queue2 use-buffering=true use-rate-estimate=false max-size-buffers=0 max-size-bytes=0 max-size-time=0.5*GST_SECOND ! h264parse ! libav_h264dec ! sink
The source works in GST_FORMAT_TIME. It pushes proper buffers with PTS, DTS and DURATION set. Caps are: video/x-h264, stream-format=byte-stream, alignment=au (no framerate provided).
The pipeline is in GST_STATE_PAUSED and the seek to 17 seconds is performed. The key frame is in PTS about 15 seconds, and the source starts giving data starting with that key frame.
The queue2 does not report any buffering (other than 0%), as the pushed buffers have timestamps` ~15`, that is below segment's start (17), and gst_segment_to_running_time() returns -1.
gst_base_parse_chain() performs this:
data = gst_adapter_map (parse->priv->adapter, av);
/* arrange for actual data to be copied if subclass tries to,
* since what is passed is tied to the adapter */
tmpbuf = gst_buffer_new_wrapped_full (GST_MEMORY_FLAG_READONLY |
GST_MEMORY_FLAG_NO_SHARE, (gpointer) data, av, 0, av, NULL, NULL);
/* already inform subclass what timestamps we have planned,
* at least if provided by time-based upstream */
if (parse->priv->upstream_format == GST_FORMAT_TIME) {
GST_BUFFER_PTS (tmpbuf) = parse->priv->next_pts;
GST_BUFFER_DTS (tmpbuf) = parse->priv->next_dts;
}
/* keep the adapter mapped, so keep track of what has to be flushed */
ret = gst_base_parse_handle_buffer (parse, tmpbuf, &skip, &flush);
The parser does set proper PTS and DTS on the buffer, but does not set DURATION (although all input buffers contained proper DURATION). This is also visible in the log:
gst_pad_chain_data_unchecked:<h264parse0:sink> calling chainfunction &gst_base_parse_chain with buffer buffer: 0x1c5d316d0880, pts 0:00:15.348688000, dts 0:00:15.390400000, dur 0:00:00.041711000, size 1180, offset 18446744073709551615, offset_end 18446744073709551615, flags 0x0
gst_base_parse_handle_buffer:`<h264parse0>` handling buffer of size 5737 with dts 0:00:15.348688000, pts 0:00:15.390400000, duration 99:99:99.999999999
In the decoder, the GstVideoCodecFrames do not contain proper duration. The log that I got from the GstVideoDecoder element:
gst_video_decoder_prepare_finish_frame:`<avdec_h264-1>` sync timestamp 0:00:15.015000000 diff 5124095:34:31.724551616
It obtained a buffer with PTS=15 seconds. The diff is calculated as frame->pts - decoder->output_segment.start, so it is negative, so it's logged as some large value. Then, in gst_video_decoder_prepare_finish_frame:
if (frame->duration == GST_CLOCK_TIME_NONE) {
frame->duration = gst_video_decoder_get_frame_duration (decoder, frame);
GST_LOG_OBJECT (decoder,
"Guessing duration %" GST_TIME_FORMAT " for frame...",
GST_TIME_ARGS (frame->duration));
}
Since the frame->duration is NONE, and the caps did not contain framerate (and the parser inserted 0/1 framerate to the caps then so gst_video_decoder_get_frame_duration() also returns NONE), the frame->duration will remain NONE. And I have that logged too:
gst_video_decoder_prepare_finish_frame:`<avdec_h264-1>` Guessing duration 99:99:99.999999999 for frame...
Then the gst_video_decoder_clip_and_push_buf() is called, and it finalizes the bug by rewriting buffer's PTS to 17 seconds (although the PTS was in 15 seconds):
gst_video_decoder_clip_and_push_buf:`<avdec_h264-1>` accepting buffer inside segment: 0:00:17.000000000 0:00:16.999999999 seg 0:00:17.000000000 to 99:99:99.999999999 time 0:00:17.000000000
gst_video_decoder_clip_and_push_buf:`<avdec_h264-1>` pushing buffer 0x25fef38a6610 of size 443520, PTS 0:00:17.000000000, dur 99:99:99.999999999
You can see in the log that GST_TIME_ARGS (GST_BUFFER_PTS (buf)) was logged as 0:00:17.000000000, and GST_TIME_ARGS (GST_BUFFER_PTS (buf) + GST_BUFFER_DURATION (buf)) was logged as 0:00:16.999999999 (because DURATION is still -1!). Why was the PTS incorrectly rewritten:
duration = GST_BUFFER_DURATION (buf);
[...]
stop = GST_CLOCK_TIME_NONE;
if (GST_CLOCK_TIME_IS_VALID (start) && GST_CLOCK_TIME_IS_VALID (duration)) {
stop = start + duration;
}
segment = &decoder->output_segment;
if (gst_segment_clip (segment, GST_FORMAT_TIME, start, stop, &cstart, &cstop))
The duration is not valid, stop remains GST_CLOCK_TIME_NONE, so finally, gst_segment_clip() obtains:
segment.start=17*GST_SECOND
segment.stop=-1,
start=15*GST_SECOND,
stop=-1,
and with such data, cstart will be set to segment.start, cstop to segment.stop, and gst_segment_clip() returns TRUE.
The buffer with PTS 15, in a segment that starts in 17, eventually gets to the sink and is prerolled. Since the pipeline's state is PAUSED, no more buffers will flow. No buffer flow on the queue2 srcpad will make it impossible for queue2 to calculate correct srctime, so queue2 would never report buffering with percent>0, and the application (which uses queue2 to ensure fluent playback) will never put the pipeline to PLAYNIG state.
This bug can be mitigated by adding framerate to caps, but such a solution would be inferior to just fixing the baseparse, because the application has no knowledge of the framerate of the stream. It knows only the durations of all buffers, so it would have to calculate framerate and update it every time the buffer duration changes.
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/94queue/queue2/multiqueue: LATENCY query handling could be improved2022-11-10T09:20:45ZBugzilla Migration Userqueue/queue2/multiqueue: LATENCY query handling could be improved## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#744337)](https://bugzilla.gnome.org/show_bug.cgi?id=744337)**
## Description
+++ This bug was initially created as a clone of [Bug 744106](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#744337)](https://bugzilla.gnome.org/show_bug.cgi?id=744337)**
## Description
+++ This bug was initially created as a clone of [Bug 744106](https://bugzilla.gnome.org/show_bug.cgi?id=744106) +++
queue should try to use the CONVERT query, or estimate the buffer/byte rate over time and update its min/max latencies from its max-size-* and min-size-* properties.
queue2 and multiqueue should do the same, but currently they don't even do that for the time limits.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/93bufferpool: Don't free GstBuffer if memory isn't writable2022-11-10T09:20:45ZBugzilla Migration Userbufferpool: Don't free GstBuffer if memory isn't writable## Submitted by kevin
**[Link to original bug (#744303)](https://bugzilla.gnome.org/show_bug.cgi?id=744303)**
## Description
GstBuffer will be freed if memory isn't writable. The reason of the memory can't writable is gst_buffer_cop...## Submitted by kevin
**[Link to original bug (#744303)](https://bugzilla.gnome.org/show_bug.cgi?id=744303)**
## Description
GstBuffer will be freed if memory isn't writable. The reason of the memory can't writable is gst_buffer_copy_into() will increase the ref count of the memory. The expect is reuse video buffer without free it. The buffer will writable later. Do we have some general solution for it?
I have asked the question in gstreamer-dev mail list:
http://lists.freedesktop.org/archives/gstreamer-devel/2015-January/051137.html
Version: 1.4.1https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/92gst-plugin-scanner should show the plugin emitting errors and warnings2021-09-24T11:11:05ZBugzilla Migration Usergst-plugin-scanner should show the plugin emitting errors and warnings## Submitted by Pacho Ramos
**[Link to original bug (#744134)](https://bugzilla.gnome.org/show_bug.cgi?id=744134)**
## Description
Created attachment 296333
build.log
On Gentoo we run compilations inside a sandbox system to p...## Submitted by Pacho Ramos
**[Link to original bug (#744134)](https://bugzilla.gnome.org/show_bug.cgi?id=744134)**
## Description
Created attachment 296333
build.log
On Gentoo we run compilations inside a sandbox system to prevent unwanted access to files and devices from "real" system. That way, we are getting now errors as gst-plugin-scanner wants to access to /dev/video0 directly.
Probably this access is due to a plugin loaded by gst-plugin-scanner but, as it doesn't show any more output than:
(gst-plugin-scanner:23320): Clutter-CRITICAL **: Unable to initialize Clutter: Unable to open display ':0'
(gst-plugin-scanner:23320): GStreamer-CRITICAL **: gst_structure_new_empty: assertion 'gst_structure_validate_name (name)' failed
* ACCESS DENIED: open_wr: /dev/video0
It's near impossible to know what plugin is causing this issue
The attached full build.log is from farstream-0.2.6, whose building calls gst-plugin-scanner and hits this problem
Thanks a lot
**Attachment 296333**, "build.log":
[farstream-0.2.6_20150207-171549.log](/uploads/793dc610dc437c8b596b22ebb20a1f13/farstream-0.2.6_20150207-171549.log)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/91bin: Deadlock when sending event2021-09-24T11:11:06ZBugzilla Migration Userbin: Deadlock when sending event## Submitted by Jan Schmidt `@thaytan`
**[Link to original bug (#744040)](https://bugzilla.gnome.org/show_bug.cgi?id=744040)**
## Description
Encountered a locking order problem while doing some playing around in the playback test ...## Submitted by Jan Schmidt `@thaytan`
**[Link to original bug (#744040)](https://bugzilla.gnome.org/show_bug.cgi?id=744040)**
## Description
Encountered a locking order problem while doing some playing around in the playback test app: A flush occuring during a step leads to a basesink deadlock.
The sink element is posting STEP_DONE, holding the STREAM_LOCK. The app sends a new step event from the sync bus handler, which tries to take the STATE_LOCK.
Meanwhile, the app has sent a flushing seek, which is holding the STATE_LOCK, and trying to acquire the STREAM_LOCK.
It seems either basesink should drop the stream lock while sending the STEP_DONE message, or the app should not send the new step event from the sync bus message handler, I'm not sure which.
```
Thread 13 (Thread 0x7ff135534700 (LWP 30991)):
#0 0x0000003907e0ef1d in __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x0000003907e09906 in __GI___pthread_mutex_lock (mutex=0x1a10c00) at ../nptl/pthread_mutex_lock.c:115
#2 0x00007ff13d8a4645 in gst_element_send_event (element=0x19cb040 [GstPlayBin], event=0x7ff1280050b0) at gstelement.c:1557
#3 0x000000000040b00d in do_shuttle (app=app@entry=0x7fff95060af0) at playback-test.c:1559
#4 0x000000000040d8c8 in msg_sync_step_done (bus=<optimized out>, message=<optimized out>, app=0x7fff95060af0)
at playback-test.c:1585
#5 0x00000036f6012d13 in g_cclosure_marshal_VOID__BOXEDv (closure=0x1cf0820, return_value=<optimized out>, instance=<optimized out>, args=<optimized out>, marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x175bee0) at gmarshal.c:1160
#6 0x00000036f600feb2 in _g_closure_invoke_va (closure=closure@entry=0x1cf0820, return_value=return_value@entry=0x0, instance=instance@entry=0x186a2c0, args=args@entry=0x7ff135532db0, n_params=1, param_types=0x175bee0) at gclosure.c:831
#7 0x00000036f6029b60 in g_signal_emit_valist (instance=0x186a2c0, signal_id=<optimized out>, detail=267, var_args=var_args@entry=0x7ff135532db0) at gsignal.c:3218
#8 0x00000036f602a3af in g_signal_emit (instance=instance@entry=0x186a2c0, signal_id=<optimized out>, detail=<optimized out>)
at gsignal.c:3365
#9 0x00007ff13d88f12a in gst_bus_sync_signal_handler (bus=0x186a2c0 [GstBus], message=0x7ff11c1702c0, data=<optimized out>)
at gstbus.c:1197
#10 0x00007ff13d88f3c4 in gst_bus_post (bus=bus@entry=0x186a2c0 [GstBus], message=message@entry=0x7ff11c1702c0) at gstbus.c:329
#11 0x00007ff13d8a1bf8 in gst_element_post_message_default (element=element@entry=0x19cb040 [GstPlayBin], message=0x7ff11c1702c0)
at gstelement.c:1688
#12 0x00007ff13d883c4f in gst_bin_post_message (element=0x19cb040 [GstPlayBin], msg=0x7ff11c1702c0) at gstbin.c:2523
#13 0x00007ff13d883f79 in gst_bin_handle_message_func (bin=0x19cb040 [GstPlayBin], message=<optimized out>) at gstbin.c:3745
#14 0x00007ff13d8c4939 in gst_pipeline_handle_message (bin=0x19cb040 [GstPlayBin], message=0x7ff11c1702c0) at gstpipeline.c:574
#15 0x00007ff136247ca5 in gst_play_bin_handle_message (bin=0x19cb040 [GstPlayBin], msg=0x7ff11c1702c0) at gstplaybin2.c:2912
#16 0x00007ff13d880828 in bin_bus_handler (bus=bus@entry=0x186a1f0 [GstBus], message=message@entry=0x7ff11c1702c0, bin=bin@entry=0x19cb040 [GstPlayBin]) at gstbin.c:2981
#17 0x00007ff13d88f39b in gst_bus_post (bus=bus@entry=0x186a1f0 [GstBus], message=message@entry=0x7ff11c1702c0) at gstbus.c:323
#18 0x00007ff13d8a1bf8 in gst_element_post_message_default (element=element@entry=0x1b06020 [GstPlaySink], message=0x7ff11c1702c0)
at gstelement.c:1688
#19 0x00007ff13d883c4f in gst_bin_post_message (element=0x1b06020 [GstPlaySink], msg=0x7ff11c1702c0) at gstbin.c:2523
---Type <return> to continue, or q <return> to quit---
#20 0x00007ff13d883f79 in gst_bin_handle_message_func (bin=0x1b06020 [GstPlaySink], message=<optimized out>) at gstbin.c:3745
#21 0x00007ff13624ce30 in gst_play_sink_handle_message (bin=0x1b06020 [GstPlaySink], message=0x7ff11c1702c0) at gstplaysink.c:4632
#22 0x00007ff13d880828 in bin_bus_handler (bus=bus@entry=0x186a390 [GstBus], message=message@entry=0x7ff11c1702c0, bin=bin@entry=0x1b06020 [GstPlaySink]) at gstbin.c:2981
#23 0x00007ff13d88f39b in gst_bus_post (bus=bus@entry=0x186a390 [GstBus], message=message@entry=0x7ff11c1702c0) at gstbus.c:323
#24 0x00007ff13d8a1bf8 in gst_element_post_message_default (element=element@entry=0x7ff12000f790 [GstBin], message=0x7ff11c1702c0)
at gstelement.c:1688
#25 0x00007ff13d883c4f in gst_bin_post_message (element=0x7ff12000f790 [GstBin], msg=0x7ff11c1702c0) at gstbin.c:2523
#26 0x00007ff13d883f79 in gst_bin_handle_message_func (bin=0x7ff12000f790 [GstBin], message=<optimized out>) at gstbin.c:3745
#27 0x00007ff13d880828 in bin_bus_handler (bus=bus@entry=0x7ff120010230 [GstBus], message=message@entry=0x7ff11c1702c0, bin=bin@entry=0x7ff12000f790 [GstBin]) at gstbin.c:2981
#28 0x00007ff13d88f39b in gst_bus_post (bus=bus@entry=0x7ff120010230 [GstBus], message=message@entry=0x7ff11c1702c0) at gstbus.c:323
#29 0x00007ff13d8a1bf8 in gst_element_post_message_default (element=0x7ff124049a10 [GstXvImageSink], message=0x7ff11c1702c0)
at gstelement.c:1688
#30 0x00007ff13de482d7 in stop_stepping (sink=sink@entry=0x7ff124049a10 [GstXvImageSink], segment=segment@entry=0x7ff124049b68, current=current@entry=0x7ff124049918, rstart=<optimized out>, rstop=16605853000, eos=0) at gstbasesink.c:1694
#31 0x00007ff13de52def in gst_base_sink_chain_unlocked (basesink=basesink@entry=0x7ff124049a10 [GstXvImageSink], obj=obj@entry=0x7ff11c3541c0, is_list=is_list@entry=0, pad=<optimized out>) at gstbasesink.c:3457
#32 0x00007ff13de544a4 in gst_base_sink_chain_main (basesink=0x7ff124049a10 [GstXvImageSink], pad=<optimized out>, obj=0x7ff11c3541c0, is_list=0) at gstbasesink.c:3547
#33 0x00007ff13d8ba704 in gst_pad_push_data (data=0x7ff11c3541c0, type=4112, pad=0x7ff124040340 [GstPad]) at gstpad.c:3838
Thread 1 (Thread 0x7ff13d832980 (LWP 30975)):
#0 0x0000003907e0ef1d in __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x0000003907e09906 in __GI___pthread_mutex_lock (mutex=0x7ff124048ce0) at ../nptl/pthread_mutex_lock.c:115
#2 0x00007ff13de4bc52 in gst_base_sink_flush_start (basesink=basesink@entry=0x7ff124049a10 [GstXvImageSink], pad=0x7ff124040340 [GstPad]) at gstbasesink.c:2910
#3 0x00007ff13de4c1c1 in gst_base_sink_default_event (basesink=0x7ff124049a10 [GstXvImageSink], event=0x7ff12009f020)
at gstbasesink.c:3001
#4 0x00007ff134281ac7 in gst_xvimagesink_event (sink=0x7ff124049a10 [GstXvImageSink], event=0x7ff12009f020) at xvimagesink.c:1036
#5 0x00007ff13d8b8ff8 in gst_pad_send_event_unchecked (pad=pad@entry=0x7ff124040340 [GstPad], event=event@entry=0x7ff12009f020, type=type@entry=320) at gstpad.c:5157
#6 0x00007ff13d8b96cf in gst_pad_push_event_unchecked (pad=pad@entry=0x1d4b600 [GstGhostPad], event=event@entry=0x7ff12009f020, type=320, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at gstpad.c:4844
#7 0x00007ff13d8c24a4 in gst_pad_push_event (pad=pad@entry=0x1d4b600 [GstGhostPad], event=0x7ff12009f020) at gstpad.c:4975
#8 0x00007ff13d8c27f3 in event_forward_func (pad=pad@entry=0x1d4b600 [GstGhostPad], data=data@entry=0x7fff95059880) at gstpad.c:2849
#9 0x00007ff13d8bf5ae in gst_pad_forward (pad=pad@entry=0x7ff12801d930 [GstProxyPad], forward=forward@entry=0x7ff13d8c2730 <event_forward_func>, user_data=user_data@entry=0x7fff95059880) at gstpad.c:2803
#10 0x00007ff13d8bf6db in gst_pad_event_default (pad=pad@entry=0x7ff12801d930 [GstProxyPad], parent=parent@entry=0x1d4b600 [GstGhostPad], event=event@entry=0x7ff12009f020) at gstpad.c:2900
#11 0x00007ff13d8b8ff8 in gst_pad_send_event_unchecked (pad=pad@entry=0x7ff12801d930 [GstProxyPad], event=event@entry=0x7ff12009f020, type=type@entry=320) at gstpad.c:5157
#12 0x00007ff13d8b96cf in gst_pad_push_event_unchecked (pad=pad@entry=0x7ff1200a36d0 [GstPad], event=event@entry=0x7ff12009f020, type=320, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at gstpad.c:4844
#13 0x00007ff13d8c24a4 in gst_pad_push_event (pad=0x7ff1200a36d0 [GstPad], event=event@entry=0x7ff12009f020) at gstpad.c:4975
#14 0x00007ff13de628a6 in gst_base_transform_sink_eventfunc (trans=0x7ff11c15c4d0 [GstVideoConvert], event=0x7ff12009f020)
at gstbasetransform.c:1923
```
### Depends on
* #150https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/90Changing bin state to NULL fails when there is a locked child which is locked2021-09-24T11:11:06ZBugzilla Migration UserChanging bin state to NULL fails when there is a locked child which is locked## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#743719)](https://bugzilla.gnome.org/show_bug.cgi?id=743719)**
## Description
If a pipeline (or any bin) has a child which has it's state locked and it's last transiti...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#743719)](https://bugzilla.gnome.org/show_bug.cgi?id=743719)**
## Description
If a pipeline (or any bin) has a child which has it's state locked and it's last transition was a failure, then the pipeline/bin transition to the NULL state will fail. But it is my understanding that gst_element_set_state(GST_STATE_NULL) should never fail.
I'm attaching a patch that just transforms failure into success in the locked case if the target is READY or NULL.
Python test program:
import sys
Gst.init(sys.argv)
p = Gst.Pipeline()
p.set_state(Gst.State.PLAYING)
s = Gst.ElementFactory.make("filesrc", None)
p.add(s)
s.set_locked_state(True)
s.set_state(Gst.State.PLAYING)
print p.set_state(Gst.State.NULL)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/89Forward scheduling query to a peer pad on multiqueue and baseparse2022-11-10T09:20:45ZBugzilla Migration UserForward scheduling query to a peer pad on multiqueue and baseparse## Submitted by HoonHee Lee
**[Link to original bug (#743639)](https://bugzilla.gnome.org/show_bug.cgi?id=743639)**
## Description
Created attachment 295644
Forward scheduling query to a peer pad on multiqueue and baseparse
...## Submitted by HoonHee Lee
**[Link to original bug (#743639)](https://bugzilla.gnome.org/show_bug.cgi?id=743639)**
## Description
Created attachment 295644
Forward scheduling query to a peer pad on multiqueue and baseparse
Decoder element demands to know about scheduling flags such as
bandwidthlimited is enabled or not.
In our product environment, our decoder element which uses H/W resources wants to know in playbin pipeline that it is streaming case or not.
Our approach is that to use a scheduling query likes uridecodebin for deploying typefind and Q2.
But, we encountered a problem that scheduling query is not forwarding to a source element such as souphttpsrc.
We reviewed the log and found out that baseparse and multiqueue are not forwarding it to a peerpad because of 'gst_pad_query_default' handler with GST_PAD_FALG_PROXY_SCHEDULING.
========================================
0:00:00.690352917 2581 0x7280a6f0 DEBUG GST_PADS gstpad.c:3028:gst_pad_query_default:<multiqueue0:src_1> not forwarding 0x71e0df20 (scheduling) query
0:00:00.896709625 2581 0x71e0e000 DEBUG GST_PADS gstpad.c:3028:gst_pad_query_default:<h264parse0:src> not forwarding 0x713080f0 (scheduling) query
========================================
Could you explain why it is not forwarding? it this a concept??
We hope that you would explain about it.
Thus, we implemented the scheduling query in multiqueue and baseparse.
Anyway, please check and review it.
**Patch 295644**, "Forward scheduling query to a peer pad on multiqueue and baseparse":
[0001-Forward-scheduling-query-to-a-peer-pad-on-multiqueue.patch](/uploads/f52637e4bdb3e664a68eeff5d5d34410/0001-Forward-scheduling-query-to-a-peer-pad-on-multiqueue.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/88Add new control binding GstAppControlBinding2022-11-10T09:20:45ZBugzilla Migration UserAdd new control binding GstAppControlBinding## Submitted by Heinrich Fink `@heinrich.fink`
**[Link to original bug (#743248)](https://bugzilla.gnome.org/show_bug.cgi?id=743248)**
## Description
Created attachment 295004
patch
GstAppControlBinding is a new GstControlBin...## Submitted by Heinrich Fink `@heinrich.fink`
**[Link to original bug (#743248)](https://bugzilla.gnome.org/show_bug.cgi?id=743248)**
## Description
Created attachment 295004
patch
GstAppControlBinding is a new GstControlBinding subclass that emits a signal ('update-value') in order to update the value of its bound property. This allows applications to connect to this signal and to set controllable properties along the time-line, without being tied to GstControlSource / GstDirectControlBinding. A patch of a first implementation, including basic unit tests and documentation is provided.
Example use case:
A live mixing application uses compositor/glvideomixer to animate multiple video layers along an application-defined time-line. This is done by setting the properties xpos/ypos/width/height of compositor's sink pads accordingly. Using GstControlSource / GstDirectControlBinding doesn't work here because:
-) 0..1 sources would be mapped to the full property range. That doesn't really make sense for properties using pixel coordinates (e.g. xpos/ypos/width/height).
-) Since this a *live* mixing application, changes of a video layer's properties (i.e. sink pad's xpos/ypos/width/height properties) need to have immediate effect (e.g. animating a transition based on real-time user input). One could try to just set xpos/ypos/width/height using a single g_object_set call, but since this is not guaranteed to be atomic, this could result in one frame to already have updated xpos/ypos values, but not yet updated width/height values, resulting in undesired animation artefacts. Using GstAppControlBinding, the application simply binds to xpos/ypos/width/height, which results in the signal being emitted before each rendered frame for all bound properties. The application could then make sure that the right xpos/ypos/width/height tuple is used for the requested render time.
Further remarks:
(1) Since GstAppControlBinding does have to map GstControlSource's 0..1 value to something useful (like GstDirectControlBinding does), we could support further PARAM_SPEC types (like strings, chars, whatever). However, until a good use case for this comes up, GstAppControlBinding only supports the same types as GstDirectControlBinding.
(2) The performance of the installed signal ('update-value') might be improved by passing more advanced flags to g_signal_new (accumulators, etc). Out of my lacking experience with this, I have only installed a basic signal for now.
(3) If GstAppControlBinding is asked for an array of values, it is currently emitting multiple signals, for each time-sample of the requested array, in order to fill the array. This could be optimized by using another signal that returns an array of GValues instead of just a single GValue.
(4) The GValue instance returned by the 'update-value' signal is currently expected to hold the same type as the bound property. Alternatively, type conversion could be attempted, if supported.
(5) Similar to GstDirectControlBinding, GstAppControlBinding does not set the target property, if the value hasn't changed.
(6) I tried to extend the documentation to document GstAppControlBinding, I hope I haven't missed anything :)
(7) Credits: I have added Stefan Sauer (ensonic) to the license headers, because most of the code was based on his GstDirectControlBinding implementation, and I have also added Sebastian Dröge (slomo), because GstAppControlBinding was his idea.
I am looking forward to your feedback!
~~**Patch 295004**~~, "patch":
[0001-gstreamer-Add-new-binding-GstAppControlBinding.patch](/uploads/9fac89dd01b7a11bc423d41955f47456/0001-gstreamer-Add-new-binding-GstAppControlBinding.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/87Permit missing codec installation when GST_REGISTRY_UPDATE=no2022-11-10T09:20:45ZBugzilla Migration UserPermit missing codec installation when GST_REGISTRY_UPDATE=no## Submitted by Michael Catanzaro `@mcatanzaro`
**[Link to original bug (#742617)](https://bugzilla.gnome.org/show_bug.cgi?id=742617)**
## Description
It would be nice for gstreamer to detect the presence of new plugins even when ru...## Submitted by Michael Catanzaro `@mcatanzaro`
**[Link to original bug (#742617)](https://bugzilla.gnome.org/show_bug.cgi?id=742617)**
## Description
It would be nice for gstreamer to detect the presence of new plugins even when running with GST_REGISTRY_UPDATE=no, which we're going to need to use to sandbox the web process in WebKitGTK+. Otherwise, I think we'll need to restart our web processes when a plugin is installed.
slomo: restarting the web process can be prevented with some changes in gstreamer though
slomo: gstreamer/gst/gstregistry.c, gst_update_registry() -> ensure_current_registry() is the interesting part
slomo: basically you need a way to set _gst_disable_registry_cache to FALSE again
slomo: assuming that code can actually be called twice, otherwise that needs to be fixed too
slomo: maybe it should actually be always called again
Version: 1.4.5
### See also
* https://bugs.webkit.org/show_bug.cgi?id=140131
* https://bugs.webkit.org/show_bug.cgi?id=146993https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/86RFC: gst-launch/gst-inspect support for presets2019-12-30T16:53:24ZBugzilla Migration UserRFC: gst-launch/gst-inspect support for presets## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#741427)](https://bugzilla.gnome.org/show_bug.cgi?id=741427)**
## Description
Hi,
gst-inspect could list the preset names if an element implements the preset iface...## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#741427)](https://bugzilla.gnome.org/show_bug.cgi?id=741427)**
## Description
Hi,
gst-inspect could list the preset names if an element implements the preset iface.
gst-launch could support a 'special' property called "@preset" to load a preset. e.g.
gst-launch uridecodebin uri="..." ! equalizer @preset="disco" ! ...
The rational for "@preset" is that it would not clash with other properties. Better ideas are welcome. if it sounds like a plan, I have a xmas vacation project :)
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/85gstpluginfeature: Properly expose the class.2021-09-24T11:11:08ZBugzilla Migration Usergstpluginfeature: Properly expose the class.## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#741260)](https://bugzilla.gnome.org/show_bug.cgi?id=741260)**
## Description
To allow external applications libraries to implement
their own factory.
+ Impl...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#741260)](https://bugzilla.gnome.org/show_bug.cgi?id=741260)**
## Description
To allow external applications libraries to implement
their own factory.
+ Implements getters and setters for priv->plugin and priv->loaded.
### Blocking
* [Bug 742610](https://bugzilla.gnome.org/show_bug.cgi?id=742610)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/84valve drop=true doesn't allow EOS to flow downstream.2020-09-09T06:49:57ZBugzilla Migration Uservalve drop=true doesn't allow EOS to flow downstream.## Submitted by Keith Thornton `@Keith`
**[Link to original bug (#740432)](https://bugzilla.gnome.org/show_bug.cgi?id=740432)**
## Description
The following pipeline hangs after all frames have flowed. This is probably because valve...## Submitted by Keith Thornton `@Keith`
**[Link to original bug (#740432)](https://bugzilla.gnome.org/show_bug.cgi?id=740432)**
## Description
The following pipeline hangs after all frames have flowed. This is probably because valve drop=true doesn't pass the EOS event downstream.
gst-launch-1.0.exe -v videotestsrc do-timestamp=true pattern=snow is-live=true num-buffers=90 !video/x-raw,width=1920,height=1080,framerate=30000/1001,format=YV12 ! tee name=t1 ! queue name=displ -queue max-size-bytes=0 leaky=2 ! valve name=display-valve drop=true ! glimagesink sync=false async=false t1. ! queue name=encode-queue max-size-bytes=124416000 ! valve name=encode-valve drop=false ! x264enc bittrate=32768 ! h264parse ! qtmux ! filesink location="f:/temp/out.mp4"https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/83tests: add unit test to show how a custom buffer pool can insert memory in a ...2022-11-10T09:20:45ZBugzilla Migration Usertests: add unit test to show how a custom buffer pool can insert memory in a buffer## Submitted by Benjamin Gaignard
**[Link to original bug (#740273)](https://bugzilla.gnome.org/show_bug.cgi?id=740273)**
## Description
Created attachment 290866
custom buffer pool unitary test
This unitary test perform the ...## Submitted by Benjamin Gaignard
**[Link to original bug (#740273)](https://bugzilla.gnome.org/show_bug.cgi?id=740273)**
## Description
Created attachment 290866
custom buffer pool unitary test
This unitary test perform the same check than gstbufferpool test but use a custom pool allocation function to add memory in a new buffer.
Nothing revolutionary here but it could be an example of how manage memory insertion in custom buffer pool.
**Patch 290866**, "custom buffer pool unitary test":
[0002-add-custom-buffer-pool.patch](/uploads/4849253f00698ca03e4849756199f1f8/0002-add-custom-buffer-pool.patch)
Version: 1.4.3https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/82baseparse: Add support to skip padding areas in segments2022-11-10T09:20:44ZBugzilla Migration Userbaseparse: Add support to skip padding areas in segments## Submitted by Carlos Rafael Giani
**[Link to original bug (#740196)](https://bugzilla.gnome.org/show_bug.cgi?id=740196)**
## Description
Created attachment 290777
Patch for new adjust_segment vfunc
Useful if the subclass ne...## Submitted by Carlos Rafael Giani
**[Link to original bug (#740196)](https://bugzilla.gnome.org/show_bug.cgi?id=740196)**
## Description
Created attachment 290777
Patch for new adjust_segment vfunc
Useful if the subclass needs to adjust the segment further before it is sent, for example to exclude padding areas.
In particular, this patch will be necessary for another patch in -good for getting gapless playback in the mpegaudioparse working. The information in the LAME tag is used to adjust the segment with this new vfunc.
~~**Patch 290777**~~, "Patch for new adjust_segment vfunc":
[0001-baseparse-add-vfunc-to-adjust-output-segment.patch](/uploads/4a4b8f48fde6beb3159ce2b46b255ad8/0001-baseparse-add-vfunc-to-adjust-output-segment.patch)
### Blocking
* [Bug 620323](https://bugzilla.gnome.org/show_bug.cgi?id=620323)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/81Race condition leads to missing ASYNC_DONE bus messages when seeking2022-11-10T09:20:44ZBugzilla Migration UserRace condition leads to missing ASYNC_DONE bus messages when seeking## Submitted by Alex
**[Link to original bug (#740121)](https://bugzilla.gnome.org/show_bug.cgi?id=740121)**
## Description
After calling gst_element_send_event to do a flushing seek, GST_MESSAGE_ASYNC_DONE should be received on the...## Submitted by Alex
**[Link to original bug (#740121)](https://bugzilla.gnome.org/show_bug.cgi?id=740121)**
## Description
After calling gst_element_send_event to do a flushing seek, GST_MESSAGE_ASYNC_DONE should be received on the bus. Usually, this happens, however sometimes the message is never received. Enabling a lot of logging makes this occur much more frequently. This is a blocker because if an application does a lot of seeking (such as scrubbing with a slider), and waits for the ASYNC_DONE message before proceeding, it will eventually deadlock. This makes seeking unusable.
I don't think this bug existed with 0.10.
The following bug might have the same underlying cause: https://bugzilla.gnome.org/show_bug.cgi?id=734060
To reproduce, run the code attached (change line 165 to point to an existing video of your choice that supports seeking). It will most likely run to the end and then crash (proper cleanup code and most error checking has been removed to prune down the example). Then run it again with GST_DEBUG=3,GST_STATES:4,myplugin:9 - this time it will probably deadlock after 1 seek.
Version: 1.4.4
### See also
* [Bug 796737](https://bugzilla.gnome.org/show_bug.cgi?id=796737)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/80gstreamer tools should support bash autocompletion2021-09-24T11:41:35ZBugzilla Migration Usergstreamer tools should support bash autocompletion## Submitted by Julien Isorce `@cap`
**[Link to original bug (#740108)](https://bugzilla.gnome.org/show_bug.cgi?id=740108)**
## Description
Examples:
- gst-launch ... ! avdec_ + tab should suggest the available avdec decoders....## Submitted by Julien Isorce `@cap`
**[Link to original bug (#740108)](https://bugzilla.gnome.org/show_bug.cgi?id=740108)**
## Description
Examples:
- gst-launch ... ! avdec_ + tab should suggest the available avdec decoders.
- gst-launch filesrc location=sample + tab should suggest available local files starting with "sample" in current directory. (was working on 0.10)
- gst-inspect matroskad + tab should complete to matroskademux.
It seems it was supported in the past but not maintained or ported at some point. If someone could point those old commits if exist, that would be great.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/79basesink: set the last position to minimum value after rewind2022-11-10T09:20:44ZBugzilla Migration Userbasesink: set the last position to minimum value after rewind## Submitted by Myoungsun Lee
**[Link to original bug (#739990)](https://bugzilla.gnome.org/show_bug.cgi?id=739990)**
## Description
Created attachment 290452
Set the last position to minimum value after rewind
Set the last p...## Submitted by Myoungsun Lee
**[Link to original bug (#739990)](https://bugzilla.gnome.org/show_bug.cgi?id=739990)**
## Description
Created attachment 290452
Set the last position to minimum value after rewind
Set the last position to minimum value after rewind
Overview:
Let's suppose the video file is encoded with wrong pts value
If we rewind this file and wait until the video play again at first,
then the basesink sets the last position to wrong value.
So in this case, basesink chooses the minimum value to set the last position.
Steps to Reproduce:
rewind the video and wait until it play again at start position.
Actual Results:
the play(current) time temporarily increases to the wrong position.
and play again at start.
Expected Results:
play well without increasing the play time to the wrong position.
~~**Patch 290452**~~, "Set the last position to minimum value after rewind":
[0001-basesink-set-the-last-position-to-minimum-value.patch](/uploads/43ea5bd6658196cd2a15133ab7e2582e/0001-basesink-set-the-last-position-to-minimum-value.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/78RFC: add API to GstPreset to compare presets2022-11-10T09:20:44ZBugzilla Migration UserRFC: add API to GstPreset to compare presets## Submitted by Stefan Kost `@ensonic`
Assigned to **Stefan Kost `@ensonic`**
**[Link to original bug (#739685)](https://bugzilla.gnome.org/show_bug.cgi?id=739685)**
## Description
Applications using the preset system will e.g. sh...## Submitted by Stefan Kost `@ensonic`
Assigned to **Stefan Kost `@ensonic`**
**[Link to original bug (#739685)](https://bugzilla.gnome.org/show_bug.cgi?id=739685)**
## Description
Applications using the preset system will e.g. show a list of presets and the properties of the element. When selecting a preset the properties get updated. When the user now edits the properties further, the user derives the preset.
It would be nice if the UI could check if the current settings are still equal to what was initially set by the preset and if not how they differ.
One way to do this could be a function in the preset iface that returns the distance between the current settings and a given preset. Patch follows.
Version: 1.x