Recherche avancée

Sur d’autres sites (6365)

• 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

• avutil/common : add av_rint64_clip

  1er novembre 2015, par Ganesh Ajjanagadde

  avutil/common : add av_rint64_clip
  The rationale for this function is reflected in the documentation for
  
  it, and is copied here :
  Clip a double value into the long long amin-amax range.
  
  This function is needed because conversion of floating point to integers when
  
  it does not fit in the integer’s representation does not necessarily saturate
  
  correctly (usually converted to a cvttsd2si on x86) which saturates numbers
  
  > INT64_MAX to INT64_MIN. The standard marks such conversions as undefined
  
  behavior, allowing this sort of mathematically bogus conversions. This provides
  
  a safe alternative that is slower obviously but assures safety and better
  
  mathematical behavior.
  
  API :
  
  @param a value to clip
  
  @param amin minimum value of the clip range
  
  @param amax maximum value of the clip range
  
  @return clipped value
  Note that a priori if one can guarantee from the calling side that the
  
  double is in range, it is safe to simply do an explicit/implicit cast,
  
  and that will be far faster. However, otherwise this function should be
  
  used.
  avutil minor version is bumped.
  Reviewed-by : Ronald S. Bultje <rsbultje@gmail.com>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libavutil/common.h
  • [DH] libavutil/version.h

• Difference in number of channels returned by mediainfo and ffprob

  16 mars 2021, par Hai Tran

  I was examining an audio file and noticed that the numbers of channels returned by mediainfo and ffprobe were different.

  


  The mediainfo command :

  


  mediainfo audio.mp4


  


  The ffprobe command (see the channels value) :

  


  ffprobe -i audio.mp4 -show_streams


  


  Does anyone know what's happening ?
Here is the audio file for your own test.