* commit 'b9ece15a':
  nullenc: Use the wrapped avframe pseudo-encoder
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit 'd00a8fd4':
  yuv4mpeg: Use the wrapped avframe pseudo-encoder
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '00332e0a':
  wrapped_avframe: Initial implementation
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Partially fixes Ticket 4727.

-duration is not a safe expression, since duration can be INT_MIN.
One might ask how it can become INT_MIN.
Although it is true that line 2574 is no longer reached with INT_MIN due
to commit 053e80f6 (which fixed another
integer overflow issue), mov_update_dts_shift is called on line 3549 as
well, right after a read of untrusted data.
One can do the fix locally there, but that function is already a huge
mess. Changing mov_update_dts_shift is likely better.

This changes duration to INT_MIN + 1 in such cases. This should not make any
practical difference since such streams are anyway fuzzer files.

Tested with FATE.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

FFABS(INT_MIN) is not safe. Alternative of using FFNABS is not as
readable.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

Reviewed-by: Henrik Gramner <henrik@gramner.com>
Signed-off-by: James Almer <jamrial@gmail.com>

This is the same test as for the 8bit case.

This avoid going through constants.c while still sharing them
with proresdsp.asm
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

changing the context state and restoring it is not safe if another
thread writes data into the fifo
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

When scaling only a slice of a frame the output was written always
in the first lines leaving the rest of the frame black.

This patch fixes build of AAC encoder optimized for mips that was broken due
 to some changes in generic code that were not propagated to the optimized code.

Also, some functions in the optimized code are basically duplicate of functions
 from generic code. Since they do not bring enough improvement to the optimized
 code to justify their existence, they are removed (which improves
 maintainability of the optimized code).

Optimizations disabled in 97437bd1 are enabled again.
Signed-off-by: Nedeljko Babic <nedeljko.babic@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

These aren't quite as helpful as the ones in 8bpp, since over there,
we can use pmulhrsw, but here the coefficients have too many bits to
be able to take advantage of pmulhrsw. However, we can still skip
cols for which all coefs are 0, and instead just zero the input data
for the row itx. This helps a few % on overall decoding speed.

The trouble with this function is that intermediates overflow 31+sign
bits, so I've added some helpers (that will also be used in 10/12bpp
8x8, 16x16 and 32x32) to make that easier, basically emulating a half-
assed pmaddqd using 2xpmaddwd. It's currently sse2-only, if anyone sees
potential in adding ssse3, I'd love to hear it.

In particular for 10 and 12 bits.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This makes it easier to see where a failure happens
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

On 12 frames of a 444p 12 bits DNxHR sequence, _put function:
C:         78902 decicycles in idct,  262071 runs,     73 skips
avx:       32478 decicycles in idct,  262045 runs,     99 skips

Difference between the 2:
stddev:    0.39 PSNR:104.47 MAXDIFF:    2

This is unavoidable and due to the scale factors used in the x86
version, which cannot match the C ones.

In addition, the trick of adding an initial bias to the input of a
pass can overflow, as the input coefficients are already 15bits,
which is the maximum this function can handle.

Overall, however, the omse on 12 bits samples goes from 0.16916 to
0.16883. Reducing rowshift by 1 improves to 0.0908, but causes
overflows.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Modeled from the prores version. Clips to [0;1023] and is bitexact.
Bitexactness requires to add offsets in different places compared to
prores or C, and makes the function approximately 2% slower.

For 16 frames of a DNxHD 4:2:2 10bits test sequence:

C:    60861 decicycles in idct, 1048205 runs,    371 skips
sse2: 27567 decicycles in idct, 1048216 runs,    360 skips
avx:  26272 decicycles in idct, 1048171 runs,    405 skips

The add version is not implemented, so the corresponding dsp
function is set to NULL to make it clear in a code executing it.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

When the input of a pass has 15 or 16 bits of precision (in particular
the column pass), the addition of a bias to W4 may lead to overflows
in the input to pmaddwd.

This requires postponing the adding of the bias to after the first
butterfly. To do so, the fact that m15, unused although zeroed, is
exploited. In case the pass is safe, an address can be directly used,
and the number of xmm regs can be decreased. Otherwise, the 32bits bias
is loaded into it.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

It was useful to (accidentally?) spot an overflow in the column pass
of the x86 simple_idct10 implementation.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

omse goes from 0.03060703 (which fails for dct-test) to 0.01663750.
This also actually improve the error of decoding the sample generated
by fate-vsynth3-dnxhd1080i-10bit using simple_idct10 to FAANI, which
goes (when resampled to yuv422p) from:
stddev:    0.06 PSNR: 72.28 MAXDIFF:    1
to identical.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This should be reused for a generic simple_idct10 function.
Requires a bit of trickery to declare common constants in C.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

To keep it similar to the other functions which are all named *_pred.

Left out of last commit which added support for eight channel audio.

Dequant or encoding were trying to reverse a scan that hadn't been
applied...
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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