1. 25 Dec, 2015 6 commits
  2. 24 Dec, 2015 10 commits
  3. 23 Dec, 2015 7 commits
  4. 22 Dec, 2015 15 commits
  5. 21 Dec, 2015 2 commits
    • Rostislav Pehlivanov's avatar
      aacenc_is: rename variable · c0f67e11
      Rostislav Pehlivanov authored
      'erf' is far from the best name for a variable and is not very
      descriptive since the actual variable points to the comparitively best
      IS phase. Therefore rename it to 'best'.
      Signed-off-by: 's avatarRostislav Pehlivanov <atomnuker@gmail.com>
      c0f67e11
    • Ganesh Ajjanagadde's avatar
      lavu/libm: add erf hack and make dynaudnorm available everywhere · dd68cde2
      Ganesh Ajjanagadde authored
      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: 's avatarJames Almer <jamrial@gmail.com>
      Signed-off-by: 's avatarGanesh Ajjanagadde <gajjanagadde@gmail.com>
      dd68cde2