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>
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>
In the non-bitexact mode, vp3 currently decodes to the same
frame crcs as before 28f9ab702 (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/
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
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
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 fc43c19a56
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 "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.
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
