The original either reported 8 or 16-bit conversion from the
original, rather than being able to return the actual original.
This makes it usable in a situation where preserving exactness
is required.
It can't be higher than vps_max_sub_layers.
Do this while keeping the workaround for qsvenc_hevc calling ff_hevc_parse_sps()
without a vps_list, as in some cases it needs to parse an sps to generate a fake
vps derived from it.
Signed-off-by: James Almer <jamrial@gmail.com>
I.e. those that are only used to figure out input/output counts, since
some filters might expect a valid hw device in init and refuse to
initalize otherwise.
This requires complex filtergraphs to be created in a separate step
after parsing global options, after all hw devices are guaranteed to
exist.
Likely a tighter check can be done
Fixes: signed integer overflow: 3305606804154370442 * 8 cannot be represented in type 'long'
Fixes: 70449/clusterfuzz-testcase-minimized-ffmpeg_dem_WEBM_DASH_MANIFEST_fuzzer-4771166007918592
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This basically ignores the overflow without undefined behavior, alternatively we could detect and error out
Fixes: signed integer overflow: 6310596683470275584 + 7660622966157213696 cannot be represented in type 'long'
Fixes: 70433/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-5483347233538048
Fixes: 369662284/clusterfuzz-testcase-minimized-media_metadata_parser_fuzzer-5327368763670528
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Depending on the magnitude of the output values, the potential
errors can be larger.
This fixes errors in the lls tests on x86_32 for some seeds,
observed with GCC 11 (on Ubuntu 22.04, with the distro compiler,
with -m32).
Signed-off-by: Martin Storsjö <martin@martin.st>
Use "bx lr", or "pop {lr}", which do proper mode switching
between thumb and arm modes. A plain "mov pc, lr" does not switch
from thumb mode to arm mode (while in arm mode, it does switch
mode for a thumb caller).
This is normally not an issue, as CONFIG_THUMB only is enabled if
the C compiler defaults to thumb; but stick to patterns that can
do mode switching if needed, for consistency.
Signed-off-by: Martin Storsjö <martin@martin.st>
Used as an intermediate entry point for the new swscale context. The extra
constification is a consistency measure, as I want to move the memcpy of
stride and plane pointers to the functions that actually need to mutate them.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of taking an int16_t pointer and a stride in halfwords, follow the
usual convention of treating all planes and strides as byte-addressed.
This does not have any immediate effect but makes these functions more
reusable without unintended "gotchas".
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This fixes an 11-year-old bug in the rgb2xyz functions, when used with a
negative stride. The current loop bounds turned it into a no-op.
Additionally, this increases performance on highly cropped images, whose
stride may be substantially higher than the effective width.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
The flexible array member struct can have padding added by
the compiler which was not taken into account properly, which
could lead to a heap buffer overflow.
spirv_compiler is an undeclared variable that was spontaneously
enabled if libshaderc or libglslang were detected, and served as
a way to enable filters.
However, it being undeclared had the effect that it was neither
considered explicitly disabled nor enabled if libshaderc or
libglslang were detected.
The only category we have which explicitly disables variables
is EXTERNAL_LIBRARY_LIST, however, spirv_compiler is not a real
external library, and making it present there would report its
detection on ./configure.
If someone were to enable libglslang/libshaderc, and then disable
all Vulkan filters, they would have the same issue as the earlier
fix for libavcodec.
