Recherche avancée

Sur d’autres sites (9740)

• avformat/flac_picture : Switch to bytestream2 API

  29 novembre 2019, par Andreas Rheinhardt

  avformat/flac_picture : Switch to bytestream2 API
  ff_flac_parse_picture() parses a buffer containing a flac metadata
  
  picture block by wrapping it in an AVIOContext and using the AVIOContext
  
  API. Consequently, when not enough data could be read AVERROR(EIO) was
  
  returned although reading didn't really fail : A block that contains a
  
  subfield whose size field indicates that it is so big as to extend
  
  beyond the buffer is just invalid.
  This commit changes this by using the bytestream2 API instead ;
  
  furthermore, the checks for whether there is enough data left are
  
  performed before allocating a buffer for said data.
  Finally, if the length of the picture description is bigger than
  
  INT_MAX, it will now raise an error.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/flac_picture.c

• Trim Overlay memory issue

  4 juillet 2019, par Костянтин Тюртюбек

  Greetings fellow FFmpeg users,

  We are experiencing a strange memory leek issue (or maybe just doing something really wrong) and need some directions on how to debug it.

  What are we trying to achieve :

  Process a conference recording that includes multiple user streams, each in its own separate file (all files are mp4/opus).

  • Make a dynamic scene from a set of recordings, based on their volume level at set point of time.
  • The scene must include two parts : smaller grid of all the participants videos, bigger grid of currently talking people. Something like Google Hangouts or Skype does in their applications.

  What went wrong :

  • Memory footprint started unpredictably skyrocketing for some reason during montage

  What are we using :

  First FFmpeg command that reads filter_complex_script from file and adds drawbox as a talking indication on each video source file, when its volume is over a set threshold.

  Second FFmpeg command that reads filter_complex_script from file and :

  • takes an input file (using 0:v),
  • trims a part of it, when the user was talking,
  • scales it according to the amount of concurrently talking users,
  • pads to that resolution (in case if user video is smaller)

  filter_complex command using SELECT :

  [0]select='between(t, 1, 2)',  scale=762:428:force_original_aspect_ratio=decrease,pad=763:429:(ow-iw)/2:(oh-ih)/2[stream-0-workspace-scale-1-1];
  
  
  
  [block-2-grid][stream-0-workspace-scale-1-1]
  
  overlay=repeatlast=1:shortest=0:x=10:y=316:enable='between(t, 1, 2)'
  
  [block-2-workspace-1]; 

  filter_complex command using TRIM :

  [input-file-tag] 
  
  trim=start=#{start}:duration=#{duration},
  
  setpts=PTS-STARTPTS,
  
  scale=#{w-1}:#{h-1}:force_original_aspect_ratio=decrease,
  
  pad=#{w}:#{h}:(ow-iw)/2:(oh-ih)/2
  
  [input-file-trimmed];
  
  
  
  [previous-block-tag] 
  
  overlay=repeatlast=1:shortest=0:x=#{x}:y=#{y}:enable='between(t, #{from}, #{to})'
  
  [next-block-tag]

  We have tried going the TRIM command way, tried the SELECT command way. Problem is, both take insane amounts of ram during execution.

  Examples and more description :

  • Lets assume that only two of the five inputs have the volume above a
    certain volume threshold from second two to five.

  • We are trying to display only them according to some overlay math.

  • Cropped commands in human readable form : https://pastebin.com/YwrnRgnA

  • Full FFmpeg command is way too long to read through, that is the reason we started using filter_complex_script and loading it from file

  • Sometimes one block of video conference may have up to 300+
    intermediate overlays, which leads to the memory issue described. We were expecting the memory footprint to be similar to the amount of input files or maybe two-to-three times higher. However, we reach 15Gb or RAM usage withing the first two minutes of montage, while the input files are no bigger than 200Mb.

  What have we done in terms of debugging :

  • We had been using split at first, but quickly figured out that split
    does in fact copy each input and load it in memory, so we had to
    ditch that approach.

  • As matter of fact we moved to using the input files themselves, so
    the problem lies elsewhere.

  • To clarify, we have split our ffmpeg command into two separate ones.
    First one overlays the talking box animation using drawbox as well as
    user avatar and name. It outputs new video files which we than use in
    the command described above as direct input files tags, like 0:v, 1:v
    etc.

  Thank you for taking time reading through our issue.
  We sure hope that you can help us narrow it down.
  Please feel free to ask for any additional information or descriptions if needed.

  Have a good day !

• avcodec/put_bits : Relax requirements to rebase PutBitContext

  16 novembre 2019, par Andreas Rheinhardt

  avcodec/put_bits : Relax requirements to rebase PutBitContext
  The earlier requirement was for the new buffer to be bigger than the old
  
  one. This has been relaxed to only demand that the new buffer can hold
  
  all the data written so far. This is in preparation for further commits.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/put_bits.h