Recherche avancée

Sur d’autres sites (6766)

• Revision 37408 : déplacement de chaines de langue Faire refonctionner l’encodage sonore

  18 avril 2010, par kent1@… — Log

  déplacement de chaines de langue
  Faire refonctionner l’encodage sonore

• 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

• avcodec/utvideodec : Avoid qsort when creating Huffman tables

  24 septembre 2020, par Andreas Rheinhardt

  avcodec/utvideodec : Avoid qsort when creating Huffman tables
  The Ut video format uses Huffman trees which are only implicitly coded
  
  in the bitstream : Only the lengths of the codes are coded, the rest has
  
  to be inferred by the decoder according to the rule that the longer
  
  codes are to the left of shorter codes in the tree and on each level the
  
  symbols are descending from left to right.
  Because longer codes are to the left of shorter codes, one needs to know
  
  how many non-leaf nodes there are on each level in order to know the
  
  code of the next left-most leaf (which belongs to the highest symbol on
  
  that level). The current code does this by sorting the entries to be
  
  ascending according to length and (for entries with the same length)
  
  ascending according to their symbols. This array is then traversed in
  
  reverse order, so that the lowest level is dealt with first, so that the
  
  number of non-leaf nodes of the next higher level is known when
  
  processing said level.
  But this can also be calculated without sorting : Simply count how many
  
  leaf nodes there are on each level. Then one can calculate the number of
  
  non-leaf nodes on each level iteratively from the lowest level upwards :
  
  It is just half the number of nodes of the level below.
  This improves performance : For the sample from ticket #4044 the amount
  
  of decicycles for one call to build_huff() decreased from 1055489 to
  
  446310 for Clang 10 and from 1080306 to 535155 for GCC 9.
  Reviewed-by : Paul B Mahol <onemda@gmail.com>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/utvideo.c
  • [DH] libavcodec/utvideo.h
  • [DH] libavcodec/utvideodec.c