this is somewhat a magic number, which can be understood from reading section
"7.1.2 Exponent Strategy" of the ac3 specification, in short:
Three exponents each represented as number 0-4 are grouped together and
base-5 encoded, so the maximal correct value is 25*4 + 5*4 + 4 = 124.
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Change log level from warning to debug: the E-AC-3 "core"
substream can be successfully decoded without the additional
and dependent substreams, and their presence is already
indicated via avpriv_request_sample in ff_eac3_parse_header.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The table in question is a 253 byte one. In fact, it turns out that
dynamic generation of the table results in an increased binary size.
Code compiled with GCC 5.2.0, x86-64 (size in bytes), before and after
patch:
old: 62321064 libavcodec/libavcodec.so.57
new: 62320536 libavcodec/libavcodec.so.57
Thus, it always make sense to statically allocate this.
Tested with FATE with/without --enable-hardcoded-tables.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
avpriv_ac3_parse_header was removed in commit 3dfb643.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Added support for AC3 heavy dynamic range compression used
to restrict the output range and added a setting to specify
the output target level and use the dialog normalization
field to apply it in the digital domain.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
the CONFIG_ prefix is used by configure, using it for other things
is potentially confusing to the reader
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Nedeljko Babic <nbabic@mips.com>
The new function has the ability to allocate the structure, allowing it to grow
without needing major bumps
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes corrupt data errors when downmixing in the AC-3 decoder.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
CC:libav-stable@libav.org
This was handled properly in the normal return case at the end
of the function, but not in this special case.
Returning a value larger than the input packet size can cause
problems for certain library users.
Returning the actual input buffer size unconditionally, since
it is not guaranteed that frame_size is set to a sensible
value at this point.
Cc: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
If the channel mapping map multiple output channels to one
input channel, we should only increment the actual pointer once.
Cc: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
It was previously declared as int.
Does not change fate results for x86.
Conflicts:
libavcodec/ppc/fmtconvert_altivec.c
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Michael Niedermayer
Nikolas Bowe
Tim Walker
Ganesh Ajjanagadde
Andreas Cadhalpun
Vittorio Giovara
Michael Niedermayer
James Almer
Christophe Gisquet
Diego Biurrun
Paul B Mahol
Jean-Francois Thibert
Nedeljko Babic
John Stebbins
Anton Khirnov
Luca Barbato
Martin Storsjö