Without this, lcov sometimes misses to normalize paths that contain "/./".
Also, ignore uninteresting hits in system headers.

In the default settings, both tools produce a lot of unhelpful noise.

This patch can be controversial, by assuming floats are IEEE-754 and
particular behaviour of the FPU will get in the way.
Timing on Arrandale and Win32 (thus, x87 FPU is used in the reference).

sbr_qmf_pre_shuffle_c: 115 to 76
sbr_neg_odd_64_c: 84 to 55
sbr_qmf_post_shuffle_c: 112 to 83
Signed-off-by: Diego Biurrun <diego@biurrun.de>

1410 cycles to 1148 on Arrandale/Win64
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Sandybridge: 47 cycles

Having a loop counter is a 7 cycle gain.
Unrolling is another 7 cycle gain.
Working in reverse scan is another 6 cycles.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

If building libav with -MD in the cflags (for making the MSVC compiler
generate code for using a dynamically linked libc), the system headers
that declare strtod, snprintf and vsnprintf declare the functions as
imported from a DLL. To hook up wrappers of our own for these functions,
the function names are defined to avpriv_*, so that the calling code
within libav calls the wrappers instead. Since these functions
are declared to be imported from DLLs, the calling code expects to
load them from DLL import function pointers (creating references to
_imp__avpriv_strtod instead of directly to avpriv_strtod). If the
libav libraries are not built as DLLs, no such function pointers (as
the calling code expects) are created.

The linker can fix this up automatically in some cases (producing
warnings LNK4217 and LNK4049), if the object files are already
included. By telling the linker to try to include those symbols
(without the _imp prefix as the calling code ends up using),
we get the object files included, so that the linker can do the
automatic fixup. This is done via config.h, so that all (or at least
most) of the object files in our libraries force including the compat
files, to make sure they are included regardless of what files from our
static libraries actually are included.
Signed-off-by: Martin Storsjö <martin@martin.st>

Prevent a serious out of buffer bound write.

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

Hack partially based on a commit by Michael Niedermayer <michaelni@gmx.at>
Should fix (or work around) bug 458.

Integrate the code in the packet reading function, instead of inserting
sleeps in many places.
This is simpler to follow and should work better.

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

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

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

97c -> 49c
Some codecs could benefit from more unrolling, but AAC doesn't.

-t 0.5 is 12.5 frames at 25 fps, which may round to either 12 or 13 on
different platforms.

It has been deprecated some time ago, but was forgotten during the last
bump.

This avoids cases where configure tries to weakly enable an item
which actually is disabled, ending up still enabling dependencies
of the item which itself is only enabled weakly.

More concretely, the h264 decoder suggests error resilience, which
is then enabled weakly (unless manually disabled). Previously,
dsputil, which is a dependency of error resilience, was enabled
even if error resilience wasn't enabled in the end.
Signed-off-by: Martin Storsjö <martin@martin.st>

The variable name 'var' is commonly used to iterate through arguments
in other functions. When the pushvar function internally uses the
variable 'var', it makes pushing/popping the variable 'var' not
work as intended.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

The function does not do any rounding, so there is no point in
keeping it in a round template file.

The function is only instantiated once, so there is no point
in keeping it in a template file.

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

Explicitly saying it can't hurt.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

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

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