Recherche avancée

Sur d’autres sites (7208)

• avcodec/jpeg2000 : replace naive pow call with smarter exp2fi

  8 décembre 2015, par Ganesh Ajjanagadde

  avcodec/jpeg2000 : replace naive pow call with smarter exp2fi
  pow is a very wasteful function for this purpose. A low hanging fruit
  
  would be simply to replace with exp2f, and that does yield some speedup.
  
  However, there are 2 drawbacks of this :
  
  1. It does not exploit the integer nature of the argument.
  
  2. (minor) Some platforms lack a proper exp2f routine, making benefits available
  
  only to non broken libm.
  
  3. exp2f does not solve the same issue that plagues pow, namely terrible
  
  worst case performance. This is a fundamental issue known as the
  
  "table-maker’s dilemma" recognized by Prof. Kahan himself and
  
  subsequently elaborated and researched by many others. All this is clear from benchmarks below.
  This exploits the IEEE-754 format to get very good performance even in
  
  the worst case for integer powers of 2. This solves all the issues noted
  
  above. Function tested with clang usan over [-1000, 1000] (beyond range of
  
  relevance for this, which is [-255, 255]), patch itself with FATE.
  Benchmarks obtained on x86-64, Haswell, GNU-Linux via 10^5 iterations of
  
  the pow call, START/STOP, and command ffplay /samples/jpeg2000/chiens_dcinema2K.mxf.
  
  Low number of runs also given to prove the point about worst case :
  pow :
  
   216270 decicycles in pow,       1 runs,      0 skips
  
   110175 decicycles in pow,       2 runs,      0 skips
  
    56085 decicycles in pow,       4 runs,      0 skips
  
    29013 decicycles in pow,       8 runs,      0 skips
  
    15472 decicycles in pow,      16 runs,      0 skips
  
     8689 decicycles in pow,      32 runs,      0 skips
  
     5295 decicycles in pow,      64 runs,      0 skips
  
     3599 decicycles in pow,     128 runs,      0 skips
  
     2748 decicycles in pow,     256 runs,      0 skips
  
     2304 decicycles in pow,     511 runs,      1 skips
  
     2072 decicycles in pow,    1022 runs,      2 skips
  
     1963 decicycles in pow,    2044 runs,      4 skips
  
     1894 decicycles in pow,    4091 runs,      5 skips
  
     1860 decicycles in pow,    8184 runs,      8 skips
  exp2f :
  
   134140 decicycles in pow,       1 runs,      0 skips
  
    68110 decicycles in pow,       2 runs,      0 skips
  
    34530 decicycles in pow,       4 runs,      0 skips
  
    17677 decicycles in pow,       8 runs,      0 skips
  
     9175 decicycles in pow,      16 runs,      0 skips
  
     4931 decicycles in pow,      32 runs,      0 skips
  
     2808 decicycles in pow,      64 runs,      0 skips
  
     1747 decicycles in pow,     128 runs,      0 skips
  
     1208 decicycles in pow,     256 runs,      0 skips
  
      952 decicycles in pow,     512 runs,      0 skips
  
      822 decicycles in pow,    1024 runs,      0 skips
  
      765 decicycles in pow,    2047 runs,      1 skips
  
      722 decicycles in pow,    4094 runs,      2 skips
  
      693 decicycles in pow,    8190 runs,      2 skips
  exp2fi :
  
     2740 decicycles in pow,       1 runs,      0 skips
  
     1530 decicycles in pow,       2 runs,      0 skips
  
      955 decicycles in pow,       4 runs,      0 skips
  
      622 decicycles in pow,       8 runs,      0 skips
  
      477 decicycles in pow,      16 runs,      0 skips
  
      368 decicycles in pow,      32 runs,      0 skips
  
      317 decicycles in pow,      64 runs,      0 skips
  
      291 decicycles in pow,     128 runs,      0 skips
  
      277 decicycles in pow,     256 runs,      0 skips
  
      268 decicycles in pow,     512 runs,      0 skips
  
      265 decicycles in pow,    1024 runs,      0 skips
  
      263 decicycles in pow,    2048 runs,      0 skips
  
      263 decicycles in pow,    4095 runs,      1 skips
  
      260 decicycles in pow,    8191 runs,      1 skips
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libavcodec/jpeg2000.c

