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>
ATRAC3+ uses VLCs whose code lengths are ascending from left to right in
the tree; ergo it is possible (and done) to run-length encode the
lengths into so-called codebooks. These codebooks were variable-sized:
The first byte contained the minimum length of a code, the second the
maximum length; this was followed by max - min + 1 bytes containing the
actual numbers. The minimal min was 1, the maximal max 12.
While one saves a few bytes by only containing the range that is
actually used, this is more than offset by the fact that there needs
to be a pointer to each of these codebooks.
Furthermore, since 5f8de7b741 the content
of the Atrac3pSpecCodeTab structure (containing data for spectrum
decoding) can be cleanly separated into fields that are only used during
initialization and fields used during actual decoding: The pointers to
the codebooks and the field indicating whether an earlier codebook should
be reused constitute the former category. Therefore the new codebooks are
not placed into the Atrac3pSpecCodeTab (which is now unused during
init), but in an array of its own. The information whether an earlier
codebook should be reused is encoded in the first number of each
spectrum codebook: If it is negative, an earlier codebook (given by the
number) should be reused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This allows to remove lots of pointers (130) to small symbol tables;
it has the downside that some of the default tables must now be coded
explicitly, but this costs only 6 + 4 + 8 + 16 + 8 bytes and is therefore
dwarfed by the gains.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The earlier code used several different offset parameters that were
initialized to magic values. This is unnecessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The ATRAC3+ decoder currently uses ff_init_vlc_sparse() to initialize
several VLCs; sometimes a symbols table is used, sometimes not; some of
the codes tables are uint16_t, some are uint8_t. Because of these two
latter facts it makes sense to switch to ff_init_vlc_from_lengths()
because it allows to remove the codes at the cost of adding symbols
tables of type uint8_t in the cases where there were none before.
Notice that sometimes the same codes and lengths tables were reused with
two different symbols tables; this could have been preserved (meaning
one could use a lengths table twice), but hasn't, because this allows
to use only one pointer to both the symbols and lengths instead of two
pointers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_init_vlc_from_lengths() can be used to offload the computation
of the codes; it also allows to omit the check whether the codes
are already properly ordered (they are). In this case, this also allows
to avoid the allocation of the buffer for the codes.
This improves performance: The amount of decicycles for one call to
tm2_build_huff_tables() when decoding tm20.avi from the FATE-suite
decreased from 46239 to 40035. This test consisted of looping 50 times
over the file and iterating the test ten times.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Switching from ff_init_vlc_sparse() to ff_init_vlc_from_lengths()
allows to replace codes which are so long that they need to be stored
in an uint16_t by symbols which fit into an uint8_t; and even these can
be avoided in case of the sprite trajectory VLC.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Switching from ff_init_vlc_sparse() to ff_init_vlc_from_lengths()
allows to replace codes which are so long that they need to be stored
in an uint16_t by symbols which fit into an uint8_t; furthermore, it is
also easily possible to already incorporate the offset (the real range
of Indeo 2 symbols starts at one, not zero) into the symbols.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_init_vlc_from_lengths() can be used to offload the computation
of the codes; it also allows to omit the check whether the codes
are already properly ordered (they are).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_init_vlc_from_lengths() can be used to offload the computation
of the codes; it also needn't check whether the codes are already
properly ordered (they are).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The lengths of the codes used by the mss4 decoder are ascending from
left to right and therefore the lengths can be run-length encoded and
the codes can be easily derived from them. And this is how it is indeed
done. Yet some things can nevertheless be improved:
a) The number of entries of the current VLC is implicitly contained in
the run-length table and needn't be externally prescribed.
b) The maximum length of a code is just the length of the last code
(given that the lengths are ascending), so there is no point in setting
max_bits in the loop itself.
c) One can offload the actual calculation of the codes to
ff_init_vlc_from_lengths().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Besides removing code duplication the method for determining the offset
of each VLC table in the VLC_TYPE buffer also has the advantage of not
wasting space for skipped AIC mode 1 VLCs.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
RealVideo 4.0 has a VLC that encodes two intra types per code; each
intra type is in the range 0..8 (inclusive) and up until now the VLC
used symbols in the range 0..80; one type was encoded as the remainder
when dividing the symbol by 9 whereas the other type was encoded as
symbol / 9. This is suboptimal; a better way would be to use the high
and low nibble to encode each symbol. But an even better way is to use
16bit symbols so that the two intra types can be directly written as
a 16bit value.
This commit implements this; in order to avoid huge tables the symbols
are stored as uint8_t with high and low nibbles encoding one type each;
they are only unpacked to uint16_t during initialization.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
After permuting the codes, symbols and lengths tables used to initialize
the VLC so that the codes are ordered from left to right in the Huffman
tree, the codes become redundant as they can be easily computed from the
lengths at runtime; in this case one has to use explicit symbol tables,
but all the symbols used here fit into an uint8_t, whereas some codes
needed uint16_t. This saves about 1.6KB.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
After permuting the codes, symbols and lengths tables used to initialize
the VLCs so that the codes are ordered from left to right in the Huffman
tree, the codes become redundant as they can be easily computed from the
lengths at runtime (or at compile time with --enable-hardcoded-tables);
in this case one has to use explicit symbol tables, but all the symbols
used here fit into an uint8_t, whereas some codes needed uint16_t.
Furthermore, the codes had holes because the range of the symbols was not
contiguous; these have also been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If both codes, lengths and symbols tables are ordered so that the codes
are sorted from left to right in the tree, the codes can be easily
derived from the lengths and therefore become redundant. This is
exploited in this commit to remove the codes tables for the mobiclip
decoder; notice that tables for the run-length VLC were already ordered
correctly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, VLCs that were part of an array of VLCs were often not
initialized in a loop, but separately. The probable reason for this
was that these VLCs differed slightly in the parameters to be used for
them (i.e. the number of codes or the number of bits to be used
differs), so that one would have to provide these parameters e.g. via
arrays.
Yet these problems have actually largely been solved by now: The length
information is contained in a run-length encoded form that is the same
for all VLCs and both the number of codes as well as the number of bits
to use for each VLC can be easily derived from them.
There is just one problem to be solved: When the underlying tables have
a different number of elements, putting them into an array of arrays
would be wasteful; using an array of pointers to the arrays would
also be wasteful. Therefore this commit combines the tables into bigger
tables. (Given that all the length tables have the same layout this
applies only to the symbols tables.)
Finally, the array containing the offset of the VLC's buffer in the big
buffer has also been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Several of the quantisation VLCs come in pairs and up until now the
number of bits used for each VLC was set to the same value for both VLCs
in such a pair even when one of the two required only a lower number.
This is a waste given that the get_vlc2() call is compatible with these
two VLCs using a different number of bits (it uses vlc->bits).
Given that the code lengths are descending it is easily possible to know
the length of the longest code for a given VLC: It is the length of the
first one. With this information one can easily use the least amount of
bits.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
After permuting both length, code as well as symbol tables so that
the codes are ordered from left to right in the tree, it became apparent
that the length of the codes decreases from left to right. Therefore one
can run-length encode the lengths to save space. This commit implements
this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Andreas Rheinhardt