Update documentation for flags/flags2
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

Correct the flags for AVCodecContext.flags2.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

fix indentation.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Gyan Doshi <ffmpeg@gyani.pro>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

When used ROUNDED_DIV(a,b), if a is unsigned integer zero, it's
will lead to an underflow issue(it called unsigned integer
wrapping).

Fixes #8062
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Mengye Lv <mengyelv@tencent.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>

Simplifies code.
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Pedro Arthur <bygrandao@gmail.com>

The argument to vec_splat_u16 must be a literal. By making the
function always inline and marking the arguments const, gcc can
turn those into literals, and avoid build errors like:

swscale_vsx.c:165:53: error: argument 1 must be a 5-bit signed literal

Fixes #7861.
Signed-off-by: Daniel Kolesa <daniel@octaforge.org>
Signed-off-by: Lauri Kasanen <cand@gmx.com>

While this technically compiles in current ffmpeg, this is only
because ffmpeg is compiled in strict ISO C mode, which disables
the builtin 'vector' keyword for AltiVec/VSX. Instead this gets
replaced with a macro inside altivec.h, which defines vector to
be actually __vector, which accepts random types.

Normally, the vector keyword should be used only with plain
scalar non-typedef types, such as unsigned int. But we have the
vec_(s|u)(8|16|32) macros, which can be used in a portable manner,
in util_altivec.h in libavutil.

This is also consistent with other AltiVec/VSX code elsewhere in
the tree.

Fixes #7861.
Signed-off-by: Daniel Kolesa <daniel@octaforge.org>
Signed-off-by: Lauri Kasanen <cand@gmx.com>

The structure of a ProRes frame in mov/mp4 is that of a typical atom:
First a 32 bit BE size field, then a tag detailling the content. Said
size field includes the eight bytes of the atom header.

This header is actually redundant, as the size of the atom is already
known from the containing atom. It is therefore stripped away when muxed
into Matroska and so the Matroska demuxer has to recreate upon demuxing.
But it did not account for the fact that the size field includes the
size of the header and this can lead to problems when a decoder uses the
in-band size field.

Fixes ticket #8210.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes: memleaks
Fixes: 17813/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5145600206569472

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: left shift of negative value -6
Fixes: 17810/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-5638541240958976

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: null pointer dereference
Fixes: signed integer overflow: 512 * 2147483647 cannot be represented in type 'int'
Fixes: 17809/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_XMA1_fuzzer-5634409947987968

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The check "if (!pb->seekable & AVIO_SEEKABLE_NORMAL)" is wrong, because
! has higher precendence than &. But it is also redundant, because this
part of the code is only ever reached when the AVIO_SEEKABLE_NORMAL flag
is set for pb. So simply remove the check.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Up until now, aiffenc didn't rely on the standard functions for adding
an element to a linked list and freeing the list, but instead
reimplemented them. This has been changed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Also properly handle EOF timestamps.
Fixes #6833.

Fixes: Timeout (100sec -> 0.7sec)
Fixes: 8668/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-5174143888130048

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

This basically checks if a pixel that was coded with prediction
and residual could have been stored using a previous case.
This avoids basically a string of 0 symbols stored in less than
50 bytes to hit a O(n²) codepath.

Fixes: Timeout (too slow to wait -> immediately)
Fixes: 8668/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-4895946310680576

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

avformat/electronicarts: If no packet has been read at the end do not treat it as if theres a packet

Fixes: Assertion failure
Fixes: 17770/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5700606668308480

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Usage of strtok() was removed from x264, see also b02490a4

Fixes ticket #7542.

Signed-off-by: Lou Logan <lou@lrcd.com>
Signed-off-by: mypopy <mypopy@gmail.com>

Helps to fix ticket #8197.

Fixes #7955.