Recherche avancée

Sur d’autres sites (7806)

• avcodec/jpeg2000_parser : Fix parsing of tile-part header

  21 juillet 2021, par Shaun Simpson

  avcodec/jpeg2000_parser : Fix parsing of tile-part header
  And frames where the end of frame marker is at the end of the buffer.
  Signed-off-by : Shaun Simpson <shauns2029@gmail.com>
  

  • [DH] libavcodec/jpeg2000_parser.c

• fftools/cmdutils : Use avfilter_pad_count() for AVFilter's number of pads

  12 août 2021, par Andreas Rheinhardt

  fftools/cmdutils : Use avfilter_pad_count() for AVFilter's number of pads
  Besides being nicer code this also has the advantage of not making
  
  assumptions about the internal implementation : While it is documented
  
  that the AVFilter.inputs and AVFilter.outputs arrays are terminated
  
  by a zeroed sentinel, one is not allowed to infer that one can just
  
  check avfilter_pad_get_name(padarray, i) to see whether one has reached
  
  the sentinel :
  
  It could be that the pointer to the string is contained
  
  in a different structure than AVFilterPad that needs to be accessed
  
  first : return pad->struct->string.
  
  It could be that for small strings an internal buffer in
  
  AVFilterPad is used (to avoid a relocation) whereas for longer strings
  
  an external string is used ; this is useful to avoid relocations :
  
  return pad->string_ptr ? pad->string_ptr : pad->interal_string
  
  Or it could be that the name has a default value :
  
  return pad->name ? pad->name : "default"
  
  (This actually made sense for us because the name of most of our
  
  AVFilterPads is just "default" ; doing so would save lots of relocations.)
  The only thing one is allowed to infer from the existence of the
  
  sentinel is that one is allowed to use avfilter_pad_count() to get
  
  the number of pads. Therefore it is used.
  Reviewed-by : Nicolas George <george@nsup.org>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] fftools/cmdutils.c

• How to compute the number of extra samples added by LAME or FFMPEG

  24 janvier 2018, par actuallyaswin

  I am attempting to build a MP3 decoder / parser in Python which supports files encoded by LAME or FFMPEG.

  My encoding shell script is shown here :

  #!/bin/bash
  
  for i in wav/*.wav; do
  
      i=${i##*/};
  
      lame --nores --strictly-enforce-ISO -t --cbr -b 64 -h "wav/${i}" "mpeg/lame/${i%.wav}.mp3";
  
      ffmpeg -i "wav/${i}" -codec:a libmp3lame -qscale:a 2 "mpeg/ffmpeg/${i%.wav}.mp3";
  
  done

  This scripts reads WAVE files located in ./wav/ and produces a controlled-bitrate MP3 of 64kbps in my ./mp3/lame/ directory, and a variable-bitrate MP3 of quality 2 in my ./mp3/ffmpeg/.

  I have written a Python script that iterates through both resultant MP3s, counting the number of frames and samples. Both the LAME and FFMPEG results are equivalent (in terms of frames and samples), but their binary files are different.

  The LAME/FFMPEG sample count was done by iterating through the binary MP3 files, locating and parsing the frame header, then using the MP3 spec to determine the number of samples per frame.

  • Number of MP3 data-frames : 112 (ignoring the Xing/Info first frame)
  • Number of output frames : 112*576 = 64512

  Here is a comparison of the sample count for a single 4-second input file :

  • Input WAV # of samples = 62996
  • Output LAME/FFMPEG # of samples = 64512
  • Difference = 1516

  I understand that according to the LAME FAQ file, resultant MP3 files are zero padded in the front and back to make sure the inverse MDCT is performed properly, but also because the windows overlap.

  What I can’t ascertain from the above FAQ, or from any previous StackOverflow post, is how to compute the number of artificially added samples. If I can be sure that all 1516 of these samples are zeros, and I can be sure of their position in the bytestream, I’d like to be able to confidently toss them out. Since there are 1516 "extra" samples and there are 576 samples per frame for a V2LIII encoding, then there must be more than two (but less than three) erroneous MPEG frames here.

  Is anyone here savvy enough with MPEG encoding/decoding to know how many samples are added, and in which frames those samples will be in ? In other words, will the first frame and last frame always contain blank data, or are there more frames ?