The specification does not seem to list what the maximum valid
value is

Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int'
Fixes: 16268/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5638164544225280

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

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/ffmpegSigned-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/ffmpegSigned-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/ffmpegReviewed-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 1afd2469)
Fixes: simple_dump_cut.webm
Fixes: regression of 1afd2469

fate-vp5 changes because the last frame is truncated and now handled
differently.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Aman Gupta <aman@tmm1.net>

Signed-off-by: Aman Gupta <aman@tmm1.net>

internal.h header required for FF_CODEC_CAP_SETS_PKT_DTS
Signed-off-by: Aman Gupta <aman@tmm1.net>

* 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>

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>

Move in out of loop.

Removed (new_size - pkt->nals_allocated) because this value is always 1
during the call.
Signed-off-by: James Almer <jamrial@gmail.com>

Big thanks to Michael Koch for providing actual formula.

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).

Signed-off-by: Aman Gupta <aman@tmm1.net>

Signed-off-by: Aman Gupta <aman@tmm1.net>

Signed-off-by: Aman Gupta <aman@tmm1.net>

This fixes h264_v4l2m2m encoding on the Raspberry Pi
Signed-off-by: Aman Gupta <aman@tmm1.net>

Signed-off-by: Aman Gupta <aman@tmm1.net>

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>

This will allow re-use of the m2m backend with AVFilterContext
Signed-off-by: Aman Gupta <aman@tmm1.net>

The single planar support was for NV12 only.
Add NV21 and YUV420P support.
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>

Signed-off-by: Aman Gupta <aman@tmm1.net>

Signed-off-by: Aman Gupta <aman@tmm1.net>

Fixes crashes with bigger h/v fov.

This will make it easy to switch to ANativeWindow_fromSurface
and ANativeWindow_release in the future.
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>