* commit '1fb63d6f':
  dnxhddata: Deduplicate dnx100 tables
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit 'cc320296':
  dnxhddata: Fix cid 1260 luma and chroma tables
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit 'bfe1cd80':
  dnxhddata: Fix 10-bit DNxHD quant matrices
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '38014692':
  x264: Add option to force IDR frames
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit 'eb02387a':
  x264: Expose the NV21 input support
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '74942685':
  hls: Check av_opt_set_dict return value as well
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit 'd0a3e89d':
  dcadec: make a number of samples per subband per subsubframe a named constant
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '8ae1d87a':
  build: Add support for known custom allocators
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '9a3202a9':
  Screenpresso SPV1 decoder
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: https://trac.ffmpeg.org/attachment/ticket/685/movie.264

In the available testcase the actual PPS only uses a few bits
while there are 7kbyte of apparently random data after it
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

* commit '1aa24df7':
  lavu: Deprecate AVFrame.error[]
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '3f1f6053':
  configure: address a copy-paste typo
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

This error was produced by rtmproto.c, it is possibly such streams
where dumped, this commit is needed to support them

Fixes: z0e.flv
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This affects Annex B streams (such as demuxed from .ts and others). It
also handles the format change in reinit-large_420_8-to-small_420_8.h264
correctly.

Instead of passing through the extradata, create it on the fly it from
the currently active SPS and PPS. Since reconstructing the PPS and SPS
NALs would be very complicated and verbose, we use the NALs as they
originally appeared in the bitstream.

The code for writing the extradata is somewhat derived from
libavformat/avc.c, but it's small and different enough that sharing it
is not really worth it.

We assume an upper bound of 4096 bytes for each raw SPS/PPS. It's hard
to determine an exact maximum size, but this value was was considered
high enough and safe.

Needed for the following VideotoolBox commit.

Otherwise, the dsp may change without its permuation being applied.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The current one, while correct, does not yield the best possible
results. The specificiations suggest another formula, which results
in quality gains in the decoded output from fate tests. This
justifies changing said formula.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The coded size is a multiple of the macroblock size, which is 16.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Tables 1258 and 1259 were not zigzagged when added, so it was not
possible to notice the equivalence.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

These table was not zigzagged when added.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Convert them to zigzag order, as the rest of them are.

When I was adding support for 10-bit DNxHD, I just copy-pasted the
missing quant matrices from the spec. Now it turns out the existing
matrices in dnxhddata.c were in zigzag order. This resulted in wrong
quantization for 10-bit DNxHD. The attached patch fixes the problem by
converting 10-bit quant matrices to zigzag order.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

It is only (mis-)used to set the dsp fucntions clear_block(s). But
these functions always work on 16bits-wide elements, which make
the parameter useless and actually harmful, as it causes all content
on more than 8-bits to not use accelerated functions.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>

This should fix RTMP input which was broken by cbbd906b
the 40 + 11 case is untested as it did not occur in the testcase
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

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

Makes it possible to use them in arithmetic expressions.

Reviewed-by: Ivan Uskov <ivan.uskov@nablet.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

When forwarding the frame type information, by default x264 can
decide which kind of keyframe output, add an option to force it
to output IDR frames in to support use-cases such as preparing
the content for segmented streams formats.

x264 build 147 adds the native support for NV21.

Useful to avoid additional pixel format conversion when encoding
from a wide range of capture devices, Android among those.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Bug-Id: CID 1320426

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Fixes Ticket #4898