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.

The named constant needs to be searched for in the same object on which
the option is set, i.e. target_obj.

This is more consistent with the naming in the rest of Libav.

To avoid allocating ridiculous amounts of memory for corrupted files,
read the input in chunks limited to filesize or an arbitrary large
amount when that is not known (chosen to be 50M).

The check `src > dst' in the form `&c->out[-back] > c->out' invokes
pointer overflow, which is undefined behavior in C.

Remove the check.  Also replace `&c->out[-back] < c->out_start' with
a safe form `c->out - c->out_start < back' to avoid overflow.

CC: libav-stable@libav.org
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>