Fixes: signed overflow
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 566e9032b1)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If this function returns an error after ff_sws_graph_add_pass() has been
called, and the pass->free callback is therefore already set up to free the
context, the graph will end up freed twice: once by the pass->free callback
(during ff_sws_graph_free()), and once before that by failure path of the
caller (e.g. add_legacy_sws_pass(), or init_legacy_subpass() itself for
cascaded contexts.)
The solution is to redefine the ownership of SwsGraph to pass clearly from
the caller of add_legacy_sws_pass() to init_legacy_subpass(), which can then
deal with appropriately freeing the context conditional on whether or not the
pass was already registered in the pass list.
Reported-by: 김영민 <kunshim@naver.com>
Signed-off-by: Niklas Haas <git@haasn.dev>
(cherry picked from commit 4ede75b5f4)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
384fe39623 introduced a regression in the
range conversion offset calculation, resulting in a slight green tint
in full-range RGB to YUV conversions of grayscale values.
The offset being calculated was not taking into consideration a bias
needed for correctly rounding the result from the multiplication stage,
leading to a truncated value.
Fixes issue #11646.
(cherry picked from commit 4bee010844)
Avoids failure of xyz12 fate tests on mingw and linux x86-32
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit ca20d42cd7)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Dithering relies on a 8 line dithering table and the code always uses it from
the beginning. So in order to make dithering independent from height of the
slices used we must enforce a 8 line alignment.
Fixes issue #20071.
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit b61e510e75)
Ticket11686 hinted at one of these overflows
this fixes them all
Issue in line 1325/1326 found by HAORAN FANG <xfanghaoran@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This function overreads the input plane for odd dimensions, because the
chroma plane is always rounded up, which means (xy << subsample) + 1 exceeds
the actual alpha plane size.
To verify:
valgrind ffmpeg -pix_fmt yuva420p -f lavfi -i color -vf \
"scale=1x1,format=yuva420p,scale=alphablend=uniform_color,format=yuv420p \
-vframes 1 -f null -
Fixes: https://trac.ffmpeg.org/ticket/11692
Fixes: signed integer overflow: -132524 * 16525 cannot be represented in type 'int'
Fixes: 414862270/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-4869083202125824
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently, planarRgbToplanarRgbWrapper() always sets the alpha value to 255,
without taking the bit depth into consideration.
This commit restricts the alpha value to the bit depth.
Currently, packed16togbra16() always sets the alpha value to 0xFFFF,
without taking the bit depth into consideration.
This causes a bug on x86, which can be reproduced with:
./libswscale/tests/swscale -unscaled 1 -src xyz12le -dst gbrap12be
The problem arises in ff_hscale14to15_4_ssse3(), in the conversion
from gbrap12be to yuva444p, which comes after the conversion from
xyz12le to gbrap12be.
It has something to do with pmaddwd not working on unsigned values.
There is some code to deal with 0xFFFF if the input has a bit depth of
16, but not for bit depths < 16.
We could fix ff_hscale14to15_4_ssse3() to also work correctly with
0xFFFF on bit depths < 16, or we could just not write 0xFFFF there in
the first place, which is what this commit does.
Currently, packed30togbra10() always sets the alpha value to 0xFFFF,
without taking the bit depth into consideration.
This commit restricts the alpha value to the bit depth.
Currently, planarCopyWrapper() assumes that src[3] must be NULL when
the source format has no alpha plane.
This commit updates the condition for filling the alpha plane based on
the number of components available in the source format as well.
The current loop only works if the input and output have the same number
of planes. However, with the new scaling logic, we can also optimize into a
noop the case where the input has extra unneeded planes.
For the memcpy fallback to work in these cases we have to instead check if
the *output* pointer is set, rather than the input pointer.
The old limits were a bit too tightly clustered around 1.0. Make the
value range much more generous, and also introduce a new highlight
for speedups above 10.0 (order of magnitude improvement).
Fixes: signed integer overflow: -293650 * 16525 cannot be represented in type 'int'
Fixes: 408304111/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-4762210299871232
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int'
Fixes: division by zero
Fixes: 391981061/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-6691017763389440
Fixes: 392929028/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-5142088307507200
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 1966895953 + 210305024 cannot be represented in type 'int'
Fixes: 391921975/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-5916798905548800
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The conversion functions were added in
e7382b4d01, yet they were never
really enabled. Found via -ffunction-sections and --gc-sections.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Sometimes, the reference SSIM is significantly higher than the
SSIM level expected for the test. This is the case when the source format
has a much lower bit depth than the destination format. In this case, the fact
that legacy swscale does not accurately preserve the source dither pattern
gives it an unfair advantage in a direct comparison, leading to false
positives.
For example, conversion like rgb4 -> rgb565 should be lossless, but swscale
low passes / downscales the input chroma, throwing away massive amounts of
detail. This gives it a higher SSIM score since the lowpassed result removes
some of the dither noise that was present in the source.
We can calculate with some confidence the theoretical expected SSIM
from an "ideal" conversion, by computing the reference SSIM level
for an image dithered with uniformly distributed quatization noise.
This gives us an additional safety net to check for regressions even in
the absence of a reference to compare against.
And bias it towards Y. This is much better at ignoring errors due to differing
dither patterns, and rewards algorithms that lower luma noise at the cost of
higher chroma noise.
The (0.8, 0.1, 0.1) weights for YCbCr are taken from the paper:
"Understanding SSIM" by Jim Nilsson and Tomas Akenine-Möller
(https://arxiv.org/abs/2006.13846)
Instead of the lossy yuva420p. This does change the results compared to the
status quo, but is more reflective of the actual strength of a conversion,
since it will faithfully measure the round-trip error from subsampling and
upsampling.
I need this to be able to test the new unscaled conversion code more quickly.
We re-order the flags order to make 0 the first entry, so we don't set any
flags when performing unscaled tests.
The field width in a %s directive gives the amount of characters
to read from the input and not the size of the receiving buffer;
the latter must be of course also have space for the trailing \0
which has been forgotten here. The commit adds it (and fixes a
-Wfortify-source warning from Clang).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The underlying integer type of an enumeration is
implementation-defined (see C11, 6.7.2.2 (4)); GCC defaults
to unsigned if there are no negative values like for all enums
from pixfmt.h except enum AVPixelFormat.
This means that tests like "if (csp >= AVCOL_SPC_NB)" for
invalid colorspaces need not work as expected (namely if
enum AVColorSpace is signed). It also means that testing
for such an enum variable to be >= 0 may be tautologically
true. Clang emits a -Wtautological-unsigned-enum-zero-compare
warning for this.
Fix both of these issues by casting to unsigned.
Also do the same in libswscale/format.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Michael Niedermayer
Niklas Haas
Ramiro Polla
Marton Balint
Timo Rothenpieler
Kacper Michajłow
James Almer
Andreas Rheinhardt
Shreesh Adiga