Split packed data in case of its contains multiple show frame in some
non-standard bitstream. This can benefit decoder which can decode
continuously instead of interrupt with unexpected error.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
(cherry picked from commit 7787cca18016c1f8100ab158f3479ba4b7e70467)
While this function on its own passes all of fate-hevc, there's
indications that the function might need to handle widths that
aren't a multiple of 8 (noted in commit
f63f9be37c799ddc835af358034630d31fb7db02, which later was
reverted).
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 24b93022fee322c7a17e326e2d162a1fbc3698ee)
In this case ff_isom_put_dvcc_dvvc() might not be available, leading
to linking failures. Given that WebM currently doesn't support DOVI,
this is fixed by #if'ing the offending code away if the Matroska
muxer is not enabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 217c90aac70af35e34381d7a99b4407686a3f47b)
Reviewed-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 41c62207f641b5cf3ae656068652f7dc958d5e79)
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 6e163619e3e46e719903de3271e8c1b850b7d501)
Forgotten in 555f5c1fc5ae0c4e7b0431dc3166c3fcf3f4e979.
Reviewed-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit df4cb384fb68454e23f8cc2b369e344c1bd8be7d)
This fixes compilation errors in case nvenc is enabled
(e.g. autodected) with both nvenc-based encoders disabled
because nvenc uses ff_alloc_a53_sei(), yet only the nvenc-based
encoders require atsc_a53.
(This error does not manifest itself in case of static linking
(nothing pulls in nvenc.o), but it exists with shared builds.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Forgotten in 3cc3f5de2afda5b8f880c0817e9d67c2dafbfe1e.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit aa8bb05d29599fb5372a715d30c290c7b723c24b)
mpegaudiodec_template.c uses stuff from mpegaudiodata directly,
yet this dependency was only indirectly fulfilled via mpegaudio-headers
before 33e6d57f01dd4742a2e25ac5fa072b487d9d02ce. Since this commit,
the latter only needs (and therefore provides) mpegaudiotabs,
leading to compilation failures.
This commit adds this missing direct dependency directly.
(Sorry for not having checked indirect dependencies.)
Found-by: Zane van Iperen <zane@zanevaniperen.com>
Reviewed-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 07fd34aca744d6ae64cd4756943ce508ee0f9973)
libplacebo supports automatic dolby vision application, but it requires
us to switch to a new API. Also add some logic to strip the dolby vision
metadata from the output frames in any case where we end up changing the
colorimetry.
The libplacebo dependency bump is justified because neither 184 nor 192
are part of any stable libplacebo release, so users have to build from
git anyways for this filter to exist.
Signed-off-by: Niklas Haas <git@haasn.dev>
- No longer mixes u8 and u16 component accesses (this was UB)
- De-duplicated 8->16 conversion
- De-duplicated component -> plane+offset conversion
- De-duplicated planar + packed RGB
- No longer calls ff_fill_rgba_map
- Removed redundant comp_mask data member
- RGB0 and related formats no longer write an alpha value to the 0 byte
- Non-planar YA formats now work correctly
- High-bit-depth semi-planar YUV now works correctly
Same outputs, but computed instead of statically known, so new formats will be
supported more easily. Asserts in place to ensure we update this if we add
anything incompatible with its logic.
Please reproduced with the following minimal configure command:
./configure --enable-shared --disable-all --enable-avcodec --enable-decoder=h264 --enable-hwaccel=h264_videotoolbox
You'll get below error:
Undefined symbols for architecture x86_64:
"_ff_videotoolbox_vpcc_extradata_create", referenced from:
_videotoolbox_start in videotoolbox.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Reported-by: Cameron Gutman <aicommander@gmail.com>
Tested-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Limin Wang <lance.lmwang@gmail.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>
(cherry picked from commit 10e4b2b1d243435445ff537cc9e3948b7490eb5b)
This is necessary to have the recent DOVI additions
in the 5.0 release.
Merged-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
libavcodec currently exports four avpriv symbols that deal with
PixelFormatTags: avpriv_get_raw_pix_fmt_tags, avpriv_find_pix_fmt,
avpriv_pix_fmt_bps_avi and avpriv_pix_fmt_bps_mov. The latter two are
lists of PixelFormatTags, the former returns such a list and the second
searches a list for a pixel format that matches a given fourcc; only
one of the aforementioned three lists is ever searched.
Yet for avpriv_pix_fmt_bps_avi, avpriv_pix_fmt_bps_mov and
avpriv_find_pix_fmt the overhead of exporting these functions actually
exceeds the size of said objects (at least for ELF; the following numbers
are for x64 Ubuntu 20.10):
The code size of avpriv_find_pix_fmt is small (GCC 10.2 37B, Clang 11 41B),
yet exporting it adds a 20B string for the name alone to the exporting
as well as to each importing library; there is more: Four bytes in the
exporting libraries .gnu.hash; two bytes each for the exporting as well
as each importing libraries .gnu.version; 24B in the exporting as well
as each importing libraries .dynsym; 16B+24B for an entry in .plt as
well as the accompanying relocation entry in .rela.plt for each
importing library.
The overhead for the lists is similar: The strings are 23B and the
.plt+.rela.plt pair is replaced by 8B+24B for an entry in .got and
a relocation entry in .rela.dyn. These lists have a size of 80 resp.
72 bytes.
Yet for ff_raw_pix_fmt_tags, exporting it is advantageous compared to
duplicating it into libavformat and potentially libavdevice. Therefore
this commit replaces all library uses of the four symbols with a single
function that is exported for shared builds. It has an enum parameter
to choose the desired list besides the parameter for the fourcc. New
lists can be supported with new enum values.
Unfortunately, avpriv_get_raw_pix_fmt_tags could not be removed, as the
fourcc2pixfmt tool uses the table of raw pix fmts. No other user of this
function remains.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
