Previously one of the branches did not check for the property value. To
avoid this in the future, check inside the QoS calculation function
instead.
As a side effect this now always prints the debug messages into the logs
when samples are dropped, which is useful information even without the
QoS messages.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1224>
If a buffer is dropped during resyncing on a discont because either its
end offset is already before the current output offset of the
aggregator or because it fully overlaps with the part of the current
output buffer that was already filled, then don't just assume that the
next buffer is going to start at exactly the expected offset. It might
still require some more dropping of samples.
This caused the input to be mixed with an offset to its actual position
in the output stream, causing additional latency and wrong
synchronization between the different input streams.
Instead consider each buffer after a discont as a discont until the
aggregator actually resynced and starts mixing samples from the input
again.
Also update the start output offset of a new input buffer if samples
have to be dropped at the beginning. Otherwise it might be mixed too
early into the output and overwrite part of the output buffer that
already took samples from this input into account.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/912
which is a regression introduced by https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1180/
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1224>
The converter might have a non-passthrough mix-matrix. The converter
can determine whether it should pass through, so let it, then remove it
if it's indeed a passthrough.
FIXME: Not converting when we need to but the config is invalid (e.g.
because the mix-matrix is not the right size) produces garbage. An
invalid config should cause a GST_FLOW_NOT_NEGOTIATED.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1070>
The way pad->priv->input_buffer reference was managed was pretty
spurious:
- it was overridden without unrefing it, which could potentially lead to
leaks.
- we were unreffing it while keeping the pointer around, which could
potentially lead to use-after-free or double-free.
As priv->input_buffer is actually no longer used outside of the
aggregate() method, remove it from pad->priv to simplify the code and
prevent the issues desribed above.
Fix a single buffer leak when shutting down the pipeline as the buffer
returned from gst_aggregator_pad_drop_buffer() was never unreffed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1061>
This code path is meant to convert the current buffer to the new format
on update. It was using priv->input_buffer as input which is either
priv->buffer or a converted version of it.
Use priv->buffer instead as priv->input_buffer may no longer be a valid
reference.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1061>
While we can convert between all formats apart from the rate, we
actually need to make sure that we comply with a) the rate of the first
configured pad and b) also all the allowed rates from downstream.
We were previously only fixating the rate in the getcaps
implementation when downstream was requiring a discrete value,
causing negotiation to fail when upstream was capable of rate
conversion, but not made aware that it had to occur.
Instead of fixating the rate, we can simply update our sink
template caps with whatever GValue the downstream caps are holding
as their rate field.
Allows negotiation to successfully complete with pipelines such as:
audiotestsrc ! audio/x-raw, rate=48000 ! audioresample ! audiomixer name=m ! \
audio/x-raw, rate={800, 1000} ! autoaudiosink \
audiotestsrc ! audio/x-raw, rate=44100 ! audioresample ! m.
The code for this is mostly lifted from audiobuffersplit, it
allows use cases such as keeping the buffers output by compositor
on one branch and audiomixer on another perfectly aligned, by
requiring the compositor to output a n/d frame rate, and setting
output-buffer-duration to d/n on the audiomixer.
The old output-buffer-duration property now simply maps to its
fractional counterpart, the last set property wins.
Otherwise subclasses might accidentially use the old audioinfo/caps.
None of the subclasses currently uses the audioinfo/caps, but future
subclasses might.
https://bugzilla.gnome.org/show_bug.cgi?id=795827
In the situation described in
https://bugzilla.gnome.org/show_bug.cgi?id=795397,
downstream_caps consists of two structures, the first with
the preferred rate, if at all possible (44100), the second
containing the full range of allowed rates, as audioresample
correctly tries to negotiate passthrough caps.
As audioaggregator cannot perform rate conversion, it wants
to return a fixated rate in its getcaps implementation,
however it previously directly used the first structure in
the caps allowed downstream, without taking the filter into
consideration, to determine the rate to fixate to.
With this, we first intersect our downstream caps with the
filter, in order not to fixate to an unsupported rate.
When outputting more than two channels, a channel-mask has to be
specified in the output caps.
We follow the same heuristic as other cases, when downstream
does not specify a channel-mask, we use that of the first
configured pad, and if there was none we generate a fallback
mask.
https://bugzilla.gnome.org/show_bug.cgi?id=794257
Don't reuse the offset variables will contain a sample offset for an
intermediate time value. Instead add a segment_pos variable of type
GstClockTime for this. Use The clock-time macros to check if we got
a valid time.
Acording to the logic this cannot happen (we already check this before). So
add a assert like we do above and remove the check. This make it clearer that
we check for the offset range.
Also remove a dead assignment since we reassign this a few lines below.
