The floating point AAC decoder is the only user of these tables, so it
makes sense to move them there. Furthermore, initializing the ordinary
power-of-two sinetables is currently not thread-safe and if the 120- and
960-point sinetables were not moved, one would have to choose whether
to guard initializing these two tables with their own AVOnces or not.
Doing so would add unnecessary AVOnces as the AAC decoder already guards
initializing its static data by an AVOnce; not doing so would be fragile
if a second user of these tables were to be added.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
There are no ff_sine_windows for 2^i, 0 <= i < 5, so one should check
for the index being >= 5.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Both the fixed as well as the floating point mpegaudio decoders use
LUTs of type int8_t and uint32_t with 32K entries each; these tables
are completely the same, yet they are not shared. This commit makes
them shared. When both fixed as well as floating point decoders are
enabled, this saves 160KiB from the bss segment for a normal build
(translating into 160KiB less memory usage if both a shared as well as
a floating point decoder have actually been used) and 160KiB from the
binary for a build with hardcoded tables.
It also means that the code to create said LUTs is no longer duplicated
(for a normal build).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The csa_tables (which always consist of 32 entries of four byte each,
but the type depends upon whether the decoder is fixed or
floating-point) are currently initialized once during decoder
initialization; yet it turns out that this is actually no benefit: The
code used to initialize these tables takes up 153 (fixed point) and 122
(floating point) bytes when compiled with GCC 9.3 with -O3 on x64, so it
is better to just hardcode these tables.
Essentially the same applies to the is_tables: They have a size of 128B
each and the code to initialize them occupies 149 (fixed point) resp.
140 (floating point) bytes. So hardcode them, too.
To make the origin of the tables clear, references to the code used to
create them have been added.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Each invocation of this function is only entered once, so using a static
array makes no sense (and given that the whole array is reinitialized at
the beginning of this function, it wouldn't even make sense if the
function were called multiple times).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The mpegaudio_tablegen header contains code to initialize several
tables; it is included in both the fixed as well as the floating point
mpegaudio decoders and some of these tables are only used by the fixed
resp. floating point decoders; yet both types are always initialized,
leaving the compiler to figure out that one of them is unused.
GCC 9.3 fails at this (even with -O3):
$ readelf -s mpegaudiodec_fixed.o|grep _float
28: 0000000000001660 32768 OBJECT LOCAL DEFAULT 4 expval_table_float
An actually unused table (expval_table_fixed/float) of size 32KiB is kept
and initialized (the reason for this is probably that this table is read
from, namely to initialize another table: exp_table_fixed/float; of course
the float resp. fixed tables are not used in the fixed resp. floating point
decoder).
Therefore #ifdef the unneeded tables away.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, there were several indiviual tables which were accessed
via pointers to them; by combining the tables, one can avoid said
pointers, saving space.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By switching from ff_init_vlc_sparse() to ff_init_vlc_from_lengths() one
can replace tables of codes of type uint16_t by tables of symbols of
type uint8_t; this saves about 1.3KB for both the fixed and floating
point decoders (if enabled).
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By switching from ff_init_vlc_sparse() to ff_init_vlc_from_lengths() one
can remove the array of codes of type uint16_t here; given that the
symbols are the default ones (0,1,2,...), no explicit symbols table
needs to be added.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By switching from ff_init_vlc_sparse() to ff_init_vlc_from_lengths() one
can remove arrays of codes in cases where there were already symbols
tables.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Expressions like array[get_vlc2()] can be optimized by using a symbols
table if the array is always the same for a given VLC. This requirement
is fulfilled for several VLCs used by the AAC decoders.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is possible by switching to ff_init_vlc_from_lengths() which allows
to replace tables of codes of size uint16_t or uint32_t by tables of
symbols of size uint8_t; in case there already were symbols tables the
savings are even bigger.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
MagicYUV transmits its Huffman trees by providing the length of the code
corresponding to each symbol; then the decoder has to assemble the table
in such a way that (i) longer codes are to the left of the tree and (ii)
for codes of the same length the symbols are ascending from left to right.
Up until now the decoder did this as follows: It counted the number of
codes of each length and derived the first code of a given length via
(ii). Then the array of lengths is traversed a second time to create
the codes; there is one running counter for each length to do so. This
process creates a default symbol table (that is omitted).
This commit changes this as follows: Everything is indexed by the
position in the tree (with codes to the left first); given (i), we can
calculate the ranges occupied by the codes of each length; and with (ii)
we can derive the actual symbols of each code; the running counters for
each length are now used for the symbols and not for the codes.
Doing so allows us to switch to ff_init_vlc_from_lengths(); this has the
advantage that the codes table needs only be traversed once and that the
codes need not be sorted any more (right now, the codes that are so long
that they will be put into subtables need to be sorted so that codes
that end up in the same subtable are contiguous).
For a sample produced by our encoder (natural content, 4000 frames,
YUV420p, ten iterations, GCC 9.3) this decreased the amount of
decicycles for each call to build_huffman() from 1336049 to 1309401.
Notice that our encoder restricts the code lengths to 12 and our decoder
only uses subtables when the code is longer than 12 bits, so the sorting
that can be avoided does not happen at the moment. If one reduces the
decoder's tables to nine bits, the performance improvement becomes more
apparent: The amount of decicycles for build_huffman() decreased from
1165210 to 654055.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The Huffman trees used by Ut Video have two important characteristics:
(i) Longer codes are on the left of the tree and (ii) for codes of the
same length, the symbol is descending from left to right in the tree.
Therefore all the information that needs to be transmitted is how long
the code corresponding to a given symbol is; and this is also all that
is transmitted.
Before 341914495e, the decoder used qsort
to sort the (length, symbol) pairs by ascending length and for equal
lengths by ascending symbol. Since said commit, the decoder uses
a first pass over the lengths table to count how many symbols of each
length there are; with (i) one can then easily calculate the code of
the left-most code with a given length in the tree and from there one
can calculate the codes for all entries, using one running counter for
each possible length. This eliminated the explicit qsort in
build_huff().
Yet ff_init_vlc_sparse() sorts the table itself as it has to ensure that
all the entries that will be placed in the same subtable are contiguous.
The tables created now are non-contiguous (they are ordered by symbol
and codes of different length aren't ordered at all; only codes of the
same length are ordered according to (ii)).
This commit therefore modifies the algorithm used to automatically create
tables whose codes are sorted from left to right in the tree. The key to
do so is the observation that the counts obtained in the first pass can
be used to contain the range of the codes of each length in the second
pass: If counts[i] is the count of codes with length i, then the first
counts[32] codes are of length 32, the next counts[31] codes are of
length 31 etc. So one knows the index of the lowest symbol whose code
has length 32 (if any): It is counts[32] - 1 due to (ii), whereas the
index of the lowest symbol whose code has length 31 (if any) is
counts[32] + counts[31] - 1; the index of the second-to-lowest symbol of
length 32 (if existing) is counts[32] - 2 etc.
If one follows the algorithm outlined above, one can switch to
ff_init_vlc_from_lengths() which has no implicit qsort; it also means
that one can offload the computation of the codes.
This turned out to be beneficial for performance: For the sample from
ticket #4044 it decreased the decicycles spent on one call to
build_huff() from 508480 to 340688 (GCC 9.3, looping 10 times over the
file to get enough runs and then repeating this ten times); for another
sample (YUV420p, natural content, 5500 frames, also ten iterations)
the time went down from 382346 to 275533 decicycles.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Expressions like array[get_vlc2()] can be optimized by using a symbols
table if the array is always the same for a given VLC. This requirement
is fulfilled for several VLCs used by ATRAC3, therefore this commit
implements this. This comes without any additional costs when using
ff_init_vlc_from_lengths() as one can then remove the codes tables.
While at it, remove the arrays of pointers to the individual arrays and
put all lengths+symbol pairs in one big array.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By switching from ff_init_vlc_sparse() to ff_init_vlc_from_lengths() one
can replace an array of codes of type uint16_t with an array of symbols
of type uint8_t, saving space.
Also remove some more code duplication while at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
theora_init_huffman_tables() does essentially the same as
ff_init_vlcs_from_lengths().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Expressions like array[get_vlc2()] can be optimized by using a symbols
table if the array is always the same for a given VLC. This requirement
is fulfilled for the VLC used for VP3 motion vectors. The reason it
hasn't been done before is probably that the array in this case
contained entries in the range -31..31; but this is no problem with
ff_init_vlc_from_lengths(): Just apply an offset of 31 to the symbols
before storing them in the table used to initialize VP3 motion vectors
and apply an offset of -31 when initializing the actual VLC.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is possible by switching to ff_init_vlc_from_lengths() because it
allows to replace codes of type uint16_t by symbols of type uint8_t; in
some cases (like here) it also allows to replace explicitly coded
codes by implicitly coded symbols.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By switching to ff_init_vlc_from_lengths() one can apply both positive
as well as negative offsets for free; in this case it even saves space
because one replaces codes tables that don't fit into an uint8_t by
symbols tables that fit into an uint8_t or can even be completely
avoided as they are trivial.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Also remove code duplication and use a named constant for the number of
VLC bits while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ATRAC9 decoder creates VLCs with parameters contained in
HuffmanCodebooks; some of these HuffmanCodebooks are empty and yet
VLCs (that were completely unused*) were created from them. Said VLC
contained a single table with 512 VLC_TYPE[2] entries, each of which
indicated that this is an invalid code. This commit stops creating said
VLCs.
*: read_coeffs_coarse() uses the HuffmanCodebook
at9_huffman_coeffs[cb][prec][cbi]. prec is c->precision_coarse[i] + 1
and every precision_coarse entry is in the 1..15 range after
calc_precision(), so prec is >= 2 (all codebooks with prec < 2 are
empty). The remaining empty codebooks are those with cb == 1 and cbi ==
0, yet this is impossible, too: cb is given by c->codebookset[i] and
this is always 0 if i < 8 (because those are never set to anything else
in calc_codebook_idx()) and cbi is given by at9_q_unit_to_codebookidx[i]
which is never zero if i >= 8.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Using separate tables has the downside that one needs a big number of
pointers to the separate tables (currently 77); unifying them avoids
this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ATRAC9 decoder uses VLCs which are currently initialized with
static length tables of type uint8_t and code tables of type uint16_t.
Furthermore, in one case the actually desired symbols are in the range
-16..15 and in order to achieve this an ad-hoc symbols table of type
int16_t is calculated.
This commit modifies this process by replacing the codes tables by
symbols tables and switching to ff_init_vlc_from_lengths(); the signed
symbols are stored in the table after having been shifted by 16 to fit
into an uint8_t and are shifted back when the VLC is created. This makes
all symbols fit into an uint8_t, saving space. Furthermore, the earlier
tables had holes in them (entries with length zero that were inserted
because the actually used symbols were not contiguous); these holes are
unnecessary in the new approach, leading to further saving.
Finally, given that now both lengths as well as symbols are of the same
type, they can be combined; this saves a pointer for each VLC.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is very beneficial for the scale factor tables where 4*64+4*15
bytes of length information can be replaced by eight codebooks of 12
bytes each; furthermore the number of codes as well as the maximum
length of a code can be easily derived from said codebooks, making
tables containing said information superfluous. This and combining the
symbols into one big array also made an array of pointers to the tables
redundant.
For the wordlen and code table tables the benefits are not that big
(given these tables don't contain that many elements), but all in all
using codebooks is also advantageouos for them. Therefore it has been
done.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
