The hevc parser parses the diagonal scan order in bitstream into raster
scan order. However, the Vulkan spec wants it as specified in H265 spec,
which is diagonal scan order.
Tested on RADV.
v2: fix copy-paste typo with PPS.
Fixes: out of array write
Fixes: 60798/clusterfuzz-testcase-minimized-ffmpeg_BSF_EVC_FRAME_MERGE_fuzzer-4633529766772736
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
A POLLERR occurs when libavcodec attempts to dequeue output buffers
before enqueuing capture buffers. This could happen to an application
deciding to send the first coded packet. Suppress these POLLERRs when
the buffers are uninitialized and avoid crashing because of enumerating
uninitialized buffers.
See https://trac.ffmpeg.org/ticket/9957 for the original bug report.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
This allows this common H.274 SEI to be parsed from both H.264
as well as HEVC, as well as probably from VVC in the future.
Generally attempts to keep the original code as similar as possible.
FATE test refererence changes only change the order of side data
export within a single frame. Nothing else seems to have changed.
This allows this common H.274 SEI to be parsed from both H.264
as well as HEVC, as well as probably from VVC in the future.
Generally attempts to keep the original code as similar as possible.
FATE test refererence changes only change the order of side data
export within a single frame. Nothing else seems to have changed.
The unchecked read caused the 2nd subsequent tell call to move backward resulting
in a negative length
Fixes: assertion failure
Fixes: 60276/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5434126636023808
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: vmixdec.c:132:34: runtime error: signed integer overflow: -2147483648 * 1856 cannot be represented in type 'int'
Fixes: vmixdec.c:119:20: runtime error: signed integer overflow: -1256 + -2147483648 cannot be represented in type 'int'
Fixes: vmixdec.c:137:36: runtime error: signed integer overflow: 2147483416 * 16 cannot be represented in type 'int'
Fixes: 59843/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VMIX_fuzzer-4857434624360448
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: division by zero
Fixes: 60306/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5538913553612800
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer <jamrial@gmail.com>
Fixed: signed integer overflow: -2 * -1085502286 cannot be represented in type 'int'
Fixed: 57986/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5123651145170944
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The implementation does not support k=32
Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int'
Fixes: 57976/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVARC_fuzzer-5911925807775744
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: 2147443649 + 65535 cannot be represented in type 'int'
Fixes: 60054/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RKA_fuzzer-5095674572832768
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Take vector reduction out of the loop and unroll.
Before:
audiodsp.scalarproduct_int16_c: 12321.0
audiodsp.scalarproduct_int16_rvv_i32: 4175.7
After:
audiodsp.scalarproduct_int16_c: 12320.5
audiodsp.scalarproduct_int16_rvv_i32: 1230.2
This cannot beat the Zbb implementation, and it is unlikely that a real
meaningful CPU design would support V and not Zbb. The best loop rewrite
that I could come up with (4 shifts, 2 ands, 3 ors) is still ~40% slower
than Zbb.
A proper faster vector implementation should be feasible with the
cryptographic vector extensions, but that is a story for another time.
The code was blindly assuming that Zbb or V implied Zba. While the
earlier is practically always true, the later broke some QEMU setups,
as V was introduced earlier than Zba.
Even though they have the same size, and typically the same alignment,
uint32_t and float are under no circumstances compatible types in C.
The casts from float * to uint32_t * are invalid here. Insofar as the
resulting pointers are dereferenced, this is undefined behaviour.
This patch uses av_float2int() / av_int2float() instead.
Except for add_squares, telling the compiler that the output vector(s)
cannot alias helps quite a bit (cycles on SiFive U74-MC):
ps_add_squares_c: 98277.7
ps_add_squares_r: 98320.2
ps_hybrid_analysis_c: 3731.2
ps_hybrid_analysis_r: 2495.7
ps_hybrid_analysis_ileave_c: 20478.0
ps_hybrid_analysis_ileave_r: 16092.2
ps_hybrid_synthesis_deint_c: 19051.5
ps_hybrid_synthesis_deint_r: 15420.0
ps_mul_pair_single_c: 122941.2
ps_mul_pair_single_r: 91035.0
Encoders (usually) have no business modifying frame->data
(which need not be writable), so they should use the appropriate
pointers.
Reviewed-by: Tomas Härdin <git@haerdin.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also allocate the AVFrame during init and use av_frame_replace()
to replace it later.
Reviewed-by: Tomas Härdin <git@haerdin.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
A private class for an encoder without options is useless.
Reviewed-by: Tomas Härdin <git@haerdin.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This increases the group multiplier as per T-Head C910 benchmarks:
inverse_coupling_c: 4597.0
inverse_coupling_rvv_i32: 1312.7 (m1)
inverse_coupling_rvv_i32: 1116.7 (m2)
inverse_coupling_rvv_i32: 732.2 (m4)
inverse_coupling_rvv_i32: 898.0 (m8)
The IMDCT offset is only relevant for NEON optimisations. There are no
VFP optimisations here that would justify the HAVE_VFP flag. In
practice, this makes no difference because HAVE_NEON is practically
always true for standard Armv8 platforms.
This decoding flag makes decoders drop all frames after a parameter
change, but what exactly constitutes a parameter change is not well
defined and will typically depend on the exact use case.
This functionality then does not belong in libavcodec, but rather in
user code
