Fixes: signed integer overflow: -2424832 - 2145653689 cannot be represented in type 'int'
Fixes: 16138/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TAK_fuzzer-5643451346976768
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: -822667928 + -1399761199 cannot be represented in type 'int'
Fixes: 15756/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5645182051024896
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: 24023040 * 112 cannot be represented in type 'int'
Fixes: 16570/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5173275211071488
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Kieran Kunhya <kierank@obe.tv>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
A threshold of 1 is sufficient for simple_dump_cut.webm, 10 is used
just to be sure the next truncated file doesnt cause the same issue
Obvious alternative fixes are to simply accept that the file is broken or to
write some advanced error concealment or to
simply accept that the decoder wont stop at the end of input.
Fixes: Ticket 8069 (artifacts not the differing md5 which was there before 1afd246960)
Fixes: simple_dump_cut.webm
Fixes: regression of 1afd246960
fate-vp5 changes because the last frame is truncated and now handled
differently.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* FFmpeg retrieves a packet from the bitstream
* It attempts to get an input buffer (from its own list or by dequeuing one from the driver)
* If no input buffer is found, the bitstream packet is dropped instead of scheduled for trying again later
It's an issue that showed especially at high speeds (like using `-f null -` as output parameters).
Signed-off-by: Aman Gupta <aman@tmm1.net>
Without this ffmpeg will attempt to copy the dts from the
most recently enqueued packet into the most recently dequeued
frame, which does not account for the buffering inside v4l2
and is not accurate.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Frames are generally dequeued into capture buffers, so using
the output properties here was incorrect. It happened to work
fine for decoding, since the output/capture buffers have the same
dimensions.
For the v4l2 scaler, the dimensions can be different between output
and capture. Using the buffer's associated context makes this code
work correctly regardless of where the frame is coming from.
Signed-off-by: Aman Gupta <aman@tmm1.net>
free work&pi_wraps in error handling path to avoid memory leak.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
free the pad.name in error handling path to avoid memory leak.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
The C and asm versions behaved differently _outside_ of the codec.
The C version returned pre-multiplied 'state' for the next execution
to use right away, while the assembly version outputted non-multiplied
'state' for the next execution to multiply to save instructions.
Since the initial state when initialized or seeking is always 0,
and since C and asm versions were never mixed, there was no issue.
However, comparing outputs directly in checkasm doesn't work without
dividing the initial state by CELT_EMPH_COEFF and multiplying the
returned state by CELT_EMPH_COEFF for the assembly function.
Since its actually faster to do this in C as well, copy the behavior the
asm versions use. As a reminder, the initial state 0 is divided by
CELT_EMPH_COEFF on seek and init (just in case in the future this is
changed, its technically more correct to init with CELT_EMPH_COEFF than 0,
however when seeking this will result in more audiable pops, unlike with 0
where the output gets in sync over a few samples).
This just makes the M2MDEC_CLASS similar to how it is done in rkmpp. It looks
clean and has proper indentation
Signed-off-by: Aman Gupta <aman@tmm1.net>
On the RPI, three different /dev/video devices exist (decoder, scaler, encoder).
When probing the devices in order, the originally requested pix fmt
would be mutated causing the wrong one to be chosen when a matching
device was finally found.
Signed-off-by: Aman Gupta <aman@tmm1.net>
In rare circumstances, if the codec is not configured with the
proper parameters the input buffers can be allocated with a size
that's too small to hold an individual packet. Since MediaCodec
expects exactly one incoming buffer with a given PTS, it is not
valid to split data for a given PTS across two input buffers.
See https://developer.android.com/reference/android/media/MediaCodec#data-processing:
> Do not submit multiple input buffers with the same timestamp
Signed-off-by: Aman Gupta <aman@tmm1.net>
When duplicating frames we need to schedule for activation again, otherwise frames can build up in the inlink fifo.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
some bitstream have trailing junk, despite being valid webp data.
In case of apparent error, abort the loop and let *got_frame
decide whether this is an error or not.
fixes trac #8107 (/#7612)
Another possibility would be turning the loop into:
while (!*got_frame) {...}
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
free the value in error handling path to avoid the memory leak.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The indentation of code dose not reflect the if block structure in
'apply_ltp_mips', and this will generate a warnning when build with
'-Wall' or '-Wmisleading-indentation'.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The loop may mutate the input buffer, so re-fetch it to ensure
the current one is always used.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
