The B extension was finally ratified in May 2024, encompassing:
- Zba (addresses),
- Zbb (basics) and
- Zbs (single bits).
It does not include Zbc (base-2 polynomials).
Signed-off-by: Paul B Mahol <onemda@gmail.com>
configure checks that the assembler supports the B extension (or rather
its constituents) anyway. These macros were dodging sanity checks for
unsupported instructions and nothing else.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The RISC-V B bit manipulation extension was ratified only two months ago.
But it is strictly equivalent to the union of the zba, zbb and zbs
extensions which were defined almost 3 years earlier. Rather than require
new assembler, we can just match the extension name manually and translate
it into its constituent parts.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
SP must be a multiple of 16 bytes at all times on POSIX - even in leaf
functions - so that signal handlers have a properly aligned stack.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The search of the current DirectShow device list has been customized so
that audio devices are always found even if no video device is connected.
Signed-off-by: Jens Frederich <jens.frederich@vector.com>
Reviewed-by: Roger Pack <rogerdpack2@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This stops decode_block() from failing when the .exr resolution is not divisable by 8 (e.g 108x192).
The dc_w and dc_h needs to be round up and not down.
Signed-off-by: Sean Devonport <tonetechnician@gmail.com <mailto:tonetechnician@gmail.com>>
Increase the tolerance from 10 ulp to 11 ulp. This fixes occasional
errors for some inputs; the errors could be reproduced on
aarch64/neon builds, with "checkasm --test=ac3dsp 3446175925".
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes an issue in 6.1 when reading a corrupted file with -xerror would
exit with success. This specific issue is not present in master, but
this should generally be a more robust behaviour.
Reported-by: Andrej Peterka
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The issue is that ac->output_elements is populated from
ac->che, which may be freed, leaving dangling pointers in this
list.
Should fix clusterfuzz.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This needs to be double checked or a checking way of writing should be used
Fixes: out of array access
Fixes: 70007/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HDR_fuzzer-5478704150020096
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes: out of array access
Fixes: 68941/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5990952685600768
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes: Assertion failure
Fixes: 68979/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5375874714107904
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes: signed integer overflow: -35511773 * 256 cannot be represented in type 'int'
Fixes: 70406/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6545326804434944
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes: 2.96539e+09 is outside the range of representable values of type 'int'
Fixes: Assertion n>=0 && n<=32 failed at libavcodec/get_bits.h:423
Fixes: 62241/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-4525761925873664
Fixes: 70406/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6545326804434944
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes: null pointer dereference
Fixes: 70376/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_VAAPI_fuzzer-4733551250046976
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes: index 9 out of bounds for type 'uint32_t [8][8]'
Fixes: 70363/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-6723855293415424.fuzz
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes: out of array read
Fixes: 70363/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-6723855293415424.fuzz
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes: left shift of 1 by 31 places cannot be represented in type 'int'
Fixes: 70122/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5172200613675008
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes: 70036/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PRORES_fuzzer-6298797647396864
Fixes: shift exponent 40 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
(the exact issue is unreproducable but the use of uninitialized data is reproducable)
Should fix: signed integer overflow: -2147483648 - 127 cannot be represented in type 'int'
Should fix: 69881/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-4751301204836352
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
An alternative would be to leave the context unchanged on failure of hls_slice_header()
Fixes: out of array access
Fixes: NULL pointer dereference
Fixes: 69584/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5931086299856896
Fixes: 69724/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5104066422702080
Fixes: 70422/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5908731129298944
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes: Timeout
Fixes: 69230/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-6540512101203968
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Use the "ldur" instruction explicitly, instead of having the
assembler implicitly convert "ldr" instructions to "ldur".
This fixes build errors like these:
libavcodec\aarch64\vvc\alf.o.asm(1023) : error A2518: operand 2: Memory offset must be aligned
ldr q22, [x3, #24]
libavcodec\aarch64\vvc\alf.o.asm(1024) : error A2518: operand 2: Memory offset must be aligned
ldr q24, [x2, #24]
libavcodec\aarch64\vvc\alf.o.asm(1393) : error A2518: operand 2: Memory offset must be aligned
ldr q22, [x3, #24]
libavcodec\aarch64\vvc\alf.o.asm(1394) : error A2518: operand 2: Memory offset must be aligned
ldr q24, [x2, #24]
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
If __riscv_hwprobe() fails, then the kernel version is presumably too
old. There is not much point falling back to the auxillary vector.
- The Linux kernel requires I, so the flag is always set on Linux, and
run-time detection is unnecessary. Our RISC-V assembler does anyway not
support targets without I.
- Linux can compile with or without F and D, but it cannot perform
run-time detection for them (a kernel with F support will not boot a
processor without F). The run-time detection is thus useless in that
case. Besides F and D extensions are used throughout the C code, so
their run-time detection would not be practical.
- Support for V was added in a later kernel version than riscv_hwprobe(),
so the system call will always be available if the kernel supports V.
The only exception would be vendor kernel forks, but those are known to
haphasardly pretend to support V on systems without actual V support, or
with only pre-ratification binary-incompatible version. Furthermore, a
large chunk of our optimisations require Zba and/or Zbb which cannot be
detected with HWCAP in those kernels.
For what it is worth, OpenJDK already took a similar action. Note that this
keeps AT_HWCAP usage for platforms with neither C run-time <sys/hwprobe.h>
nor kernel <asm/hwprobe.h>, notably kernels other than Linux.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This reuses the DC bypass functions from the multiple IDCT functions, to
leverage vector code.
As an added bonus, the caller functions can now rely on the callee functions
to preserve their parameters, thus cutting down on stack spills.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
No functional changes. This just moves the assembler so that it can be
referenced by other functions in h264idct_rvv.S with local jumps.
Edited-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes: CID1458043 Unchecked return value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes: CID1604383 Unchecked return value
Fixes: CID1604439 Unchecked return value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>