This change is buggy.

This reverts commit d46c9f83.

Mostly useful for the audio-filters branch, to make more apparent the
distinction between configure_audio_filters() and
configure_video_filters().
Signed-off-by: Stefano Sabatini <stefano.sabatini-lala@poste.it>

Signed-off-by: Stefano Sabatini <stefano.sabatini-lala@poste.it>

Signed-off-by: Stefano Sabatini <stefano.sabatini-lala@poste.it>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This patch completes the high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This patch lets e.g. dsputil_init chose dsp functions with respect to
the bit depth to decode. The naming scheme of bit depth dependent
functions is <base name>_<bit depth>[_<prefix>] (i.e. the old
clear_blocks_c is now named clear_blocks_8_c).

Note: Some of the functions for high bit depth is not dependent on the
bit depth, but only on the pixel size. This leaves some room for
optimizing binary size.

Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

In high bit depth, the QP values may now be up to (51 + 6*(bit_depth-8)).

Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

In high bit depth the pixels will not be stored in uint8_t like in the
normal case, but in uint16_t. The pixel size is thus 1 in normal bit
depth and 2 in high bit depth.

Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The functions moved are used when decoding h264.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Also add support for these formats in libswscale.

Needed for high bit depth h264 decoding.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Needed for high bit depth h264 decoding.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Unfortunately the output buffer size check assumes that the
input buffer is never over-consumed, thus this actually
also allowed to write outside the output buffer if "lucky".

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

AS      libavcodec/arm/ac3dsp_armv6.o
ffmpeg-src/libavcodec/arm/ac3dsp_armv6.S: Assembler messages:
ffmpeg-src/libavcodec/arm/ac3dsp_armv6.S:40: Error: selected processor
does not support `movw r8,#0x1fe0'
make[1]: *** [libavcodec/arm/ac3dsp_armv6.o] Error 1

MOVW is ARMv7 way to load constant:
   * movw, or move wide, will move a 16-bit constant into a register,
implicitly zeroing the top 16 bits of the target register.
   * movt, or move top, will move a 16-bit constant into the top half
of a given register without altering the bottom 16 bits
To load 32 bit constant, movw  lower16; movt upper16; is better than
ldr if available, because:
While this approach takes two instructions, it does not require any
extra space to store the constant so both the movw/movt method and the
ldr method will end up using the same amount of memory. Memory
bandwidth is precious in and the movw/movt approach avoids an extra
read on the data side, not to mention the read could have missed the
cache.

But here it is armv6 optimization, so that we have to use ldr.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

* qatar/master:
  daud: Don't write packets that are too large to have their size expressed in the bytestream.
DUPLICATE  pthread: validate_thread_parameters() ignored slice-threading being intentionally off
DUPLICATE  Use consistent condition for whether to run slice-threading execute function.
  avformat.h: fix a misplaced #endif
DUPLCIATE  vaapi: cope with VA-API 0.32, i.e. fix VC-1 decoding on Sandy Bridge.
DUPLICATE  vaapi: filter out DELAYED_PIC_REF flag to determine field.
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Fixes ticket #15.

The thread_type API allows you to request only FF_THREAD_FRAME (instead of
FRAME | SLICE), but it was being ignored.
We don't implement both of them at the same time, so there isn't an effect
on current codecs, except that you can request no kinds of threading now
(a bit useless).
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

(cherry picked from commit a18e7b4f)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>

This fixes ticket #23.

(cherry picked from commit 621f4c98)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>

As previously discussed, the CrystalHD hardware returns exceptionally
useless information about interlaced h.264 content - to the extent
that it's not possible to distinguish most MBAFF and PAFF content until
it's too late.

In an attempt to compensate for this, I'm introducing two mechanisms:

1) Peeking at the picture number of the next picture

The hardware provides a capability to peek the next picture number. If
it is the same as the current picture number, then we are clearly dealing
with two fields and not a frame or fieldpair.

If this always worked, it would be all we need, but it's not guaranteed
to work. Sometimes, the next picture may not be decoded sufficiently
for the number to be known; alternately, a corruption in the stream may
cause the hardware to refuse to return the number even if the next
intact frame is decoded. In either case, the query will return 0.

If we are unable to peek the next picture number, we assume that the
picture is a frame/fieldpair and return it accordingly. If that turns
out to be incorrect, we discard the second field, and the user has
to live with the glitch. In testing, false detection can occur for
the first couple of seconds, and then the pipeline stabalizes and
we get correct detection.

2) Use the h264_parser to detect when individual input fields have
been combined into an output fieldpair.

I have multiple PAFF samples where this behaviour is detected. The
peeking mechanism described above will correctly detect that the
output is a fieldpair, but we need to know what the input type was
to ensure pipeline stability (only return one output frame per input
frame).

If we find ourselves with an output fieldpair, yet the input picture
type was a field, as reported by the parser, then we are dealing with
this case, and can make sure not to return anything on the next
decode() call.

Taken together, these allow us to remove the hard-coded hacks for
different h.264 types, and we can clearly describe the conditions
under which we can trust the hardware's claim that content is
interlaced.
Signed-off-by: Philip Langdale <philipl@overt.org>

Now that we know the type of the input picture, we have to bring
that information to the output picture to help identify its type.
We do this by adding a field to the opaque_list node.
Signed-off-by: Philip Langdale <philipl@overt.org>