for 5.1 ch, the channel elements are as follows: SCE - CPE - CPE - LFE
and the channel-mapping table for 5.1 ch is :
{ 2, 0, 1, 4, 5, 3,255,255}, /* 5.1ch */
For the last LFE channel, sbr decoder returns error, SBRDEC_UNSUPPORTED_CONFIG;
This fixes cases where an ADTS header could set numberOfRawDataBlocks
to a number larger than 1, which would lead to transportDec_FillData
not feeding any more data, even though the input buffer was depleted.
Fixes: 3014/clusterfuzz-testcase-5425740193464320
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Alternatively, the bits read in CProgramConfig_ReadHeightExt could
be checked right there instead.
Fixes: 2802/clusterfuzz-testcase-minimized-6752357788418048
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
If channel numbers are changed on the fly (in invalid bitstreams),
we can end up with a channel mapping with fewer channels mapped
than we actually try to output.
Ideally, this condition should probably be checked somewhere
closer to where it enters such a state, not when using the
channel mapping though.
Fixes: 2808/clusterfuzz-testcase-minimized-4694952892170240
Fixes: 2275/clusterfuzz-testcase-minimized-6205444085252096
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
This probably doesn't fix the root cause, but at least fixes
the issues found in this particular fuzzed sample.
Compared to the previous fix in 39e13c1acbca94f562f9776e1555ced50dd0dfcd,
this doesn't break HE-AACv2 encoding, by allowing the case with
usb==no_channels.
Fixes: 1973/clusterfuzz-testcase-minimized-6319232084082688
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
This reverts commit 39e13c1acbca94f562f9776e1555ced50dd0dfcd.
This turned out to break HE-AACv2 encoding. Will look for a better
fix for the issue found by the fuzzed sample.
This fixes issue #69.
This probably doesn't fix the root cause, but at least fixes
the issues found in this particular fuzzed sample.
Fixes: 1994/clusterfuzz-testcase-minimized-6368089497141248
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
This probably doesn't fix the root cause, but at least fixes
the issues found in this particular fuzzed sample.
Fixes: 1973/clusterfuzz-testcase-minimized-6319232084082688
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
This fixes assert failures, when a (corrupt/fuzzed) bitstream
doesn't trigger starting/ending CRCs properly (or when decoding
is aborted halfway when an error is encountered). Skipping ending
a CRC region doesn't trigger an assert failure, but when a later
CRC region is started and ended, an assert fails when the end
doesn't match the expected CRC region.
Fixes: 1928/clusterfuzz-testcase-minimized-6480505958563840
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
1) Fixes some potential NULL-pointer access in case input pointer is
passed NULL
2) Modified some for lazy init
Test: mm -j 8
Change-Id: I7fca97e1d9f70d8e8c1533b519181af35a5468f7
* In an effort to modernize build configurations to the new Soong
system, we need to upgrade existing Android.mk files to Android.bp
* This file is done by using the following steps:
1. Manually removing all *_sources from Android.mk, because
of the unusual make logic they use
2. Running the auto-conversion tool:
androidmk Android.mk > Android.bp
3. Editing the result Android.bp:
3.1. Writing the "srcs" list
3.2. Removing the escaping around -Wno-#warnings in cflags,
because those are not needed anymore
3.3. Renamed local_include_dirs to export_include_dirs to
facilititate the inclusion of header files.
It appears users of libFraunhoferAAC are using header
files from all include directories, hence the renaming.
Test: Code compilation ("mm" in external/aac, and "make" in top-directory)
Bug: b/32958753 b/34454142
Change-Id: Ie89f73722908e8734f4b88f1407952311ec064af
Clang warns about this being deprecated, when building without specifying
-std=c++98.
This doesn't give any measurable encoding speed impact on ARM or AArch64,
on neither GCC nor Clang.
Change-Id: I63a0bbd1dccb97547522da188ee585d4d8127c29
This fixes building in C++11 mode, which normally errors out
on narrowing hex literals to signed long.
This is similar to what was done in git commit ef30836651
(change id I64d19a8a8059c5a96386b1eaac297fd2469515f8), completing
the fix for that category of issues.
Change-Id: I1907bc947d43bf44910fb2b34bf2b31c0e53aa53
The fixmuldiv functions don't need inline assembly to be fast
in this architecture; the compiler (both clang and GCC) figure
out to use the optimal instructions for this (which is 2 instruction
sequence), and when letting the compiler emit the instructions
instead of using inline assembly, the compiler is able to
interleave those instructions with other instructions,
improving scheduling, making it even faster than when using
inline assembly.
Overall, this gives about 50% speedup.
