Recherche avancée

Sur d’autres sites (5700)

• avfilter/formats : Fix double frees and memleaks on error

  7 août 2020, par Andreas Rheinhardt

  avfilter/formats : Fix double frees and memleaks on error
  The formats API deals with lists of channel layouts, sample rates,
  
  pixel formats and sample formats. These lists are refcounted in a way in
  
  which the list structure itself contains pointers to all of its owners.
  
  Furthermore, it is possible for a list to be not owned by anyone yet ;
  
  this status is temporary until the list has been attached to an owner.
  
  Adding an owner to a list involves reallocating the list's list of
  
  owners and can therefore fail.
  In order to reduce the amount of checks and cleanup code for the users
  
  of this API, the API is supposed to be lenient when faced with input
  
  lists that are NULL and it is supposed to clean up if adding an owner
  
  to a list fails, so that a simple use case like
  list = ff_make_format_list(foo_fmts) ;
  
  if ((ret = ff_formats_ref(list, &ctx->inputs[0]->out_formats)) < 0)
  
      return ret ;
  needn't check whether list could be successfully allocated
  
  (ff_formats_ref() return AVERROR(ENOMEM) if it couldn't) and it also
  
  needn't free list if ff_formats_ref() couldn't add an owner for it.
  But the cleaning up after itself was broken. The root cause was that
  
  the refcount was decremented during unreferencing whether or not the
  
  element to be unreferenced was actually an owner of the list or not.
  
  This means that if the above sample code is continued by
  if ((ret = ff_formats_ref(list, &ctx->inputs[1]->out_formats)) < 0)
  
      return ret ;
  and that if an error happens at the second ff_formats_ref() call, the
  
  automatic cleaning of list will decrement the refcount from 1 (the sole
  
  owner of list at this moment is ctx->input[0]->out_formats) to 0 and so
  
  the list will be freed ; yet ctx->input[0]->out_formats still points to
  
  the list and this will lead to a double free/use-after-free when
  
  ctx->input[0] is freed later.
  Presumably in order to work around such an issue, commit
  
  93afb338a405eac0f9e7b092bc26603378bfcca6 restricted unreferencing to
  
  lists with owners. This does not solve the root cause (the above example
  
  is not fixed by this) at all, but it solves some crashs.
  This commit fixes the API : The list's refcount is only decremented if
  
  an owner is removed from the list of owners and not if the
  
  unref-function is called with a pointer that is not among the owners of
  
  the list. Furtermore, the requirement for the list to have owners is
  
  dropped.
  This implies that if the first call to ff_formats_ref() in the above
  
  example fails, the refcount which is initially zero during unreferencing
  
  is not modified, so that the list will be freed automatically in said
  
  call to ff_formats_ref() as every list whose refcount reaches zero is.
  If on the other hand, the second call to ff_formats_ref() is the first
  
  to fail, the refcount would stay at one during the automatic
  
  unreferencing in ff_formats_ref(). The list would later be freed when
  
  its last (and in this case sole) owner (namely
  
  ctx->inputs[0]->out_formats) gets unreferenced.
  The issues described here for ff_formats_ref() also affected the other
  
  functions of this API. E.g. ff_add_format() failed to clean up after
  
  itself if adding an entry to an already existing list failed (the case
  
  of a freshly allocated list was handled specially and this commit also
  
  removes said code). E.g. ff_all_formats() inherited the flaw.
  Reviewed-by : Nicolas George <george@nsup.org>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavfilter/formats.c

• ffmpeg - Unable to record screen and speaker audio at the same time

  11 janvier 2023, par dems98

  I'm trying to record my screen and speaker audio with ffmpeg but I'm facing various problems.

  


  This is the command I'm using :

  


  ffmpeg -video_size 1920x1080 -framerate 60 -f x11grab -i :0.0 -f pulse -ac 2 -i alsa_output.pci-0000_2d_00.4.analog-stereo.monitor output.mp4


  


  but the output video is really slow and out of sync with the audio.
  
Moreover, I'm getting these warnings :

  


  [x11grab @ 0x563635302480] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8)
[aac @ 0x563635319f40] Queue input is backward in time04.49 bitrate= 466.9kbits/s dup=268 drop=45 speed=1.84x    
[mp4 @ 0x5636353172c0] Non-monotonous DTS in output stream 0:1; previous: 217669, current: 210387; changing to 217670. This may result in incorrect timestamps in the output file.                                                                                        


  


  When recording the screen with alsa source (microphone), the output video has no problems.

  


  How can I solve ?

  


