summaryrefslogtreecommitdiff
path: root/configure
diff options
context:
space:
mode:
authorGanesh Ajjanagadde <gajjanagadde@gmail.com>2015-12-19 18:17:03 -0800
committerGanesh Ajjanagadde <gajjanagadde@gmail.com>2015-12-21 09:03:11 -0800
commitdd68cde28a44bbf5307d29ee6cb8ebd14985dea5 (patch)
treecb099a33847277480e02deeff09e0a3ada28c084 /configure
parentfc5e39544b92af71e2cce7ea9dcb300875f9773b (diff)
lavu/libm: add erf hack and make dynaudnorm available everywhere
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>
Diffstat (limited to 'configure')
-rwxr-xr-xconfigure1
1 files changed, 0 insertions, 1 deletions
diff --git a/configure b/configure
index da74616323..89c98d19eb 100755
--- a/configure
+++ b/configure
@@ -2851,7 +2851,6 @@ cropdetect_filter_deps="gpl"
delogo_filter_deps="gpl"
deshake_filter_select="pixelutils"
drawtext_filter_deps="libfreetype"
-dynaudnorm_filter_deps="erf"
ebur128_filter_deps="gpl"
eq_filter_deps="gpl"
fftfilt_filter_deps="avcodec"