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.
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.
Before GST_PAD_PROBE_HANDLED was introduced, we had to handle the case
where some probes would reset the probe info data field to NULL. This would
be considered an invalid use-case.
But with GST_PAD_PROBE_HANDLED it is totally fine to reset that, since
the probe has "handled" it.
The original version of the patch used glib-2.0 but that was later changed
to gstreamer-1.0 for autotools. The meson file was forgotten.
Fix the path to match the one used in libgstreamer-gdb.py.in.
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>
Other gstreamer repositories have their own valgrind suppression file
directly in the repository.
Add a suppression file to the core gstreamer repository too, this makes
it easier to use it with gst-build which does not check out the common
module.
This is also a little step towards the removal of the common submodule.
NOTE: the added file is the latest version from the "common" repository
but it has been renamed from gst.supp to gstreamer.supp for symmetry
with the suppression files in the other repositories.
This suppresses the annoying 'g-ir-scanner: link: cc ..' output
that we get even if everything works just fine.
We still get g-ir-scanner warnings and compiler warnings if
we pass this option.
