remove unused variable to fix compile error:
make -C audioparsers
make[3]: Betrete Verzeichnis '/home/lex/tmp/gst-plugins-good/gst/audioparsers'
CC libgstaudioparsers_la-gstaacparse.lo
gstaacparse.c: In function 'gst_aac_parse_read_loas_audio_specific_config':
gstaacparse.c:446:12: error: variable 'sbr' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
Signed-off-by: Oleksij Rempel (Alexey Fisher) <bug-track@fisher-privat.net>
The LOAS variant seems to have three different subvariants itself,
only one of them is implemented as my two samples happen to be
using that one.
The sample rate is not always reported correctly, as the "main"
sample rate is apparently sometimes half what it should be (both
of my samples report 24000 Hz there), and there are two other
parts of the subvariant with different sampling rates. One of them
is parsed, but not the other, as it's located after some other
large amount of variable data that needs parsing first, and there
seems to be a LOT of it, which is useless for our needs here.
This ends up being rather inconsequential, as ffdec_aac_latm,
which is the only decoder that can decode such streams, does not
need the sample rate on the caps anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=665394
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.
If the sample/block number happens to be the same as the block
size, we assume variable block size, and thus counters in samples
in the headers. This can only get us a false positive for a block
size of 1, which is invalid. We can get false negatives more
often though (eg, if not starting at the start of the stream),
but then that's already GIGO.
The last block may have a different block size, so we should not
use it to scale or we'll end up with a wrong timestamp.
See comment and quote from the FLAC format documentation in the code.
Fixes looped playback of FLAC files (via about-to-finish).
https://bugzilla.gnome.org/show_bug.cgi?id=661215
Yes, I was tracking another bug and the small test file I generated
to test with improbably just happened to trigger this, with a second
and last frame of 1615 bytes.
https://bugzilla.gnome.org/show_bug.cgi?id=656649
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.
