Latency is easier to read when formatted as time rather than displayed
as a flat number in ns.
Especially when displaying GST_CLOCK_TIME_NONE which is now formated as
99:99:99.999999999 instead of 18446744073709551615.
It's possible that setcap is installed, but the libcap headers/libs aren't (e.g.
during cross compilation, when you have the program installed for the host,
but need the headers of the target). Also removes the need to manually check
for the libcap headers.
Internal gst_net_utils_set_socket_dscp renamed and turned into external
function. Similar functionality exists in e.g. multidupsink, which could
instead use this one.
And add strduped function pointer names to the global quark
table, so that they don't get reported as lost by valgrind.
This allows us to use GST_DEBUG when running tests under
valgrind.
Creating seek events segfaults on 32-bit ARM since commit 2fa15d5371
('event: add new seek parameter, "trickmode-interval"'), which missed
casting the trickmode-interval initializer in the variable argument list
to guint64.
The pad name sotred in the latency event has no longer the name of the element,
so we have to get the element Id, element name and pad name values from the data
structure and compare all 3 values.
Otherwise we'll get an assertion if the object behind the weak pointer
was already destroyed in the meantime as we would pass NULL as first
argument to g_object_remove_weak_pointer().
This will output latency information when parsing a log file with gst-stats that
has latency trace information. It will show the min, max and mean latency for
the pipeline and all its elements. It will also show the reported latency for
each element of the pipeline. Output example:
Latency Statistics:
pulsesrc0_src|fakesink0_sink: mean=190000043 min=190000043 max=190000043
Element Latency Statistics:
flacparse0_src: mean=45561281 min=654988 max=90467575
flacenc0_src: mean=89938883 min=81913512 max=97964254
flacdec0_src: mean=45804881 min=228962 max=91380801
Element Reported Latency:
pulsesrc0: min=10000000 max=200000000 ts=0:00:00.262846528
flacenc0: min=104489795 max=104489795 ts=0:00:00.262898616
flacparse0: min=0 max=0 ts=0:00:00.262927962
First, the event would be leaved, but also when an element takes
several buffers before producing one, we want the reported latency to be
the aggregation, so the distance from the oldest buffer.
This sets back the default to trace only pipeline latency, and add flags
to enabled element tracing. It is now possible to only trace element
latency, only trace pipeline latency, trace both or none.
This removes the passing of pad inside of a GstEvent. While this is not
a bug, it may affect the live time of the pad, hense change the pipeline
behaviour.
The signal will be emitted when a buffer was consumed on
a pad, if the newly-added "emit-signals" property has been
set to TRUE.
Handlers connected to the signal will receive a valid reference on
the consumed buffer, allowing for example the retrieval of metas in
order to forward them once an output buffer is pushed out.
When printing a GstStructure property (e.g. the "stats" property in
rtpsession) the first field is printed on the same line of the type
description, and this is both inconsistent compared to how Enum values
are printed and confusing as the reader might miss the first field.
To fix this, add a newline before printing GstStructure fields in
properties.
NOTE: this does not change the existing inconsistent behavior of an
extra newline *after* a GstStructure property, but the latter is not as
annoying and it would take more effort to fix because GstStructure
fields are printed in CAPS descriptions too.
When performing a key unit trickmode seek, it may be useful to
specify a minimum interval between the output frames, either
in very high rate cases, or as a protection against streams
that may contain an overly large amount of key frames.
One use case is ONVIF Section 6.5.3:
<https://www.onvif.org/specs/stream/ONVIF-Streaming-Spec.pdf>
