Recherche avancée

Sur d’autres sites (9523)

• libavcodec/ppc/hpeldsp_altivec.c : fix ff_put_pixels16_altivec() put_no_rnd_pixels16_...

  7 novembre 2014, par Rong Yan

  libavcodec/ppc/hpeldsp_altivec.c : fix ff_put_pixels16_altivec() put_no_rnd_pixels16_xy2_altivec() put_no_rnd_pixels8_xy2_altivec() avg_pixels8_altivec() avg_pixels8_xy2_altivec() put_pixels16_xy2_altivec() put_pixels8_xy2_altivec() ff_avg_pixels16_altivec() for POWER LE
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/ppc/hpeldsp_altivec.c

• imdct15 : replace the FFT with a faster PFA FFT algorithm

  4 janvier 2017, par Rostislav Pehlivanov

  imdct15 : replace the FFT with a faster PFA FFT algorithm
  This commit replaces the current inefficient non-power-of-two FFT with a
  
  much faster FFT based on the Prime Factor Algorithm.
  
  Although it is already much faster than the old algorithm without SIMD,
  
  the new algorithm makes use of the already very throughouly SIMD’d power
  
  of two FFT, which improves performance even more across all platforms
  
  which we have SIMD support for.
  Most of the work was done by Peter Barfuss, who passed the code to me to
  
  implement into the iMDCT and the current codebase. The code for a
  
  5-point and 15-point FFT was derived from the previous implementation,
  
  although it was optimized and simplified, which will make its future
  
  SIMD easier. The 15-point FFT is currently using 6% of the current
  
  overall decoder overhead.
  The FFT can now easily be used as a forward transform by simply not
  
  multiplying the 5-point FFT’s imaginary component by -1 (which comes
  
  from the fact that changing the complex exponential’s angle by -1 also
  
  changes the output by that) and by multiplying the "theta" angle of the
  
  main exptab by -1. Hence the deliberately left multiplication by -1 at
  
  the end.
  FATE passes, and performance reports on other platforms/CPUs are
  
  welcome.
  Performance comparisons :
  iMDCT, PFA :
  
  101127 decicycles in speed,   32765 runs,      3 skips
  
  iMDCT, Old :
  
  211022 decicycles in speed,   32768 runs,      0 skips
  Standalone FFT, 300000 transforms of size 960 :
  
      PFA        Old FFT     kiss_fft    libfftw3f
  
      3.659695s, 15.726912s, 13.300789s, 1.182222s
  Being only 3x slower than libfftw3f is a big achievement by itself.
  There appears to be something capping the performance in the iMDCT side
  
  of things, possibly during the pre-stage reindexing. However, it is
  
  certainly fast enough for now.
  Signed-off-by : Rostislav Pehlivanov <atomnuker@gmail.com>
  

  • [DH] libavcodec/imdct15.c
  • [DH] libavcodec/imdct15.h

• How to render video and audio

  25 octobre 2011, par pic11

  I am trying to implement my own media player. What is the best way to render video and audio ? At this point I am thinking to use SurfaceView and AudioTrack classes, but not sure if it is the best option. I am interested in SDK and NDK solutions.

  File output on regular desktop is non-blocking, that is OS takes care of buffering and actual disk writes are asynchronous to the thread that initiates the output. Does the same principle apply to video and audio output ? If not, I would need to run a separate thread to handle output asynchronously from decoding/demuxing.

  What free software decoders are available for android ? I am thinking to use ffmpeg. Can relatively recent (say, top 30% in terms of CPU power) tablet handle 1,280×720 and 1,920×1,080 formats in software mode ?