Recherche avancée

Sur d’autres sites (4643)

• Ffmpeg possible sws_scale memory leak

  5 décembre 2024, par Expressingx

  I'm decoding whatever the camera codec is and then always encode it to H264 and more specifically qsv if it is supported. Currently having 2 cameras to test. One is H264 encoding and one is rawvideo. The problem comes with rawvideo. The pixel format is BGR24 and scaling to NV12

  



  I will simplify the code because it is as any other example.

  



  avcodec_send_packet()
// while
avcodec_receive_frame()

// if frame is not EAGAIN convert BGR24 to NV12
if (_pConvertContext == null)
{
    _pConvertContext = CreateContext(sourcePixFmt, targePixFmt);
}

if (_convertedFrameBufferPtr == IntPtr.Zero)
{
    int buffSize = ffmpeg.av_image_get_buffer_size(targePixFmt, sourceFrame->width, sourceFrame->height, 1);
    _convertedFrameBufferPtr = Marshal.AllocHGlobal(buffSize);
     ffmpeg.av_image_fill_arrays(ref _dstData, ref _dstLinesize, (byte*)_convertedFrameBufferPtr, targePixFmt, sourceFrame->width, sourceFrame->height, 1);
}

return ScaleImage(_pConvertContext, sourceFrame, targePixFmt, _dstData, _dstLinesize);


  



  And ScaleImage method

  



  ffmpeg.sws_scale(ctx, sourceFrame->data, sourceFrame->linesize, 0, sourceFrame->height, dstData, dstLinesize);

AVFrame* f = ffmpeg.av_frame_alloc();

var data = new byte_ptrArray8();
data.UpdateFrom(dstData);
var linesize = new int_array8();
linesize.UpdateFrom(dstLinesize);

f->data = data;
f->linesize = linesize;
f->width = sourceFrame->width;
f->height = sourceFrame->height;
f->format = (int)targePixelFormat;

return f;


  



  After that sending the scaled frame to the encoder and receiving it and writing the file. After that I call av_frame_free(&frame) on the frame returned from the method. But when I set breakpoint I can see the address of the frame is the same even after calling av_frame_alloc() and cleaning everytime. And I think this is the reason for the memory leak. If I do deep clone of the f before returning it everything is fine. Why is that happening while the same logic works fine with the other camera ?

  


• avfilter : do not leak frame if ff_get_audio_buffer() fails

  25 novembre 2015, par Paul B Mahol

  avfilter : do not leak frame if ff_get_audio_buffer() fails
  Signed-off-by : Paul B Mahol <onemda@gmail.com>
  

  • [DH] libavfilter/af_adelay.c
  • [DH] libavfilter/af_aecho.c
  • [DH] libavfilter/af_biquads.c
  • [DH] libavfilter/af_chorus.c

• stream_decoder : fix memory leak after seek table read error

  14 juillet 2016, par Max Kellermann

  stream_decoder : fix memory leak after seek table read error
  When read_metadata_seektable_() fails, the has_seek_table flag is
  
  never set to true, and thus free() is never called.
  Example valgrind output :
   11,185,464 bytes in 1 blocks are definitely lost in loss record 62 of 62
  
      at 0x4C2BC0F : malloc (vg_replace_malloc.c:299)
  
      by 0x4C2DE6F : realloc (vg_replace_malloc.c:785)
  
      by 0x40A7880 : safe_realloc_ (alloc.h:159)
  
      by 0x40A7911 : safe_realloc_mul_2op_ (alloc.h:205)
  
      by 0x40AB6B5 : read_metadata_seektable_ (stream_decoder.c:1654)
  
      by 0x40AAB2D : read_metadata_ (stream_decoder.c:1422)
  
      by 0x40A9C79 : FLAC__stream_decoder_process_until_end_of_metadata (stream_decoder.c:1055)
  It is easy to craft a FLAC file which leaks megabytes of memory on
  
  every attempt to open the file.
  This patch fixes the problem by removing checks which are unnecessary
  
  (and harmful).  Checking the has_seek_table flag is not enough, as
  
  described above.  The NULL check is not harmful, but is not helpful
  
  either, because free(NULL) is documented to be legal.
  After running this code block, we’re in a well-known safe state, no
  
  matter how inconsistent pointer and flag may have been before, for
  
  whatever reasons.
  Signed-off-by : Erik de Castro Lopo <erikd@mega-nerd.com>
  

  • [DH] src/libFLAC/stream_decoder.c