The post tracer hooks have a GstQuery argument which was truncated from
the trace. As the post hook is the one that contains the useful data,
this bug was hiding the important information from that trace.
A pointer to a hook in this list can easily not be unique, given both
the slice-allocator reusing memory, and the OS re-using freed blocks
in malloc.
By doing many repeated add and remove of probes, this becomes very easily
reproduced.
Instead use hook_id, which *is* unique for a added GHook.
If a segment has stop == -1, then gst_segment_to_running_time()
would refuse to calculate a running time for negative rates,
but gst_segment_do_seek() allows this scenario and uses a
valid duration for calculations.
Make the 2 functions consistent by using any configured duration
to calculate a running time too in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=796559
Since we use full signed running times, we no longer need to clamp
the buffer time.
This avoids having the position of single queues not advancing for
buffers that are out of segment and never waking up non-linked
streams (resulting in an apparent "deadlock").
The follow-up and delay-resp messages carry precise
timestamps for the arrival at the clock master, but
the local return time is unimportant, so we should be very
lenient in accepting them late. Some PTP masters don't
prioritise sending those packets, and we reject all the
responses and never sync - or take forever to do so.
Increase the tolerance to 20x the mean path delay.
Also fix a typo in one debug output that would print
the absolute time of the delay-resp message, not the offset
from the delay-req that it's actually being compared against.
Previously, with opportunistic sync we'd track a master
clock as soon as we see a SYNC message, and hence sync up
faster, but then we'd announce we're synched before seeing
the ANNOUNCE, leaving the clock details like grandmaster-clock
empty.
A better way is to start tracking the clock opportunistically,
but not announce we're synched until we've also seen the ANNOUNCE.
If we ever get a GST_FLOW_EOS from downstream, we might retry
pushing new data. But if pushing that data doesn't return a
GstFlowReturn (such as pushing events), we would end up returning
the previous GstFlowReturn (i.e. EOS).
Not properly resetting it would cause cases where queue2 would
stop pushing on the first GstEvent stored (even if there is more
data contained within).
Using a rate of 1.1 in the test is causing the test to
fail on 32-bit because ceil(1.1 * 10) can round to 12.
Instead use a rate 2.0 that can be expressed as floating
point number and doesn't trigger the problem.
https://bugzilla.gnome.org/show_bug.cgi?id=797154
Fixes for gst_segment_position_from_running_time_full() when
converting running_times that precede the segment start (or
stop in a negative rate segment)
The return value was incorrectly negated in those cases.
Add some more unit test checks for those cases, and especially
for segments with offsets.
gst_element_post_message() takes ownership of the message so we need to increase
its refcount until we no longer require access to its data (context_type).
https://bugzilla.gnome.org/show_bug.cgi?id=797099
The avg_bitrate is an unsigned int, so the gst_util_uin64_scale() function can't
be used for it, as it expects signed integers for the fraction parts arguments.
https://bugzilla.gnome.org/show_bug.cgi?id=797054
And only ever use the non-live values if all pads are non-live,
otherwise only use the results of all live pads.
It's unclear what one would use the values for in the non-live case, but
by this we at least pass them through correctly then.
This is a follow-up for 794944f779, which
causes wrong latency calculations if the first pad is non-live but a
later pad is actually live. In that case the live values would be
accumulated together with the values of the non-live first pad,
generally causing wrong min/max latencies to be calculated.
IDLE probes that are directly called when being added will increase /
decrease the "number of IDLE probes running" counter around the call,
but when running from the streaming thread this won't happen.
This has the effect that when running from a streaming thread it is
possible to push serialized events or data out of the pad without
problems, but otherwise it would deadlock because serialized data would
wait for the IDLE probe to finish first (it is blocking after all!).
With this change it will now always consistently deadlock instead of
just every once in a while, which should make it obvious why this
happens and prevent racy deadlocks in application code.
https://bugzilla.gnome.org/show_bug.cgi?id=796895
And make use of it in the typefind element. It's useful to distinguish
between the different errors why typefinding can fail, and especially to
not consider GST_FLOW_FLUSHING as an actual error.
https://bugzilla.gnome.org/show_bug.cgi?id=796894
Otherwise downstream will consider the pipeline not live if the active
pad is live, even though some inactive pads might be live and might
require a non-zero latency configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=796901
gst_base_transform_transform_caps can return NULL in various conditions
thus we should not treat its result as valid caps.
In all other places NULL is properly handled.
Under MSYS2 glib-mkenums is an executable and has a .exe extension and
the path does not end with "glib-mkenums".
Make the script compare the path without the file extension instead.
https://bugzilla.gnome.org/show_bug.cgi?id=796273
Probes were remembering a cookie that was used to check if the probe was
already called this time before the probes list changed. However the
same probes could've been called by another thread in between and thus
gotten a new cookie, and would then be called a second time.
https://bugzilla.gnome.org/show_bug.cgi?id=795987
strncpy() is assumed to be for strings so the compiler assumes that
it will need an extra byte for the string-terminaning NULL.
For cases where we know it's actually "binary" data, just copy it
with memcpy.
Fixes compiler warnings with gcc 8.
https://bugzilla.gnome.org/show_bug.cgi?id=795756
gst_buffer_list_new_sized(0) will cause an underflow in a calculation
which then makes it try to allocate huge amounts of memory, which
may lead to aborts.
https://bugzilla.gnome.org/show_bug.cgi?id=795758
