* commit 'fb147308':
  aac_parser: add required padding for GetBitContext buffer

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

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

The code gave apparently completely wrong values

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

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

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

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

Fixes stack buffer overflow errors detected by address sanitizer in
various fate tests.

CC: libav-stable@libav.org

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

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

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

Fixes part of Ticket3619
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This avoid potential out of array accesses
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fix part of Ticket3619
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

If one of the dimensions is larger than 8176, s->mb_width or
s->mb_height is larger than 511, leading to an int16_t overflow of
s->mv_max.{x,y}. This then causes av_clip to be called with amin > amax.

Changing the type to int avoids the overflow and has no negative
effect, because s->mv_max is only used in clamp_mv for clipping.
Since mv_max.{x,y} is positive and mv_min.{x,y} negative, av_clip can't
increase the absolute value. The input to av_clip is an int16_t, and
thus the output fits into int16_t as well.

For additional safety, s->mv_{min,max}.{x,y} are clipped to int16_t range
before use.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

The first check is done without the AVIOContext, so alloc it only if said check succeeds
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>

* commit '4733a12d':
  rtpdec_asf: Check memory allocation and free memory on error

Conflicts:
	libavformat/rtpdec_asf.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '6308cd48':
  mov: Check memory allocation
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'bc1eace1':
  jack: Check memory allocation

Conflicts:
	libavdevice/jack.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'f7e93247':
  audiointerleave: Always initialize new_pkt

Conflicts:
	libavformat/audiointerleave.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '8ef98855':
  sctp: Always initialize outmsg struct
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'caf7be30':
  mpjpgdec: free AVIOContext leak on early probe fail

Conflicts:
	libavformat/mpjpegdec.c

See: 34d278f9, this was mistakenly reimplemented, also see ffmpeg IRC log of today
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '925b80d6':
  mpegvideo: Move OutFormat enum to mpegutils.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '9bb11be0':
  mpegvideo: Split picture allocation for encoding and decoding

Conflicts:
	libavcodec/mpegvideo.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Otherwise the check 'tile_size < size' treats a negative size as
unsigned, causing the check to pass. This subsequently leads to
segmentation faults.

This was originally fixed as part of Libav commit 72ca83, so the
original author is one of the following developers:
        Anton Khirnov <anton@khirnov.net>
        Diego Biurrun <diego@biurrun.de>
        Luca Barbato <lu_zero@gentoo.org>
        Martin Storsjö <martin@martin.st>
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

* commit 'f8716a14':
  mpegvideo: Rework frame_size_alloc function

Conflicts:
	libavcodec/mpegvideo.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'da0c8664':
  mpegvideo: Move various temporary buffers to a separate context

Conflicts:
	libavcodec/mpegvideo.c
	libavcodec/mpegvideo_enc.c
	libavcodec/mpegvideo_motion.c
	libavcodec/rv34.c
	libavcodec/vc1_mc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

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

* commit 'a6f19d6a':
  configure: Support MSVC 2015

Conflicts:
	configure
	libavutil/internal.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>

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

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

Currently restricted to blending pixels that only contain either
0 or 255 in their alpha components
Signed-off-by: Donny Yang <work@kota.moe>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Donny Yang <work@kota.moe>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Donny Yang <work@kota.moe>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The spec specifies the dispose operation as how the current (i.e., currently
being rendered) frame should be disposed when the next frame is blended onto it

This is contrary to ffmpeg's current behaviour of interpreting the dispose
operation as how the previous (i.e., already rendered) frame should be disposed

This patch fixes ffmpeg's behaviour to match those of the spec, which involved
a rewrite of the blending function
Signed-off-by: Donny Yang <work@kota.moe>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This can be useful for debugging, or in scenarios where the user
doesn't want to use the system's DNS settings for whatever reason.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

CC: libav-stable@libav.org
Bug-Id: CID 1257774

CC: libav-stable@libav.org
Bug-Id: CID 1292518

CC: libav-stable@libav.org
Bug-Id: CID 1292520

CC: libav-stable@libav.org
Bug-Id: CID 609333

CC: libav-stable@libav.org
Bug-Id: CID 1302711