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.
Otherwise we write out the SYNC_AFTER buffer immediately, and the
previously queued up buffers afterwards which then breaks the order of
data.
Also add various debug output.
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.
Make our own deprecation marker for libgstcheck,
since the function declaration must contain the
right API export decorator (GST_CHECK_API) and
not the one for GStreamer core.
Don't return a value from a function that doesn't
return a value using the returned value from a
function that also doesn't return a value.
gstbitwriter.h(265): warning C4098: 'gst_bit_writer_align_bytes_unchecked': 'void' function returning a value
Otherwise it's not guaranteed that buffers are actually on disk after
pushing them, and reading the file via g_file_get_contents() might not
include them yet.
fflush() has no effect because we use writev() directly, so fsync()
should be used instead which is actually flushing the kernel-side
buffers.
As a next step, a non-line-buffered buffering mode is to be added.
https://bugzilla.gnome.org/show_bug.cgi?id=794173
Instead, use -fvisibility=hidden and explicit exports via GST_EXPORT.
This should result in consistent behaviour for the autotools and
Meson builds where this is done already, and will allow us to drop
the win32 .def files.
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
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
A regression was causing the helpers to be installed in /share which
would lead to permission denied error or PolicyKit to promtp for
permission. See:
054fa3aa2 meson: Use new define_variable: feature instead of run_command()
And make use of that in the typefind element to also be able to make use
of the extension in push mode. It previously only did that in pull mode
and this potentially speeds up typefinding and might also prevent false
positives.
https://bugzilla.gnome.org/show_bug.cgi?id=796865
