When encoding alpha channel in libvpx, the stride isn't set
properly for the alpha encoder. Fixing it.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
fmtconvert: Explicitly use int32_t instead of int
Conflicts:
libavcodec/ac3dec.c
libavcodec/fmtconvert.c
libavcodec/fmtconvert.h
See: f49564c6075935443323abf4571a62205e7b3c59
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '8f24c12be7a3b3ea105e67bba9a867fe210a2333':
ac3dec: Don't consume more data than the actual input packet size
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This was handled properly in the normal return case at the end
of the function, but not in this special case.
Returning a value larger than the input packet size can cause
problems for certain library users.
Returning the actual input buffer size unconditionally, since
it is not guaranteed that frame_size is set to a sensible
value at this point.
Cc: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '25a6666f6c07c6ac8449a63d7fbce0dfd29c54cd':
indeo: Bound-check before applying motion compensation
The added checks and one previously added check are replaced by asserts,
the conditions can only be
true when vectors are invalid or there are worse inconsistencies.
We are checking the vectors validity and there should be no
inconsistencies, thus the checks should not be needed.
Also no files are known to cause any anomalies in ffmpeg
Merged-by: Michael Niedermayer <michaelni@gmx.at>
A frame marked FRAMETYPE_NULL cannot be scalable and requires a
previous frame successfully decoded.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
* commit '031be5b41b54c3b666f31d83fe3ad41c194af8c5':
ac3dec: Consistently use AC3_BLOCK_SIZE and sizeof
Conflicts:
libavcodec/ac3dec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
If the channel mapping map multiple output channels to one
input channel, we should only increment the actual pointer once.
Cc: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '3802833bc1f79775a1547c5e427fed6e92b77e53':
dca: Respect the current limits in the downmixing capabilities
Conflicts:
libavcodec/dcadec.c
See: 8e77c3846e91b1af9df4084736257d9899156eef
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'c82da343e635663605bd81c59d872bee3182da73':
pcm: always use codec->id instead of codec_id
This is not merged as we consistently use codec_id, while libav against what
the comit message might hint at mixes both in the decoder.
Its fine to use either but it should be consistent.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'c0d973c41b4568d5bad1295879e35cfa611bdcf2':
vdpau: use the correct namespace for the union
Conflicts:
libavcodec/vdpau.h
See: 68dfe530e0fb03b4d21dfe37f8a572b95c68485e
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e9d394f3fad7e8fd8fc80e3b33cb045bbaceb446':
mlpdec: Do not set invalid context in read_restart_header
Conflicts:
libavcodec/mlpdec.c
See: a9cd12ee2afb3f3aad783c396816b23d8513f472
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3abde1a3b49cf299f2aae4eaae6b6cb5270bdc22':
pcx: Do not overread source buffer in pcx_rle_decode
Conflicts:
libavcodec/pcx.c
See: 8cd1c0febe88b757e915e9af15559575c21ca728
Bytestream based system is left in place and not switched to buf+end, such switch would be
a step backward
Merged-by: Michael Niedermayer <michaelni@gmx.at>
