Derived from VLC's http module.
Original authors:
Antoine Cellerier <dionoea@videolan.org>
Sébastien Escudier <sebastien-devel@celeos.eu>
Rémi Duraffort <ivoire@videolan.org>
Rémi Denis-Courmont <remi@remlab.net>
Francois Cartegnie <fcvlcdev@free.fr>
Normally, http servers shouldn't send this to us since we
don't advertise it with an Accept-Encoding header, but some
servers still do it anyway.
Signed-off-by: Martin Storsjö <martin@martin.st>
Only check dependencies if invoking the make targets 'check'
or anything matching 'fate%' except 'fate-rsync'.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure that values that are left-shifted by this constant
end up casted to 64 bit before shifting, avoiding overflow if the
value ends up larger than 2 GB.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously it was partly only added to central functions called
internally, however if GCC would inline these into the public fuction, the
alignment attribute would not take effect.
Instead, add it to all public entry points to avoid these problems.
Signed-off-by: Martin Storsjö <martin@martin.st>
Slice threading does not work with hardware acceleration, as decoding
is per-picture. This fixes Bugzilla #542.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
VDPAU expects the bitstream value (0, 2 or 3).
libavcodec uses an enum (0, 1 or 2).
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
When building for iOS in thumb mode, gas-preprocessor.pl doesn't
mark unused labels as thumb functions (as it does for other
local labels, where it can figure out that they are functions
due to being referenced in branch instructions). This leads to
linker warnings for some of those local labels, such as:
ld: warning: ARM function not 4-byte aligned: __a_evaluation from
libavcodec/libavcodec.a(simple_idct_arm.o)
Therefore, comment them out since they don't have any function.
They do still have a value in documenting key points in the
assembly source though.
Signed-off-by: Martin Storsjö <martin@martin.st>
Before After
Mean StdDev Mean StdDev Change
This function 1323.0 98.0 746.2 60.6 +77.3%
Overall 15400.0 336.4 14147.5 288.4 +8.9%
Signed-off-by: Martin Storsjö <martin@martin.st>
Before After
Mean StdDev Mean StdDev Change
This function 1389.3 4.2 967.8 35.1 +43.6%
Overall 15577.5 83.2 15400.0 336.4 +1.2%
Signed-off-by: Martin Storsjö <martin@martin.st>
Before After
Mean StdDev Mean StdDev Change
This function 868.2 33.5 436.0 27.0 +99.1%
Overall 15973.0 223.2 15577.5 83.2 +2.5%
Signed-off-by: Martin Storsjö <martin@martin.st>
Before After
Mean StdDev Mean StdDev Change
This function 2653.0 28.5 1108.8 51.4 +139.3%
Overall 17049.5 408.2 15973.0 223.2 +6.7%
Signed-off-by: Martin Storsjö <martin@martin.st>
Before After
Mean StdDev Mean StdDev Change
This function 366.2 18.3 277.8 13.7 +31.9%
Overall 18420.5 489.1 17049.5 408.2 +8.0%
Signed-off-by: Martin Storsjö <martin@martin.st>
This is similar to int32_to_float_fmul_scalar, but
loads a new scalar multiplier every 8 input samples.
This enables the use of much larger input arrays, which
is important for pipelining on some CPUs (such as
ARMv6).
Signed-off-by: Martin Storsjö <martin@martin.st>
Before After
Mean StdDev Mean StdDev Change
This function 1175.0 4.4 366.2 18.3 +220.8%
Overall 19285.5 292.0 18420.5 489.1 +4.7%
Signed-off-by: Martin Storsjö <martin@martin.st>
Before After
Mean StdDev Mean StdDev Change
This function 9295.0 114.9 4853.2 83.5 +91.5%
Overall 23699.8 397.6 19285.5 292.0 +22.9%
Signed-off-by: Martin Storsjö <martin@martin.st>
libx264 has a few data exports which require X264_API_IMPORTS
to be defined if we link to libx264 dynamically on Windows.
In a similar fashion to how we handle our compat snprintf
implementation, if we define it all the time, the compiler
will first try and link to __imp_x264_symbol_name, and failing
that, as in the case of a static libx264, will attempt to link
to the non-prefixed symbol, which has already been pulled in by
other x264 functions' object files.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
