Fixes: out of array access
Fixes: zeropath/off-by-one-one-byte
Found-by: Joshua Rogers <joshua@joshua.hu>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The quantization parameter (qp) can exceed 63 when the base value
from frame header (0-63) is combined with the offset from slice data
(up to +2), resulting in qp=65. This causes out-of-bounds access to
the rv60_qp_to_idx[64] array in decode_cbp8(), decode_cbp16(), and
get_c4x4_set().
Fixes: Out-of-bounds read
Signed-off-by: oblivionsage <cookieandcream560@gmail.com>
No testsample is available
This is related to 61cbcaf93f and clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-5160167345291264
which fixed rv60_qp_to_idx[qp + 32] out of array access
These 2 checks are not redundant and neither covers the cases of the other
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
update the switch statement for EXR_UINT in pxr24_uncompress to
correctly use the tile width td->xsize instead of using the full window
width s->xdelta. s->delta is larger than td->xsize which lead to two
buffer overflows when interacting with the ptr variable in the same
switch statement.
Fixes: out of bounds read and write
Found-by: veygax's insomnia network (INSOMNIA-1)
Signed-off-by: veygax <veyga@veygax.dev>
The existing is_luma check is fragile as depending on the order
of channels it can be set or reset
No testcase
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
There is no need to check the whole AVChannelLayout; checking
its nb_channels is enough.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
E.g. check that the ordinary entries are valid (e.g. no negative sample
rates, must have pix fmt descriptor) and also that the sentinels
are valid where they contain redundant information.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For decoders, the pixel format is negotiated via the get_format callback
(if there is a choice at all), so decoders should not set pix_fmts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not supposed to be set by decoders (where format negotiation
happens via the get_format callback).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Right now, FFCodec contains a dedicated pointer for
alpha_mode; this is wasteful, as there is only a very limited
range of options for this value, namely four.
So store it as a two-bit bitfield like color_ranges.
This reduces sizeof(FFCodec) by 16 here (the placement
of alpha_mode entailed unnecessary padding) and
saves 11328B of .data.rel.ro here (on a standard build with
no external libraries).
(If it were not for effective-type violations, one could
share the code and the table with AV_CODEC_CONFIG_COLOR_RANGE.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avcodec_get_supported_config() always sets a dummy for
the pointer to the number of entries in case it is not set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
And rename it to ff_encode_add_stats_side_data() and move its
declaration to encode.h. Also constify the error pointee.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
pict_type is always used since 5e0eac3d4566839598f6d6fe5d77770023d6713a;
ctx in set_pix_fmt() seems to have been always unused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The optimised version does not work if the stride is not a multiple 8,
which can occur as reproduce by vsynth3-asv1 and vsynth3-asv2 tests.
This reverts commit 02594c8c01.
Conflicts:
libavcodec/riscv/pixblockdsp_init.c
libavcodec/riscv/pixblockdsp_rvv.S
Combine P-frame with following B-frame into a single packet with the
latter's order. Emit a tail packet with a show_existing_frame header
to show it at the correct PTS.
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.
This one takes about 2.93s on my machine, but ensures that every pixel
format conversion roundtrips correctly. Note that due to existing bugs in
libswscale, this one only passes when using the new format conversion code.
Restrict the test to -v 16 (AV_LOG_ERROR) to avoid excess amounts of output.
We can't use ANSI color codes inside av_log(), so fall back to printf()
for these; but match the INFO verbosity level.
Also change the format slightly to drop SSIM numbers down to just below
VERBOSE level, since VERBOSE tends to generate a lot of swscale related
spam.
This is more informative than the current behavior, because when the first
MERGE() succeeds but the second fails, the original link already has
merged formats and thus the error message is confusing.
Doubling the register size allowed to avoid two pmaddubsw.
It is also ABI compliant (the old version lacked an emms)
and the average versions no longer rely on padding (the old versions
used pavgb with a memory operand reading eight bytes,
although only four are needed).
Old benchmarks (the latter four refer to RV40):
avg_h264_chroma_mc4_8_c: 145.7 ( 1.00x)
avg_h264_chroma_mc4_8_ssse3: 32.3 ( 4.51x)
put_h264_chroma_mc4_8_c: 136.1 ( 1.00x)
put_h264_chroma_mc4_8_ssse3: 29.0 ( 4.70x)
avg_chroma_mc4_c: 162.1 ( 1.00x)
avg_chroma_mc4_ssse3: 31.1 ( 5.22x)
put_chroma_mc4_c: 137.5 ( 1.00x)
put_chroma_mc4_ssse3: 28.6 ( 4.81x)
New benchmarks:
avg_h264_chroma_mc4_8_c: 146.7 ( 1.00x)
avg_h264_chroma_mc4_8_ssse3: 26.5 ( 5.53x)
put_h264_chroma_mc4_8_c: 136.8 ( 1.00x)
put_h264_chroma_mc4_8_ssse3: 22.5 ( 6.09x)
avg_chroma_mc4_c: 165.5 ( 1.00x)
avg_chroma_mc4_ssse3: 27.2 ( 6.08x)
put_chroma_mc4_c: 138.1 ( 1.00x)
put_chroma_mc4_ssse3: 23.2 ( 5.96x)
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Vulkan headers define *FlagBits enum with individual bit values, and
coresponding *Flags typedef to be used to store the bitmask of
coresponding bits.
In practice those two types map to the same type, but for consistency
*Flags should be used.
Fixes MSVC warnings about type mismatch.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Wrong enum value was used to check unit_elems. While
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA (11) would trigger when
UNIT_MASTERING_DISPLAY (2) was set, it also would match
UNIT_CONTENT_LIGHT_LEVEL (1) which is not expected.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>