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/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: 873/clusterfuzz-testcase-5714546230558720

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

* commit '8d126793':
  x86/h264_weight: use appropriate register size for weight parameters

This commit is a noop, see 5ae0ad00Merged-by: James Almer <jamrial@gmail.com>

* commit '2caa93b8':
  mpegaudiodsp: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>

* commit '15b4f494':
  mss*: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>

* commit 'a339e919':
  ea: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>

* commit 'ba479f3d':
  hevc: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>

* commit 'e4a94d8b':
  h264chroma: Change type of stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>

* commit '2ec9fa5e':
  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.

Fixes memleak.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

Also make it more readable while at it.
Signed-off-by: James Almer <jamrial@gmail.com>

* commit 'b2939a75':
  blockdsp: Change type of array stride parameters to ptrdiff_t
Merged-by: Clément Bœsch <u@pkh.me>

* commit '3281d823':
  intrax8: Change type of array stride parameters to ptrdiff_t
Merged-by: Clément Bœsch <u@pkh.me>

* commit '92c5755a':
  hpeldsp: arm: Update comments left behind in 25841dfeMerged-by: Clément Bœsch <u@pkh.me>

* commit '009adfd4':
  x86: fpel: Remove unnecessary sign extend
Merged-by: Clément Bœsch <u@pkh.me>

* commit '956a5412':
  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:

ee1d04f9 vaapi_h264: Set max_num_ref_frames to 1 when not using B frames
94f446c6 vaapi_encode: Sync to input surface rather than output
478a4b7e vaapi_encode: Check packed header capabilities
c8241e73 vaapi_encode: Refactor initialisation
Merged-by: Clément Bœsch <u@pkh.me>

* commit '67d28f4a':
  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 '7bf8db4d':
  tdsc: use the new decoding API
Merged-by: Clément Bœsch <u@pkh.me>

* commit 'de2ae3c1':
  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 '68811a41':
  mpegvideo_enc: use the new encoding API for b_strategy=2
Merged-by: Clément Bœsch <u@pkh.me>

* commit 'f03f78bc':
  mpegvideo_enc: handle encoding errors with b_strategy=2
Merged-by: Clément Bœsch <u@pkh.me>

* commit '6f733eca':
  mpegvideo_enc: add const to the AVCodec instance
Merged-by: Clément Bœsch <u@pkh.me>

* commit '6c09af7e':
  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 '0e8d1fc1':
  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 '2b5b1e1e':
  swscale: Rename is9_OR_10 to match what it does

This commit is a noop. We use isNBPS() in these places instead since
d736b52a. is9_15BPS() wouldn't be a good name in our codebase due to
supporting only up to 14 (see 2ea585b8).
Merged-by: Clément Bœsch <u@pkh.me>

* commit 'e87a501e':
  swscale: Update bitdepth range check

This commit is a noop.

Up to 14 bits is supported since fa36f334. 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>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

* commit 'de8e096c':
  swscale: Consistently order input YUV pixel formats
Merged-by: Clément Bœsch <u@pkh.me>

Avoids reading from uninitialized memory, regression since af1761f7

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.

Whatever it was supposed to do.

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>

Merges Libav commit 8dfba25c.
Signed-off-by: wm4 <nfxjfg@googlemail.com>

This improves commit 59c70227.

In ff_thread_report_progress(), the fast code path can load
progress[field] with the relaxed memory order, and the slow code path
can store progress[field] with the release memory order. These changes
are mainly intended to avoid confusion when one inspects the source code.
They are unlikely to have measurable performance improvement.

ff_thread_report_progress() and ff_thread_await_progress() form a pair.
ff_thread_await_progress() reads progress[field] with the acquire memory
order (in the fast code path). Therefore, one expects to see
ff_thread_report_progress() write progress[field] with the matching
release memory order.

In the fast code path in ff_thread_report_progress(), the atomic load of
progress[field] doesn't need the acquire memory order because the
calling thread is trying to make the data it just decoded visible to the
other threads, rather than trying to read the data decoded by other
threads.

In ff_thread_get_buffer(), initialize progress[0] and progress[1] using
atomic_init().
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Merges Libav commit 343e2833.
Signed-off-by: wm4 <nfxjfg@googlemail.com>

When decoding with threads enabled, the get_format callback will be
called with one of the per-thread codec contexts rather than with the
outer context.  If a hwaccel is in use too, this will add a reference
to the hardware frames context on that codec context, which will then
propagate to all of the other per-thread contexts for decoding.  Once
the decoder finishes, however, the per-thread contexts are not freed
normally, so these references leak.

Merges Libav commit fd0fae60.
Signed-off-by: wm4 <nfxjfg@googlemail.com>

Merges Libav commit 84f22568.
Signed-off-by: wm4 <nfxjfg@googlemail.com>

Merges Libav commit 59c70227.
Signed-off-by: wm4 <nfxjfg@googlemail.com>