The code uses int, unsigned int and uint16_t to store num_entry_point_offsets
This limits it to the smallest of the 3.
Alternatively uint16_t can be changed and then a larger limit used.
A Check will still be needed.
Fixes: 391974932/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5966648879677440
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It invalidates (removes by duplicates) AVCodecContext.extradata
and AVCodecContext.coded_side_data which is quite surprising
and leads to bugs like #11617 where an AVCPBProperties
is used after it has been freed in ff_dovi_configure().
Reported-by: Ayose
Reviewed-by: Niklas Haas <ffmpeg@haasn.xyz>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This happens on systems where get_pixels really needs
to be properly aligned, like ARMV7 or RISC-V. For these
systems, 0401ca714a caused
a bus error for the vsynth3-asv[12] tests, because
the stride in these tests is unaligned. See e.g.
https://fate.ffmpeg.org/report.cgi?slot=armv7-linux-gcc-13&time=20250527020548https://fate.ffmpeg.org/report.cgi?slot=rv64gcvb-linux-gnu-gcc&time=20250527001827
It can also happen (even before said commit) if the pointers
itself are unaligned, e.g. by using the crop filter:
ffmpeg -filter_complex nullsrc=s=740x576:r=25,format=yuv420p,crop=w=720:x=2 \
-c:v asv2 -f null -
The alignment requirements for the frames passed to encoders are
mostly undocumented; the only thing I could find is the documentation
of AVFrame.linesize: "For video the linesizes should be multiples
of the CPUs alignment preference". This means that the FFmpeg cli
violates our API.
Yet as the above command line shows, it can also happen with
unaligned pointers and there does not seem to be a prohibition
of this, so we need to handle this case. This commit does so
by using get_pixels_unaligned when needed.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Check the alpha plane for (almost) transparent frames, instead of checking
the luma channel for almost black frames.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: nxtedition
Up until now, our muxer wrote FFV1 in video-for-windows
compatibility mode out of concern for old demuxers that
only support that (whereas the demuxer accepts V_FFV1).
This commit switches to using native mode, because
a) V_FFV1 is around long enough so that old demuxers
should not be an issue (support in FFmpeg has been added
in commit 9ae762da7e
in March 2017/FFmpeg 3.3),
b) using native mode uses fewer bytes for the CodecPrivate,
c) the VfW extradata is zero-padded to an even length
if necessary, but our demuxer forgot to undo the padding
until very recently (92e310eb82),
so that there are many versions of our demuxer around that
are buggy wrt VFW, but not V_FFV1.
This affects the FFV1 extradata checksums, specifically
the (experimental) version 4 files with error check version 2*
as created by
ffmpeg -i ../fate-suite/mpeg2/sony-ct3.bs -c:v ffv1 \
-slices 16 -frames 1 -level 4 -strict experimental ffv1.mkv
VFW files like the above created by this muxer before this patch
would not work with an old demuxer.
*: Without error check version 2, the CRC for the whole extradata
is zero, which is not changed by appending a zero byte.
Reviewed-by: compn <ff@hawaiiantel.net>
Reviewed-by: Dave Rice <dave@dericed.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Legal since commit 1cd0a9be4b2d1e7c60184ec68404e00e46e3123e
(Jan 4) in the Cellar Matroska specification git repo.
We still hold out on muxing it due to compatibility with
old demuxers.
Reviewed-by: compn <ff@hawaiiantel.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
- merge forgotten uninit from work branch
- add set_str() function to free before overwriting
- fix some other leaks
Signed-off-by: softworkz <softworkz@hotmail.com>
The structure is padded to an even length with an internal
size field to indicate the real size.
The matroska-matroska-display-metadata test (writing FFV1
in VFW mode) was affected by this.
It should also fix ticket #11613.
Reviewed-by: compn <ff@hawaiiantel.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
crcref needs to be set properly iff ec is two, regardless
of whether it has been explicitly set by the user or set
by default based on level/version.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
On msys2, `uname -m` returns the architecture of the base msys2
layer. On Windows on arm64, the base msys2 layer itself is still
x86_64 only, even if running with e.g. the clangarm64 where the
windows native applications are built as aarch64.
If MSYSTEM_CARCH is set, use this instead of `uname -m` for
the default architecture. This gives the correct behaviour
for the clangarm64 environments. It also gives the correct
default for the 32 bit x86 environments such as `mingw32`.
(On `mingw32`, the fact that `uname -m` returned `x86_64`
hasn't been an issue, as both that and `i686` gets normalized
into `x86` internally in ffmpeg's configure.)
Signed-off-by: Coia Prant <coiaprant@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
It is only used to indicate to ff_h263_show_pict_info()
that we are decoding H.263+; pass this information
via a function parameter instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This means that these buffers won't be allocated any more
for H.263+ with AIC disabled.
Also remove setting h263_plus for the RV20 encoder,
as it has only been done to force allocating dc_val.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Just ensure that dct_unquantize_inter is set iff it is used
and check for the function pointer instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows to remove checks from ff_xvid_idct_init()
(and also the AVCodecContext* parameter).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_xvid_idct_init() is now only called from ff_idctdsp_init()
and only if idct_algo is FF_IDCT_XVID.
This also implies that it is unnecessary to initalize
the permutation on our own.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unnecessary: If the dst context is not already initialized,
then it will be initialized by memcpy(dst, src, sizeof(*dst),
which already initializes the IDCT to the desired one, potentially
followed by ff_mpv_common_init(), which does not touch the IDCT.
(This call has been added in f89d76c10355242c39b08f253c1d1524f45ef778;
the aforementioned copying took place back then, too, but
ff_mpv_common_init() reinitialized the IDCT to a non-xvid one,
therefore the initialization here has been added to fix
multithreaded decoding.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These are sufficiently different to warrant their own functions;
in particular, the earlier code had two callsites for the actual
"write block" function, one for intra and one for inter, yet
the "write block" function nevertheless performed a check
(that the compiler can't optimize away) for whether the current
MB is intra or not.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
While it offers modest speedups compared to the ordinary code,
removing it completely offers even bigger speedups; and given
that these speedups also exist in the ordinary mode, they are
even more important. The no-output code has a 7.8% performance
improvement (based on benchmarking mpeg4_encode_mb()), yet
removing the no-output code resulted in a 9.4% improvement.
Furthermore, the no-output code was broken for the majority of
its existence (until 9207dc3b0d)
and no one complained, so it is likely not used at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
