Without the specification, limiting the index is the best that can be done.
Fixes: out of array access
Fixes: 487591441/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-6205915698364416
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: left shift of negative value -2
Fixes: 487591441/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-6205915698364416
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
A new Sequence Header or a Temporal Delimiter OBU invalidate any previous frame
if not yet complete (As is the case of missing Tile Groups).
Similarly, a new Frame Header invalidates any onging Tile Group parsing.
Fixes: out of array access
Fixes: av1dec_tile_desync.mp4
Fixes: av1dec_tile_desync_bypass.mp4
Signed-off-by: James Almer <jamrial@gmail.com>
Section 6.8.1 of the AV1 specification states:
"If obu_type is equal to OBU_REDUNDANT_FRAME_HEADER, it is a requirement of
bitstream conformance that SeenFrameHeader is equal to 1."
Leave the existing behavior for reading scenarios as such a file may still
be readable.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: out of array acces
Fixes: 487838419/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_DEC_fuzzer-4683933221715968
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: 256 * 8396351 cannot be represented in type 'int'
Fixes: 482692578/clusterfuzz-testcase-minimized-ffmpeg_dem_SWF_fuzzer-5865521093607424
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The value of vb_pos at vb_bottom, vb_above is known
at compile-time, so one can avoid the modifications
to vb_pos and just compare against immediates.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They are completely unnecessary for the 8bit case (which only
handles 8bit) and overtly complicated for the 10 and 12bit cases:
All one needs to do is set up the (1<<bpp)-1 vector register
and jmp from (say) the 12bpp function stub inside the 10bpp
function. The way it is done here even allows to share the
prologue between the two functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It can be combined with an earlier lea for the loop
processing 16 pixels at a time; it is unnecessary
for the tail, because the new values will be overwritten
immediately afterwards anyway.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The vvc_alf_filter functions don't use x86inc's stack managment
feature at all; they merely push and pop some regs themselves.
So don't tell x86inc to provide stack (which in this case
entails aligning the stack).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Each luma alf block has 2*12 auxiliary coefficients associated
with it that the alf_filter functions consume; the C version
simply increments the pointers.
The x64 dsp function meanwhile does things differenty:
The vvc_alf_filter functions have three levels of loops.
The middle layer uses two counters, one of which is
just the horizontal offset xd in the current line. It is only
used for addressing these auxiliary coefficients and
yet one needs to perform work translate from it to
the coefficient offset, namely a *3 via lea and a *2 scale.
Furthermore, the base pointers of the coefficients are incremented
in the outer loop; the stride used for this is calculated
in the C wrapper functions. Furthermore, due to GPR pressure xd
is reused as loop counter for the innermost loop; the
xd from the middle loop is pushed to the stack.
Apart from the translation from horizontal offset to coefficient
offset all of the above has been done for chroma, too, although
the coefficient pointers don't get modified for them at all.
This commit changes this to just increment the pointers
after reading the relevant coefficients.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The permutation that was applied before the write macro
is actually only beneficial when one has 16 entries to write,
so move it into the macro to write 16 entries and optimize
the other macro.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
One always has eight samples when processing the luma remainder,
so xmm registers are sufficient for everything. In fact, this
actually simplifies loading the luma parameters.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When width is known to be 8 (i.e. for luma that is not width 16),
the upper lane is unused, so use an xmm-sized packuswb and avoid
the vpermq altogether. For chroma not known to be 16 (i.e. 4,8 or
12) defer extracting from the high lane until it is known to be needed.
Also do so via vextracti128 instead of vpermq (also do this for
bpp>8).
Also use vextracti128 and an xmm-sized packuswb in case of width 16
instead of an ymm-sized packuswb followed by vextracti128.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
At the end of the height==8 codepath, a jump to RET at the end
of the height==16 codepath is performed. Yet the epilogue
is so cheap on Unix64 that this jump is not worthwhile.
For Win64 meanwhile, one can still avoid jumps, because
for width 16 >8bpp and width 8 8bpp content a jump is performed
to the end of the height==8 position, immediately followed
by a jump to RET. These two jumps can be combined into one.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Write them in assembly instead; this exchanges a call+ret
with a jmp and also avoids the stack for (1<<bpp)-1.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Both the 8bpp width 16 and >8bpp width 8 cases write
16 contiguous bytes; deduplicate writing them. In fact,
by putting this block of code at the end of the SAVE macro,
one can even save a jmp for the width 16 8bpp case
(without adversely affecting the other cases).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For 8bpp width 8 content, an unnecessary jump was performed
for every write: First to the end of the SAVE_8BPC macro,
then to the end of the SAVE macro. This commit changes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When processing the last block, we no longer need to preserve
some registers for the next block, allowing simplifications.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Output directly to the desired destination registers instead
of zeroing them, followed by adding the desired values.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
BDOF_PROF_GRAD just adds some values to m12,m13,
so one can avoid two pxor, paddw by deferring
saving these registers prematurely.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: out of array access
Fixes: crash_vvc_heap_oob_read.bin
Found-by: akshay jain <akshaythe@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes compiling with MSVC for aarch64 after
510999f6b0.
While MSVC does do dead code elimintation for function references
within e.g. "if (0)", it doesn't do that for functions referenced
within a static function, even if that static function itself ends
up not used.
A reproduction example:
void missing(void);
void (*func_ptr)(void);
static void wrapper(void) {
missing();
}
void init(int cpu_flags) {
if (0) {
func_ptr = wrapper;
}
}
If "wrapper" is entirely unreferenced, then MSVC doesn't produce
any reference to the symbol "missing". Also, if we do
"func_ptr = missing;" then the reference to missing also is
eliminated. But for the case of referencing the function in a
static function, even if the reference to the static function can
be eliminated, then MSVC does keep the reference to the symbol.
Fixes: applying non-zero offset 16 to null pointer
Fixes: 471614378/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5967030642868224
Note: FF_PTR_ADD() does not work as this code has NULL + 123 cases where the pointer is unsused afterwards
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Use PRIu32/PRIX32 format specifiers instead of %d/%u/%X for uint32_t
variables in av_log calls. On some platforms (e.g. NuttX), uint32_t is
typedef'd as unsigned long rather than unsigned int, which triggers
-Wformat warnings despite both types being 4 bytes. Using PRI macros
is the portable way to match the actual underlying type of uint32_t.
Signed-off-by: zengshuang <zengshuang@xiaomi.com>
Ensures samples where a missing Frame Header is handled by a subsequent
Redundant one are parsed correctly.
Signed-off-by: James Almer <jamrial@gmail.com>
