The pre_push_frame default clipping behaviour was introduced in 2010
with commit 30be03004e and modified with commit 4163969a24 in 2011,
when most parsers didn't implement a pre_push_frame yet. Not having it
meant that clipping was done by default. Those that did implement a
pre_push_frame (flacparse and mpegaudioparse) at the time, had the flag
adjusted as part of the 2011 refactor work.
All other parsers got a pre_push_frame vfunc implementation only in
2013, but seem to have forgot to keep the clipping behaviour, as
was done automatically when a pre_push_frame implementation doesn't
exist for the parser. aacparse lost it with commit 91d4abcea in
July 2013; the others in Dec 2013 as part of AUDIO_CODEC tag posting
in commits 6f89b430e, d2ab5199b, 29f2cae12, 753d3c23a and 292780574.
Fix chain function not handling not-linked from baseparse.
When an input data is separated into 2 buffers, the second buffer
would not be pushed into the adapter if baseparse returns not-linked
for first buffer.
This caused glitches when switching streams and selecting
a stream that was previously unselected.
https://bugzilla.gnome.org/show_bug.cgi?id=786268
The parser can accept input that is not completely specified. Use the
ACCEPT_INTERSECT flag on the sinkpad to tweak the acceptcaps function to
check for intersection only. This allows us to proxy downstream
constraints while still allowing non-subset caps as input.
We can then also remove the appended template caps workaround.
Make a unit-test to check the new feature.
This reverts commit 26040ee38c
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=705024
Otherwise we will intersect with the srcpad template caps and add all the caps fields
that the parser will ever set, no matter if downstream restricts this field or not.
This requires upstream to set this field on the caps to successfully negotiate.
https://bugzilla.gnome.org/show_bug.cgi?id=690184
They should take the filter caps into account and always return
the template caps appended to the actual caps. Otherwise the
parsers stop to accept unparsed streams where upstream does not
know about channels, rate, etc.
Fixes bug #677401.
Conflicts:
ext/pulse/pulseaudiosink.c
ext/pulse/pulsesrc.c
gst/audioparsers/gstaacparse.c
gst/audioparsers/gstamrparse.c
gst/audioparsers/gstdcaparse.c
gst/audioparsers/gstflacparse.c
gst/effectv/gstradioac.c
gst/effectv/gstradioac.h
gst/effectv/gstripple.c
Some possible FIXMEs remaining in the audio parser getcaps functions.
When pushing out buffers over S/PDIF or HDMI, IEC 61937 payloading
requires each buffer to contain 6 blocks from each substream. This adds
code to collect all the frames needed to meet this requirement before
pushing out a buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=650313
The gst_base_parse_set_frame_rate call was predicated on a change to
sample rate, duration or profile. However, the block count per frame can
also change between packets, which would result in incorrect buffer
durations.
