In baseparse we set the fixed caps flag on all src pads, therefore the
source pad caps query in get_allowed_caps will return the current caps.
Current caps won't necessarily intersect with the new caps (e.g. sample
rate change). Replace get_allowed_caps with peer_query_caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/816>
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.
Raw AAC streams might have very small frames, e.g. 6 byte frames
when encoding silence. These frames are then smaller than aacparse's
default min_frame_size of 10 bytes (ADTS_MAX_SIZE).
When passthrough is disabled or aacparse has to output ADTS, GstBaseParse
will concatenate these short frames to the following frame before
handling them to aacparse, which processes each input buffer as a single
frame, producing bad output.
To avoid this problem, set the min_frame_size to 1 when receiving a raw
stream.
https://bugzilla.gnome.org/show_bug.cgi?id=792644
AudioSpecifigConfig is used in a variety of AAC streams but was
being parsed differently. Instead, make everyone use the same parsing.
* Remove unused 'bits' field (it was always set to 0 if present)
* Add proper GAConfig parsing (to know the number of samples per frame
if present).
Fixes wrong rate/channels configuration in streams coming from qtdemux
https://bugzilla.gnome.org/show_bug.cgi?id=780966
According to ISO/IEC:14496-2:2009 , in the case of HE-AACv2 (audioObjecType
29) parametric stereo is used (a single mono track is used and then
transformations are applied to it to provide a stereo output).
We therefore report two channels in the case where there is one reported
in the audioChannelConfiguration.
Fixes the various issues where a demuxer would report two channels, but
then the parser would say there's only one channel, and then the decoder
would output two channels.
aacparse resizes input buffer while converting ADTS stream to RAW,
During buffer resize buffer write permission is not checked.
This throws gst_buffer_is_writable assertion and leads to AV sync issue some times.
It is corrected by making buffer writeable using gst_buffer_make_writable
https://bugzilla.gnome.org/show_bug.cgi?id=774129
There might be multiple LOAS config in a row in a full frame. The first
one might be a multi-layer config (which we can't properly parse yet)...
but then followed by a valid (single-layer) one.
The code was previously skipping whole frames (instead of just the LOAS
config we failed to read) resulting in multiple frames (seen up to 6s in
some situation) being dropped before finally getting the configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=758826
On reading LOAS config, flag v=1 and vA=1 combination can occur, leading to warning
"Spec says "TBD"...". Returning TRUE on this case while parameters 'sample_rate' and
'channels' are pointing to uninitialized values can end on setting random values as
rate and channels on src caps.
https://bugzilla.gnome.org/show_bug.cgi?id=755611
It's normal when dropping into the middle of a stream to
not always have the config available immediately, so skip LOAS
until a valid config is seen without either setting invalid
caps or erroring out.
https://bugzilla.gnome.org/show_bug.cgi?id=751386
Adds two extra checks:
- Sampling frequency on header can't be 15.
- Frame size should be at least 9 or 7, depending
on whether CRC protection is present.
https://bugzilla.gnome.org/show_bug.cgi?id=724638
According to ISO/IEC 13818-7, "channel_config" field in ADTS header
may have value of 0, as in the case of frame with PCE.
gst_aac_parse_detect_streams() returned FALSE for those frames
and discarded them.
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
This patch will prepend ADTS headers to raw AAC audio frames, allowing
upstream elements to link to decoders that only support AAC in ADTS format.
Note that no error correction bits are added to ADTS frames in this code.
https://bugzilla.gnome.org/show_bug.cgi?id=615740
Some muxers (eg, qtmux) only support raw AAC, so this allows linking
an encoder that outputs ADTS only to those muxers.
The conversion is simple (omit the first 7 or 9 bytes of the frame),
but has to be done in pre_push instead of handle_frame as 1.0 does
not seem to allow skipping bytes there as 0.10 used to.
Other conversions are not supported (yet).
According to http://wiki.multimedia.cx/index.php?title=ADTS,
the value stored in ADTS headers is one less than the object
type of the AAC stream.
A look at ffmpeg shows it also adds 1 to the value read off
the ADTS header.
Note that this might break other things that happen to have
an inverse off by one to match the existing code.
