See previous commit.

The purpose of this commit is to make error management simpler and less
error prone, just like av_free() which is safe with NULL.

This ensures that no uninitialized bytes cause non-deterministic behavior.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Prevent an invalid free in case of init failure.

Fix trac ticket #2930.

Some parts of the code have been known to react badly to
empty frames; they should not, but there is no need to
take risks.

The benchmark tests the speed of the following algorithms:
MD5, SHA-1, SHA-256, SHA-512, RIPEMD-160, AES-128.

It can optionally be built to perform the same benchmark on
other crypto libraries, for comparison purposes.
The supported libraries are:
- crypto:   OpenSSL's libcrypto;
- gcrypt:   GnuTLS's libgcrypt;
- tomcrypt: LibTomCrypt
To enable them, use this syntax:
make VERSUS=crypto+gcrypt+tomcrypt tools/crypto_bench
They do not need to have been enabled in configure.

It uses at least sin()

"into the doc/examples directory" vs "into doc/examples".

Currently all uses of the emu edge code as well as the code itself
assume int linesize
changing some but not changing all would introduce a security issue
once all use this typedef a simple search and replace can be
done to switch them all to ptrdiff_t
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

* qatar/master:
  mpegvideo: Avoid 32-bit wrapping of linesize multiplications

This is not merged as its not correct for ffmpeg and would introduce a
security issue if merged as is.
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '0ebfdae0':
  doc: Describe TB option of setpts filter

Conflicts:
	doc/filters.texi
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'b4ec7a5f':
  mem: Document the av_realloc family of functions properly
Merged-by: Michael Niedermayer <michaelni@gmx.at>

This makes sure that linesize * start_y doesn't overflow, so that
emulated_edge_mc can get back the original value if needed.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

* commit '7f9e893f':
  build: Report an error message when a pc file is not found

Conflicts:
	configure
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'af11fa54':
  mjpegb: Detect changing number of planes in interlaced video

Conflicts:
	libavcodec/mjpegdec.c

See: ecc31630Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '35cbc98b':
  alac: Check that the channels fit at the given offset

Conflicts:
	libavcodec/alac.c

See: b53f8971Merged-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

* commit 'd7199812':
  4xm: Check that the read track value is non-negative

Conflicts:
	libavformat/4xm.c

See: 0838cfdcMerged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '5bcd3ae5':
  matroskadec: Check that .lang was allocated and set before reading it

Conflicts:
	libavformat/matroskadec.c

See: 01fd1aa0Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'f7c58831':
  alac: Limit max_samples_per_frame

See: 3920d138Merged-by: Michael Niedermayer <michaelni@gmx.at>

realloc() does not accept pointers from memalign().

Ease tracking path problems.

* cehoyos/master:
  Show subtitle resolution in avcodec_string().
Merged-by: Michael Niedermayer <michaelni@gmx.at>

This ensures that no read timestamp functions finds packets before the search window in ff_find_last_ts()
which could cause an infinite loop
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This fixes an infinite loop
An alternative fix would be to revert d73cbc22
but that would worsen error resilience.

Found-by: Justin Ruggles
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

On openbsd the exif-image-jpg test fails but diff treats the files as
binary due to some non ascii symbols in them. This should force it to
treat them as text, which should result in more informative output
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This ensures that no invalid size leaks through
(This issue is hypothetical, ive no testcase)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

The code tries to decode a number of channels at the
offset given by the ff_alac_channel_layout_offsets table.
Even if the number of channels decoded so far doesn't
exceed the total number of channels, we need to check that
we actually can decode that number of channels at this offset
as well.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Otherwise buffer size calculations in allocate_buffers could
overflow later, making the code think a large enough buffer
actually was allocated.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>