Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
To: ffmpeg-devel@ffmpeg.org
Cc: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Subject: [FFmpeg-devel] [PATCH v3 01/27] avcodec/threadprogress: Add new API for frame-threaded progress
Date: Tue,  9 Apr 2024 08:33:54 +0200
Message-ID: <GV1P250MB0737049999C51A81D91DCF408F072@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <GV1P250MB073755270DAD40B30BE913B78F002@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM>

The API is similar to the ThreadFrame API, with the exception
that it no longer has an included AVFrame and that it has its
own mutexes and condition variables which makes it more independent
of pthread_frame.c. 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. This will typically be solved
by putting a ThreadProgress in a refcounted structure that is
shared between threads.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
---
Now using ff_mutex_*/ff_cond_* instead of their pthread counterparts.

 libavcodec/threadprogress.c | 79 ++++++++++++++++++++++++++++++++
 libavcodec/threadprogress.h | 91 +++++++++++++++++++++++++++++++++++++
 2 files changed, 170 insertions(+)
 create mode 100644 libavcodec/threadprogress.c
 create mode 100644 libavcodec/threadprogress.h

diff --git a/libavcodec/threadprogress.c b/libavcodec/threadprogress.c
new file mode 100644
index 0000000000..62c4fd898b
--- /dev/null
+++ b/libavcodec/threadprogress.c
@@ -0,0 +1,79 @@
+/*
+ * Copyright (c) 2022 Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include <limits.h>
+#include <stdatomic.h>
+
+#include "pthread_internal.h"
+#include "threadprogress.h"
+#include "libavutil/attributes.h"
+#include "libavutil/thread.h"
+
+DEFINE_OFFSET_ARRAY(ThreadProgress, thread_progress, init,
+                    (offsetof(ThreadProgress, progress_mutex)),
+                    (offsetof(ThreadProgress, progress_cond)));
+
+av_cold int ff_thread_progress_init(ThreadProgress *pro, int init_mode)
+{
+    atomic_init(&pro->progress, init_mode ? -1 : INT_MAX);
+#if HAVE_THREADS
+    if (init_mode)
+        return ff_pthread_init(pro, thread_progress_offsets);
+#endif
+    pro->init = init_mode;
+    return 0;
+}
+
+av_cold void ff_thread_progress_destroy(ThreadProgress *pro)
+{
+#if HAVE_THREADS
+    ff_pthread_free(pro, thread_progress_offsets);
+#else
+    pro->init = 0;
+#endif
+}
+
+void ff_thread_progress_report(ThreadProgress *pro, int n)
+{
+    if (atomic_load_explicit(&pro->progress, memory_order_relaxed) >= n)
+        return;
+
+    atomic_store_explicit(&pro->progress, n, memory_order_release);
+
+    ff_mutex_lock(&pro->progress_mutex);
+    ff_cond_broadcast(&pro->progress_cond);
+    ff_mutex_unlock(&pro->progress_mutex);
+}
+
+void ff_thread_progress_await(const ThreadProgress *pro_c, int n)
+{
+    /* Casting const away here is safe, because we only read from progress
+     * and will leave pro_c in the same state upon leaving the function
+     * as it had at the beginning. */
+    ThreadProgress *pro = (ThreadProgress*)pro_c;
+
+    if (atomic_load_explicit(&pro->progress, memory_order_acquire) >= n)
+        return;
+
+    ff_mutex_lock(&pro->progress_mutex);
+    while (atomic_load_explicit(&pro->progress, memory_order_relaxed) < n)
+        ff_cond_wait(&pro->progress_cond, &pro->progress_mutex);
+    ff_mutex_unlock(&pro->progress_mutex);
+}
diff --git a/libavcodec/threadprogress.h b/libavcodec/threadprogress.h
new file mode 100644
index 0000000000..786802cbf1
--- /dev/null
+++ b/libavcodec/threadprogress.h
@@ -0,0 +1,91 @@
+/*
+ * Copyright (c) 2022 Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVCODEC_THREADPROGRESS_H
+#define AVCODEC_THREADPROGRESS_H
+
+/**
+ * ThreadProgress is an API to easily notify other threads about progress
+ * of any kind as long as it can be packaged into an int and is consistent
+ * with the natural ordering of integers.
+ *
+ * Each initialized ThreadProgress can be in one of two modes: No-op mode
+ * or ordinary mode. In the former mode, ff_thread_report_progress() and
+ * ff_thread_await_progress() are no-ops to simply support usecases like
+ * non-frame-threading. Only in the latter case perform these functions
+ * what their name already implies.
+ */
+
+#include <limits.h>
+#include <stdatomic.h>
+#include "libavutil/thread.h"
+
+/**
+ * This struct should be treated as opaque by users.
+ */
+typedef struct ThreadProgress {
+    atomic_int progress;
+    unsigned   init;
+    AVMutex progress_mutex;
+    AVCond  progress_cond;
+} ThreadProgress;
+
+/**
+ * Initialize a ThreadProgress.
+ *
+ * @param init_mode If zero, the ThreadProgress will be initialized so that
+ *                  to be in no-op mode as described above. Otherwise
+ */
+int ff_thread_progress_init(ThreadProgress *pro, int init_mode);
+
+/**
+ * Destroy a ThreadProgress. Can be called on a ThreadProgress that
+ * has never been initialized provided that the ThreadProgress struct
+ * has been initially zeroed. Must be called even if ff_thread_progress_init()
+ * failed.
+ */
+void ff_thread_progress_destroy(ThreadProgress *pro);
+
+/**
+ * Reset the ThreadProgress's progress progress counter; must only be called
+ * if it is not in use in any way (e.g. no thread may wait on it via
+ * ff_thread_progress_await()).
+ */
+static inline void ff_thread_progress_reset(ThreadProgress *pro)
+{
+    atomic_init(&pro->progress, pro->init ? -1 : INT_MAX);
+}
+
+/**
+ * This function is a no-op in no-op mode; otherwise it notifies
+ * other threads that a certain level of progress has been reached.
+ * Later calls with lower values of progress have no effect.
+ */
+void ff_thread_progress_report(ThreadProgress *pro, int progress);
+
+/**
+ * This function is a no-op in no-op mode; otherwise it waits
+ * until other threads have reached a certain level of progress:
+ * This function will return after another thread has called
+ * ff_thread_progress_report() with the same or higher value for progress.
+ */
+void ff_thread_progress_await(const ThreadProgress *pro, int progress);
+
+#endif /* AVCODEC_THREADPROGRESS_H */
-- 
2.40.1

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

  parent reply	other threads:[~2024-04-09  6:34 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-08 19:51 [FFmpeg-devel] [PATCH v2 " Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 02/27] avcodec/decode: Add new ProgressFrame API Andreas Rheinhardt
2024-04-09  1:40   ` Michael Niedermayer
2024-04-09  6:35     ` Andreas Rheinhardt
2024-04-10  7:01   ` Anton Khirnov
2024-04-10  7:09     ` Andreas Rheinhardt
2024-04-10  7:59       ` Anton Khirnov
2024-04-10  8:02         ` Andreas Rheinhardt
2024-04-10  8:06           ` Anton Khirnov
2024-04-10  8:09             ` Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 03/27] avcodec/mimic: Switch to ProgressFrames Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 04/27] avcodec/vp3: " Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 05/27] avcodec/vp9: " Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 06/27] avcodec/vp9: Fix race when attaching side-data for show-existing frame Andreas Rheinhardt
2024-04-10  7:06   ` Anton Khirnov
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 07/27] avcodec/vp9: Reduce wait times Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 08/27] avcodec/vp9: Simplify replacing VP9Frame Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 09/27] avcodec/vp9: Replace atomic_store() by atomic_init() Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 10/27] avcodec/pthread_frame: Add API to share RefStruct refs just once Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 11/27] avcodec/wavpack: Use ThreadProgress API Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 12/27] avcodec/wavpack: Move initializing DSD data to a better place Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 13/27] avcodec/wavpack: Only reset DSD context upon parameter change Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 14/27] avcodec/wavpack: Optimize always-false comparison away Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 15/27] avcodec/wavpack: Move transient variable from context to stack Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 16/27] avcodec/vp8: Convert to ProgressFrame API Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 17/27] avcodec/vp8: Mark flushing functions as av_cold Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 18/27] avcodec/codec_internal: Remove FF_CODEC_CAP_ALLOCATE_PROGRESS Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 19/27] avcodec/hevcdec: Switch to ProgressFrames Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 20/27] avcodec/pngdec: " Andreas Rheinhardt
2024-04-08 20:13 ` [FFmpeg-devel] [PATCH v2 21/27] avcodec/ffv1dec: " Andreas Rheinhardt
2024-04-08 20:14 ` [FFmpeg-devel] [PATCH v2 22/27] avcodec/qsv: Use RefStruct API for memory id (mids) array Andreas Rheinhardt
2024-04-08 20:14 ` [FFmpeg-devel] [PATCH v2 23/27] avcodec/rkmppdec: Fix double-free on error Andreas Rheinhardt
2024-04-08 20:14 ` [FFmpeg-devel] [PATCH v2 24/27] avcodec/rkmppdec: Check av_buffer_ref() Andreas Rheinhardt
2024-04-08 20:14 ` [FFmpeg-devel] [PATCH v2 25/27] avcodec/rkmppdec: Use RefStruct API for references to decoder itself Andreas Rheinhardt
2024-04-08 20:14 ` [FFmpeg-devel] [PATCH v2 26/27] avcodec/rkmppdec: Allocate AVDRMFrameDescriptor and frame ctx jointly Andreas Rheinhardt
2024-04-08 20:14 ` [FFmpeg-devel] [PATCH v2 27/27] avcodec/v4l2_(m2m|buffers): Use RefStruct API for context references Andreas Rheinhardt
2024-04-09  6:33 ` Andreas Rheinhardt [this message]
2024-04-10  6:38 ` [FFmpeg-devel] [PATCH v2 01/27] avcodec/threadprogress: Add new API for frame-threaded progress Anton Khirnov
2024-04-18 20:40 ` Andreas Rheinhardt
2024-04-18 21:30   ` epirat07

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=GV1P250MB0737049999C51A81D91DCF408F072@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM \
    --to=andreas.rheinhardt@outlook.com \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git