The problem occurs in slice quant estimation and slice encoding:
If the slice quant is larger than MAX_STORED_Q we don't use pre-calculated
quant matrices, but generate a new one, but both qmat and qmat_chroma both
point to the same table, so the luma table ends up having chroma table
values.
Add custom_chroma_q the same way as custom_q.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This commit adds configuration options to libvpxenc.c that can be used to
tune the sharpness parameter for VP8 and VP9.
Signed-off-by: Rene Claus <rclaus@google.com>
Signed-off-by: James Zern <jzern@google.com>
The AV_INPUT_BUFFER_PADDING_SIZE has been increased to 64, but the value is still 32
in function ff_hevc_sao_edge_filter_8_msa. So, use AV_INPUT_BUFFER_PADDING_SIZE directly.
Also, use MAX_PB_SIZE directly instead of 64. Fate tests passed.
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
webrtc uses a int32_t like the existing code in ilbcdec
Fixes: signed integer overflow: 2080245063 + 257939661 cannot be represented in type 'int'
Fixes: 11037/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ILBC_fuzzer-5682976612941824
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The specification allows 2^32-1 to be encoded as any number of zeroes
greater than 31, followed by a one. This previously failed because the
trace code would overflow the array containing the string representation
of the bits if there were more than 63 zeroes. Fix that by splitting the
trace output into batches, and at the same time move it out of the default
path.
(While this seems likely to be a specification error, libaom does support
it so we probably should as well.)
From a test case by keval shah <skeval65@gmail.com>.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Silences a warning with clang on arm:
libavcodec/opus_rc.c:170:17: warning: passing 'const uint8_t *' (aka 'const unsigned char *') to parameter of type 'void *' discards qualifiers
delta_frame_id_minus1 is not a single value in the bitstream, and can
store values up to 17 bits wide.
Fixes parsing files with frame ids.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Change the some options location in avcodec_options to make code more
readable. And update the fate test with this change.
Signed-off-by: Jun Zhao <mypopydev@gmail.com>
Set initialization order of MSA after MMI to make it work on loongson platform(msa is supported by loongson2k、3a4000 etc.).
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
1. Old logic meaned: everywhere, except Windows, ffmpeg has to use HW
acceleration, but on Windows ffmpeg has to use (unavailable) software
HEVC by default
2. Software HEVC is available only if you provide corresponding
software MediaSDK library, which isn't provided with ffmpeg. More
information could be found in
https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/samples/readme-encode_linux.pdf
3. HW HEVC decoding/encoding are available on Windows in the driver by default
Note: Default case should be the most common case but this change still has potential risk
on windows if HW path is not supported(or doesn't work as expection).
(See the historical disscution: https://lists.libav.org/pipermail/libav-devel/2016-November/080419.html).
In such case, two options suggested:
1. Use the option "-load_plugin hevc_sw" to switch SW path manually.
2. Or report bug to Intel windows driver if your GPU can support HEVC HW codec.
(HEVC decoding is supported since Braswell, and encoding supported since Skylake)
Patch started by Landgraph. Add similar change for hevc decoder and bump a new version.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Reviewed-by: Maxym Dmytrychenko <maxim.d33@gmail.com>
Signed-off-by: Landgraph <me@landgraph.ru>
Signed-off-by: Zhong Li <zhong.li@intel.com>
Fixes: OOM
Fixes: 10307/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RASC_fuzzer-5393974559244288
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Timeout
Fixes: 10313/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP7_fuzzer-5637719389110272
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes#7410.
The value of sub-pixel precision for me/mc can change during an Intra frame. In multi-threaded decoding this change is not propagated to other frame threads causing decoding artifacts. This patch initializes the sub-pixel precision parameter from previous thread, which fixes the issue.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
