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>
Such frames will crash when pthread functions are called on the NULL pointer
Fixes: member access within null pointer of type 'VVCFrameThread' (aka 'struct VVCFrameThread')
Fixes: 65160/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_METADATA_fuzzer-4665241535119360 (partly)
Fixes: 65636/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-5394745824182272
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also move AV_CHECK_OFFSET to its only user, namely
lavc/arm/mpegvideo_arm.c and rename it to CHECK_OFFSET.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.
Keep it for external users in order to not cause breakages.
Also improve the other headers a bit while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also update the checks that guard against inserting
a new enum entry in the middle of a range.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In particular, declare iterators with loop scope.
Also remove av_uninit while at it, because they
are now unnecessary due to the changes of the preceding
commit.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
While this change IMO makes the control flow clearer
for the human reader, it is especially important for
GCC: It erroneously believes that it is possible to
enter the SHORT2(UNUSED|LONG) cases without having
entered the preceding block that initializes pic,
frame_num, structure and j; it would emit -Wmaybe-uninitialized
warnings for these variables if they were not pseudo-
initialized with av_uninit(). This patch allows to remove
the latter.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
HEVCHdrParams* receives a pointer which points to a dynamically
allocated memory block. It causes the memcmp always returning 1.
Add a function to do the comparision. A condition is also added to
avoid malloc(0).
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Tong Wu <tong1.wu@intel.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Also rewrite the code so that a variable that is only used
depending upon CONFIG_LIBVPX_VP9_ENCODER is not declared
outside of the #if block.
(The variable was declared with av_uninit, but it should have been
av_unused, as the former does not work for all compilers.)
Reviewed-by: James Zern <jzern@google.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
hevc_data.c only provides ff_hevc_diag_scan tables and
neither the QSV HEVC encoder nor the HEVC parser use these
directly and the indirect dependency is already accounted
for in the dependencies of the hevcparse subsystem since
b0c61209cd, so remove these
spurious dependencies.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is highly unsafe, as AVCodecContext contains many allocated fields.
Almost everything needed by worker threads should be covered by
routing through AVCodecParameters and av_opt_copy(), except for a few
fields that are copied manually.
avcodec_free_context() can now be used for per-thread contexts.
