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.rheinha...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
