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.
It's useful enough already to be used in other elements for audio aggregation,
let's give people the opportunity to use it and give it some API testing.
https://bugzilla.gnome.org/show_bug.cgi?id=760733
2016-01-22 12:39:48 +02:00
Renamed from gst/audiomixer/gstaudioaggregator.c (Browse further)
