1. 05 May, 2020 5 commits
  2. 04 May, 2020 3 commits
    • Linjie Fu's avatar
      lavc/vaapi_encode: add FF_CODEC_CAP_INIT_CLEANUP caps for encoders · 2b320689
      Linjie Fu authored
      ff_vaapi_encode_close() is not enough to free the resources like cbs
      if initialization failure happens after codec->configure (except for
      vp8/vp9).
      
      We need to call avctx->codec->close() to deallocate, otherwise memory
      leak happens.
      
      Add FF_CODEC_CAP_INIT_CLEANUP for vaapi encoders and deallocate the
      resources at free_and_end inside avcodec_open2().
      Reviewed-by: 's avatarTimo Rothenpieler <timo@rothenpieler.org>
      Signed-off-by: 's avatarLinjie Fu <linjie.fu@intel.com>
      2b320689
    • Andreas Rheinhardt's avatar
      avformat/matroskadec: Free right buffer on error · 5767a2ed
      Andreas Rheinhardt authored
      Since commit 979b5b89, 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: 's avatarAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      5767a2ed
    • Steven Liu's avatar
      doc/muxers: remove hls_fmp4_init_resend parameter · 0b0a36b4
      Steven Liu authored
      the parameter should boolean
      0b0a36b4
  3. 03 May, 2020 17 commits
  4. 02 May, 2020 15 commits