* commit 'a9ba59591ed509fb7e6decfde8da4cbfd4ddf4b8':
ac3dsp: Add some special-case handling for the C downmix function
Merged-by: Clément Bœsch <u@pkh.me>
* commit '8ea35af7620e4f73f9e8c072e1c0fac9a04ec161':
avio: add a new flag for marking streams seekable by timestamp
Merged-by: James Almer <jamrial@gmail.com>
Fixes: runtime error: shift exponent 255 is too large for 32-bit type 'unsigned int'
Fixes: 894/clusterfuzz-testcase-4841537823309824
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '8d1267932ca9c2e343ef303349101bab6681d02e':
x86/h264_weight: use appropriate register size for weight parameters
This commit is a noop, see 5ae0ad001a
Merged-by: James Almer <jamrial@gmail.com>
* commit '2caa93b813adc5dbb7771dfe615da826a2947d18':
mpegaudiodsp: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
* commit '15b4f494fc6bddb8178fdb5aed18b420efc75e22':
mss*: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
* commit 'a339e919cad1ab0125948f0dd9d49f6cb590db89':
ea: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
* commit 'ba479f3daafc7e4359ec1212164569ebe59f0bb7':
hevc: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
* commit 'e4a94d8b36c48d95a7d412c40d7b558422ff659c':
h264chroma: Change type of stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
* commit '2ec9fa5ec60dcd10e1cb10d8b4e4437e634ea428':
idct: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
Aliased compressed AAC bytes are almost certainly not meaningful SBR
data. In the wild this causes harsh artifacts switching HE-AAC streams
that don't have SBR headers aligned with segment boundaries.
Turning off SBR falls back to a default set of upsampling parameters
that can function as a sort of error concealment. This is consistent
with how the decoder handles other sorts of errors.
* commit '956a54129db522998a5abae869568dae2c9774cb':
vaapi_h264: Set max_num_ref_frames to 1 when not using B frames
vaapi_encode: Sync to input surface rather than output
vaapi_encode: Check packed header capabilities
vaapi_encode: Refactor initialisation
This merge is a noop, see:
ee1d04f970 vaapi_h264: Set max_num_ref_frames to 1 when not using B frames
94f446c628 vaapi_encode: Sync to input surface rather than output
478a4b7e6d vaapi_encode: Check packed header capabilities
c8241e730f vaapi_encode: Refactor initialisation
Merged-by: Clément Bœsch <u@pkh.me>
* commit '67d28f4a0fbb52d0734ca3682b85035e96d294fb':
examples/output: switch to the new encoding API
This commit is a noop, our examples are different. Still, we need to
update them to the new API, so doc/libav-merge.txt is updated.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'de2ae3c1fae5a2eb539b9abd7bc2a9ca8c286ff0':
lavc: add clobber tests for the new encoding/decoding API
The merge only re-order what we already have.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '6c09af7e46a5a1ada67ffe832f7895cf2749130b':
APIchanges: fix a typo in the version number
This commit is a noop (typo is not present in FFmpeg).
Merged-by: Clément Bœsch <u@pkh.me>
* commit '0e8d1fc1f013eb805a7b66656d9452bcbca36d22':
lavu: Bump version for the 12bit Planar YUV support
pixfmt: Add yuv444p12 pixel format
pixfmt: Add yuv422p12 pixel format
pixfmt: Add yuv420p12 pixel format
This merge is a noop, we already have all these pixel formats.
Merged-by: Clément Bœsch <u@pkh.me>
It was done on a whim because of the FATE header check and was actually
meant to be removed before pushing.
Also, nobody in review spotted it.
Reviewed-by: wm4
* commit '2b5b1e1e9b89063d352e2efed014f9d761b85032':
swscale: Rename is9_OR_10 to match what it does
This commit is a noop. We use isNBPS() in these places instead since
d736b52a04. is9_15BPS() wouldn't be a good name in our codebase due to
supporting only up to 14 (see 2ea585b8e3).
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e87a501e7d03ac68b58520108fe24ad9d0b36765':
swscale: Update bitdepth range check
This commit is a noop.
Up to 14 bits is supported since fa36f33422. This commits pushes the
limit to 15 bits but we don't seem to have pixel formats that enters in
that category.
12:03 <ubitux> so what's your opinion? should we move to 15 even if unused currently to make it consistent with libav and the function names, or keep our 14 suggesting there might be an issue with 15?
12:05 <ubitux> (functions are called hScale8To15_c, hScale16To15_c, ff_hscale8to15, ...)
12:06 <michaelni> I prefer to keep 14 until theres a case that allows us to test this and i suspect it will not work with 15 at least not all the code
Merged-by: Clément Bœsch <u@pkh.me>
libavcodec now automatically serializes decoding for hwaccels which
are not thread-safe. This means API users, which rely on the libavcodec
native software fallback mechanism, can now simply enable threading
without running into problems.
Certain hardware decoding APIs are not guaranteed to be thread-safe, so
having the user access decoded hardware surfaces while the decoder is
running in another thread can cause failures (this is mainly known to
happen with DXVA2).
For such hwaccels, only allow the decoding thread to run while the user
is inside a lavc decode call (avcodec_send_packet/receive_frame).
Merges Libav commit d4a91e65.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
