Fixes: runtime error: signed integer overflow: -2147483647 - 2 cannot be represented in type 'int'
Fixes: 2702/clusterfuzz-testcase-minimized-4511932591636480
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Export the raw data as ICC Profile frame side data.
Reviwed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Print the name metadata entry and the buffer size.
Reviwed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: double free
Fixes: clusterfuzz-testcase-minimized-5080550145785856
Found-by: ClusterFuzz
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Many image formats support embedding of ICC profiles directly in
their bitstreams. Add a new side data type to allow exposing them to
API users.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Fixes: runtime error: shift exponent 32 is too large for 32-bit type 'unsigned int'
Fixes: 2698/clusterfuzz-testcase-minimized-4713541443518464
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: avcodec/aacps.c:511:40: runtime error: signed integer overflow: 1509077651 + 758068176 cannot be represented in type 'int'
Fixes: 2678/clusterfuzz-testcase-minimized-4702787684270080
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ticket-id: #6541
when use hls fmp4 muxer, the extention name is not .m4s, this
code can fix it.
Found-by: JohnPi
Signed-off-by: Steven Liu <lq@onvideo.cn>
Fixes: runtime error: shift exponent 64 is too large for 64-bit type 'residual' (aka 'unsigned long')
Fixes: 2674/clusterfuzz-testcase-minimized-4999700518273024
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
That line has been written by previous job.
Fix tsan warning.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
Otherwise the first decoded frame will still be tagged with the
original transfer instead of the alternative one.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Reduced msa load-store code.
Removed inline asm of GP load-store for 64 bit.
Updated variable names in GP load-store macros for naming consistency.
Corrected macro descriptions.
Signed-off-by: Kaustubh Raste <kaustubh.raste@imgtec.com>
Reviewed-by: Manojkumar Bhosale <Manojkumar.Bhosale@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ff_h264_decode_mb_cabac() and ff_h264_decode_mb_cavlc() are very long
functions. Declaring decode_chroma as const makes it clear the variable
doesn't change after initialization.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
hevc_await_progress() uses the variable |y| only inside the "if" block.
So |y| only needs to be declared and initialized in that block.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This file already has #include "idctdsp.h", which is resolved to the
idctdsp.h header in the directory where this file resides by compilers.
Two other files in this directory, libavcodec/x86/idctdsp_init.c and
libavcodec/x86/xvididct_init.c, also rely on #include "idctdsp.h"
working this way.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For the blue and violet noise, I took the pink and brown noise
respectively and subtracted the offsets instead of adding them. When I
eyeball the frequency spectrum of the resulting outputs it looks correct
to me, i.e. the blue graph appears to be a mirror image of the pink, and
the same can be said of the violet and the brown. I did not do anything
else to confirm the correctness.