• Decoded H.264 gives different frame and context size

  28 août 2015, par Deanna

  We’re using avcodec to decode H.264, and in some circumstances, after changing the resolution, avcodec gets confused, and gives two different sizes for the decoded frame :

  if (av_init_packet_dll)
  
      av_init_packet_dll(&avpkt);
  
  
  
  avpkt.data  = pBuffer;
  
  avpkt.size  = lBuffer;
  
  
  
  //  Make sure the output frame has NULLs for the data lines
  
  pAVFrame->data[0]   = NULL;
  
  pAVFrame->data[1]   = NULL;
  
  pAVFrame->data[2]   = NULL;
  
  pAVFrame->data[3]   = NULL;
  
  
  
  res = avcodec_decode_video2_dll(pCodecCtx, pAVFrame, &FrameFinished, &avpkt);
  
  
  
  DEBUG_LOG("Decoded frame: %d, %d, resulting dimensions: context: %dx%d, frame: %dx%d\n", res, FrameFinished, pCodecCtx->width, pCodecCtx->height, pAVFrame->width, pAVFrame->height);
  
  
  
  if (pCodecCtx->width != pAVFrame->width || pCodecCtx->height != pAVFrame->height) {
  
      OutputDebugStringA("Size mismatch, ignoring frame!\n");
  
      FrameFinished = 0;
  
  }
  
  
  
  if (FrameFinished == 0)
  
      OutputDebugStringA("Unfinished frame\n");

  This results in this log (with some surrounding lines) :

  [5392] Decoded frame: 18690, 1, resulting dimensions: context: 640x480, frame: 640x480
  
  [5392] Set dimensions to 640x480 in DecodeFromMap
  
  [5392] checking size 640x480 against 640x480
  
  [5392] Drawing 640x480, 640x480, 640x480, 0x05DB0060, 0x05DFB5C0, 0x05E0E360, 0x280, to surface 0x03198100, 1280x800
  
  [5392] Drawing 640x480, 640x480, 640x480, 0x05DB0060, 0x05DFB5C0, 0x05E0E360, 0x280, to surface 0x03198100, 1280x800
  
  [5392] Delayed frames seen. Reenabling low delay requires a codec flush.
  
  [5392] Reinit context to 1280x800, pix_fmt: yuvj420p
  
  *[5392] Decoded frame: 54363, 1, resulting dimensions: context: 1280x800, frame: 640x480
  
  [5392] Set dimensions to 1280x800 in DecodeFromMap
  
  [5392] checking size 1280x800 against 640x480
  
  [5392] Found adapter NVIDIA GeForce GTX 650 ({D7B71E3E-4C86-11CF-4E68-7E291CC2C435}) on monitor 00020003
  
  [5392] Found adapter NVIDIA GeForce GTX 650 ({D7B71E3E-4C86-11CF-4E68-7E291CC2C435}) on monitor FA650589
  
  [5392] Creating Direct3D interface on adapter 1 at 1280x800 window 0015050C
  
  [5392] Direct3D created using hardware vertex processing on HAL.
  
  [5392] Creating D3D surface of 1280x800
  
  [5392] Result 0x00000000, got surface 0x03210C40
  
  [5392] Drawing 1280x800, 1280x800, 640x480, 0x02E3B0A0, 0x02E86600, 0x02E993A0, 0x280, to surface 0x03210C40, 1280x800

  The line where this breaks is marked with a *. pAVFrame contains the old frame dimensions, while pCodecCtx contains the new dimensions. When the drawing code than tries to access the data as a 1280x800 image, it hits an access violation.

  When going down a size, avcodec transitions correctly, and sets FrameFinished to 0 and leaves pAVFrame resolution at 0x0.

  Can anyone think what is causing this, why avcodec is reporting success, yet not doing anything, and what I can do to correctly resolve this ?

  For now, the mismatch check is protecting against this.

  The avcodec in use is built from git-5cba529 by Zeranoe.

  FFmpeg version: 2015-03-31 git-5cba529
  
    libavutil      54. 21.100 / 54. 21.100
  
    libavcodec     56. 32.100 / 56. 32.100