Recherche avancée

Sur d’autres sites (8684)

• avfilter/vf_remap : Fix double-free of AVFilterFormats on error

  7 août 2020, par Andreas Rheinhardt

  avfilter/vf_remap : Fix double-free of AVFilterFormats on error
  The query_formats function of the remap filter tries to allocate
  
  two lists of formats which on success are attached to more permanent objects
  
  (AVFilterLinks) for storage afterwards. If attaching a list to an
  
  AVFilterLink succeeds, it is in turn owned by the AVFilterLink (or more
  
  exactly, the AVFilterLink becomes one of the common owners of the list).
  
  Yet if attaching a list to one of its links succeeds and an error happens
  
  lateron, both lists were manually freed, which means that is wrong if the
  
  list is already owned by one or more links ; these links' pointers to
  
  their lists will become dangling and there will be a double-free/use-after-
  
  free when these links are cleaned up automatically.
  This commit fixes this by removing the custom free code ; this will
  
  temporarily add a leaking codepath (if attaching a list not already
  
  owned by a link to a link fails, the list will leak), but this will
  
  be fixed soon by making sure that an AVFilterFormats without owner will
  
  be automatically freed when attaching it to an AVFilterLink fails.
  
  Notice at most one list leaks because a new list is only allocated
  
  after the old list has been successfully attached to a link.
  Reviewed-by : Nicolas George <george@nsup.org>
  
  Reviewed-by : Paul B Mahol <onemda@gmail.com>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavfilter/vf_remap.c

• avcodec/movtextenc : Fix memleak on (re)allocation error

  17 octobre 2020, par Andreas Rheinhardt

  avcodec/movtextenc : Fix memleak on (re)allocation error
  Up until now, the mov_text encoder used the dynamic array API for its
  
  list of style attributes ; it used the (horrible) av_dynarray_add() which
  
  works with an array of pointers ; on error it frees its array but not
  
  the buffers referenced by the pointers said array contains. It also
  
  returns no error code, encouraging not to check for errors.
  These properties imply that this function may only be used if the buffers
  
  referenced by the list either need not be freed at all or if they are
  
  freed by other means (i.e. if the list contains non-ownership pointers).
  In this case, the style attributes are owned by the pointers of the
  
  dynamic list. Ergo the old style attributes leak on a subsequent
  
  reallocation failure. But given that the (re)allocation isn't checked
  
  for success, the style attribute intended to be added to the list also
  
  leaks because the only pointer to it gets overwritten in the belief that
  
  it is now owned by the list.
  This commit fixes this by switching to av_fast_realloc() and an array
  
  containing the styles directly instead of pointers to individually
  
  allocated style attributes. The current style attributes are now no longer
  
  individually allocated, instead they are part of the context.
  Furthermore, av_fast_realloc() allows to easily distinguish between
  
  valid and allocated elements, thereby allowing to reuse the array
  
  (which up until now has always been freed after processing an
  
  AVSubtitleRect).
  Reviewed-by : Philip Langdale <philipl@overt.org>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/movtextenc.c

• FFmpeg - Memory leak using sws_scale

  12 décembre 2018, par AlexVestin

  I’m trying to read a video-file and extract RGB24 frames from this. The problem is when I use sw_scale, the program leaks 200MB/s, which isn’t ideal.

  A shortened version of the code I’m using is :

  static int decode_packet(uint8_t** data, int* frame_size){
  
      int ret = 0, dec_ret = 0;
  
      dec_ret = avcodec_send_packet(video_dec_ctx, &pkt);
  
      while(dec_ret >= 0) {
  
          dec_ret = avcodec_receive_frame(video_dec_ctx, frame);            
  
          if(dec_ret == AVERROR(EAGAIN) || dec_ret == AVERROR_EOF) {
  
              return decoded;
  
          }
  
          if(!image_inited && frame->format != -1) {
  
              sws_context = init_context();
  
              image_inited = true;
  
          }
  
  
  
          const int size = video_dec_ctx->width*video_dec_ctx->height*3;
  
          uint8_t* buffer = malloc(size);
  
  
  
          const int out_linesize[1] = { 3 * video_dec_ctx->width };
  
          sws_scale(
  
              sws_context, 
  
              frame->data, 
  
              frame->linesize, 
  
              0, 
  
              video_dec_ctx->height, 
  
              (const uint8_t * const *)&buffer, 
  
              out_linesize
  
          );
  
  
  
          *data = buffer;
  
      }
  
  }
  
  
  
  void get_next_frame(uint8_t* data) {
  
     int ret = av_read_frame(fmt_ctx, &pkt);
  
     AVPacket orig_pkt = pkt;
  
     ret = decode_packet(&data, &idummy);
  
     av_packet_unref(&orig_pkt);
  
     av_frame_unref(frame);
  
     return ret; 
  
  }

  And called from a main (pseduocode) :

  int main(inr argc, char** argv) {
  
     while(frames_left) {
  
        uint8_t* f;
  
        get_next_frame(f);
  
        apply_frame(f);
  
        free(f);
  
     }
  
  }

  After a bit of debugging I found that this part :

     const int out_linesize[1] = { 3 * video_dec_ctx->width };
  
      sws_scale(
  
          sws_context, 
  
          frame->data, 
  
          frame->linesize, 
  
          0, 
  
          video_dec_ctx->height, 
  
          (const uint8_t * const *)&buffer, 
  
          out_linesize
  
      );

  was the culprit. If I comment this section out the program runs fine (or at least without 200MB memory leak ^^)

  I’ve tried freeing the sws_context after each call, freeing the av_frame after each call in get_next_frame but the memory leak is still there.

  Does anyone know how to fix the leak ?