Recherche avancée

Sur d’autres sites (10090)

• rtmpcrypt : Do the xtea decryption in little endian mode

  11 novembre 2015, par Martin Storsjö

  rtmpcrypt : Do the xtea decryption in little endian mode
  The XTEA algorithm operates on 32 bit numbers, not on byte sequences.
  
  The XTEA implementation in libavutil is written assuming big endian
  
  numbers, while the rtmpe signature encryption assumes little endian.
  This fixes rtmpe communication with rtmpe servers that use signature
  
  type 8 (XTEA), e.g. crunchyroll.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavformat/rtmpcrypt.c

• swresample/resample : speed up Blackman Nuttall filter

  9 novembre 2015, par Ganesh Ajjanagadde

  swresample/resample : speed up Blackman Nuttall filter
  This may be a slightly surprising optimization, but is actually based on
  
  an understanding of how math libraries compute trigonometric functions.
  
  Explanation is given here so that future development uses libm more effectively
  
  across the codebase.
  All libm’s essentially compute transcendental functions via some kind of
  
  polynomial approximation, be it Taylor-Maclaurin or Chebyshev.
  
  Correction terms are added via polynomial correction factors when needed
  
  to squeeze out the last bits of accuracy. Lookup tables are also
  
  inserted strategically.
  In the case of trigonometric functions, periodicity is exploited via
  
  first doing a range reduction to an interval around zero, and then using
  
  some polynomial approximation.
  This range reduction is the most natural way of doing things - else one
  
  would need polynomials for ranges in different periods which makes no
  
  sense whatsoever.
  To avoid the need for the range reduction, it is helpful to feed in
  
  arguments as close to the origin as possible for the trigonometric
  
  functions. In fact, this also makes sense from an accuracy point of view :
  
  IEEE floating point has far more resolution for small numbers than big ones.
  This patch does this for the Blackman-Nuttall filter, and yields a
  
  non-negligible speedup.
  Sample benchmark (x86-64, Haswell, GNU/Linux)
  
  test : fate-swr-resample-dblp-2626-44100
  
  old :
  
  18893514 decicycles in build_filter (loop 1000),     256 runs,      0 skips
  
  18599863 decicycles in build_filter (loop 1000),     512 runs,      0 skips
  
  18445574 decicycles in build_filter (loop 1000),    1000 runs,     24 skips
  new :
  
  16290697 decicycles in build_filter (loop 1000),     256 runs,      0 skips
  
  16267172 decicycles in build_filter (loop 1000),     512 runs,      0 skips
  
  16251105 decicycles in build_filter (loop 1000),    1000 runs,     24 skips
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libswresample/resample.c

• avformat/cache : Avoid int-overflow in cache compare function

  9 novembre 2015, par Bryan Huh

  avformat/cache : Avoid int-overflow in cache compare function
  cache protocol indexes its cache using AVTreeNodes which require a cmp
  
  function for inserting and searching new cache-entries. This cmp
  
  function expects a 32-bit int return value (negative, zero, or positive)
  
  but the cache cmp function returns an int64_t which can overflow the
  
  int, giving negative numbers for when it should be positive, vice versa.
  
  This manifests itself only for very large files (e.g. 4GB+)
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/cache.c