This was missed from 350ad50b - this fixes building the fate-srtp
test.
Signed-off-by: Martin Storsjö <martin@martin.st>

This fixes connecting to "Ceton InfiniTV4 PCIe & USB".
Signed-off-by: Martin Storsjö <martin@martin.st>

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

The pointers that get assigned ff_cropTbl were made const in
9e0f14f1, but other variables that transitively are assigned
based on these variables were missed.
Signed-off-by: Martin Storsjö <martin@martin.st>

These are widely used throughout libavcodec, nothing dsputil-specific.

Change ff_cropTbl to a statically initialized table, to avoid
initializing it with a function call.
Signed-off-by: Martin Storsjö <martin@martin.st>

There's no point in these pointers not being const.
Signed-off-by: Martin Storsjö <martin@martin.st>

This makes the vp3 decoder less dependent on dsputil, and will aid
in making it (eventually) dsputil-independent.
Signed-off-by: Martin Storsjö <martin@martin.st>

This way, they can be shared between mpeg4qpel and h264qpel without
requiring either one to be compiled unconditionally.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

In the non-bitexact mode, vp3 currently decodes to the same
frame crcs as before 28f9ab70 (and the output visually looks
correct).
Signed-off-by: Martin Storsjö <martin@martin.st>

Timing on Arrandale:
        C   SSE
Win32:  57   44
Win64:  47   38
Unrolling and not storing mask both save some cycles.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

The gcov/lcov are a common toolchain for visualizing code coverage with
the GNU/Toolchain. The documentation and implementation of this
integration was heavily inspired from the blog entry by Mike Melanson:
http://multimedia.cx/eggs/using-lcov-with-ffmpeg/

There is no arch-optimized version of the H.261 loop filter and there
likely will never be, so the dsputil overhead does not give any benefit.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

CC: libav-stable@libav.org

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

It can be 0 or -1 for invalid files, which may result in invalid memory
access.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

This can happen when the number of skipped lines is not consistent with
the number of coded lines.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Each lace must be independent according to the specification.

Fix heap-buffer-overflow in matroska_parse_block for
corrupted real media in mkv files.

Stricter check than fc43c19a

CC: libav-stable@libav.org

Make sure we notice when the lace_size[n] is a negative value.

CC: libav-stable@libav.org

Fix heap-buffer-overflow in matroska_parse_block for
corrupted real media in mkv files.

CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

The previous syntax is deprecated.

Avoid snprintfing a NULL pointer.

CC: libav-stable@libav.org

The "suncc" atomics implementation uses a suncc specific memory
barrier, but also relies on a few atomic functions from atomic.h,
that are not suncc specific but specific to solaris. This made
the current implementation fail on suncc on linux.

Add simpler names and a shorthand for native atomics (as opposed to
pthreads fallback).

The sample rate index is 3 bits even if currently index 5, 6 and 7 are
not supported.

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

Only deprecated things need this at all anymore, as we have functions
to access them or they are no longer needed.

The document should not encourage use of deprecated APIs.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>