Whether lowres is in use or not is inlined in
mpv_reconstruct_mb_internal(), so one can use the fact
that lowres is always zero during encoding to evaluate
the checks for whether one is encoding or not at compile-time
when one is in lowres mode.
Also reorder the main check to check for whether it is an encoder
first to shortcircuit it in the common case of a decoder.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The very first check in this if-else if-else if construct is
"if (s->encoding ||", i.e. in case of the WMV2 encoder the else
branches are never executed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The a53_cc option is only useful and meaningful for MPEG-2,
yet it was accidentally added for all mpegvideo-based encoders.
This means that it is possible for a53_cc to be set for other
encoders as well.
This commit changes this and reroutes a53_cc to the dummy field
in MpegEncContext for all codecs for which it is not supported.
This allows to avoid a check for the current codec in mpeg12enc.c.
Also add a compile-time check for whether the MPEG-2 encoder is
available while at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that MJpegContext is allocated jointly
with MpegEncContext as part of the AVCodecContext's private data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This factors the translation from MpegEncContext out
and will enable further optimizations in the next commits.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The generic code ensures that only codecs with
the FF_CODEC_CAP_AUTO_THREADS internal cap ever have to
handle the case avctx->thread_count == 0 themselves;
moreover, it is also ensured generically that only codecs
that support some form of threading have thread_count set
to something else than one. So these checks are unnecessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently, ff_mpv_encode_end() is the close function of
the two MJPEG-based encoders; it calls ff_mjpeg_encode_close()
for them which adds a check to the generic code.
This commit reverses the order of this relationship:
The MJPEG encoders directly use a custom close function
which in turn calls ff_mpv_encode_end(). This avoids the branch
in ff_mpv_encode_end() and makes the generic code more generic.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fix warning caused by this field changing from uint64_t to uint16_t.
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This reverts commit 2589060b92 which was
originally to fix the FATE test. The real cause of the test breakage was
fixed in 22b7c37275.
Signed-off-by: J. Dekker <jdek@itanimul.li>
The assembly is written assuming that the width is a multiple of 8.
However the real issue is the functions were errorneously assigned to
the 2, 4, 6 & 12 widths. This behaviour never broke the decoder as
samples which trigger the functions for these widths have not been found
in the wild. This relies on the mappings in ff_hevc_pel_weight[].
Signed-off-by: J. Dekker <jdek@itanimul.li>
This is done a second time for 5.0 because master was
merged into 5.0 so that it contains the recent DOVI additions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, we had a PacketList structure which is actually
a PacketListEntry; a proper PacketList did not exist
and all the related functions just passed pointers to pointers
to the head and tail elements around. All these pointers were
actually consecutive elements of their containing structs,
i.e. the users already treated them as if they were a struct.
So add a proper PacketList struct and rename the current PacketList
to PacketListEntry; also make the functions use this structure
instead of the pair of pointers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This function is quite small (96B with GCC 11.2 on x64 Ubuntu 21.10
at -O3), making it more economical to duplicate it into libavformat
instead of exporting it as avpriv: Doing so saves 2x24B in .dynsim,
2x16B in .dynstr, 2x2B .gnu.version, 24B in .rela.plt, 16B in .plt,
16B in .plt.sec (if enabled), 4B .gnu.hash; besides the actual
duplicated code this also adds 2x8B .eh_frame_hdr and 24B .eh_frame.
In other words: Duplicating is neutral size-wise (it is also presumed
neutral for other systems). Given that it avoids the runtime
overhead of dynamic symbols, it is advantageouos to duplicate the
function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These arrays have a size of 180 resp. six bytes. This does not
make it worthwhile to export them due to the overhead this occurs;
for x64 Elf/Linux/GNU: 2x2B version, 2x24B .dynsym, 24B .rela.dyn,
8B .got, 4B hash + twice the size of the name (here 20+23B).
Therefore these symbols are unavprived and duplicated for shared
builds.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avpriv_mpeg4audio_sample_rates has a size of 64B and it is currently
avpriv; a clone of it exists in aacenctab.h and from there it is inlined
in aacenc.c (which also uses the avpriv version) and in the FLV muxer.
This means that despite it being avpriv both libavformat as well as
libavcodec have copies already.
This situation is clearly suboptimal. Given the overhead of exporting
symbols (for x64 Elf/Linux/GNU: 2x2B version, 2x24B .dynsym, 24B .rela.dyn,
8B .got, 4B hash + twice the size of the name (here 31B)) the object is
unavprived, i.e. duplicated into libavformat when creating a shared
build; but the duplicates in the AAC encoder and FLV muxer are removed.
This involves splitting of the sample rate table into a file of its own;
this allowed to break some spurious dependencies (e.g. both the AAC
encoder as well as the Matroska demuxer actually don't need the
mpeg4audio_get_config stuff).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This group is mainly for the users of *_mpeg4audio_get_config2();
it is not for those who only use avpriv_mpeg4audio_sample_rates.
This is in preparation for splitting the latter into a file of its own;
if there were no CONFIG_EXTRA group for *_mpeg4audio_get_config2()
users, one would have to add a dependency to the new file for all
these users on top of the existing dependency on mpeg4audio.o.
Adding a new CONFIG_EXTRA group only takes effect after a reconfigure;
so in order to force a reconfigure some unnecessary headers from
libavdevice/alldevices.c have been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are seven MJPEG-tables, five small (1x12, 4x17) and two
not small (2x162). These are all avpriv, despite this not being
worthwhile due to the overhead of exporting a symbol: The total
overhead for each symbol consists of two entries in .dynsym (24B each),
one entry in the importing library's .rela.dyn (24B) and one in .got
(8B) as well as 2x2B for symbol versions and 4B for symbol hashes
in the exporting library; in addition to that, the name of the symbol
is included in both exporting and importing libraries, using 2x210 bytes
in this case.
(The above numbers are for a x64 Elf/Linux/GNU system. Other platforms
will give different numbers.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Said table is 64 bytes long and exported so that it can be used both
in libavcodec and libavformat. This commit stops doing so and instead
duplicates it for shared builds, because the overhead of exporting the
symbol is bigger than 64 bytes. It consists of the length of the name of
the symbol (2x24 bytes), two entries in .dynsym (2x24 bytes), two
entries for symbol version (2x2 bytes), one hash value in the exporting
library (4 bytes) in addition to one entry in the importing library's
.got and .rela.dyn (8 + 24 bytes).
(The above numbers are for a Linux/GNU/Elf system; the numbers for other
platforms may be different.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is small (16 B) and therefore the overhead of exporting it more
than outweighs the size savings from not having duplicated symbols:
When the symbol is no longer avpriv, one saves twice the size of
the string containing the symbols name (2x30 byte), two entries
in .dynsym (24 bytes each on x64), one entry in the importing libraries
.got and .rela.dyn (8 + 24 bytes on x64) and two entries for the
symbol version (2 bytes each) and one hash value in the exporting
library (4 bytes).
(The exact numbers are of course different for other platforms
(e.g. when using dlls), but given that the strings saved alone
more than outweigh the array size it can be presumed that this
is beneficial for all platforms.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
