Recherche avancée

Sur d’autres sites (4968)

• Correctly Allocate And Fill Frame In FFmpeg

  24 février 2016, par mFeinstein

  I am filling a Frame with a BGR image for encoding, and I am getting a memory leak. I think I got to the source of the problem but it appears to be a library issue instead. Since FFmpeg is such a mature library, I think I am misusing it and I would like to be instructed on how to do it correctly.

  I am allocating a Frame using :

  AVFrame *bgrFrame = av_frame_alloc();

  And later I allocate the image in the Frame using :

  av_image_alloc(bgrFrame->data, bgrFrame->linesize, bgrFrame->width, bgrFrame->height, AV_PIX_FMT_BGR24, 32);

  Then I fill the image allocated using :

  av_image_fill_pointers(bgrFrame->data, AV_PIX_FMT_BGR24, bgrFrame->height, originalBGRImage.data, bgrFrame->linesize);

  Where originalBGRImage is an OpenCV Mat.

  And this has a memory leak, apparently, av_image_alloc() allocates memory, and av_image_fill_pointers() also allocates memory, on the same pointers (I can see bgrFrame->data[0] changing between calls).

  If I call

  av_freep(&bgrFrame->data[0]);

  After av_image_alloc(), it’s fine, but if I call it after av_image_fill_pointers(), the program crashes, even though bgrFrame->data[0] is not NULL, which I find very curious.

  Looking FFmpeg’s av_image_alloc() source code, I see it calls av_image_fill_pointers() twice inside it, once allocating a buffer buff....and later in av_image_fill_pointers() source code, data[0] is substituted by the image pointer, which is (I think) the source of the memory leak, since data[0] was holding buf from the previous av_image_alloc() call.

  So this brings the final question : What’s the correct way of filling a frame with an image ?.

• avcodec/nvenc : include nvEncodeAPI v7 SDK header

  27 août 2016, par Timo Rothenpieler

  avcodec/nvenc : include nvEncodeAPI v7 SDK header
  As Nvidia has put the most recent Video Codec SDK behind a double
  
  registration wall, of which one needs manual approval of a lenghty
  
  application, bundling this header saves everyone trying to use NVENC
  
  from that headache.
  The header is still MIT licensed and thus fine to bundle with ffmpeg.
  Not bundling this header would get ffmpeg stuck at SDK v6, which is
  
  still freely available, holding back future development of the NVENC
  
  encoder.
  

  • [DH] compat/nvenc/nvEncodeAPI.h
  • [DH] configure
  • [DH] libavcodec/nvenc.h
  • [DH] tests/ref/fate/source

• FFMpeg(Android) av_read_frame or avcodec_decode_video2 returning same colour

  5 décembre 2012, par Cehm

  I've been experimenting FFMpeg for the past 2 weeks and I'm having a bit of trouble...
  First I've been working with a Galaxy S3, which worked super fine, gave me the best pictures ever but I recently switched to a Galaxy NEXUS which gave me a bunch of problems...

  What I'm doing : I just extract frame from a video

  How I'm doing :

  while(av_read_frame(gFormatCtx, &packet)>=0)
  
          {
  
              // Is this a packet from the video stream?
  
              if(packet.stream_index==videoStream)
  
              {
  
                  // Decode video frame
  
                  avcodec_decode_video2(gVideoCodecCtx, pFrame, &frameFinished, &packet);
  
                  // Did we get a video frame?
  
                  if(frameFinished)
  
                  {//and so on... But our problem is already here...

  Ok, now pFrame is holding a YUV representation of my frame... So, in order to check what I'm getting from the avcodec_decode_video2(...) function I'm just writing pFrame to a file so I can see it with any YUV reader on the web.

  char yuvFileName[100];
  
  sprintf(yuvFileName,"/storage/sdcard0/yuv%d.yuv",index);
  
  FILE* fp = fopen(yuvFileName, "wb");
  
  int y;
  
  // Write pixel data
  
  for(y=0; yheight; y++)
  
  {
  
      fwrite(pFrame->data[0]+y*pFrame->linesize[0], 1, gVideoCodecCtx->width, fp);    
  
  }
  
  for(y=0; yheight/2; y++)
  
  {
  
      fwrite(pFrame->data[1]+y*pFrame->linesize[1], 1, gVideoCodecCtx->width/2, fp);
  
  }
  
  for(y=0; yheight/2; y++)
  
  {
  
      fwrite(pFrame->data[2]+y*pFrame->linesize[2], 1, gVideoCodecCtx->width/2, fp);
  
  }
  
  fclose(fp);

  Ok so Here I now have my result on a file store @ /storage/sdcard0/blabla.YUV on my Galaxy Nexus root memory.

  But If I open the file with (for example XnView, which is meant to display YUV type properly) I only see Dark green on the picture.

  What bothers me is that everything worked properly on Galaxy S3 but something failed on GNexus...

  So here's my question : Why doesn't it work on Galaxy Nexus ?

  Compatibility problem between Gnexus and armeabiv7 ?

  I don't know !

  Regards,
  Cehm