av_realloc_f() frees the buffer it is given on allocation
failure. But in this case, the buffer is an array of
ownership pointers, causing leaks on error. Furthermore,
the count of pointers is unchanged on error and the codec's
close function uses it to free said ownership pointers,
causing a NPD.
This is a regression since 46412a8935.
Fix this by switching to av_realloc_array().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The alignment of all the parameters in diff_bytes can be
anything the despite the documentation claiming otherwise.
8ecd383122 was based around
said documentation and is therefore insufficient to fix
e.g. the misaligned loads that happen in the huffyuvbgra
and huffyuvbgr24 vsynth FATE-tests.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use SHLIBOBJS and STLIBOBJS in the Makefiles for avcodec and avformat,
and add a stub ffjni.c to libavformat, which allows the symbols to be
duplicated for shared builds but not static builds.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Fixes: signed integer overflow: -2088796289 + -91276551 cannot be represented in type 'int'
Fixes: 67772/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVARC_fuzzer-6533568953122816
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The LC3 audio codec is the default codec of Bluetooth LE audio.
This is a wrapper over the liblc3 library (https://github.com/google/liblc3).
Signed-off-by: Antoine Soulier <asoulier@google.com>
A namespace is unnecessary here given that all these files
are already in the vvc subfolder.
Reviewed-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Newer specifications such as H.273 have, and probably will further
in the future add new values to these, so - instead of trying to update
these limits - we should simply check if the values are not set to the
value of "unspecified".
This should allow newer avutil values such as IPT-C2 or YCgCo-R
variants be passed to x265 itself, which apparently does its own
validation further down the line.
Once upon a time, there used to be a LGPL and a GPL ProRes decoder
in FFmpeg; the current decoder evolved from the second of these.
But given that it is now the only ProRes decoder we have, it's file
should simply be named proresdec.c (which also brings it in line with
its header).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We split the inner loop between v1 and v2 extension blocks to print
a warning where an extension block was encountered in an unexpected
context.
Co-authored-by: quietvoid <tcChlisop0@gmail.com>
The Dolby Vision RPU contains a CRC32 to validate the payload against.
The implementation is CRC32/MPEG-2.
The CRC is only verified with the AV_EF_CRCCHECK flag.
Co-authored-by: quietvoid <tcChlisop0@gmail.com>
This ensures that `gb` in the following section is fully byte-aligned,
points at the start of the actual RPU, and ends on the CRC terminator.
This is important for both calculation of the CRC, as well as dovi
extension block parsing (which aligns to byte boundaries in various
places).
The NLQ pivots are not documented but should be present in the header
for profile 7 RPU format. It has been verified using Dolby's
verification toolkit.
Signed-off-by: quietvoid <tcChlisop0@gmail.com>
Signed-off-by: Niklas Haas <git@haasn.dev>
Fixes: negation of -2147483648 cannot be represented in type 'int32_t' (aka 'int'); cast to an unsigned type to negate this value to itself
Fixes: 67738/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5444313212321792
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
VLC_MULTI_ELEM contains an uint8_t array that is supposed
to be treated as an array of uint16_t when the used symbols
have a size of two; otherwise it should be treated as just
an array of uint8_t, but it was not always treated that way:
vlc_multi_gen() initialized the first entry of the array
by writing the symbol via AV_WN16; on big endian systems,
the intended value was instead written into the second entry
of the array (where it would likely be overwritten lateron
during initialization).
read_vlc_multi() also treated this case incorrectly: In case
the code is so long that it needs a classical multi-stage lookup,
the symbol has been written to the destination as if via AV_WN16.
On little endian systems, this sets the correct first symbol and
clobbers (zeroes) the next one, but the next one will be overwritten
lateron anyway, so it won't be recognized. But on big-endian systems,
the first symbol will be set to zero and the actually read symbol
will be put into the slot for the next one (where it will be overwritten
lateron).
This commit fixes this; this fixes the magicyuv and utvideo FATE-tests
on big endian arches.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
