It amounts to about 1/2 of the warnings generated and does not help
spotting anything useful.

Avoid false positives while syncing.

Bug-Id: ffmpeg/4086
Bug-Id: 879

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

avio_tell returns an int64_t.

Bug-Id: CID 1339818

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Additional improvements by Michael Niedermayer <michaelni@gmx.at>.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Fixes out of array reads.

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Avoid some confusion when the information is not present.

Bug-Id: 902

Copy pointers to AVPicture after memory has been allocated.
Fixes NULL pointers in AVPicture after a17a7661.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Explain better which environment is discouraged and mention the
shortcuts names.

Originally based on the capture written by
Thilo Borgmann <thilo.borgmann@mail.de>.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Assume that the default C compiler and the default ObjC compiler match
(default for OSX).

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

And make one more informative.

And forward the logging contexts when needed.

And properly report the error when it happens.

Signed-off-by: Martin Storsjö <martin@martin.st>

Silences warnings when using -Wshift-overflow (GCC 6+).
Found-by: James Almer <jamrial@gmail.com>

Use the result directly, removing an unneeded cast.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

SGI RLE encoding is slighlty different than the one provided by rle
module (especially at high bit depth). The pixel count function however
does not change, so it is simply made library-public.

This is never mentioned in the specifications, and decoders work
just as fine without it. Update the fate references since the compressed
file is smaller.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

VP8E_UPD_ENTROPY, VP8E_UPD_REFERENCE, VP8E_USE_REFERENCE were removed
from libvpx and the remaining values were never used here

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Zern <jzern@google.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

The demuxer returned INVALIDDATA and failed to demux the remaining data
when an invalid stream index was read, now it just skips the asf packet
for the stream with an invalid stream index and continues demuxing.

Reported-By: Hendrik Leppkes

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

The auxiliary data length field is not reliable,
and incorrect overread errors could be returned
for valid, real-world bitstreams.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

MSYS, as per cygwin, by default uses a custom posix abstraction
in the form of a "msys2.dll". Programs build that way are harder to
distribute and use.

MSYS2 provides alternate launcher scripts that provide a MINGW
environment nearly out of box.

This function returns the encoded data of a frame, one slice at a time
directly when that slice is encoded, instead of waiting for the full
frame to be done. However this field has a debatable usefulness, since
it looks like it is just a convoluted way to get data at lowest
possible latency, or a somewhat hacky way to store h263 in RFC-2190
rtp encapsulation.

Moreover when multi-threading is enabled (which is by default) the order
of returned slices is not deterministic at all, making the use of this
function not reliable at all (or at the very least, more complicated
than it should be).

So, for the reasons stated above, and being used by only a single encoder
family (mpegvideo), this field is deemed unnecessary, overcomplicated,
and not really belonging to libavcodec. Libavformat features a complete
implementation of RFC-2190, for any other case.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>