-
Andreas Rheinhardt authored
This already fixes a race in the vp9-encparams test. In this test, side data is added to the current frame after having been decoded (and therefore after ff_thread_finish_setup() has been called). Yet the update_thread_context callback called ff_thread_ref_frame() and therefore av_frame_ref() with this frame as source frame and the ensuing read was unsynchronised with adding the side data, i.e. there was a data race. By switching to the ProgressFrame API the implicit av_frame_ref() is removed and the race fixed except if this frame is later reused by a show-existing-frame which uses an explicit av_frame_ref(). The vp9-encparams test does not cover this, so this commit already fixes all the races in this test. This decoder kept multiple references to the same ThreadFrames in the same context and therefore had lots of implicit av_frame_ref() even when decoding single-threaded. This incurred lots of small allocations: When decoding an ordinary 10s video in single-threaded mode the number of allocations reported by Valgrind went down from 57,814 to 20,908; for 10 threads it went down from 84,223 to 21,901. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
7bd3b737