This patch improves af_asyncts behavior on streams with bogus PTS, which
are either non-monotonic, or contain PTS jitter, and trigger the
non-monotonicity error. With this patch, af_asyncts is able to correct
these streams and avoid the error.

Firstly, it fixes resample compensation calculation by supplying proper
units to avresample_set_compensation (sample count per second instead
of sample count per some arbitrary frame size). Also, the calculation of
the compensation itself is fixed - delta is proportional to an adjustment
of the compensation, not the compensation itself. Ideally, the compensation
should converge to a value that keeps delta at zero.

To be able to deal with sources with PTS jitter even without resampling,
small PTS errors are adjusted, so the output frames do not overlap.

Finally, one more monotonicity check is added.

The FATE reference changes because now there is 8 less samples of
silence because of the pts jitter.
Signed-off-by: Jindřich Makovička <makovick@gmail.com>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

free_tables() frees it already.

This way it does not look like a constant.

This way it does not look like a constant.

This way it does not look like a constant.

This way it does not look like a constant.

This way it does not look like a constant.

This way it does not look like a constant.

This way it does not look like a constant.

This way it does not look like a constant.

There is no point in keeping those separate.

It is not called from outside h264.c

AVCodecContext.bits_per_raw_sample is updated from the previous thread
in the generic update function before the codec specific update_thread
function is called. The check for reinitialization of dsp functions uses
bits_per_raw_sample. When called from update_thread_context it will be
already at the current value and the dsp functions aren't updated if
only the bit depth changes.

do_adobe_auth takes the parameters in the order "opaque, challenge".

Due to the way they are treated, this didn't matter in the tested
setups though - if both are set, we only use one. In the tested
setups (Wowza and Akamai) either one of them were null or they
were both set to the same value, which is why this worked before.
Signed-off-by: Martin Storsjö <martin@martin.st>

This ensures the hwaccel privdata does not leak when a frame buffer could
not be allocated (and toggle the assert when the frame is re-used).
Having no frame buffer available is quite common when using the DXVA2
hwaccel in situations where the DXVA2 renderer is being re-allocated, for
example when moving between displays.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

This ensures the hwaccel privdata does not leak when a frame buffer could
not be allocated (and toggle the assert when the frame is re-used).
Having no frame buffer available is quite common when using the DXVA2
hwaccel in situations where the DXVA2 renderer is being re-allocated, for
example when moving between displays.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Vertical shift is log2_chroma_h, not log2_chroma_w.

Number of planes is not always equal to the number of components even
for formats marked with PIX_FMT_PLANAR -- e.g. NV12 has three components
in two planes.

It just shadows the corresponding AVOption and prevents using named
constants.

This reverts commit d1bec33b, it breaks
FATE.

Those are not usable from the avtools, so mentioning them in the
manpages just confuses the reader.

The total frame size is a combination of the 12 bits in the sequence
header and 2 more bits in the the sequence extension. While the
specification explicitly forbids the dimensions from the sequence header
from being 0 (thus ruling out multiples of 4096), such videos
apparrently exist in the wild so we should attempt to decode them.

Based on a patch by Michael Niedermayer <michaelni@gmx.at>

Fixes Bug 416.

Fixes CVE-2013-2495

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

CC: libav-stable@libav.org

According to the specification the timestamp is represented by a 32bit
unsigned.

CC: libav-stable@libav.org

It is supposed to be height * linesize, not width * linesize.
Thanks to Hendrik Leppkes for pointing out the bug.

They are auto-negotiated.

Filter private data is memset to 0 so there is no point in explicitly
initing anything to 0.