[FFmpeg-devel] [PATCH 35/42] avcodec/threadprogress: Add new API for frame-threaded progress

Anton Khirnov anton at khirnov.net
Wed Oct 25 16:25:40 EEST 2023


Quoting Andreas Rheinhardt (2023-09-19 21:57:27)
> The API is very similar by the ProgressFrame API, with the exception
> that it no longer has an included AVFrame. Instead one can wait
> on anything via a ThreadProgress. One just has to ensure that
> the lifetime of the object containing the ThreadProgress is long
> enough (the corresponding problem for ProgressFrames is solved
> by allocating the progress and giving each thread a reference
> to it). This will typically be solved by putting a ThreadProgress
> in a refcounted structure that is shared between threads.
> It will be put to the test in the following commits.
> 
> An alternative to the check for whether the owner exists
> (meaning "do we use frame-threading?") would be to initialize
> the progress to INT_MAX in case frame threading is not in use.
> This would probably be preferable on arches where atomic reads
> are cheap (like x86), but are there ones where it is not?
> 
> One could also (guarded by e.g. an ASSERT_LEVEL check) actually
> track the progress for non-framethreading, too, in order to
> track errors even in single-threaded mode.
> 
> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt at outlook.com>
> ---
>  libavcodec/pthread_frame.c  | 50 +++++++++++++++++++++++++++++++++++++
>  libavcodec/threadprogress.h | 37 +++++++++++++++++++++++++++
>  2 files changed, 87 insertions(+)
>  create mode 100644 libavcodec/threadprogress.h

Again, I'd prefer to do without owner.

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list