Recherche avancée

Sur d’autres sites (7953)

• avformat/matroskadec : Free right buffer on error

  3 mai 2020, par Andreas Rheinhardt

  avformat/matroskadec : Free right buffer on error
  Since commit 979b5b89594c7628bd846c63198cb64ef9d81d16, reverting the
  
  Matroska ContentCompression is no longer done inside
  
  matroska_parse_frame() (the function that creates AVPackets out of the
  
  parsed data (unless we are dealing with certain codecs that need special
  
  handling)), but instead in matroska_parse_block(). As a consequence,
  
  the data that matroska_parse_frame() receives is no longer always owned
  
  by an AVBuffer ; it is owned by an AVBuffer iff no ContentCompression needed
  
  to be reversed ; otherwise the data is independently allocated and needs
  
  to be freed on error.
  Whether the data is owned by an AVBuffer or not is indicated by a variable
  
  buf of type AVBufferRef * : If it is NULL, the data is independently
  
  allocated, if not it is owned by the underlying AVBuffer (and is used to
  
  avoid copying the data when creating the AVPackets).
  Because the allocation of the buffer holding the uncompressed data happens
  
  outside of matroska_parse_frame() (if a ContentCompression needs to be
  
  reversed), the data is passed as uint8_t ** in order to not leave any
  
  dangling pointers behind in matroska_parse_block() should the data need to
  
  be freed : In case of errors, said uint8_t ** would be av_freep()'ed in
  
  case buf indicated the data to be independently allocated.
  Yet there is a problem with this : Some codecs (namely WavPack and
  
  ProRes) need special handling : Their packets are only stored in
  
  Matroska in a stripped form to save space and the demuxer reconstructs
  
  full packets. This involved allocating a new, enlarged buffer. And if
  
  an error happens when trying to wrap this new buffer into an AVBuffer,
  
  this buffer needs to be freed ; yet instead the given uint8_t ** (holding
  
  the uncompressed, yet still stripped form of the data) would be freed
  
  (av_freep()'ed) which certainly leads to a memleak of the new buffer ;
  
  even worse, in case the track does not use ContentCompression the given
  
  uint8_t ** must not be freed as the actual data is owned by an AVBuffer
  
  and the data given to matroska_parse_frame() is not the start of the
  
  actual allocated buffer at all.
  Both of these issues are fixed by always freeing the current data in
  
  case it is independently allocated. Furthermore, while it would be
  
  possible to track whether the pointer from matroska_parse_block() needs
  
  to be reset or not, there is no gain in doing so, as the pointer is not
  
  used at all afterwards and the sematics are clear : If the data passed
  
  to matroska_parse_frame() is independently allocated, then ownership
  
  of the data passes to matroska_parse_frame(). So don't pass the data
  
  via uint8_t **.
  Fixes Coverity ID 1462661 (the issue as described by Coverity is btw
  
  a false positive : It thinks that this error can be triggered by ProRes
  
  with a size of zero after reconstructing the original packets, but the
  
  reconstructed packets can't have a size of zero).
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskadec.c

• Speed advantage in combining FFmpeg filters ?

  4 mai 2020, par lach_codes

  I'm currently using five separate FFmpeg processes to do the following :

  



  

  1. trim & crop Vid B

  


  2. scale Vid B to height of Vid A

  


  3. combine Vid B & Vid A

  


  4. add a fade-in/fade-out to Combined Vid

  


  5. add an overlay to fade in/out vid

  


  



  I have them all set to ultrafast but it still takes a long time - about 40 seconds when each video is 10 seconds long.

  



  I initially explored combining some of the filters but couldn't get it working in the timeframe I had available. I also wasn't sure if the time spent figuring out how to combine all the filters would pay off in a faster processing time.

  



  Any thoughts/insights from you brilliant FFmpeg gurus ? Would this speed up processing, and if so, should I combine all the commands together or are there some I should combine and others I should leave separate ?

  



  Here are my current commands, all of which are working :

  



  // trimming 200ms off begining of vid B + cropping frame (note that I have previously retrieved dimensions and duration of both videos with ffprobe)
1. `ffmpeg -i vidB.mov -ss 200 -t ${vidB.duration} -async 1 -filter:v "crop=iw:${vidB.croppedHeight}:0:${vidB.offset}" -preset ultrafast -c:a copy croppedVidB.mov`

// scale Vid B up to Vid A's height
2. `ffmpeg -i croppedVidB.mov -vf scale=-2:${vidA.height} vidBScaled.mov`

// combine videos
3. `ffmpeg -i vidA.mov -i vidBScaled.mov -filter_complex "[0:v][1:v] hstack=inputs=2[v]; [0:a][1:a]amix[a]" -map "[v]" -map "[a]" -preset ultrafast -ac 2 combined.mov`

// add fade in & out
4. `ffmpeg -i combined.mov -sseof -1 -copyts -i combined.mov -filter_complex "[1]fade=out:0:30[t];[0][t]overlay,fade=in:0:30[v]; anullsrc,atrim=0:1[at];[0][at]acrossfade=d=1,afade=d=1[a]" -map "[v]" -map "[a]" -c:v libx264 -crf 22 -preset ultrafast -shortest fadeInOut.mov`

// add overlay
5. `ffmpeg -i fadeInOut.mov -i overlay.png -filter_complex overlay=W-w-10:H-h-10 -codec:a copy -preset ultrafast -async 1 overlay.mov`


  



  Thanks in advance for your thoughts !

  


• PHP ffmpeg - save mp4 as H.264 in Baseline profile

  2 mai 2020, par Pikaboo

  I'm trying to play a mp4 file in android but it's not working.

  



  According to Android VideoView Cannot play video mp4

  



  the file needs to be H.264 in Baseline.

  



  I don't know what the hell this means.

  



  This is the PHP code I'm using to create mp4 :

  



  $videoname = str_replace('.gif', '.mp4', $picname);
$ffmpeg = FFMpeg\FFMpeg::create(array(
    'ffmpeg.binaries'  => 'ffmpeg/bin/ffmpeg.exe',
    'ffprobe.binaries' => 'ffmpeg/bin/ffprobe.exe',
    'timeout'          => 6600, // The timeout for the underlying process
    'ffmpeg.threads'   => 12,   // The number of threads that FFMpeg should use
), $logger);

$video = $ffmpeg->open('memes/' . $folder . '/' . $picname);
$video
    ->save(new \FFMpeg\Format\Video\X264(), 'memes/' . $folder . '/' . $videoname);


  



  How can I set it to be H.264 in Baseline profile ?