Recherche avancée

Sur d’autres sites (4561)

• avcodec/mpegpicture : Don't copy unnecessarily, fix race

  8 août 2022, par Andreas Rheinhardt

  avcodec/mpegpicture : Don't copy unnecessarily, fix race
  mpegvideo uses an array of Pictures and when it is done with using
  
  them, it only unreferences them incompletely : Some buffers are kept
  
  so that they can be reused lateron if the same slot in the Picture
  
  array is reused, making this a sort of a bufferpool.
  
  (Basically, a Picture is considered used if the AVFrame's buf is set.)
  
  Yet given that other pieces of the decoder may have a reference to
  
  these buffers, they need not be writable and are made writable using
  
  av_buffer_make_writable() when preparing a new Picture. This involves
  
  reading the buffer's data, although the old content of the buffer
  
  need not be retained.
  Worse, this read can be racy, because the buffer can be used by another
  
  thread at the same time. This happens for Real Video 3 and 4.
  This commit fixes this race by no longer copying the data ;
  
  instead the old buffer is replaced by a new, zero-allocated buffer.
  (Here are the details of what happens with three or more decoding threads
  
  when decoding rv30.rm from the FATE-suite as happens in the rv30 test :
  
  The first decoding thread uses the first slot of its picture array
  
  to store its current pic ; update_thread_context copies this for the
  
  second thread that decodes a P-frame. It uses the second slot in its
  
  Picture array to store its P-frame. This arrangement is then copied
  
  to the third decode thread, which decodes a B-frame. It uses the third
  
  slot in its Picture array for its current frame.
  
  update_thread_context copies this to the next thread. It unreferences
  
  the third slot containing the other B-frame and then it reuses this
  
  slot for its current frame. Because the pic array slots are only
  
  incompletely unreferenced, the buffers of the previous B-frame are
  
  still in there and they are not writable ; in fact the previous
  
  thread is concurrently writing to them, causing races when making
  
  the buffer writable.)
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/mpegpicture.c

• avcodec/hevcdec : Check early whether film grain is supported, fix race

  22 août 2022, par Andreas Rheinhardt

  avcodec/hevcdec : Check early whether film grain is supported, fix race
  Applying film grain happens after ff_thread_finish_setup(),
  
  so the parameters synced in hevc_update_thread_context() must not
  
  be modified. But this is exactly what happens in case applying
  
  film grain fails. (The likely result is that in case of frame threading
  
  an uninitialized frame is output.)
  Given that it is actually very easy to know in advance whether
  
  ff_h274_apply_film_grain() supports a given set of parameters,
  
  one can check for this before ff_thread_finish_setup()
  
  and avoid allocating an unused buffer lateron.
  Reviewed-by : Niklas Haas <ffmpeg@haasn.xyz>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/h274.h
  • [DH] libavcodec/hevcdec.c
  • [DH] libavcodec/hevcdec.h

• 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