Recherche avancée

Sur d’autres sites (2167)

• armv6 : Accelerate ff_fft_calc for general case (nbits != 4)

  16 juillet 2014, par Ben Avison

  armv6 : Accelerate ff_fft_calc for general case (nbits != 4)
  The previous implementation targeted DTS Coherent Acoustics, which only
  
  requires nbits == 4 (fft16()). This case was (and still is) linked directly
  
  rather than being indirected through ff_fft_calc_vfp(), but now the full
  
  range from radix-4 up to radix-65536 is available. This benefits other codecs
  
  such as AAC and AC3.
  The implementaion is based upon the C version, with each routine larger than
  
  radix-16 calling a hierarchy of smaller FFT functions, then performing a
  
  post-processing pass. This pass benefits a lot from loop unrolling to
  
  counter the long pipelines in the VFP. A relaxed calling standard also
  
  reduces the overhead of the call hierarchy, and avoiding the excessive
  
  inlining performed by GCC probably helps with I-cache utilisation too.
  I benchmarked the result by measuring the number of gperftools samples that
  
  hit anywhere in the AAC decoder (starting from aac_decode_frame()) or
  
  specifically in the FFT routines (fft4() to fft512() and pass()) for the
  
  same sample AAC stream :
                Before          After
  
                Mean   StdDev   Mean   StdDev  Confidence  Change
  
  Audio decode  2245.5 53.1     1599.6 43.8    100.0%      +40.4%
  
  FFT routines  940.6  22.0     348.1  20.8    100.0%      +170.2%
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavcodec/arm/fft_init_arm.c
  • [DH] libavcodec/arm/fft_vfp.S

• checkasm : Add vc1dsp inverse transform tests

  31 mars 2022, par Ben Avison

  checkasm : Add vc1dsp inverse transform tests
  This test deliberately doesn't exercise the full range of inputs described in
  
  the committee draft VC-1 standard. It says :
  input coefficients in frequency domain, D, satisfy   -2048 <= D < 2047
  
  intermediate coefficients, E, satisfy                -4096 <= E < 4095
  
  fully inverse-transformed coefficients, R, satisfy    -512 <= R <  511
  For one thing, the inequalities look odd. Did they mean them to go the
  
  other way round ? That would make more sense because the equations generally
  
  both add and subtract coefficients multiplied by constants, including powers
  
  of 2. Requiring the most-negative values to be valid extends the number of
  
  bits to represent the intermediate values just for the sake of that one case !
  For another thing, the extreme values don't look to occur in real streams -
  
  both in my experience and supported by the following comment in the AArch32
  
  decoder :
      tNhalf is half of the value of tN (as described in vc1_inv_trans_8x8_c).
  
      This is done because sometimes files have input that causes tN + tM to
  
      overflow. To avoid this overflow, we compute tNhalf, then compute
  
      tNhalf + tM (which doesn't overflow), and then we use vhadd to compute
  
      (tNhalf + (tNhalf + tM)) >> 1 which does not overflow because it is
  
      one instruction.
  My AArch64 decoder goes further than this. It calculates tNhalf and tM
  
  then does an SRA (essentially a fused halve and add) to compute
  
  (tN + tM) >> 1 without ever having to hold (tNhalf + tM) in a 16-bit element
  
  without overflowing. It only encounters difficulties if either tNhalf or
  
  tM overflow in isolation.
  I haven't had sight of the final standard, so it's possible that these
  
  issues were dealt with during finalisation, which could explain the lack
  
  of usage of extreme inputs in real streams. Or a preponderance of decoders
  
  that only support 16-bit intermediate values in their inverse transforms
  
  might have caused encoders to steer clear of such cases.
  I have effectively followed this approach in the test, and limited the
  
  scale of the coefficients sufficient that both the existing AArch32 decoder
  
  and my new AArch64 decoder both pass.
  Signed-off-by : Ben Avison <bavison@riscosopen.org>
  
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] tests/checkasm/vc1dsp.c

• lavf doxy : add some general lavf information.

  11 décembre 2011, par Anton Khirnov

  lavf doxy : add some general lavf information.