It is small (16 B) and therefore the overhead of exporting it more
than outweighs the size savings from not having duplicated symbols:
When the symbol is no longer avpriv, one saves twice the size of
the string containing the symbols name (2x30 byte), two entries
in .dynsym (24 bytes each on x64), one entry in the importing libraries
.got and .rela.dyn (8 + 24 bytes on x64) and two entries for the
symbol version (2 bytes each) and one hash value in the exporting
library (4 bytes).
(The exact numbers are of course different for other platforms
(e.g. when using dlls), but given that the strings saved alone
more than outweigh the array size it can be presumed that this
is beneficial for all platforms.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Possible now that the next pointer no longer exists.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: null pointer dereference
Fixes: ffmpeg_crash_6.avi
Found-by: Thuan Pham, Marcel Böhme, Andrew Santosa and Alexandru Razvan Caciulescu with AFLSmart
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
It was replaced by avpriv_ac3_parse_header2.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Buffers containing copies of the AAC and AC3 header bits were not padded
before parsing, violating init_get_bits() buffer padding requirement,
leading to potential buffer read overflows.
This change adds FF_INPUT_BUFFER_PADDING_SIZE bytes to the bit buffer
for parsing the header in each of aac_parser.c and ac3_parser.c.
Based on patch by: Matt Wolenetz <wolenetz@chromium.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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>
That way all mix levels as exported by avpriv_ac3_parse_header()
will have the same meaning.
Previously the 3-bit center mix level for E-AC-3 was used to index in a
4-entry table, leading to out-of-array reads.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
Signed-off-by: Alex Converse <alex.converse@gmail.com>
That way all mix levels as exported by the parser
will have the same meaning.
Previously the 3bit center mix level for eac3 was
used to index in a 4 entry table leading to out of array reads.
this change removes the table and offsets the ac3 variable by 4
so it matches the meanings for eac3 except the reserved case.
The reserved case is then explicitly handled.
Idea-by: Justin Ruggles <justin.ruggles@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It is pretty hopeless that other considerable projects will adopt
libavutil alone in other projects. Projects that need small footprint
are better off with more specialized libraries such as gnulib or rather
just copy the necessary parts that they need. With this in mind, nobody
is helped by having libavutil and libavcore split. In order to ease
maintenance inside and around FFmpeg and to reduce confusion where to
put common code, avcore's functionality is merged (back) to avutil.
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
None of these symbols should be accessed directly, so declare them as
hidden.
Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit d36beb3f69)
Other parts of FFmpeg use NE (native endian) rather than ME (machine).
This makes it consistent.
Originally committed as revision 24169 to svn://svn.ffmpeg.org/ffmpeg/trunk
if any E-AC-3 frames have been detected instead of switching back and forth for
AC-3 core + dependent E-AC-3 substream(s).
Fixes Issue 2022.
Originally committed as revision 24103 to svn://svn.ffmpeg.org/ffmpeg/trunk