Unnecessary since acf63d5350adeae551d412db699f8ca03f7e76b9;
also avoids relocations.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The encoder is fixed point, and uses an MDCT only for analysis. Due
to the slightly different rounding, the encoder makes a different
decision, so the tests have to be adjusted as well.
AVCodec.channel_layouts is deprecated and Clang (unlike GCC)
warns when setting this field in a codec definition.
Fortunately, Clang (unlike GCC) allows to use
FF_DISABLE_DEPRECATION_WARNINGS inside a definition (of an FFCodec),
so that one can create simple macros to set AVCodec.channel_layouts
that also suppress deprecation warnings for Clang.
(Notice that some of the codec definitions were already
inside FF_DISABLE/ENABLE_DEPRECATION_WARNINGS (that were not
guarded by FF_API_OLD_CHANNEL_LAYOUT); these have been removed.
Also notice that setting AVCodec.channel_layouts was not guarded
by FF_API_OLD_CHANNEL_LAYOUT either, so testing disabling it
it without removing all the codeblocks would not have worked.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_encode_preinit() ensures that the channel layout is equivalent
to one of the channel layouts in AVCodec.ch_layout; given that
all of these channel layouts have distinct numbers of channels,
one can therefore uniquely determine the channel layout by
the number of channels.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This encoder has AVCodec.ch_layouts set, so ff_encode_preinit()
ensures that the used channel layout is equivalent to one of
these.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, initializing the dca VLC tables uses ff_init_vlc_sparse()
with length tables of type uint8_t and code tables of type uint16_t
(except for the LBR tables, which uses length and symbols of type
uint8_t; these tables are interleaved). In case of the quant index
codebooks these arrays were accessed via tables of pointers to the
individual tables.
This commit changes this: First, we switch to ff_init_vlc_from_lengths()
to replace the uint16_t code tables by uint8_t symbol tables
(this necessitates ordering the tables from left-to-right in the tree
first). These symbol tables are interleaved with the length tables.
Furthermore, these tables are combined in order to remove the table of
pointers to individual tables, thereby avoiding relocations (for x64
elf systems this amounts to 96*24B = 2304B saved in .rela.dyn) and
saving 1280B from .data.rel.ro (for 64bit systems). Meanwhile the
savings in .rodata amount to 2709 + 2 * 334 = 3377B. Due to padding
the actual savings are higher: The ELF x64 ABI requires objects >= 16B
to be padded to 16B and lots of the tables have 2^n + 1 elements
of these were from replacing uint16_t codes with uint8_t symbols;
the rest was due to the fact that combining the tables eliminated
padding (the ELF x64 ABI requires objects >= 16B to be padded to 16B
and lots of the tables have 2^n + 1 elements)). Taking this into
account gives savings of 4548B. (GCC by default uses an even higher
alignment (controlled by -malign-data); for it the savings are 5748B.)
These changes also necessitated to modify the init code for
the encoder tables.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the encoder used the same tables that the decoder
uses to create its VLCs. These have the downside of requiring
the encoder to offset the tables at runtime as well as having
to read from separate tables for the length as well as the code
of the symbol to encode. The former are uint8_t, the latter uint16_t,
so using a joint table would require padding, but this doesn't
matter when these tables are generated at runtime, because they
live in the .bss segment.
Also move these init functions as well as the functions that
actually use them to dcaenc.c, because they are encoder-specific.
This also allows to remove an inclusion of PutBitContext from
dcahuff.h (and indirectly from all dca-decoder files).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It reduces typing: Before this patch, there were 105 codecs
whose long_name-definition exceeded the 80 char line length
limit. Now there are only nine of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
and remove FF_CODEC_CAP_INIT_THREADSAFE
All our native codecs are already init-threadsafe
(only wrappers for external libraries and hwaccels
are typically not marked as init-threadsafe yet),
so it is only natural for this to also be the default state.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible, because every given FFCodec has to implement
exactly one of these. Doing so decreases sizeof(FFCodec) and
therefore decreases the size of the binary.
Notice that in case of position-independent code the decrease
is in .data.rel.ro, so that this translates to decreased
memory consumption.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This structure is no longer declared in a public header,
so using an FF-prefix is more appropriate.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, codec.h contains both public and private parts
of AVCodec. This exposes the internals of AVCodec to users
and leads them into the temptation of actually using them
and forces us to forward-declare structures and types that
users can't use at all.
This commit changes this by adding a new structure FFCodec to
codec_internal.h that extends AVCodec, i.e. contains the public
AVCodec as first member; the private fields of AVCodec are moved
to this structure, leaving codec.h clean.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also move FF_CODEC_TAGS_END as well as struct AVCodecDefault.
This reduces the amount of files that have to include internal.h
(which comes with quite a lot of indirect inclusions), as e.g.
most encoders don't need it. It is furthemore in preparation
for moving the private part of AVCodec out of the public codec.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since the removal of the 16-bit FFT said define is unnecessary as
FFT_FIXED_32 is always !FFT_FLOAT. But one wouldn't believe it when
looking at the code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the packet size is known in advance like here, one can avoid
an intermediate buffer for the packet data by using
ff_get_encode_buffer() and also set AV_CODEC_CAP_DR1 at the same time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Given that the AVCodec.next pointer has now been removed, most of the
AVCodecs are not modified at all any more and can therefore be made
const (as this patch does); the only exceptions are the very few codecs
for external libraries that have a init_static_data callback.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Functionally identical to the old code, with less lines wasted.
Partially fixes the complete disregard for the 80 col/line guide.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
The encoder didn't clean up if a malloc failed during init.
It also doesn't need any external tables to be initialized on init.
Finally, it didn't need to check for whether avctx->priv_data exists during
uninit.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Old behaviour - abort if at least one subband has 1bit quantizer
and consumed_bits still greater than frame_bits size. It was
a bit strange - we still could reduce bits consumption by reducing
SNR for other subbands. Same strange logic with upper threshold -
stop bits allocation if at least one subband reach 26bits.
New behaviour - if consumed_bits greater than frame_bits and all
subbands has 1 bit quantizer we restart bits allocation and allow
zero subbands.
DCA core decoder no longer uses fixed tables for channel reordering.
Move them into private encoder header (and drop ff_dca_ prefix).
Signed-off-by: James Almer <jamrial@gmail.com>
The idea is to use ffmath.h for internal implementations of math functions.
Currently, it is used for variants of libm functions, but is by no means
limited to such things.
Note that this is not exported; use lavu/mathematics for such purposes.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanag@gmail.com>
This parameter can be used to inform the allocation code about how much
downsizing might occur, and can be used to optimize how to allocate the
packet
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Anton Khirnov
Andreas Rheinhardt
Lynne
Andreas Rheinhardt
Michael Niedermayer
Rostislav Pehlivanov
Daniil Cherednik
Carl Eugen Hoyos
foo86
Ganesh Ajjanagadde
Paul B Mahol
Ganesh Ajjanagadde
James Almer
Michael Niedermayer
Lou Logan