The option became too aggressive with GCC 6, generating nearly 500
warnings from static const variables defined in assorted headers
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
It serves absolutely no purpose other than to confuse potentional
Android developers about how to use hardware acceleration properly
on the the platform. The stagefright "API" is not public, and the
MediaCodec API is the proper way to do this.
Furthermore, stagefright support in avcodec needs a series of
magic incantations and version-specific stuff, such that
using it actually provides downsides compared just using the actual
Android frameworks properly, in that it is a lot more work and confusion
to get it even running. It also leads to a lot of misinformation, like
these sorts of comments (in [1]) that are absolutely incorrect.
[1] http://stackoverflow.com/a/29362353/3115956
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Let's disable the ISAs first, and then the core capabilities, as we do
for the rest of the cores. This way the code is better organized.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Solves an issue that will get triggered when gcc 20 rolls in.
Found-by: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Replaces by real arithmetic. Tested the validity of these transformations separately.
Numerical differences are ~1e-15, and should not matter: it is not even
clear which is more precise mathematically.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
exp10 is a function available in GNU libm. Looks like no other common
libm has it. This adds support for it to FFmpeg.
There are essentially 2 ways of handling the fallback:
1. Using pow(10, x)
2. Using exp2(M_LOG2_10 * x).
First one represents a Pareto improvement, with no speed or accuracy
regression anywhere, but speed improvement limited to GNU libm.
Second one represents a slight accuracy loss (relative error ~ 1e-13)
for non GNU libm. Speedup of > 2x is obtained on non GNU libm platforms,
~30% on GNU libm. These are "average case numbers", another benefit is
the lack of triggering of the well-known terrible worst case paths
through pow.
Based on reviews, second one chosen. Comment added accordingly.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
complex is not available on all platforms. Furthermore, it is trivial to
rewrite complex number expressions to real arithmetic, and in fact
sometimes advantageous for performance reasons: by wrapping as a complex,
one forces a particular Cartesian representation that is not necessarily optimal for the purpose.
Configure dependencies also removed, and aemphasis is now available across
all platforms.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Source code is from Boost:
http://www.boost.org/doc/libs/1_46_1/boost/math/special_functions/erf.hpp
with appropriate modifications for FFmpeg.
Tested on interval -6 to 6 (beyond which it saturates), +/-NAN, +/-INFINITY
under -fsanitize=undefined on clang to test for possible undefined behavior.
This function turns out to actually be essentially as accurate and faster than the
libm (GNU/BSD's/Mac OS X), and I can think of 3 reasons why upstream
does not use this:
1. They are not aware of it.
2. They are concerned about licensing - this applies especially to GNU
libm.
3. They do not know and/or appreciate the benefits of rational
approximations over polynomial approximations. Boost uses them to great
effect, see e.g swr/resample for bessel derived from them, which is also
similarly superior to libm variants.
First, performance.
sample benchmark (clang -O3, Haswell, GNU/Linux):
3e8 values evenly spaced from 0 to 6
time (libm):
./test 13.39s user 0.00s system 100% cpu 13.376 total
time (boost based):
./test 9.20s user 0.00s system 100% cpu 9.190 total
Second, accuracy.
1e8 eval pts from 0 to 6
maxdiff (absolute): 2.2204460492503131e-16
occuring at point where libm erf is correctly rounded, this is not.
Illustration of superior rounding of this function:
arg : 0.83999999999999997
erf : 0.76514271145499457
boost : 0.76514271145499446
real : 0.76514271145499446
i.e libm is actually incorrectly rounded. Note that this is clear from:
https://github.com/JuliaLang/openlibm/blob/master/src/s_erf.c (the Sun
implementation used by both BSD and GNU libm's), where only 1 ulp is
guaranteed.
Reasons it is not easy/worthwhile to create a "correctly rounded"
variant of this function (i.e 0.5ulp):
1. Upstream libm's don't do it anyway, so we can't guarantee this unless
we force this implementation on all platforms. This is not easy, as the
linker would complain unless measures are taken.
2. Nothing in FFmpeg cares or can care about such things, due to the
above and FFmpeg's nature.
3. Creating a correctly rounded function will in practice need some use of long
double/fma. long double, although C89/C90, unfortunately has problems on
ppc. This needs fixing of toolchain flags/configure. In any case this
will be slower for miniscule gain.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
For systems with broken libms.
Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular double x and
combinations of these.
Old versions of MSVC need some UINT64_C hackery.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
arc4random() was designed as a superior interface for system random
number generation, designed for OpenBSD and subsequently incorporated by
other BSD's, Mac OS X, and some non-standard libc's. It is thus an improvement to
use it whenever available.
As a side note, this may or may not get included in glibc, and there is
a proposal to create a posix_random family based on these ideas:
http://austingroupbugs.net/view.php?id=859.
Tested on Mac OS X.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
* commit 'e02de9df4b218bd6e1e927b67fd4075741545688':
lavc: export Dirac parsing API used by the ogg demuxer as public
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Having a configure option with the same name as a MIPS ISA is confusing,
so better to remove it. This option was being used to add some
optimizations to a specific core (i6400). We will add the optimizations
just when the i6400 core has been detected, in a later patch.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Having a configure option with the same name as a MIPS ISA is confusing,
so better to remove it. This option was being used to add some
optimizations to a specific core (p5600). We will add the optimizations
just when the p5600 core has been detected, in a later patch.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes builds with --disable-vda, which previously failed with
undefined references to CVImageBuffer* and CVPixelBuffer* functions.
Signed-off-by: Martin Storsjö <martin@martin.st>
While pr is a valid POSIX.1 command, its usage in configure
is a little borderline and is possible to replace it with
printf.
Bug-Id: 913
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* commit 'afdff8008149515afebf9992eae84be7d76e6b1e':
configure: Clearly state that MSYS native builds are discouraged
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
MSYS, as per cygwin, by default uses a custom posix abstraction
in the form of a "msys2.dll". Programs build that way are harder to
distribute and use.
MSYS2 provides alternate launcher scripts that provide a MINGW
environment nearly out of box.
It is known that the naive sqrt(x*x + y*y) approach for computing the
hypotenuse suffers from overflow and accuracy issues, see e.g
http://www.johndcook.com/blog/2010/06/02/whats-so-hard-about-finding-a-hypotenuse/.
This adds hypot support to FFmpeg, a C99 function.
On platforms without hypot, this patch does a reaonable workaround, that
although not as accurate as GNU libm, is readable and does not suffer
from the overflow issue. Improvements can be made separately.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This implementation does not support TLS listen sockets and loading
CA/Certs from files.
The Windows API does not support loading PEM certs, and would either
require a manual loader or instead be limited to loading Windows PFX
certificates
TLS listen sockets would have to be implemented quite separately, as many
of the APIs are different for server-mode (as opposed to client mode).
* commit 'a0562e531723923b632684c7b51a9dd584bf534f':
configure: Add a SONAME entry for the android target
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '00b62968d079e63bf22028f253ac297292436ebe':
os_support: Don't try to return the service name as a string in getnameinfo
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '567ca142952c5be57e52c149c815dfe5d6ac6d41':
configure: Add -D_CRT_NONSTDC_NO_WARNINGS when building with msvc
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
In order to load libraries in Android they need to be unversioned.
The android target section was derived from the BSD ones, and they
that simply drop the SONAME
Android M requires to have a SONAME entry but unversioned.
Some systems may be lacking getservbyport; the previous ifdef wasn't
quite enough since it still assumed that struct servent was defined,
as pointed out by Clément Gregoire.
Simply remove the possibility to return non-numeric services in
getnameinfo; no caller of getnameinfo within libavformat
currently try to use getnameinfo for retrieving the port number without
NI_NUMERICSERV, and falling back on getservbyport may be non-threadsafe.
Signed-off-by: Martin Storsjö <martin@martin.st>
This silences warnings like this one:
libavformat/file.c(62) : warning C4996: 'read': The POSIX name for this
item is deprecated. Instead, use the ISO C++ conformant name: _read.
See online help for details.
Signed-off-by: Martin Storsjö <martin@martin.st>
GCC (and Clang) have this useful warning that is not enabled by -Wall or
-Wextra. This will ensure that issues like those fixed in
4da52e3630
will trigger warnings.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Register mmaldec as mpeg2 decoder. Supporting mpeg2 in mmaldec is just a
matter of setting the correct MMAL_ENCODING on the input port. To ease the
addition of further supported mmal codecs a macro is introduced to generate
the decoder and decoder class structs.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: wm4 <nfxjfg@googlemail.com>
Fixes Ticket4922.
Commit 060102389e broke configure, since
the inversion ! was missed while converting the grep to a case
statement.
Reviewed-by: Nicolas George <george@nsup.org>
Reviewed-by: Timothy Gu <timothygu99@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
The versioning facility in the Solaris linker differs from Linux in 3 ways:
1. It does not support globs in linker scripts for
symbol versioning -- this is a GNU extension.
2. The linker argument is '-M', instead of '--version-script'.
3. It is picky about line endings.
Each symbol or directive must be on a line of it's own.
Let's use make_sunver.pl from GCC to generate a version script that works
correctly with the Solaris linker. It's function is to correctly expand the
globs in the original generated version script.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* commit 'd7a5a178c252b625537adc046392624ad543dea7':
configure: When disabling a library disable all the related components
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
When trying to build the binary dct-test under MSYS2/Win64, the
makefile rule does not have the SUBDIR in the target for its
object file.
Consequently, modifications to various include files (e.g. C ones)
do not trigger a recompilation.
When tracing the dependency generating, the dependency generation
has this strange content (linebreak inserted):
sed -e "/^#.*/d" -e "s,^[[:space:]]*dct\\.o,libavcodec/dct.o," \
> libavcodec/dct-test.d
For some reason, the $(*F) has weird content. It looks simpler to
use $(@F) instead of $(*F)\\.o, although this was tested on one
single version of make.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This way is sufficient to use the component specific configure variable
and not guard against the global library configure variable in code
that is outside it (e.g. checkasm).
Currently, errors are thrown for various macros while building that are completely bogus.
They occur during the dependency (.d) generation phase, and have no bearing on the compiled output,
since only the stdout is piped into the sed command to generate the .d files.
They basically occur as the relevant -I paths are not (and cannot be passed) during
the dependancy generation phase.
As such, this patch silences them.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
