At the moment, we can only use crank if the pending entry is in the
future. This patch leaves the clock time to the same point if the
pending entry was in the past. This still execute a single entry. This
will be needed for the jitterbuffer, since as soon as we stop waking up
the jitterbuffer when the timer is reschedule later, we may endup with
such case in the unit tests.
Related to #608
There was a race where we could still get the pad event function
called when its private member were already unset, leading to
a segfault in the event handler:
```
0 gst_multi_queue_src_event (pad=<optimized out>, parent=<optimized out>, event=0x7f3ff0007600) at ../subprojects/gstreamer/plugins/elements/gstmultiqueue.c:2534
2534 ret = gst_pad_push_event (sq->sinkpad, event);
[Current thread is 1 (Thread 0x7f406c0258c0 (LWP 21925))]
(gdb) bt
0 0x00007f4062ec1399 in gst_multi_queue_src_event (pad=<optimized out>, parent=<optimized out>, event=0x7f3ff0007600 [GstEvent]) at ../subprojects/gstreamer/plugins/elements/gstmultiqueue.c:2534
1 0x00007f406b40f46d in gst_validate_pad_monitor_src_event_check (handler=0x7f4062ec1360 <gst_multi_queue_src_event>, event=0x7f3ff0007600 [GstEvent], parent=0x7f3fcc01f090 [GstMultiQueue|multiqueue167], pad_monitor=0x7f3fe809e7c0 [GstValidatePadMonitor|validatepadmonitor2213]) at ../subprojects/gst-devtools/validate/gst/validate/gst-validate-pad-monitor.c:2101
2 0x00007f406b40f46d in gst_validate_pad_monitor_src_event_func (pad=<optimized out>, parent=0x7f3fcc01f090 [GstMultiQueue|multiqueue167], event=0x7f3ff0007600 [GstEvent]) at ../subprojects/gst-devtools/validate/gst/validate/gst-validate-pad-monitor.c:2374
3 0x00007f406b904387 in gst_pad_send_event_unchecked (pad=pad@entry=0x7f3fdc027650 [GstPad|src_0], event=event@entry=0x7f3ff0007600 [GstEvent], type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5772
4 0x00007f406b90481b in gst_pad_push_event_unchecked (pad=pad@entry=0x7f4058182fc0 [GstPad|sink], event=event@entry=0x7f3ff0007600 [GstEvent], type=type@entry=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5417
5 0x00007f406b90f016 in gst_pad_push_event (pad=0x7f4058182fc0 [GstPad|sink], event=event@entry=0x7f3ff0007600 [GstEvent]) at ../subprojects/gstreamer/gst/gstpad.c:5554
6 0x00007f406a1c99ba in gst_video_decoder_src_event_default (decoder=0x7f3fe81c6060 [GstTheoraDec|theoradec46], event=<optimized out>) at ../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:1532
7 0x00007f406b40f46d in gst_validate_pad_monitor_src_event_check (handler=0x7f406a1ca270 <gst_video_decoder_src_event>, event=0x7f3ff0007600 [GstEvent], parent=0x7f3fe81c6060 [GstTheoraDec|theoradec46], pad_monitor=0x7f4028163aa0 [GstValidatePadMonitor|validatepadmonitor2216]) at ../subprojects/gst-devtools/validate/gst/validate/gst-validate-pad-monitor.c:2101
8 0x00007f406b40f46d in gst_validate_pad_monitor_src_event_func (pad=<optimized out>, parent=0x7f3fe81c6060 [GstTheoraDec|theoradec46], event=0x7f3ff0007600 [GstEvent]) at ../subprojects/gst-devtools/validate/gst/validate/gst-validate-pad-monitor.c:2374
```
This make the GstSingleQueue a MiniObject, mainly so it is properly
refcounted.
This also make use of the GstMultiQueuePad class for srcpads which
is totally valid as srcpads and sinkpads share the same SingleQueue
object.
The `query` argument of gst_pad_query is "transfer none".
Query objects are "borrowed" by the pad query handlers and those
should never unref them.
This was leading to double freed queries in a very racy way with nested
GESTimelines.
By only having it on sinkpad-creation, it is racy to write a test
with a sometimes-pad (like a demuxer) that you want to pull from, having
the pull wait until the pad arrives and the buffer can be produced.
For the query function there's a risk that the function may be called
after the harness has been teared down. Since the function accesses a
pointer to the harness via the pad's data, the harness must protect
itself against this.
Event and chain function is also handled for constistency, although
they don't have the same problem since the gstpad.c checks whether the
pad is flushing before calling these.
This was a misguided effort to try and guarantee the buffers of
the sink pads would not change during aggregate, when an upstream
branch is seeked independently, however this is simply incorrect
as downstream has not necessarily been flushed, or the aggregate
function might be waiting to receive buffers on other pads.
In !159 , we switched to sending flush_start ourselves from the
do_seek implementation. If no flushing seek successfully made its
way upstream, we need to send flush_stop ourselves as well.
Releasing a GRecMutex from a different thread is undefined
behaviour.
There should be no reason to hold the stream lock from the
moment aggregator receives a flush_start until it receives
the last flush_stop: the source pad task is stopped, and can
only be restarted once the last flush_stop has arrived.
I can only speculate as to the reason why this was done,
as it was that way since the original commit. My best
guess is that aggregator originally didn't marshall events
and queries to the aggregate thread, and this somehow
helped work around this.
Instead of tracking "pending_flush_*" on the pads and the
aggregator, we now simply track the last seqnum for flush start
and flush stop events on the pads, and use it to determine whether
we should enter or exit our flushing state.
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/977
Otherwise when seeking backwards we would keep the last_stop at the last
position we saw until playback passed the seek position again, and if
switching to the next pad happens in the meantime we would set the wrong
offset in the outgoing segment.
Since we started depending on GLib 2.44, we can be sure this macro is
defined (it will be a no-op on compilers that don't support it). For
plugins we should just start using `G_DECLARE_FINAL_TYPE` which means
we no longer need the macro there, but for most types in core we don't
want to break ABI, which means it's better to just keep it like it is
(and use the `#ifdef` instead).
This means we can use some newer features and get rid of some
boilerplate code using the `G_DECLARE_*` macros.
As discussed on IRC, 2.44 is old enough by now to start depending on it.
Not that it matters, since we don't check the return value
anyway. Unclear why the aggregator pad flush function should
have a return value at all really, and perhaps it should be
called reset anyway. Spotted by dv on irc.
Another helper to navigate a pipeline. It makes it possible to easily
access the pads of an element:
(gdb) print $gst_element_pad(basesink, "sink")
$1 = 0x7fffe80770f0 [GstPad|sink]
This add the different timestamps for segment events:
(gdb) gst-print pad
SrcPad(src, push) {
events:
[...]
segment: time
rate: 1.1
start: 0:03:08.449753330
time: 0:03:08.449753330
position: 0:03:08.449753330
duration: 0:12:14.166687500
[...]
}
It shows a simple tree of all elements in pipeline.
As with gst-dot, the toplevel bin is found from any element of the
pipeline:
(gdb) gst-pipeline-tree bsink
playbin
inputselector1
inputselector0
uridecodebin0
queue2-0
decodebin0
avdec_aac0
aacparse0
vaapidecodebin0
vaapipostproc0
capsfilter1
vaapi-queue
vaapidecode0
capsfilter0
h264parse0
multiqueue0
matroskademux0
typefind
typefindelement0
source
playsink
abin
aconv
resample
conv
identity
aqueue
pulsesink0
vbin
vconv
scale
conv
identity
vqueue
vaapisink0
vdbin
deinterlace
vdconv
audiotee
streamsynchronizer0
This simplifies navigating in a GStreamer pipeline, e.g.
(gdb) print $gst_bin_get($gst_pipeline(pad), "matroskademux0")
$1 = 0x7fffe81b4050 [GstMatroskaDemux|matroskademux0]
For elements, this adds all child elements, the state and base/start time:
(gdb) gst-print pipeline
0x5555556ebd20 "pipeline0"
GstPipeline(pipeline0) {
children:
fakesink0
queue0
videotestsrc0
state: PLAYING
base_time: +2:54:36.892581150
start_time: 0:00:00.000000000
}
For pads, this adds the peer pads and the current task state and the
offset (if not zero):
(gdb) gst-print pad
SrcGhostPad(src, push) {
events:
[...]
peer: vaapisink0:sink
inner peer: scale:src
}
(gdb) gst-print pad
SrcPad(src, push) {
events:
[...]
peer: queue0:sink
task: STARTED
offset: 30000000 [+0:00:00.030000000]
}
This URI is valid:
data:,;base64
(It encodes the literal string ";base64")
But would lead to a crash because the code assumed the semicolon would
be placed before the colon.
Quoting RFC 2396:
For resiliency, programs interpreting URI should treat upper case
letters as equivalent to lower case in scheme names (e.g., allow
"HTTP" as well as "http").