• lavu/libm : add erf hack and make dynaudnorm available everywhere

  20 décembre 2015, par Ganesh Ajjanagadde

  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>
  

  • [DH] configure
  • [DH] libavutil/libm.h

• OpenCV 3.0.0 make error with FFMPEG

  24 mars 2016, par Ujjwal Aryan

  I have been using OpenCV for a while. However I have recently changed my system to a cluster where I do not have any admin permission. The problem is like this :

  In my home folder, I installed FFMPEG (latest stable version available on ffmpeg site). I installed it in $HOME, and so in $HOME/lib there are the library files installed. For more information I compiled FFMPEG with following options :

  ./configure --prefix=$HOME --enable-shared --enable-pic

  I then downloaded the latest stable version of OpenCV 3.0.0 and configured it using ccmake. When I try to make -j8, it gives me the following error.

   Scanning dependencies of target opencv_videoio
  
  [ 63%] [ 63%] [ 63%] [ 63%] [ 63%] [ 63%] Building CXX object modules/videoio/CMakeFiles/opencv_videoio.dir/src/cap.cpp.o
  
  Building CXX object modules/videoio/CMakeFiles/opencv_videoio.dir/src/cap_mjpeg_decoder.cpp.o
  
  Building CXX object modules/videoio/CMakeFiles/opencv_videoio.dir/src/cap_images.cpp.o
  
  Building CXX object modules/videoio/CMakeFiles/opencv_videoio.dir/src/cap_v4l.cpp.o
  
  Building CXX object modules/videoio/CMakeFiles/opencv_videoio.dir/src/cap_mjpeg_encoder.cpp.o
  
  Building CXX object modules/videoio/CMakeFiles/opencv_videoio.dir/src/cap_ffmpeg.cpp.o
  
  In file included from /home/uujjwal/libraries/opencv-nogpu/opencv-3.0.0/modules/videoio/src/cap_ffmpeg.cpp:45:0:
  
  /home/uujjwal/libraries/opencv-nogpu/opencv-3.0.0/modules/videoio/src/cap_ffmpeg_impl.hpp:1546:71: error: use of enum 'AVCodecID' without previous declaration
  
  /home/uujjwal/libraries/opencv-nogpu/opencv-3.0.0/modules/videoio/src/cap_ffmpeg_impl.hpp:1556:83: error: use of enum 'AVCodecID' without previous declaration
  
  make[2]: *** [modules/videoio/CMakeFiles/opencv_videoio.dir/src/cap_ffmpeg.cpp.o] Error 1
  
  make[2]: *** Waiting for unfinished jobs....

  However without ffmpeg support it works fine. However I need ffmpeg support due to the nature of my work.

  In trying to resolve the problem, I tried installing OpenCV 2.4.11 but it also gave this error. The latest GIT version does not give me this error but rather an error a part of which goes like this

  Linking CXX shared library ../../lib/libopencv_highgui.so /usr/bin/ld: /home/matheus/ffmpeg_build/lib/../lib/libavcodec.a(avpacket.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used

  I have pasted the above error from another unresolved question online and so the folder names are different but the relocation error is exactly the same.

  In trying to resolve the problem I searched and found the following link http://answers.opencv.org/question/12597/build-problems-for-opencv-241-with-ubuntu-1204-lts/

  However, one of the answers over there mentioned changing some lines in cap_ffmpeg_impl.hpp file. I tried doing that but either i am not able to do it correctly or something else is going wrong and it is not working. Exact line numbers and exact changes are not mentioned and so I am having difficulty changing things and being sure.

  I am using Fedora 19 (Schrodinger Cat) as the operating system I hope the details of my question are clear and I hope that the community would oblige me with a good response.

  Regards
  Ujjwal