Recherche avancée

Sur d’autres sites (9880)

• FFMPEG with QT memory leak

  22 août 2011, par Timothy Baldridge

  Let me start with a code clip :

  QByteArray ba;
  
  ba.resize(500000);
  
  
  
  int encsize = avcodec_encode_video(context, (uint8_t*)ba.data(), 500000, frame.unownedPointer());

  What I'm doing is encoding the data from frame and putting the data into the buffer pointed at QByteArray. If I comment out the avcodec_encode_video line my memory leak goes away. unownedPointer() looks like this :

   if (this->frame != NULL) return this->frame;
  
      this->frame =  avcodec_alloc_frame();
  
      uchar *data = this->img.bits();
  
      frame->data[0] = (uint8_t *)data;
  
      frame->data[1] = (uint8_t *)data + 1;
  
      frame->data[2] = (uint8_t *)data + 2;
  
      frame->linesize[0] = width * lineSize(this->fmt);
  
      frame->linesize[1] = width * lineSize(this->fmt);
  
      frame->linesize[2] = width * lineSize(this->fmt);
  
      return this->frame;

  Where this->frame is a AVFrame *, and this->img is a QImage.

  At a encoding rate of about 30fps, I'm getting a memory leak of about 50MB/sec. So I'm not sure what the issue could be. It seems as if avcodec_encode_video() is copying memory and never freeing it or something. Any ideas ?

  If avcodec_encode_video is converting my RGB24 data to YUV420P would it be modifying the data pointed to by frame.unownedPointer() ?

• avcodec/rv34 : Don't needlessly copy VLC length and symbol arrays

  22 octobre 2020, par Andreas Rheinhardt

  avcodec/rv34 : Don't needlessly copy VLC length and symbol arrays
  Most of the VLCs used by RealVideo 3 and 4 obey three simple rules :
  
  Shorter codes are on the left of the tree, for each length, the symbols
  
  are ascending from left to right and the symbols either form a
  
  permutation of 1..size or 0..(size - 1). For the latter case, one just
  
  needs to store the length of each symbol and create the codes according
  
  to the other rules ; no explicit code or symbol array must be stored.
  
  The former case is also treated in much the same way by artificially
  
  assigning a length of zero to the symbol 0 ; when a length of zero was
  
  encountered, the element was ignored except that the symbol counter was
  
  still incremented. If the length was nonzero, the symbol would be
  
  assigned via the symbol counter and the length copied over into a new
  
  array.
  Yet this is unnecessary, as ff_init_vlc_sparse() follows exactly the
  
  same pattern : If a length of zero is encountered, the element is ignored
  
  and only the symbol counter incremented. So one can directly forward the
  
  length array and also need not create a symbol table oneself, because
  
  ff_init_vlc_sparse() will infer the same symbol table in this case.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/rv34.c

• avcodec/dvdsub_parser : Fix length check for short packets

  30 septembre 2022, par Aidan MacDonald

  avcodec/dvdsub_parser : Fix length check for short packets
  The DVD subtitle parser handles two types of packets : "normal"
  
  packets with a 16-bit length, and HD-DVD packets that set the
  
  16-bit length to 0 and encode a 32-bit length in the next four
  
  bytes. This implies that HD-DVD packets are at least six bytes
  
  long, but the code didn't actually verify this.
  The faulty length check results in an out of bounds read for
  
  zero-length "normal" packets that occur in the input, which are
  
  only 2 bytes long, but get misinterpreted as an HD-DVD packet.
  
  When this happens the parser reads packet_len from beyond the
  
  end of the input buffer. The subtitle stream is not correctly
  
  decoded after this point due to the garbage packet_len.
  Fixing this is pretty simple : fix the length check so packets
  
  less than 6 bytes long will not be mistakenly parsed as HD-DVD
  
  packets.
  Signed-off-by : Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
  
  Signed-off-by : Anton Khirnov <anton@khirnov.net>
  

  • [DH] libavcodec/dvdsub_parser.c