The warnings are false positives, older gcc versions (such as 4.5)
think the variables can be used uninitialized while they in
practice can't, while newer (4.6) gets it right.
Signed-off-by: Martin Storsjö <martin@martin.st>

CC:libav-stable@libav.org

Since decode_slice_header() returns before the reference lists are
constructed, there are zero valid references.

CC:libav-stable@libav.org

They are filled in decode_slice_header() anyway.

The callers of this function can't report errors sanely. If this
one malloc fails, don't write the extradata byte, make sure we
try to malloc it the next time we're called instead, and make sure
we still consume the input data byte.

CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

This header byte is only present when actually reading a VP6 frame,
not when reading the codec type field in the metadata. This
potential bug has been present since 5b54a90c.

CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

This reverts commit f90ff772.

The code should be put back in h264_qpel_8bit.asm, but unfortunately
it is unconditionally used from dsputil_mmx.c since 71155d7b.

The value is within 0 and 32.

Remove an `array subscript is below array bounds` warning.

The functions are private.

This allows setting/overriding e.g. the bitrate parameter, which
is required for the smoothstreaming muxer. Normally, the bitrate
is set by the demuxer in these cases, but not all demuxers can
provide it. This allows stream copy of data to the smoothstreaming
muxer from such inputs.
Signed-off-by: Martin Storsjö <martin@martin.st>

In this case, no encoder specific options are filtered, only
options specific to that codec type in general.
Signed-off-by: Martin Storsjö <martin@martin.st>

This fixes boken fate tests with MSVC with DLLs, broken since
b5f536d2.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

The handling of the environment variable no_proxy, present since
one of the initial commits (de6d9b64), is inconsistent with
how many other applications and libraries interpret this
variable. Its bare presence does not indicate that the use of
proxies should be skipped, but it is some sort of pattern for
hosts that does not need using a proxy (e.g. for a local network).

As investigated by Rudolf Polzer, different libraries handle this
in different ways, some supporting IP address masks, some supporting
arbitrary globbing using *, some just checking that the pattern matches
the end of the hostname without regard for whether it actually is
the right domain or a domain that ends in the same string.

This simple logic should be pretty similar to the logic used by
lynx and curl.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

The external assembly function uses mmxext instructions and should not be
masqueraded as an mmx-only function. Instead, use the mmx-only inline
assembly function.

These became unused in 71155d7b.
Signed-off-by: Martin Storsjö <martin@martin.st>

This fixes many icc warnings when not setting the CPU type.

avprobe and avserver use cmdutils and do not strictly require libavresample.

This is consistent with the rest of libavcodec.

This is consistent with the rest of libavcodec.

This is consistent with the rest of libavcodec.

This is more compatible and not more complicated.

The specification does not prevent an encoder to write the amplitude 0
as 0 amplitude_bits.

Our get_bits() implementation might not support a zero sized read
properly, thus the additional branch.

Rate and order must not be 0 even if the specification does not say that
explicitly.

Use the commonly used "if (!var)" instead of "if (var == 0)".

The value is used to calculate output LSP curve and a division by zero
and out of array accesses would occur.

CVE-2013-0894

CC: libav-stable@libav.org
Reported-by: Dale Curtis <dalecurtis@chromium.org>
Found-by: inferno@chromium.org
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>