In 16x8 motion compensation, for lower 16x8 region, the input to mpeg_motion() for motion_y was "motion_y + 16", which causes wrong rounding. For 4:2:0, chroma scaling for y is dividing by two and rounding toward zero. When motion_y < 0 and motion_y + 16 > 0, the rounding direction of "motion_y" and "motion_y + 16" is different and rounding "motion_y + 16" would be incorrect.
We should input "motion_y" as is to round correctly. I add "is_16x8" flag to do that.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: 5919/clusterfuzz-testcase-minimized-5859311382167552
Fixes: special case for theora (untested due to lack of sample)
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For B field pictures, the spec says,
> The prediction shall be made from the field of the same parity as the field being predicted.
I did it.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Timeout
Fixes: 5487/clusterfuzz-testcase-4696837035393024
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>
avcodec bump missed in 7e8eba2d87
avformat bump missed in ff46124b0d and
0694d87024
avdevice bump missed in 0fd475704e
Signed-off-by: James Almer <jamrial@gmail.com>
They don't modify AVCodec, no needs to call it at register. They will be
wasteful if these codecs are unused. Instead, call static data initialization
at codecs' init.
Benchmark:
old: 51281340 decicycles in avcodec_register_all, 1 runs, 0 skips
new: 6738960 decicycles in avcodec_register_all, 1 runs, 0 skips
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
Fixes: 5396/clusterfuzz-testcase-minimized-6558555529281536
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The existing code attempts to clear the frame by painting in OVER
mode with transparent black - which is a no-op. As a result if you
have many input frames (e.g. you're using a sequence of svg files),
you'll start to see new frames drawn over old frames as memory gets
re-used.
Switch the code to paint using the CLEAR compositing operator,
which fills every channel with 0 values (setting a source colour
is not required).
Fixes: runtime error: signed integer overflow: 2052929346 + 204817098 cannot be represented in type 'int'
Fixes: 5275/clusterfuzz-testcase-minimized-5367635958038528
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This makes sure that consumers of the side data actually can
rely on the padding as intended, without having the callers of
av_packet_new_side_data to explicitly zero initialize it.
Signed-off-by: Martin Storsjö <martin@martin.st>
The rounding caused by the size scaler wasn't compensated for and the
slice sizes grew beyond what is allowed per frame.
Signed-off-by: Rostislav Pehlivanov <rpehlivanov@obe.tv>
Fixes: runtime error: signed integer overflow: -2146071175 + -268479557 cannot be represented in type 'int'
Fixes: 5237/clusterfuzz-testcase-minimized-4569895275593728
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 4868/clusterfuzz-testcase-minimized-6236542906400768
Fixes: runtime error: shift exponent 126 is too large for 32-bit type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Otherwise the decoder will throw "Missing header" errors when the
packets are sent for decoding.
This is similar to 89a420b71b.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The spec implies that 0 is invalid in addition to the existing checks
Found-by: <kierank>
Reviewed-by: Kieran Kunhya <kieran618@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
