Recherche avancée

Sur d’autres sites (3851)

• Video Compression on Android

  26 mai 2015, par Sumit Sheoran

  I want to compress video files on android device before uploading them to server. I have looked for Mediacodec (feature supported in 4.3+) and ffmpeg for android but unable to decide which one to use. Is there any compariosion available based on supported input formats, memory load, increase in app size etc. ?

• 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

• Adjusting video length to fit audio length in FFmpeg

  8 avril 2015, par Spreadys

  This has been driving me mad !
  I have video.avi, a raw uncompressed video with a duration of 6mins
  I have audio.wav, a raw uncompressed audio with a duration of 9mins

  I need to mux these together, but map the timing information from the audio.
  Using Vsync 2 I would hope that video frames get duplicated in order to do this.

  My current (failed) attempt is

  ffmpeg -i video.avi -i audio.wav
   c:v rawvideo -c:a copy
   vsync 2 -map 0:0,1:0 -map 1:0,1:0
  newvideo.avi

  My understanding is that the -map first designates what file:stream, and this is followed by the file:stream to be used for timing information.

  I have attempted all my usual research methods in an attempt to avoid asking but it is still resulting in the avi container holding two streams with the video length unchanged.
  If anyone can shed some light on my errors, I would be very grateful....or if you need further info - please ask !

  Thanks
  David

  Any guidance on what other information may promote some suggestions to where i’m going wrong also appreciated.
  Thanks