Move AC3HeaderInfo into ac3_parser_internal.h and the rest
into a new header ac3defs.h.
This also breaks an include cycle of ac3.h and ac3tab.h
(the latter now only needs ac3defs.h).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Some of these were made possible by moving several common macros to
libavutil/macros.h.
While just at it, also improve the other headers a bit.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
This fixes an invalid read if end is 0:
band_end = ff_ac3_bin_to_band_tab[end-1] + 1;
Depending on what is before the array, this can cause stack smashing,
when band_end becomes too large.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It is only used to generate band_start_tab, which about the same size, at
runtime, so it's simpler just to always hardcode band_start_tab.
Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit 24e3ad3031)
It is only used to generate band_start_tab, which about the same size, at
runtime, so it's simpler just to always hardcode band_start_tab.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This symbol is only ever used to calculate the non-hardcoded tables, so
only enable it in that case, and static to the source unit that uses it.
Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit 6ed3b504f9)
This symbol is only ever used to calculate the non-hardcoded tables, so
only enable it in that case, and static to the source unit that uses it.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Passing an explicit filename to this command is only necessary if the
documentation in the @file block refers to a file different from the
one the block resides in.
Originally committed as revision 22921 to svn://svn.ffmpeg.org/ffmpeg/trunk
About 1% faster ff_ac3_bit_alloc_calc_psd on Intel Atom, overall speedup
not measurable though.
Should have a bigger effect on systems without cmov or with very slow cmov.
Originally committed as revision 21214 to svn://svn.ffmpeg.org/ffmpeg/trunk
Otherwise doxygen complains about ambiguous filenames when files exist
under the same name in different subdirectories.
Originally committed as revision 16912 to svn://svn.ffmpeg.org/ffmpeg/trunk
Andreas Rheinhardt
Diego Biurrun
Ganesh Ajjanagadde
Andreas Cadhalpun
Michael Niedermayer
Justin Ruggles
Mans Rullgard
Diego Elio Pettenò
Reimar Döffinger
Stefano Sabatini
Zuxy Meng