Recherche avancée

Sur d’autres sites (6840)

• Encoded images into H264 video are skipped and/or missing ?

  25 juillet 2013, par Jona

  I'm trying to encode images into an H264 MP4 video. The issues I'm having is that some of the images are skipped or at the end of the video simply missing. I need the video to play every single image I encode since it is an animation.

  Any help setting the encoder properly would be greatly appreciated !

  Encoder settings :

  AVCodecContext *c;
  
  ...
  
  c->codec_id = AV_CODEC_ID_H264;
  
  c->bit_rate = mOutputWidth*mOutputHeight*4;//400000;
  
  /* Resolution must be a multiple of two. */
  
  c->width    = mOutputWidth;
  
  c->height   = mOutputHeight;
  
      /* timebase: This is the fundamental unit of time (in seconds) in terms
  
       * of which frame timestamps are represented. For fixed-fps content,
  
       * timebase should be 1/framerate and timestamp increments should be
  
       * identical to 1. */
  
  c->time_base.den = mFps;
  
  c->time_base.num = 1;
  
  c->gop_size      = 12; /* emit one intra frame every twelve frames at most */
  
  c->pix_fmt       = AV_PIX_FMT_YUV420P;
  
  ...
  
  av_dict_set(&pOptions, "preset", "medium", 0);
  
  av_dict_set(&pOptions, "tune", "animation", 0);
  
  
  
  /* open the codec */
  
  ret = avcodec_open2(c, codec, &pOptions);
  
  if (ret < 0) {
  
      LOGE("Could not open video codec: %s", av_err2str(ret));
  
      return -1;
  
  }

  Update 07/24/13 :
  I was able to achieve a better video by setting the gop_size=FPS and writing the last video frame repeatedly FPS+1 times seemed to resolve all issues. To me it seems odd to do that but might be something standard in the video encoding world ? Any tips feedback about this ?

• avutil/mem : Handle fast allocations near UINT_MAX properly

  5 juillet 2022, par Andreas Rheinhardt

  avutil/mem : Handle fast allocations near UINT_MAX properly
  av_fast_realloc and av_fast_mallocz ? store the size of
  
  the objects they allocate in an unsigned. Yet they overallocate
  
  and currently they can allocate more than UINT_MAX bytes
  
  in case a user has requested a size of about UINT_MAX * 16 / 17
  
  or more if SIZE_MAX > UINT_MAX (and if the user increased
  
  max_alloc_size via av_max_alloc). In this case it is impossible
  
  to store the true size of the buffer via the unsigned* ;
  
  future requests are likely to use the (re)allocation codepath
  
  even if the buffer is actually large enough because of
  
  the incorrect size.
  Fix this by ensuring that the actually allocated size
  
  always fits into an unsigned. (This entails erroring out
  
  in case the user requested more than UINT_MAX.)
  Reviewed-by : Tomas Härdin <tjoppen@acc.umu.se>
  
  Reviewed-by : Anton Khirnov <anton@khirnov.net>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavutil/mem.c

• avcodec/decode : Reset MMX state for receive_frame decoders, too

  14 mars 2023, par Andreas Rheinhardt

  avcodec/decode : Reset MMX state for receive_frame decoders, too
  FFmpeg's assembly code currently does not abide by the
  
  plattform-specific ABIs wrt its handling of the X86 MMX flag :
  
  Resetting the MMX state is deferred to avoid doing it multiple times
  
  instead of ensuring that the CPU is in floating point state
  
  upon return from any function.
  Furthermore, resetting said state is sometimes done generically,
  
  namely for all the decoders using the ordinary decode callback ;
  
  yet this is not done for the decoders using the receive_frame API.
  This led to problems when MJPEG (and the MJPEG-based decoders)
  
  were switched to the receive_frame API in commit
  
  e9a2a8777317d91af658f774c68442ac4aa726ec, because ff_mjpeg_decode_sos()
  
  only resets the MMX state on success, not on failure.
  
  Such issues are probably still possible with SMVJPEG, which still
  
  uses the receive_frame API. See issue #10210.
  This commit therefore also resets the MMX state for
  
  the receive_frame API to avoid any more surprises of this sort.
  Reviewed-by : Anton Khirnov <anton@khirnov.net>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/decode.c