* commit 'ebc29519d1634bfeb386c20a5d8a52837aae2436':
hwaccel: Support specific frame allocators
Conflicts:
libavcodec/utils.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '5c1d7246cd65dc4db1b6dc36e29ce39fc1068f3f':
lavc: set AVCodecContext.hwaccel in ff_get_format()
Conflicts:
libavcodec/mpeg12dec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The most interesting parts are initialization in ff_MPV_common_init() and
uninitialization in ff_MPV_common_end().
ff_mpeg_unref_picture and ff_thread_release_buffer have additional NULL
checks for Picture.f, because these functions can be called on
uninitialized or partially initialized Pictures.
NULL pointer checks are added to ff_thread_release_buffer() stub function.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit '6f273093e54cba130f3ffde3d6433e74baa4ad89':
LucasArts SMUSH VIMA audio decoder
Conflicts:
Changelog
libavcodec/avcodec.h
libavcodec/codec_desc.c
libavcodec/version.h
libavcodec/vima.c
This commit adds a AV_CODEC_ID_ADPCM_VIMA alias in addition to the previously
used AV_CODEC_ID_VIMA, as well as a AVCodec with name "adpcm_vima" in addition
to the previously used name "vima"
These changes are needed for compatibility with the renamed codec in libav
See: b18357326c and others
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '4a0f6651434c6f213d830140f575b4ec7858519f':
libavcodec: when decoding, copy replaygain side data to decoded frames
Conflicts:
libavcodec/internal.h
libavcodec/rawdec.c
libavcodec/utils.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This limits ABI issues in case libavcodec is linked to a libavutil with larger AVFrame
Which can happen if they are shiped in seperate binary packages and libavutil is upgraded
A cleaner alternative would be to replace them by pointers but this would likely cause
a small speedloss
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is a bit tricky, we allocate a correctly sized AVFrame but then only
copy the compile time AVFrame size, this is to ensure that user applications
which do not use the correct av frame API dont end with out of array reads.
Note, applications using the correct API have set extended_data and the
changed code will never be executed for them.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '8feac29cc46270cc89d6016340e7bac780877131':
lavc: use AVFrame API properly in ff_reget_buffer()
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Fixes inconsistency and out of array accesses
Fixes: 10cdd7e63e7f66e3e66273939e0863dd-asan_heap-oob_1a4ff32_7078_cov_4056274555_mov_h264_aac__mp4box_frag.mp4
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e0ab5078a7d865f8f6fd6a6d3cbe0f380ead4a3d':
lavc: do not force the emu edge flag
Conflicts:
libavcodec/utils.c
There should be no such bugs in ffmpeg, but merging it anyway
as its safer.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The default get_buffer2() implementation (and possibly some
user ones) does not allocate edges when this flag is set, which may
expose bugs in some decoders. Until the 10 release is out, it is safer
to remove this part.
* commit 'f7e85ee996b3886c2b13e928b83277382311af96':
lavc: allow the caller to override dimensions in ff_get_buffer()
Conflicts:
libavcodec/utils.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '50079a6aa93291e6dc9d9fb8d33da83f79e9311d':
lavc: do not leak the internal frame if opening the codec fails
Conflicts:
libavcodec/utils.c
See: 8b285f03f7
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '8058284ce09030b47512746d726fb2ad3ae8a20f':
lavc: add 422/444 YUV with alpha to align_dimensions()
Conflicts:
libavcodec/utils.c
Only cosmetical changes happen as these formats already where in the list before
Merged-by: Michael Niedermayer <michaelni@gmx.at>
