Recherche avancée

Sur d’autres sites (15967)

• fftools/resources/resman : Don't alloc ResourceManager, fix race

  1er juin, par Andreas Rheinhardt

  fftools/resources/resman : Don't alloc ResourceManager, fix race
  The resman_ctx pointer was accessed outside of its guarding
  
  mutex.
  Also make the ResourceManager static.
  Reviewed-by : softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] fftools/resources/resman.c

• lavc/vvc : Fix race condition for MVs cropped to subpic

  30 décembre 2024, par Frank Plowman

  lavc/vvc : Fix race condition for MVs cropped to subpic
  When the current subpicture has sps_subpic_treated_as_pic_flag equal to
  
  1, motion vectors are cropped such that they cannot point to other
  
  subpictures.  This was accounted for in the prediction logic, but not
  
  in pred_get_y, which is used by the scheduling logic to determine which
  
  parts of the reference pictures must have been reconstructed before
  
  inter prediction of a subsequent frame may begin.  Consequently, where a
  
  motion vector pointed to a location significantly above the current
  
  subpicture, there was the possibility of a race condition.  Patch fixes
  
  this by cropping the motion vector to the current subpicture in
  
  pred_get_y.
  Signed-off-by : Frank Plowman <post@frankplowman.com>
  

  • [DH] libavcodec/vvc/ctu.c

• avcodec/h264dec : Fix data race when updating decode_error_flags

  12 septembre 2023, par Andreas Rheinhardt

  avcodec/h264dec : Fix data race when updating decode_error_flags
  When using multi-threaded decoding, every decoding thread
  
  has its own DBP consisting of H264Pictures and each of these
  
  points to its own AVFrames. They are synced during
  
  update_thread_context via av_frame_ref() and therefore
  
  the threads actually decoding (as well as all the others)
  
  must not modify any field that is copied by av_frame_ref()
  
  after ff_thread_finish_setup().
  Yet this is exactly what happens when an error occurs
  
  during decoding and the AVFrame's decode_error_flags are updated.
  
  Given that these errors only become apparent during decoding,
  
  this can't be set before ff_thread_finish_setup() without
  
  defeating the point of frame-threading ; in practice,
  
  this meant that the decoder did not set these flags correctly
  
  in case frame-threading was in use. (This means that e.g.
  
  the ffmpeg cli tool fails to output its "corrupt decoded frame"
  
  message in a nondeterministic fashion.)
  This commit fixes this by adding a new H264Picture field
  
  that is actually propagated across threads ; the field
  
  is an AVBufferRef* whose data is an atomic_int ; it is
  
  atomic in order to allow multiple threads to update it
  
  concurrently and not to provide synchronization
  
  between the threads setting the field and the thread
  
  ultimately returning the AVFrame.
  This unfortunately has the overhead of one allocation
  
  per H264Picture (both the original one as well as
  
  creating a reference to an existing one), even in case
  
  of no errors. In order to mitigate this, an AVBufferPool
  
  has been used and only if frame-threading is actually
  
  in use. This expense will be removed as soon as
  
  a proper API for refcounted objects (not based upon
  
  AVBuffer) is in place.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/h264_picture.c
  • [DH] libavcodec/h264_slice.c
  • [DH] libavcodec/h264dec.c
  • [DH] libavcodec/h264dec.h