1
0
mirror of https://github.com/FFmpeg/FFmpeg.git synced 2024-12-28 20:53:54 +02:00
Commit Graph

8 Commits

Author SHA1 Message Date
Andreas Rheinhardt
b52e0d9504 avcodec/atrac9tab: Unify tables used to initialize VLCs
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>
2020-12-08 17:51:46 +01:00
Andreas Rheinhardt
5ac9d78dd2 avcodec/atrac9dec: Make tables used to initialize VLCs smaller
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>
2020-12-08 17:51:46 +01:00
Andreas Rheinhardt
164ce14e5c avcodec/atrac9tab: Add missing static to internal table
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
2020-11-24 11:35:03 +01:00
Andreas Rheinhardt
92209cf4c9 avcodec/atrac9dec: Don't confuse max_depth of VLC with max codelength
The whole point of VLCs with their tables is to read more than one bit
at a time; therefore max_depth, the number of times one has to
(maximally) read further bits is given by ceil(max_code_length / table_bits)
which in the case of ATRAC9's coefficient VLCs gives an upper bound of
two. Instead the maximum length of a code of the given VLC has been used
(which is not even a compile-time constant). Use two instead.

Furthermore, given that this was the only usage of the field containing
the maximum of all the code lengths of a given VLC the field has been
removed from its containing struct.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
2020-11-24 11:35:03 +01:00
James Almer
78a24fd014 avcodec/atrac9tab: use explicit ATRAC9BlockConfig struct initializers
Cosmetic change.

Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: James Almer <jamrial@gmail.com>
2019-10-22 10:49:30 -03:00
James Almer
a61b56624b avcodec/atrac9tab: add missing header include
Fixes make checkheaders

Signed-off-by: James Almer <jamrial@gmail.com>
2018-07-04 15:56:44 -03:00
Carl Eugen Hoyos
e25c25ebd8 lavc/atrac9tab: Add inclusion guards.
Fixes fate-source.
2018-07-04 18:54:44 +02:00
Rostislav Pehlivanov
755e618399 lavc: implement an ATRAC9 decoder
This commit implements a full ATRAC9 decoder, a simple low-delay codec
developed by Sony and used in most PSVita games, some PS3 games and some
PS4 games. Its similar to AAC in that it uses Huffman coded scalefactors
but instead of vector quantization it just Huffman codes the spectral
coefficients (in a way similar to how Opus splits band energy coding
into coarse and fine precision). It opts to write rather large Huffman
codes by packing several small coefficients into one Huffman coded
symbol, though I don't believe this increases efficiency at all.
Band extension implements SBC in a simple way, first it mirrors the
lower spectrum onto the higher frequencies and then it uses one of 5
filters to shape it. Noise substitution is implemented via 2 of them.
Unlike previous ATRAC codecs, there's no QMF, this is a standard MDCT
codec.

Based off of the reverse engineering work of Alex Barney.

Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
2018-07-03 20:15:01 +01:00