Fixes undefined behavior and segfault
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 8edc17b639)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Workaround for ticket #4287.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 7b1c03aa74)
Conflicts:
libavcodec/libx264.c
Fixes ticket #4628.
The problem arose, in the sample file at least, in the last block where the
minimum and maximum Rice partition orders were both 0. In that case, and any
other where pmax == pmin, the original UINT32_MAX placeholder value for
bits[opt_porder] was getting overwritten before the comparison to check if the
current partition order is a new optimal, so the correct partition order and
RiceContext params were not being set.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 2469ed32c8)
Neccessary -> Necessary
formated -> formatted
thee -> the
eventhough -> even though
seperately -> separately
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
(cherry picked from commit ed0b1db640)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If chan2 is not smaller than the number of channels, it can cause
segmentation faults due to dereferencing a NULL pointer.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 05c57ba2f4)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The AVFrame values are closer to the AVFrame bitmap changed instead of
the AVCodecContext values, so this should be more robust
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit aef0e0f009)
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>
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 'da0c8664b4dc906696803685f7e53ade68594ab8':
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>
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>
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>
The main ff_alloc_picture() function is made more generic with all the
parameters necessary as arguments. This will allows to move most of the
related functions to a separate file later.
Right now wrappers are provided to try and minimize the number of
changes in the code.
* commit 'bc76c46943272515805d7ac48ca39f14826d1fed':
aac: Wait to know the channels before allocating frame
Conflicts:
libavcodec/aacdec.c
See: 676a395ab9
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The channel configuration can be delivered only by the PCE,
try to parse it first and not try to decode until a channel
configuration is set.
CC: libav-stable@libav.org
