Recherche avancée

Sur d’autres sites (12650)

• Cleaning up after av_frame_get_buffer

  4 novembre 2016, par Jason C

  There are two aspects of my question. I’m using libav, ffmpeg, 3.1.

  ---

  First, how do you appropriately dispose of a frame whose buffer has been allocated with av_frame_get_buffer ? E.g. :

  AVFrame *frame = av_frame_alloc();
  
  frame->width = ...;
  
  frame->height = ...;
  
  frame->format = ...;
  
  av_frame_get_buffer(frame, ...);

  Do any buffers have to be freed manually, beyond the call to av_frame_free(frame) ? The documentation doesn’t mention anything special, but in my experience the ffmpeg documentation often leaves out important details, or at least hides them in places far away from the obvious spots. I took a look at the code for av_frame_free and av_frame_unref but it branched out quite a bit and I couldn’t quite determine if it covered everything.

  ---

  Second, if something beyond av_frame_free needs to be done, then is there any catch-all way to clean up a frame if you don’t know how its data has been allocated ? For example, assuming someBuffer is already allocated with the appropriate size :

  AVFrame *frame2 = av_frame_alloc();
  
  frame2->width = ...;
  
  frame2->height = ...;
  
  frame2->format = ...;
  
  av_image_fill_arrays(frame2->data, frame2->linesize, someBuffer, 
  
                       frame2->format, frame2->width, frame2->height, 1);

  Is there a way to free both frame and frame2 in the above examples using the exact same code ? That is frame and its data should be freed, and frame2 should be freed, but not someBuffer, since libav did not allocate it.

• ffmpeg sws_scale converting from YUV420P to RGB24 results in wrong color values

  3 novembre 2016, par Drazurh

  I’m using sws_scale to convert a video from YUV420P to RGB24. The resulting RGB values are wrong, looking much more saturated/contrasted. For example, the first pixel should have an RGB value of (223,73,30) but using sws_scale results in (153,0,0).

  Here’s the code I’m using :

  uint8_t *buffer = NULL;
  
  int numBytes;
  
  // Determine required buffer size and allocate buffer
  
  numBytes=avpicture_get_size(PIX_FMT_RGB24, pCodecCtx->width,
  
                             pCodecCtx->height);
  
  buffer=(uint8_t *)av_malloc(numBytes*sizeof(uint8_t));
  
  
  
  // Assign appropriate parts of buffer to image planes in pFrameRGB
  
  // Note that pFrameRGB is an AVFrame, but AVFrame is a superset
  
  // of AVPicture
  
  std::cout << "Filling picture of size " << pCodecCtx->width <<" x "<height << std::endl;
  
  avpicture_fill((AVPicture *)pFrameRGB, buffer, PIX_FMT_RGB24,
  
                  pCodecCtx->width, pCodecCtx->height);
  
  
  
  
  
  
  
  // initialize SWS context for software scaling
  
  std::cout << "initializing SWS context\n";
  
  sws_ctx = sws_getContext(pCodecCtx->width,
  
      pCodecCtx->height,
  
      pCodecCtx->pix_fmt,
  
      pCodecCtx->width,
  
      pCodecCtx->height,
  
      PIX_FMT_RGB24,
  
      SWS_FAST_BILINEAR,
  
      NULL,
  
      NULL,
  
      NULL
  
  );
  
  
  
  while(frameFinished == 0)
  
  {
  
      if(av_read_frame(pFormatCtx, &packet)<0){
  
          std::cerr << "Could not read frame!\n";
  
          return false;
  
      }
  
  
  
      if(packet.stream_index==videoStream)
  
      {
  
          avcodec_decode_video2(pCodecCtx, pFrame, &frameFinished, &packet);
  
      }
  
  
  
  }
  
  
  
  sws_scale(sws_ctx, (uint8_t const * const *)pFrame->data,
  
            pFrame->linesize, 0, pCodecCtx->height,
  
            pFrameRGB->data, pFrameRGB->linesize);

  The values in pFrameRGB are incorrect. I’ve tried troubleshooting this for hours :-( Any ideas on how to track down my mistake ?

  Here’s a link to the repo. The offending code is in Icosahedron Video Player/mesh.cpp, Mesh::LoadVideo and Mesh::NextFrame().

• Repairing corrupt MOV file

  28 août 2016, par Simon Ridley

  I’m attempting to recover / repair MOV files from a formatted SD card. In the first instance I’ve made a copy of the physical disk using the unix command-line utility "DD". Once that completed I’ve used a working MOV file from the same recording device as a reference file to manually extract the required files using a Hex editor and Python.

  I have attempted to use other recovery tools such as Photorec, and X-Ways, however the extractions appear damaged. This is why I’m using a Hex editor to manually inspect the data to determine what is damaged.

  The software FFMPEG is reporting "moov atom not found" when attempting to process the damaged MOV file.

  When the file is examined in a hex editor I can clearly see that the header appears intact. Offsets 4 to 10 show the ’ftypqt’ signature, then offsets 17 and 16 display ’qt’ and finally the ’mdat’ identifier is at offsets 36 to 39. This is identical to the reference file I have. The mdat container doesn’t appear to finish until ’moov’ which is found at offset 733093392 followed by ’lmvhd’.

  This all appears in the reference file too and as far as I can tell all seems intact. am I correct in thinking that the mdat data is broken in chunks, this is possibly what is referred to as atoms ?

  In which case I appreciate that the data could be damaged somewhere within the mdat. Is it possible to extract the raw data out and rebuild the container ? I’m happy to attempt this with python but I need to understand the structure of the file in more detail. Can anyone help with this please ?