1. 14 Jan, 2016 1 commit
  2. 25 Dec, 2015 2 commits
  3. 23 Dec, 2015 1 commit
    • Ganesh Ajjanagadde's avatar
      lavu/libm: add exp10 support · e29db08c
      Ganesh Ajjanagadde authored
      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: 's avatarHendrik Leppkes <h.leppkes@gmail.com>
      Reviewed-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      Reviewed-by: 's avatarRonald S. Bultje <rsbultje@gmail.com>
      Signed-off-by: 's avatarGanesh Ajjanagadde <gajjanagadde@gmail.com>
      e29db08c
  4. 21 Dec, 2015 1 commit
    • 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
  5. 19 Dec, 2015 1 commit
  6. 25 Nov, 2015 1 commit
    • Ganesh Ajjanagadde's avatar
      avutil/libm: fix isnan compatibility hack · 29af74e4
      Ganesh Ajjanagadde authored
      Commit 14ea4151 had a bug in that the
      conversion of the uint64_t result to an int (the return signature) would
      lead to implementation defined behavior, and in this case simply
      returned 0 for NAN. A fix via AND'ing the result with 1 does the trick,
      simply by ensuring a 0 or 1 return value.
      
      Patch tested with FATE on x86-64, GNU/Linux by forcing the compatibility
      code via an ifdef hack suggested by Michael.
      Signed-off-by: 's avatarGanesh Ajjanagadde <gajjanagadde@gmail.com>
      29af74e4
  7. 21 Nov, 2015 2 commits
    • Ganesh Ajjanagadde's avatar
      configure+libm.h: add hypot emulation · 275aca8f
      Ganesh Ajjanagadde authored
      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: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      Signed-off-by: 's avatarGanesh Ajjanagadde <gajjanagadde@gmail.com>
      275aca8f
    • Ganesh Ajjanagadde's avatar
      avutil/libm: correct isnan, isinf compat hacks · 14ea4151
      Ganesh Ajjanagadde authored
      isnan and isinf are actually macros as per the standard. In particular,
      the existing implementation has incorrect signature. Furthermore, this
      results in undefined behavior for e.g double values outside float range
      as per the standard.
      
      This patch corrects the undefined behavior for all usage within FFmpeg.
      
      Note that long double is not handled as it is not used in FFmpeg.
      Furthermore, even if at some point long double gets used, it is likely
      not needed to modify the macro in practice for usage in FFmpeg. See
      below for analysis.
      
      Getting long double to work strictly per the spec is significantly harder
      since a long double may be an IEEE 128 bit quad (very rare), 80 bit
      extended precision value (on GCC/Clang), or simply double (on recent Microsoft).
      On the other hand, any potential future usage of long double is likely
      for precision (when a platform offers extra precision) and not for range, since
      the range anyway varies and is not as portable as IEEE 754 single/double
      precision. In such cases, the implicit cast to a double is well defined
      and isinf and isnan should work as intended.
      Reviewed-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      Signed-off-by: 's avatarGanesh Ajjanagadde <gajjanagadde@gmail.com>
      14ea4151
  8. 08 Nov, 2014 1 commit
    • Carl Eugen Hoyos's avatar
      Remove fminf() emulation. · 4436a8f4
      Carl Eugen Hoyos authored
      The emulation is unused and causes compilation trouble on systems
      where fminf() is defined in <math.h> but missing from libm.
      This should fix compilation on Debian powerpcspe.
      4436a8f4
  9. 06 Jun, 2014 5 commits
  10. 22 Jan, 2013 1 commit
  11. 23 Oct, 2012 1 commit
  12. 11 Jul, 2012 1 commit
  13. 27 Jun, 2012 1 commit
  14. 26 Jun, 2012 1 commit
  15. 11 Jun, 2012 1 commit
    • Nedeljko Babic's avatar
      Optimization of AMR NB and WB decoders for MIPS · 3827a86e
      Nedeljko Babic authored
      AMR NB and WB decoders are optimized for MIPS architecture.
      Appropriate Makefiles are changed accordingly.
      
      Cnfigure script is changed in order to support optimizations.
       Optimizations are enabled by default when compiling is done for
        mips architecture.
       Appropriate cflags are automatically set.
       Support for several mips CPUs is added in configure script.
      
      New ffmpeg options are added for disabling optimizations.
      
      The FFMPEG option --disable-mipsfpu disables MIPS floating point
       optimizations.
      The FFMPEG option --disable-mips32r2 disables MIPS32R2
       optimizations.
      The FFMPEG option --disable-mipsdspr1 disables MIPS DSP ASE R1
       optimizations.
      The FFMPEG option --disable-mipsdspr2 disables MIPS DSP ASE R2
       optimizations.
      Signed-off-by: 's avatarNedeljko Babic <nbabic@mips.com>
      Reviewed-by: 's avatarVitor Sessak <vitor1001@gmail.com>
      Signed-off-by: 's avatarMichael Niedermayer <michaelni@gmx.at>
      3827a86e
  16. 22 Oct, 2011 1 commit
  17. 21 Apr, 2011 1 commit
  18. 19 Mar, 2011 1 commit
  19. 23 Apr, 2010 1 commit
  20. 20 Apr, 2010 1 commit
  21. 09 Mar, 2010 2 commits
    • Måns Rullgård's avatar
      libm.h needs attributes.h · 297bfb2f
      Måns Rullgård authored
      Originally committed as revision 22405 to svn://svn.ffmpeg.org/ffmpeg/trunk
      297bfb2f
    • Måns Rullgård's avatar
      Move libm replacements to new header libm.h · 335ee1aa
      Måns Rullgård authored
      ffmpeg.c uses lrintf(), which is missing on some systems.  Previously
      it picked up the replacement via libavutil/internal.h due to
      HAVE_AV_CONFIG_H being erroneously defined.
      
      Moving these replacements to a separate header enables ffmpeg.c to
      use them without being exposed to internal interfaces.
      
      This use of a non-public header is justified by the header in question
      not being part of the internal interface either.  It should rather be
      considered as part of the build system, which is shared between the
      libraries and the applications.
      
      This header cannot be installed since the tested conditions depend on
      the compiler.
      
      Originally committed as revision 22399 to svn://svn.ffmpeg.org/ffmpeg/trunk
      335ee1aa