active-pad switch causes reconfigure event with lock taken,
and upstream element might query the current position or duration
before returning the reconfigure event.
Meanwhile, gst_input_selector_get_linked_pad() is used to get srcpad
inside of default query handle, and it takes also lock.
Since inputselector is still locked by active-pad switch, and so the query
cannot be handled further.
https://bugzilla.gnome.org/show_bug.cgi?id=775445
This is what Autoconf already does for us, so just do this. Avoids
people making typos while adding header or function checks. Because we
use a config.h.meson, such typos won't even be noticed.
Also, starting from Meson 0.36.0, the XCode 8 workaround that we use for
clock_gettime is no longer needed.
Before emitting have-type, switch to NORMAL
mode, as part of the have-type processing sends
the caps event downstream, which might trigger
actions like downstream autoplugging or
flushing seeks - and the latter are only
passed upstream if we've set typefind to NORMAL
mode.
It might happen that the srcpad task function is never called at all, in
which case unlocking everything from there will never happen.
Make sure to unlock everything another time after the task function is
definitely stopped.
https://bugzilla.gnome.org/show_bug.cgi?id=776039
This is an API break but that API has not been released yet.
We are passing a flag rather than a simple boolean as we can imagine
to implement more features in the future for example to retrieve a
stack trace for all the threads, etc..
Retrieving source file and line numbers is pretty
expensive while getting a stack trace, this new argument
allows the user to decide to retrieve a backtrace
without those infos instead which is much faster.
For example running $ GST_LEAKS_TRACER_STACK_TRACE=1 GST_DEBUG=GST_TRACER:7 \
GST_TRACERS=leaks time gst-launch-1.0 videotestsrc num-buffers=1 ! fakesink:
* With simple stack traces:
0.04s user 0.02s system 99% cpu 0.060 total
* With full stack traces:
0.66s user 0.23s system 96% cpu 0.926 total
https://bugzilla.gnome.org/show_bug.cgi?id=775423
The correct behaviour of anything stuck in the ->render() function
between ->unlock() and ->unlock_stop() is to call
gst_base_sink_wait_preroll() and only return an error if this returns an
error, otherwise, it must continue where it left off!
https://bugzilla.gnome.org/show_bug.cgi?id=773912
When running in sync-by-running-time mode, pad groups
that have exactly 1 pad and it's not-linked might never
wake up after computing a high time, as the per-pad-group
high time was only recomputed when a pad in the group
advances.
Wake those up using the global multiqueue high-time across
all other groups instead.
https://bugzilla.gnome.org/show_bug.cgi?id=774322
When subtracting queued data sizes from upstream queries
in queue, queue2, downloadbuffer and typefind, clamp the
result to not go negative, in case upstream returned
a nonsense value that's too small (as could happen if
upstream is estimating, or just broken)
Implement handling in basesink to not unconditionally discard
out-of-segment buffers and expose it as a new property on fakesink
(not unconditionally in all basesink based sinks).
The property defaults to FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=765734
Otherwise downstream will have an inconsistent set of sticky events at this
point, e.g. when a TAG event is pushed and downstream wants to relate it to
the stream by looking at the current STREAM_START event.
https://bugzilla.gnome.org/show_bug.cgi?id=768526
On the first buffer, it's possible that sink_segment is set but
src_segment has not been set yet. If this is the case, we should not
calculate cur_level.time since sink_segment.position may be large and
src_segment.position default is 0, with the resulting diff being larger
than max-size-time, causing the queue to start leaking (if
leaky=downstream).
One potential consequence of this is that the segment event may be
stored on the srcpad before the caps event is pushed downstream, causing
a g_warning ("Sticky event misordering, got 'segment' before 'caps'").
https://bugzilla.gnome.org/show_bug.cgi?id=773096
