* [FFmpeg-devel] [PATCH 1/2] avcodec/thread: add support for frame threading receive_frame based decoders
@ 2022-12-05 13:39 Timo Rothenpieler
2022-12-05 13:39 ` [FFmpeg-devel] [PATCH 2/2] avcodec/mjpegdec: add support for frame threading Timo Rothenpieler
2022-12-06 14:37 ` [FFmpeg-devel] [PATCH 1/2] avcodec/thread: add support for frame threading receive_frame based decoders Anton Khirnov
0 siblings, 2 replies; 13+ messages in thread
From: Timo Rothenpieler @ 2022-12-05 13:39 UTC (permalink / raw)
To: ffmpeg-devel; +Cc: Timo Rothenpieler
This is fairly basic and makes a lot of assumptions, but it works
for the most simple cases.
For one, it only ever fetches exactly one packet per call to receive_frame.
Right now it's impossible for there to ever be more than one, but the API
allows for more, which might need handled in the future.
It also basically translates the new API back to the old, since that's how
the frame threading code operates. Which feels backwards in regards to
the new API, but it was the path with least resistance in implementing this.
---
libavcodec/decode.c | 6 +++-
libavcodec/pthread_frame.c | 68 ++++++++++++++++++++++++++++++++++++--
libavcodec/thread.h | 17 ++++++++++
3 files changed, 88 insertions(+), 3 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 6be2d3d6ed..72a8253aae 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -577,7 +577,11 @@ static int decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
av_assert0(!frame->buf[0]);
if (codec->cb_type == FF_CODEC_CB_TYPE_RECEIVE_FRAME) {
- ret = codec->cb.receive_frame(avctx, frame);
+ if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME)
+ ret = ff_thread_receive_frame(avctx, frame);
+ else
+ ret = codec->cb.receive_frame(avctx, frame);
+
if (ret != AVERROR(EAGAIN))
av_packet_unref(avci->last_pkt_props);
} else
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index df82a4125f..8f704e35d3 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -92,6 +92,7 @@ typedef struct PerThreadContext {
AVCodecContext *avctx; ///< Context used to decode packets passed to this thread.
AVPacket *avpkt; ///< Input packet (for decoding) or output (for encoding).
+ int avpkt_read; ///< Indicates if the packet has been read for this recv_frame call already.
AVFrame *frame; ///< Output frame (for decoding) or input (for encoding).
int got_frame; ///< The output of got_picture_ptr from the last avcodec_decode_video() call.
@@ -237,8 +238,14 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
av_frame_unref(p->frame);
- p->got_frame = 0;
- p->result = codec->cb.decode(avctx, p->frame, &p->got_frame, p->avpkt);
+ if (codec->cb_type == FF_CODEC_CB_TYPE_RECEIVE_FRAME) {
+ p->avpkt_read = 0;
+ p->result = codec->cb.receive_frame(avctx, p->frame);
+ p->got_frame = !p->result;
+ } else {
+ p->got_frame = 0;
+ p->result = codec->cb.decode(avctx, p->frame, &p->got_frame, p->avpkt);
+ }
if ((p->result < 0 || !p->got_frame) && p->frame->buf[0])
ff_thread_release_buffer(avctx, p->frame);
@@ -621,6 +628,58 @@ finish:
return err;
}
+int ff_thread_receive_frame(AVCodecContext *avctx, AVFrame *frame)
+{
+ AVPacket *const avpkt = avctx->internal->in_pkt;
+ int got_picture = 0;
+ int draining = 0;
+ int ret;
+
+ av_packet_unref(avpkt);
+ ret = ff_decode_get_packet(avctx, avpkt);
+ if (ret < 0 && ret != AVERROR_EOF)
+ return ret;
+ draining = ret == AVERROR_EOF;
+
+ ret = ff_thread_decode_frame(avctx, frame, &got_picture, avpkt);
+
+ if (ret == avpkt->size) {
+ if (got_picture) {
+ return 0;
+ } else if (draining) {
+ return AVERROR_EOF;
+ }
+
+ return AVERROR(EAGAIN);
+ } else if (ret < 0) {
+ return ret;
+ }
+
+ return AVERROR_BUG;
+}
+
+int ff_thread_decode_get_packet(AVCodecContext *avctx, AVPacket *pkt)
+{
+ PerThreadContext *p;
+ int err;
+
+ if (!(avctx->active_thread_type & FF_THREAD_FRAME))
+ return ff_decode_get_packet(avctx, pkt);
+
+ p = avctx->internal->thread_ctx;
+
+ if (p->avpkt_read)
+ return AVERROR(EAGAIN);
+
+ err = av_packet_ref(pkt, p->avpkt);
+ if (err < 0)
+ return err;
+
+ p->avpkt_read = 1;
+
+ return 0;
+}
+
void ff_thread_report_progress(ThreadFrame *f, int n, int field)
{
PerThreadContext *p;
@@ -775,6 +834,7 @@ void ff_frame_thread_free(AVCodecContext *avctx, int thread_count)
av_freep(&ctx->slice_offset);
av_buffer_unref(&ctx->internal->pool);
+ av_packet_free(&ctx->internal->in_pkt);
av_freep(&ctx->internal);
av_buffer_unref(&ctx->hw_frames_ctx);
}
@@ -826,6 +886,10 @@ static av_cold int init_thread(PerThreadContext *p, int *threads_to_free,
return AVERROR(ENOMEM);
copy->internal->thread_ctx = p;
+ copy->internal->in_pkt = av_packet_alloc();
+ if (!copy->internal->in_pkt)
+ return AVERROR(ENOMEM);
+
copy->delay = avctx->delay;
if (codec->priv_data_size) {
diff --git a/libavcodec/thread.h b/libavcodec/thread.h
index d5673f25ea..76e7d44bd4 100644
--- a/libavcodec/thread.h
+++ b/libavcodec/thread.h
@@ -52,6 +52,15 @@ void ff_thread_flush(AVCodecContext *avctx);
int ff_thread_decode_frame(AVCodecContext *avctx, AVFrame *picture,
int *got_picture_ptr, AVPacket *avpkt);
+/**
+ * Receive a new frame from a decoding thread.
+ * Returns the next available frame, or AVERROR(EAGAIN) if
+ * none is available.
+ *
+ * Parameters are the same as FFCodec.receive_frame.
+ */
+int ff_thread_receive_frame(AVCodecContext *avctx, AVFrame *frame);
+
/**
* If the codec defines update_thread_context(), call this
* when they are ready for the next thread to start decoding
@@ -99,6 +108,14 @@ int ff_thread_get_buffer(AVCodecContext *avctx, AVFrame *f, int flags);
*/
void ff_thread_release_buffer(AVCodecContext *avctx, AVFrame *f);
+/**
+ * Wrapper around ff_decode_get_packet() for frame-multithreaded codecs.
+ * Call this functions instead of ff_decode_get_packet().
+ *
+ * Parameters are the same as ff_decode_get_packet().
+ */
+int ff_thread_decode_get_packet(AVCodecContext *avctx, AVPacket *pkt);
+
int ff_thread_init(AVCodecContext *s);
int ff_slice_thread_execute_with_mainfunc(AVCodecContext *avctx,
int (*action_func2)(AVCodecContext *c, void *arg, int jobnr, int threadnr),
--
2.34.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".
^ permalink raw reply [flat|nested] 13+ messages in thread
* [FFmpeg-devel] [PATCH 2/2] avcodec/mjpegdec: add support for frame threading
2022-12-05 13:39 [FFmpeg-devel] [PATCH 1/2] avcodec/thread: add support for frame threading receive_frame based decoders Timo Rothenpieler
@ 2022-12-05 13:39 ` Timo Rothenpieler
2022-12-05 14:15 ` Andreas Rheinhardt
2022-12-06 14:37 ` [FFmpeg-devel] [PATCH 1/2] avcodec/thread: add support for frame threading receive_frame based decoders Anton Khirnov
1 sibling, 1 reply; 13+ messages in thread
From: Timo Rothenpieler @ 2022-12-05 13:39 UTC (permalink / raw)
To: ffmpeg-devel; +Cc: Timo Rothenpieler
In my tests, this lead to a notable speed increase with the amount
of threads used. Decoding a 720p sample gave the following results:
1 Thread: 1428 FPS
2 Threads: 2501 FPS
8 Threads: 7575 FPS
Automatic: 11326 FPS (On a 16 Core/32 Threads system)
---
libavcodec/jpeglsdec.c | 2 +-
libavcodec/mjpegdec.c | 13 +++++++------
libavcodec/sp5xdec.c | 4 ++--
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/libavcodec/jpeglsdec.c b/libavcodec/jpeglsdec.c
index 2e6d018ea6..c0642e8e30 100644
--- a/libavcodec/jpeglsdec.c
+++ b/libavcodec/jpeglsdec.c
@@ -559,7 +559,7 @@ const FFCodec ff_jpegls_decoder = {
.init = ff_mjpeg_decode_init,
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
- .p.capabilities = AV_CODEC_CAP_DR1,
+ .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
FF_CODEC_CAP_SETS_PKT_DTS,
};
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 9b7465abe7..d30d722398 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -54,6 +54,7 @@
#include "exif.h"
#include "bytestream.h"
#include "tiff_common.h"
+#include "thread.h"
static int init_default_huffman_tables(MJpegDecodeContext *s)
@@ -713,7 +714,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
s->avctx->pix_fmt,
AV_PIX_FMT_NONE,
};
- s->hwaccel_pix_fmt = ff_get_format(s->avctx, pix_fmts);
+ s->hwaccel_pix_fmt = ff_thread_get_format(s->avctx, pix_fmts);
if (s->hwaccel_pix_fmt < 0)
return AVERROR(EINVAL);
@@ -729,7 +730,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
}
av_frame_unref(s->picture_ptr);
- if (ff_get_buffer(s->avctx, s->picture_ptr, AV_GET_BUFFER_FLAG_REF) < 0)
+ if (ff_thread_get_buffer(s->avctx, s->picture_ptr, AV_GET_BUFFER_FLAG_REF) < 0)
return -1;
s->picture_ptr->pict_type = AV_PICTURE_TYPE_I;
s->picture_ptr->key_frame = 1;
@@ -2388,7 +2389,7 @@ static int mjpeg_get_packet(AVCodecContext *avctx)
int ret;
av_packet_unref(s->pkt);
- ret = ff_decode_get_packet(avctx, s->pkt);
+ ret = ff_thread_decode_get_packet(avctx, s->pkt);
if (ret < 0)
return ret;
@@ -3020,7 +3021,7 @@ const FFCodec ff_mjpeg_decoder = {
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
.flush = decode_flush,
- .p.capabilities = AV_CODEC_CAP_DR1,
+ .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.p.max_lowres = 3,
.p.priv_class = &mjpegdec_class,
.p.profiles = NULL_IF_CONFIG_SMALL(ff_mjpeg_profiles),
@@ -3050,7 +3051,7 @@ const FFCodec ff_thp_decoder = {
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
.flush = decode_flush,
- .p.capabilities = AV_CODEC_CAP_DR1,
+ .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.p.max_lowres = 3,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
FF_CODEC_CAP_SETS_PKT_DTS,
@@ -3068,7 +3069,7 @@ const FFCodec ff_smvjpeg_decoder = {
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
.flush = decode_flush,
- .p.capabilities = AV_CODEC_CAP_DR1,
+ .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.caps_internal = FF_CODEC_CAP_EXPORTS_CROPPING |
FF_CODEC_CAP_SETS_PKT_DTS | FF_CODEC_CAP_INIT_CLEANUP,
};
diff --git a/libavcodec/sp5xdec.c b/libavcodec/sp5xdec.c
index 394448c5a9..8b08dc672a 100644
--- a/libavcodec/sp5xdec.c
+++ b/libavcodec/sp5xdec.c
@@ -101,7 +101,7 @@ const FFCodec ff_sp5x_decoder = {
.init = ff_mjpeg_decode_init,
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
- .p.capabilities = AV_CODEC_CAP_DR1,
+ .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.p.max_lowres = 3,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
FF_CODEC_CAP_SETS_PKT_DTS,
@@ -118,7 +118,7 @@ const FFCodec ff_amv_decoder = {
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
.p.max_lowres = 3,
- .p.capabilities = AV_CODEC_CAP_DR1,
+ .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
FF_CODEC_CAP_SETS_PKT_DTS,
};
--
2.34.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".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mjpegdec: add support for frame threading
2022-12-05 13:39 ` [FFmpeg-devel] [PATCH 2/2] avcodec/mjpegdec: add support for frame threading Timo Rothenpieler
@ 2022-12-05 14:15 ` Andreas Rheinhardt
2022-12-05 14:28 ` Paul B Mahol
2022-12-05 23:02 ` Timo Rothenpieler
0 siblings, 2 replies; 13+ messages in thread
From: Andreas Rheinhardt @ 2022-12-05 14:15 UTC (permalink / raw)
To: ffmpeg-devel
Timo Rothenpieler:
> In my tests, this lead to a notable speed increase with the amount
> of threads used. Decoding a 720p sample gave the following results:
>
> 1 Thread: 1428 FPS
> 2 Threads: 2501 FPS
> 8 Threads: 7575 FPS
> Automatic: 11326 FPS (On a 16 Core/32 Threads system)
> ---
> libavcodec/jpeglsdec.c | 2 +-
> libavcodec/mjpegdec.c | 13 +++++++------
> libavcodec/sp5xdec.c | 4 ++--
> 3 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/jpeglsdec.c b/libavcodec/jpeglsdec.c
> index 2e6d018ea6..c0642e8e30 100644
> --- a/libavcodec/jpeglsdec.c
> +++ b/libavcodec/jpeglsdec.c
> @@ -559,7 +559,7 @@ const FFCodec ff_jpegls_decoder = {
> .init = ff_mjpeg_decode_init,
> .close = ff_mjpeg_decode_end,
> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
> - .p.capabilities = AV_CODEC_CAP_DR1,
> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
> FF_CODEC_CAP_SETS_PKT_DTS,
> };
> diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> index 9b7465abe7..d30d722398 100644
> --- a/libavcodec/mjpegdec.c
> +++ b/libavcodec/mjpegdec.c
> @@ -54,6 +54,7 @@
> #include "exif.h"
> #include "bytestream.h"
> #include "tiff_common.h"
> +#include "thread.h"
>
>
> static int init_default_huffman_tables(MJpegDecodeContext *s)
> @@ -713,7 +714,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
> s->avctx->pix_fmt,
> AV_PIX_FMT_NONE,
> };
> - s->hwaccel_pix_fmt = ff_get_format(s->avctx, pix_fmts);
> + s->hwaccel_pix_fmt = ff_thread_get_format(s->avctx, pix_fmts);
> if (s->hwaccel_pix_fmt < 0)
> return AVERROR(EINVAL);
>
> @@ -729,7 +730,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
> }
>
> av_frame_unref(s->picture_ptr);
> - if (ff_get_buffer(s->avctx, s->picture_ptr, AV_GET_BUFFER_FLAG_REF) < 0)
> + if (ff_thread_get_buffer(s->avctx, s->picture_ptr, AV_GET_BUFFER_FLAG_REF) < 0)
> return -1;
> s->picture_ptr->pict_type = AV_PICTURE_TYPE_I;
> s->picture_ptr->key_frame = 1;
> @@ -2388,7 +2389,7 @@ static int mjpeg_get_packet(AVCodecContext *avctx)
> int ret;
>
> av_packet_unref(s->pkt);
> - ret = ff_decode_get_packet(avctx, s->pkt);
> + ret = ff_thread_decode_get_packet(avctx, s->pkt);
> if (ret < 0)
> return ret;
>
> @@ -3020,7 +3021,7 @@ const FFCodec ff_mjpeg_decoder = {
> .close = ff_mjpeg_decode_end,
> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
> .flush = decode_flush,
> - .p.capabilities = AV_CODEC_CAP_DR1,
> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
> .p.max_lowres = 3,
> .p.priv_class = &mjpegdec_class,
> .p.profiles = NULL_IF_CONFIG_SMALL(ff_mjpeg_profiles),
> @@ -3050,7 +3051,7 @@ const FFCodec ff_thp_decoder = {
> .close = ff_mjpeg_decode_end,
> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
> .flush = decode_flush,
> - .p.capabilities = AV_CODEC_CAP_DR1,
> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
> .p.max_lowres = 3,
> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
> FF_CODEC_CAP_SETS_PKT_DTS,
> @@ -3068,7 +3069,7 @@ const FFCodec ff_smvjpeg_decoder = {
> .close = ff_mjpeg_decode_end,
> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
> .flush = decode_flush,
> - .p.capabilities = AV_CODEC_CAP_DR1,
> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
> .caps_internal = FF_CODEC_CAP_EXPORTS_CROPPING |
> FF_CODEC_CAP_SETS_PKT_DTS | FF_CODEC_CAP_INIT_CLEANUP,
> };
> diff --git a/libavcodec/sp5xdec.c b/libavcodec/sp5xdec.c
> index 394448c5a9..8b08dc672a 100644
> --- a/libavcodec/sp5xdec.c
> +++ b/libavcodec/sp5xdec.c
> @@ -101,7 +101,7 @@ const FFCodec ff_sp5x_decoder = {
> .init = ff_mjpeg_decode_init,
> .close = ff_mjpeg_decode_end,
> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
> - .p.capabilities = AV_CODEC_CAP_DR1,
> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
> .p.max_lowres = 3,
> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
> FF_CODEC_CAP_SETS_PKT_DTS,
> @@ -118,7 +118,7 @@ const FFCodec ff_amv_decoder = {
> .close = ff_mjpeg_decode_end,
> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
> .p.max_lowres = 3,
> - .p.capabilities = AV_CODEC_CAP_DR1,
> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
> FF_CODEC_CAP_SETS_PKT_DTS,
> };
Can you test the sample that Michael mentioned here:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/AS8PR01MB7944E105BE990A5D01EF89208FEF9@AS8PR01MB7944.eurprd01.prod.exchangelabs.com/?
(I never got around to analyzing this, but if I am not mistaken, it
shows that this decoder is not a simple one-in, one-out decoder, so that
making it multithreaded will be more complicated than just adding the
flag and using ff_thread_get_buffer/format.)
- Andreas
_______________________________________________
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".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mjpegdec: add support for frame threading
2022-12-05 14:15 ` Andreas Rheinhardt
@ 2022-12-05 14:28 ` Paul B Mahol
2022-12-05 23:02 ` Timo Rothenpieler
1 sibling, 0 replies; 13+ messages in thread
From: Paul B Mahol @ 2022-12-05 14:28 UTC (permalink / raw)
To: FFmpeg development discussions and patches
On 12/5/22, Andreas Rheinhardt <andreas.rheinhardt@outlook.com> wrote:
> Timo Rothenpieler:
>> In my tests, this lead to a notable speed increase with the amount
>> of threads used. Decoding a 720p sample gave the following results:
>>
>> 1 Thread: 1428 FPS
>> 2 Threads: 2501 FPS
>> 8 Threads: 7575 FPS
>> Automatic: 11326 FPS (On a 16 Core/32 Threads system)
>> ---
>> libavcodec/jpeglsdec.c | 2 +-
>> libavcodec/mjpegdec.c | 13 +++++++------
>> libavcodec/sp5xdec.c | 4 ++--
>> 3 files changed, 10 insertions(+), 9 deletions(-)
>>
>> diff --git a/libavcodec/jpeglsdec.c b/libavcodec/jpeglsdec.c
>> index 2e6d018ea6..c0642e8e30 100644
>> --- a/libavcodec/jpeglsdec.c
>> +++ b/libavcodec/jpeglsdec.c
>> @@ -559,7 +559,7 @@ const FFCodec ff_jpegls_decoder = {
>> .init = ff_mjpeg_decode_init,
>> .close = ff_mjpeg_decode_end,
>> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> - .p.capabilities = AV_CODEC_CAP_DR1,
>> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
>> FF_CODEC_CAP_SETS_PKT_DTS,
>> };
>> diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
>> index 9b7465abe7..d30d722398 100644
>> --- a/libavcodec/mjpegdec.c
>> +++ b/libavcodec/mjpegdec.c
>> @@ -54,6 +54,7 @@
>> #include "exif.h"
>> #include "bytestream.h"
>> #include "tiff_common.h"
>> +#include "thread.h"
>>
>>
>> static int init_default_huffman_tables(MJpegDecodeContext *s)
>> @@ -713,7 +714,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
>> s->avctx->pix_fmt,
>> AV_PIX_FMT_NONE,
>> };
>> - s->hwaccel_pix_fmt = ff_get_format(s->avctx, pix_fmts);
>> + s->hwaccel_pix_fmt = ff_thread_get_format(s->avctx,
>> pix_fmts);
>> if (s->hwaccel_pix_fmt < 0)
>> return AVERROR(EINVAL);
>>
>> @@ -729,7 +730,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
>> }
>>
>> av_frame_unref(s->picture_ptr);
>> - if (ff_get_buffer(s->avctx, s->picture_ptr,
>> AV_GET_BUFFER_FLAG_REF) < 0)
>> + if (ff_thread_get_buffer(s->avctx, s->picture_ptr,
>> AV_GET_BUFFER_FLAG_REF) < 0)
>> return -1;
>> s->picture_ptr->pict_type = AV_PICTURE_TYPE_I;
>> s->picture_ptr->key_frame = 1;
>> @@ -2388,7 +2389,7 @@ static int mjpeg_get_packet(AVCodecContext *avctx)
>> int ret;
>>
>> av_packet_unref(s->pkt);
>> - ret = ff_decode_get_packet(avctx, s->pkt);
>> + ret = ff_thread_decode_get_packet(avctx, s->pkt);
>> if (ret < 0)
>> return ret;
>>
>> @@ -3020,7 +3021,7 @@ const FFCodec ff_mjpeg_decoder = {
>> .close = ff_mjpeg_decode_end,
>> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> .flush = decode_flush,
>> - .p.capabilities = AV_CODEC_CAP_DR1,
>> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> .p.max_lowres = 3,
>> .p.priv_class = &mjpegdec_class,
>> .p.profiles = NULL_IF_CONFIG_SMALL(ff_mjpeg_profiles),
>> @@ -3050,7 +3051,7 @@ const FFCodec ff_thp_decoder = {
>> .close = ff_mjpeg_decode_end,
>> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> .flush = decode_flush,
>> - .p.capabilities = AV_CODEC_CAP_DR1,
>> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> .p.max_lowres = 3,
>> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
>> FF_CODEC_CAP_SETS_PKT_DTS,
>> @@ -3068,7 +3069,7 @@ const FFCodec ff_smvjpeg_decoder = {
>> .close = ff_mjpeg_decode_end,
>> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> .flush = decode_flush,
>> - .p.capabilities = AV_CODEC_CAP_DR1,
>> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> .caps_internal = FF_CODEC_CAP_EXPORTS_CROPPING |
>> FF_CODEC_CAP_SETS_PKT_DTS |
>> FF_CODEC_CAP_INIT_CLEANUP,
>> };
>> diff --git a/libavcodec/sp5xdec.c b/libavcodec/sp5xdec.c
>> index 394448c5a9..8b08dc672a 100644
>> --- a/libavcodec/sp5xdec.c
>> +++ b/libavcodec/sp5xdec.c
>> @@ -101,7 +101,7 @@ const FFCodec ff_sp5x_decoder = {
>> .init = ff_mjpeg_decode_init,
>> .close = ff_mjpeg_decode_end,
>> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> - .p.capabilities = AV_CODEC_CAP_DR1,
>> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> .p.max_lowres = 3,
>> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
>> FF_CODEC_CAP_SETS_PKT_DTS,
>> @@ -118,7 +118,7 @@ const FFCodec ff_amv_decoder = {
>> .close = ff_mjpeg_decode_end,
>> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> .p.max_lowres = 3,
>> - .p.capabilities = AV_CODEC_CAP_DR1,
>> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
>> FF_CODEC_CAP_SETS_PKT_DTS,
>> };
>
> Can you test the sample that Michael mentioned here:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/AS8PR01MB7944E105BE990A5D01EF89208FEF9@AS8PR01MB7944.eurprd01.prod.exchangelabs.com/?
> (I never got around to analyzing this, but if I am not mistaken, it
> shows that this decoder is not a simple one-in, one-out decoder, so that
> making it multithreaded will be more complicated than just adding the
> flag and using ff_thread_get_buffer/format.)
That is full FUD.
>
> - Andreas
>
> _______________________________________________
> 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".
>
_______________________________________________
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".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mjpegdec: add support for frame threading
2022-12-05 14:15 ` Andreas Rheinhardt
2022-12-05 14:28 ` Paul B Mahol
@ 2022-12-05 23:02 ` Timo Rothenpieler
2023-09-07 17:17 ` Paul B Mahol
1 sibling, 1 reply; 13+ messages in thread
From: Timo Rothenpieler @ 2022-12-05 23:02 UTC (permalink / raw)
To: ffmpeg-devel
On 05.12.2022 15:15, Andreas Rheinhardt wrote:
> Timo Rothenpieler:
>> In my tests, this lead to a notable speed increase with the amount
>> of threads used. Decoding a 720p sample gave the following results:
>>
>> 1 Thread: 1428 FPS
>> 2 Threads: 2501 FPS
>> 8 Threads: 7575 FPS
>> Automatic: 11326 FPS (On a 16 Core/32 Threads system)
>> ---
>> libavcodec/jpeglsdec.c | 2 +-
>> libavcodec/mjpegdec.c | 13 +++++++------
>> libavcodec/sp5xdec.c | 4 ++--
>> 3 files changed, 10 insertions(+), 9 deletions(-)
>>
>> diff --git a/libavcodec/jpeglsdec.c b/libavcodec/jpeglsdec.c
>> index 2e6d018ea6..c0642e8e30 100644
>> --- a/libavcodec/jpeglsdec.c
>> +++ b/libavcodec/jpeglsdec.c
>> @@ -559,7 +559,7 @@ const FFCodec ff_jpegls_decoder = {
>> .init = ff_mjpeg_decode_init,
>> .close = ff_mjpeg_decode_end,
>> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> - .p.capabilities = AV_CODEC_CAP_DR1,
>> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
>> FF_CODEC_CAP_SETS_PKT_DTS,
>> };
>> diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
>> index 9b7465abe7..d30d722398 100644
>> --- a/libavcodec/mjpegdec.c
>> +++ b/libavcodec/mjpegdec.c
>> @@ -54,6 +54,7 @@
>> #include "exif.h"
>> #include "bytestream.h"
>> #include "tiff_common.h"
>> +#include "thread.h"
>>
>>
>> static int init_default_huffman_tables(MJpegDecodeContext *s)
>> @@ -713,7 +714,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
>> s->avctx->pix_fmt,
>> AV_PIX_FMT_NONE,
>> };
>> - s->hwaccel_pix_fmt = ff_get_format(s->avctx, pix_fmts);
>> + s->hwaccel_pix_fmt = ff_thread_get_format(s->avctx, pix_fmts);
>> if (s->hwaccel_pix_fmt < 0)
>> return AVERROR(EINVAL);
>>
>> @@ -729,7 +730,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
>> }
>>
>> av_frame_unref(s->picture_ptr);
>> - if (ff_get_buffer(s->avctx, s->picture_ptr, AV_GET_BUFFER_FLAG_REF) < 0)
>> + if (ff_thread_get_buffer(s->avctx, s->picture_ptr, AV_GET_BUFFER_FLAG_REF) < 0)
>> return -1;
>> s->picture_ptr->pict_type = AV_PICTURE_TYPE_I;
>> s->picture_ptr->key_frame = 1;
>> @@ -2388,7 +2389,7 @@ static int mjpeg_get_packet(AVCodecContext *avctx)
>> int ret;
>>
>> av_packet_unref(s->pkt);
>> - ret = ff_decode_get_packet(avctx, s->pkt);
>> + ret = ff_thread_decode_get_packet(avctx, s->pkt);
>> if (ret < 0)
>> return ret;
>>
>> @@ -3020,7 +3021,7 @@ const FFCodec ff_mjpeg_decoder = {
>> .close = ff_mjpeg_decode_end,
>> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> .flush = decode_flush,
>> - .p.capabilities = AV_CODEC_CAP_DR1,
>> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> .p.max_lowres = 3,
>> .p.priv_class = &mjpegdec_class,
>> .p.profiles = NULL_IF_CONFIG_SMALL(ff_mjpeg_profiles),
>> @@ -3050,7 +3051,7 @@ const FFCodec ff_thp_decoder = {
>> .close = ff_mjpeg_decode_end,
>> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> .flush = decode_flush,
>> - .p.capabilities = AV_CODEC_CAP_DR1,
>> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> .p.max_lowres = 3,
>> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
>> FF_CODEC_CAP_SETS_PKT_DTS,
>> @@ -3068,7 +3069,7 @@ const FFCodec ff_smvjpeg_decoder = {
>> .close = ff_mjpeg_decode_end,
>> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> .flush = decode_flush,
>> - .p.capabilities = AV_CODEC_CAP_DR1,
>> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> .caps_internal = FF_CODEC_CAP_EXPORTS_CROPPING |
>> FF_CODEC_CAP_SETS_PKT_DTS | FF_CODEC_CAP_INIT_CLEANUP,
>> };
>> diff --git a/libavcodec/sp5xdec.c b/libavcodec/sp5xdec.c
>> index 394448c5a9..8b08dc672a 100644
>> --- a/libavcodec/sp5xdec.c
>> +++ b/libavcodec/sp5xdec.c
>> @@ -101,7 +101,7 @@ const FFCodec ff_sp5x_decoder = {
>> .init = ff_mjpeg_decode_init,
>> .close = ff_mjpeg_decode_end,
>> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> - .p.capabilities = AV_CODEC_CAP_DR1,
>> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> .p.max_lowres = 3,
>> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
>> FF_CODEC_CAP_SETS_PKT_DTS,
>> @@ -118,7 +118,7 @@ const FFCodec ff_amv_decoder = {
>> .close = ff_mjpeg_decode_end,
>> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> .p.max_lowres = 3,
>> - .p.capabilities = AV_CODEC_CAP_DR1,
>> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
>> FF_CODEC_CAP_SETS_PKT_DTS,
>> };
>
> Can you test the sample that Michael mentioned here:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/AS8PR01MB7944E105BE990A5D01EF89208FEF9@AS8PR01MB7944.eurprd01.prod.exchangelabs.com/?
> (I never got around to analyzing this, but if I am not mistaken, it
> shows that this decoder is not a simple one-in, one-out decoder, so that
> making it multithreaded will be more complicated than just adding the
> flag and using ff_thread_get_buffer/format.)
Assuming this is the right file:
https://trac.ffmpeg.org/attachment/ticket/1915/not_interleaved.avi
It does not decode for me at all, with or without this patch applied:
> [mjpeg @ 0x562e81877c80] No JPEG data found in image
> Error while decoding stream #0:0: Invalid data found when processing input
_______________________________________________
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".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] avcodec/thread: add support for frame threading receive_frame based decoders
2022-12-05 13:39 [FFmpeg-devel] [PATCH 1/2] avcodec/thread: add support for frame threading receive_frame based decoders Timo Rothenpieler
2022-12-05 13:39 ` [FFmpeg-devel] [PATCH 2/2] avcodec/mjpegdec: add support for frame threading Timo Rothenpieler
@ 2022-12-06 14:37 ` Anton Khirnov
2022-12-06 14:39 ` Timo Rothenpieler
1 sibling, 1 reply; 13+ messages in thread
From: Anton Khirnov @ 2022-12-06 14:37 UTC (permalink / raw)
To: FFmpeg development discussions and patches; +Cc: Timo Rothenpieler
Quoting Timo Rothenpieler (2022-12-05 14:39:37)
> This is fairly basic and makes a lot of assumptions, but it works
> for the most simple cases.
>
> For one, it only ever fetches exactly one packet per call to receive_frame.
> Right now it's impossible for there to ever be more than one, but the API
> allows for more, which might need handled in the future.
>
> It also basically translates the new API back to the old, since that's how
> the frame threading code operates. Which feels backwards in regards to
> the new API, but it was the path with least resistance in implementing this.
If it only supports one packet to one frame, then it goes against the
whole point of using the receive_frame API.
--
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-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] avcodec/thread: add support for frame threading receive_frame based decoders
2022-12-06 14:37 ` [FFmpeg-devel] [PATCH 1/2] avcodec/thread: add support for frame threading receive_frame based decoders Anton Khirnov
@ 2022-12-06 14:39 ` Timo Rothenpieler
2022-12-06 14:43 ` Anton Khirnov
0 siblings, 1 reply; 13+ messages in thread
From: Timo Rothenpieler @ 2022-12-06 14:39 UTC (permalink / raw)
To: ffmpeg-devel
On 06/12/2022 15:37, Anton Khirnov wrote:
> Quoting Timo Rothenpieler (2022-12-05 14:39:37)
>> This is fairly basic and makes a lot of assumptions, but it works
>> for the most simple cases.
>>
>> For one, it only ever fetches exactly one packet per call to receive_frame.
>> Right now it's impossible for there to ever be more than one, but the API
>> allows for more, which might need handled in the future.
>>
>> It also basically translates the new API back to the old, since that's how
>> the frame threading code operates. Which feels backwards in regards to
>> the new API, but it was the path with least resistance in implementing this.
>
> If it only supports one packet to one frame, then it goes against the
> whole point of using the receive_frame API.
Otherwise the entirety of pthread_frame.c would need rewritten from
scratch. It has that assumption coded into it.
It also raises question as to how it'd distribute those packets accross
threads.
Does it just try to read packets until it either runs out of ready
threads or encounters EAGAIN?
Or does it read until EAGAIN and then passes all those to the same threads?
_______________________________________________
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".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] avcodec/thread: add support for frame threading receive_frame based decoders
2022-12-06 14:39 ` Timo Rothenpieler
@ 2022-12-06 14:43 ` Anton Khirnov
2022-12-06 15:08 ` Timo Rothenpieler
0 siblings, 1 reply; 13+ messages in thread
From: Anton Khirnov @ 2022-12-06 14:43 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Quoting Timo Rothenpieler (2022-12-06 15:39:50)
> On 06/12/2022 15:37, Anton Khirnov wrote:
> > Quoting Timo Rothenpieler (2022-12-05 14:39:37)
> >> This is fairly basic and makes a lot of assumptions, but it works
> >> for the most simple cases.
> >>
> >> For one, it only ever fetches exactly one packet per call to receive_frame.
> >> Right now it's impossible for there to ever be more than one, but the API
> >> allows for more, which might need handled in the future.
> >>
> >> It also basically translates the new API back to the old, since that's how
> >> the frame threading code operates. Which feels backwards in regards to
> >> the new API, but it was the path with least resistance in implementing this.
> >
> > If it only supports one packet to one frame, then it goes against the
> > whole point of using the receive_frame API.
>
> Otherwise the entirety of pthread_frame.c would need rewritten from
> scratch. It has that assumption coded into it.
I told you on IRC I already have a mostly-finished branch that
implements threading with receive_frame(), so I don't really understand
what's the point of your writing this patch.
--
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-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] avcodec/thread: add support for frame threading receive_frame based decoders
2022-12-06 14:43 ` Anton Khirnov
@ 2022-12-06 15:08 ` Timo Rothenpieler
2022-12-06 16:00 ` Anton Khirnov
0 siblings, 1 reply; 13+ messages in thread
From: Timo Rothenpieler @ 2022-12-06 15:08 UTC (permalink / raw)
To: ffmpeg-devel
On 06/12/2022 15:43, Anton Khirnov wrote:
> Quoting Timo Rothenpieler (2022-12-06 15:39:50)
>> On 06/12/2022 15:37, Anton Khirnov wrote:
>>> Quoting Timo Rothenpieler (2022-12-05 14:39:37)
>>>> This is fairly basic and makes a lot of assumptions, but it works
>>>> for the most simple cases.
>>>>
>>>> For one, it only ever fetches exactly one packet per call to receive_frame.
>>>> Right now it's impossible for there to ever be more than one, but the API
>>>> allows for more, which might need handled in the future.
>>>>
>>>> It also basically translates the new API back to the old, since that's how
>>>> the frame threading code operates. Which feels backwards in regards to
>>>> the new API, but it was the path with least resistance in implementing this.
>>>
>>> If it only supports one packet to one frame, then it goes against the
>>> whole point of using the receive_frame API.
>>
>> Otherwise the entirety of pthread_frame.c would need rewritten from
>> scratch. It has that assumption coded into it.
>
> I told you on IRC I already have a mostly-finished branch that
> implements threading with receive_frame(), so I don't really understand
> what's the point of your writing this patch.
>
You said it wasn't even in a state to be tested.
Do you have a link to it? Happy to help finishing it up.
_______________________________________________
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".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] avcodec/thread: add support for frame threading receive_frame based decoders
2022-12-06 15:08 ` Timo Rothenpieler
@ 2022-12-06 16:00 ` Anton Khirnov
0 siblings, 0 replies; 13+ messages in thread
From: Anton Khirnov @ 2022-12-06 16:00 UTC (permalink / raw)
To: FFmpeg development discussions and patches
Quoting Timo Rothenpieler (2022-12-06 16:08:49)
> On 06/12/2022 15:43, Anton Khirnov wrote:
> > Quoting Timo Rothenpieler (2022-12-06 15:39:50)
> >> On 06/12/2022 15:37, Anton Khirnov wrote:
> >>> Quoting Timo Rothenpieler (2022-12-05 14:39:37)
> >>>> This is fairly basic and makes a lot of assumptions, but it works
> >>>> for the most simple cases.
> >>>>
> >>>> For one, it only ever fetches exactly one packet per call to receive_frame.
> >>>> Right now it's impossible for there to ever be more than one, but the API
> >>>> allows for more, which might need handled in the future.
> >>>>
> >>>> It also basically translates the new API back to the old, since that's how
> >>>> the frame threading code operates. Which feels backwards in regards to
> >>>> the new API, but it was the path with least resistance in implementing this.
> >>>
> >>> If it only supports one packet to one frame, then it goes against the
> >>> whole point of using the receive_frame API.
> >>
> >> Otherwise the entirety of pthread_frame.c would need rewritten from
> >> scratch. It has that assumption coded into it.
> >
> > I told you on IRC I already have a mostly-finished branch that
> > implements threading with receive_frame(), so I don't really understand
> > what's the point of your writing this patch.
> >
>
> You said it wasn't even in a state to be tested.
> Do you have a link to it? Happy to help finishing it up.
Sure, see branch 'thread_receive' in git://git.khirnov.net/libav
IIRC it was only missing some allocations for frames or packets in
AVCodecInternal.
--
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-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mjpegdec: add support for frame threading
2022-12-05 23:02 ` Timo Rothenpieler
@ 2023-09-07 17:17 ` Paul B Mahol
2023-09-07 17:28 ` Paul B Mahol
0 siblings, 1 reply; 13+ messages in thread
From: Paul B Mahol @ 2023-09-07 17:17 UTC (permalink / raw)
To: FFmpeg development discussions and patches
On Tue, Dec 6, 2022 at 12:02 AM Timo Rothenpieler <timo@rothenpieler.org>
wrote:
> On 05.12.2022 15:15, Andreas Rheinhardt wrote:
> > Timo Rothenpieler:
> >> In my tests, this lead to a notable speed increase with the amount
> >> of threads used. Decoding a 720p sample gave the following results:
> >>
> >> 1 Thread: 1428 FPS
> >> 2 Threads: 2501 FPS
> >> 8 Threads: 7575 FPS
> >> Automatic: 11326 FPS (On a 16 Core/32 Threads system)
> >> ---
> >> libavcodec/jpeglsdec.c | 2 +-
> >> libavcodec/mjpegdec.c | 13 +++++++------
> >> libavcodec/sp5xdec.c | 4 ++--
> >> 3 files changed, 10 insertions(+), 9 deletions(-)
> >>
>
I made almost same patch, can you apply this one?
Thanks.
> >> diff --git a/libavcodec/jpeglsdec.c b/libavcodec/jpeglsdec.c
> >> index 2e6d018ea6..c0642e8e30 100644
> >> --- a/libavcodec/jpeglsdec.c
> >> +++ b/libavcodec/jpeglsdec.c
> >> @@ -559,7 +559,7 @@ const FFCodec ff_jpegls_decoder = {
> >> .init = ff_mjpeg_decode_init,
> >> .close = ff_mjpeg_decode_end,
> >> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
> >> - .p.capabilities = AV_CODEC_CAP_DR1,
> >> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
> >> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
> >> FF_CODEC_CAP_SETS_PKT_DTS,
> >> };
> >> diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> >> index 9b7465abe7..d30d722398 100644
> >> --- a/libavcodec/mjpegdec.c
> >> +++ b/libavcodec/mjpegdec.c
> >> @@ -54,6 +54,7 @@
> >> #include "exif.h"
> >> #include "bytestream.h"
> >> #include "tiff_common.h"
> >> +#include "thread.h"
> >>
> >>
> >> static int init_default_huffman_tables(MJpegDecodeContext *s)
> >> @@ -713,7 +714,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
> >> s->avctx->pix_fmt,
> >> AV_PIX_FMT_NONE,
> >> };
> >> - s->hwaccel_pix_fmt = ff_get_format(s->avctx, pix_fmts);
> >> + s->hwaccel_pix_fmt = ff_thread_get_format(s->avctx,
> pix_fmts);
> >> if (s->hwaccel_pix_fmt < 0)
> >> return AVERROR(EINVAL);
> >>
> >> @@ -729,7 +730,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
> >> }
> >>
> >> av_frame_unref(s->picture_ptr);
> >> - if (ff_get_buffer(s->avctx, s->picture_ptr,
> AV_GET_BUFFER_FLAG_REF) < 0)
> >> + if (ff_thread_get_buffer(s->avctx, s->picture_ptr,
> AV_GET_BUFFER_FLAG_REF) < 0)
> >> return -1;
> >> s->picture_ptr->pict_type = AV_PICTURE_TYPE_I;
> >> s->picture_ptr->key_frame = 1;
> >> @@ -2388,7 +2389,7 @@ static int mjpeg_get_packet(AVCodecContext *avctx)
> >> int ret;
> >>
> >> av_packet_unref(s->pkt);
> >> - ret = ff_decode_get_packet(avctx, s->pkt);
> >> + ret = ff_thread_decode_get_packet(avctx, s->pkt);
> >> if (ret < 0)
> >> return ret;
> >>
> >> @@ -3020,7 +3021,7 @@ const FFCodec ff_mjpeg_decoder = {
> >> .close = ff_mjpeg_decode_end,
> >> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
> >> .flush = decode_flush,
> >> - .p.capabilities = AV_CODEC_CAP_DR1,
> >> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
> >> .p.max_lowres = 3,
> >> .p.priv_class = &mjpegdec_class,
> >> .p.profiles = NULL_IF_CONFIG_SMALL(ff_mjpeg_profiles),
> >> @@ -3050,7 +3051,7 @@ const FFCodec ff_thp_decoder = {
> >> .close = ff_mjpeg_decode_end,
> >> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
> >> .flush = decode_flush,
> >> - .p.capabilities = AV_CODEC_CAP_DR1,
> >> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
> >> .p.max_lowres = 3,
> >> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
> >> FF_CODEC_CAP_SETS_PKT_DTS,
> >> @@ -3068,7 +3069,7 @@ const FFCodec ff_smvjpeg_decoder = {
> >> .close = ff_mjpeg_decode_end,
> >> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
> >> .flush = decode_flush,
> >> - .p.capabilities = AV_CODEC_CAP_DR1,
> >> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
> >> .caps_internal = FF_CODEC_CAP_EXPORTS_CROPPING |
> >> FF_CODEC_CAP_SETS_PKT_DTS |
> FF_CODEC_CAP_INIT_CLEANUP,
> >> };
> >> diff --git a/libavcodec/sp5xdec.c b/libavcodec/sp5xdec.c
> >> index 394448c5a9..8b08dc672a 100644
> >> --- a/libavcodec/sp5xdec.c
> >> +++ b/libavcodec/sp5xdec.c
> >> @@ -101,7 +101,7 @@ const FFCodec ff_sp5x_decoder = {
> >> .init = ff_mjpeg_decode_init,
> >> .close = ff_mjpeg_decode_end,
> >> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
> >> - .p.capabilities = AV_CODEC_CAP_DR1,
> >> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
> >> .p.max_lowres = 3,
> >> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
> >> FF_CODEC_CAP_SETS_PKT_DTS,
> >> @@ -118,7 +118,7 @@ const FFCodec ff_amv_decoder = {
> >> .close = ff_mjpeg_decode_end,
> >> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
> >> .p.max_lowres = 3,
> >> - .p.capabilities = AV_CODEC_CAP_DR1,
> >> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
> >> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
> >> FF_CODEC_CAP_SETS_PKT_DTS,
> >> };
> >
> > Can you test the sample that Michael mentioned here:
> >
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/AS8PR01MB7944E105BE990A5D01EF89208FEF9@AS8PR01MB7944.eurprd01.prod.exchangelabs.com/
> ?
> > (I never got around to analyzing this, but if I am not mistaken, it
> > shows that this decoder is not a simple one-in, one-out decoder, so that
> > making it multithreaded will be more complicated than just adding the
> > flag and using ff_thread_get_buffer/format.)
>
> Assuming this is the right file:
> https://trac.ffmpeg.org/attachment/ticket/1915/not_interleaved.avi
>
> It does not decode for me at all, with or without this patch applied:
>
> > [mjpeg @ 0x562e81877c80] No JPEG data found in image
> > Error while decoding stream #0:0: Invalid data found when processing
> input
>
>
> _______________________________________________
> 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".
>
_______________________________________________
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".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mjpegdec: add support for frame threading
2023-09-07 17:17 ` Paul B Mahol
@ 2023-09-07 17:28 ` Paul B Mahol
0 siblings, 0 replies; 13+ messages in thread
From: Paul B Mahol @ 2023-09-07 17:28 UTC (permalink / raw)
To: FFmpeg development discussions and patches
On Thu, Sep 7, 2023 at 7:17 PM Paul B Mahol <onemda@gmail.com> wrote:
>
>
> On Tue, Dec 6, 2022 at 12:02 AM Timo Rothenpieler <timo@rothenpieler.org>
> wrote:
>
>> On 05.12.2022 15:15, Andreas Rheinhardt wrote:
>> > Timo Rothenpieler:
>> >> In my tests, this lead to a notable speed increase with the amount
>> >> of threads used. Decoding a 720p sample gave the following results:
>> >>
>> >> 1 Thread: 1428 FPS
>> >> 2 Threads: 2501 FPS
>> >> 8 Threads: 7575 FPS
>> >> Automatic: 11326 FPS (On a 16 Core/32 Threads system)
>> >> ---
>> >> libavcodec/jpeglsdec.c | 2 +-
>> >> libavcodec/mjpegdec.c | 13 +++++++------
>> >> libavcodec/sp5xdec.c | 4 ++--
>> >> 3 files changed, 10 insertions(+), 9 deletions(-)
>> >>
>>
>
> I made almost same patch, can you apply this one?
> Thanks.
>
Actually, on better look, this one is more complicated, and does not apply
anymore.
So ignore my 'request'.
>
>
>> >> diff --git a/libavcodec/jpeglsdec.c b/libavcodec/jpeglsdec.c
>> >> index 2e6d018ea6..c0642e8e30 100644
>> >> --- a/libavcodec/jpeglsdec.c
>> >> +++ b/libavcodec/jpeglsdec.c
>> >> @@ -559,7 +559,7 @@ const FFCodec ff_jpegls_decoder = {
>> >> .init = ff_mjpeg_decode_init,
>> >> .close = ff_mjpeg_decode_end,
>> >> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> >> - .p.capabilities = AV_CODEC_CAP_DR1,
>> >> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> >> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
>> >> FF_CODEC_CAP_SETS_PKT_DTS,
>> >> };
>> >> diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
>> >> index 9b7465abe7..d30d722398 100644
>> >> --- a/libavcodec/mjpegdec.c
>> >> +++ b/libavcodec/mjpegdec.c
>> >> @@ -54,6 +54,7 @@
>> >> #include "exif.h"
>> >> #include "bytestream.h"
>> >> #include "tiff_common.h"
>> >> +#include "thread.h"
>> >>
>> >>
>> >> static int init_default_huffman_tables(MJpegDecodeContext *s)
>> >> @@ -713,7 +714,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
>> >> s->avctx->pix_fmt,
>> >> AV_PIX_FMT_NONE,
>> >> };
>> >> - s->hwaccel_pix_fmt = ff_get_format(s->avctx, pix_fmts);
>> >> + s->hwaccel_pix_fmt = ff_thread_get_format(s->avctx,
>> pix_fmts);
>> >> if (s->hwaccel_pix_fmt < 0)
>> >> return AVERROR(EINVAL);
>> >>
>> >> @@ -729,7 +730,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
>> >> }
>> >>
>> >> av_frame_unref(s->picture_ptr);
>> >> - if (ff_get_buffer(s->avctx, s->picture_ptr,
>> AV_GET_BUFFER_FLAG_REF) < 0)
>> >> + if (ff_thread_get_buffer(s->avctx, s->picture_ptr,
>> AV_GET_BUFFER_FLAG_REF) < 0)
>> >> return -1;
>> >> s->picture_ptr->pict_type = AV_PICTURE_TYPE_I;
>> >> s->picture_ptr->key_frame = 1;
>> >> @@ -2388,7 +2389,7 @@ static int mjpeg_get_packet(AVCodecContext
>> *avctx)
>> >> int ret;
>> >>
>> >> av_packet_unref(s->pkt);
>> >> - ret = ff_decode_get_packet(avctx, s->pkt);
>> >> + ret = ff_thread_decode_get_packet(avctx, s->pkt);
>> >> if (ret < 0)
>> >> return ret;
>> >>
>> >> @@ -3020,7 +3021,7 @@ const FFCodec ff_mjpeg_decoder = {
>> >> .close = ff_mjpeg_decode_end,
>> >> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> >> .flush = decode_flush,
>> >> - .p.capabilities = AV_CODEC_CAP_DR1,
>> >> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> >> .p.max_lowres = 3,
>> >> .p.priv_class = &mjpegdec_class,
>> >> .p.profiles = NULL_IF_CONFIG_SMALL(ff_mjpeg_profiles),
>> >> @@ -3050,7 +3051,7 @@ const FFCodec ff_thp_decoder = {
>> >> .close = ff_mjpeg_decode_end,
>> >> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> >> .flush = decode_flush,
>> >> - .p.capabilities = AV_CODEC_CAP_DR1,
>> >> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> >> .p.max_lowres = 3,
>> >> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
>> >> FF_CODEC_CAP_SETS_PKT_DTS,
>> >> @@ -3068,7 +3069,7 @@ const FFCodec ff_smvjpeg_decoder = {
>> >> .close = ff_mjpeg_decode_end,
>> >> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> >> .flush = decode_flush,
>> >> - .p.capabilities = AV_CODEC_CAP_DR1,
>> >> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> >> .caps_internal = FF_CODEC_CAP_EXPORTS_CROPPING |
>> >> FF_CODEC_CAP_SETS_PKT_DTS |
>> FF_CODEC_CAP_INIT_CLEANUP,
>> >> };
>> >> diff --git a/libavcodec/sp5xdec.c b/libavcodec/sp5xdec.c
>> >> index 394448c5a9..8b08dc672a 100644
>> >> --- a/libavcodec/sp5xdec.c
>> >> +++ b/libavcodec/sp5xdec.c
>> >> @@ -101,7 +101,7 @@ const FFCodec ff_sp5x_decoder = {
>> >> .init = ff_mjpeg_decode_init,
>> >> .close = ff_mjpeg_decode_end,
>> >> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> >> - .p.capabilities = AV_CODEC_CAP_DR1,
>> >> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> >> .p.max_lowres = 3,
>> >> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
>> >> FF_CODEC_CAP_SETS_PKT_DTS,
>> >> @@ -118,7 +118,7 @@ const FFCodec ff_amv_decoder = {
>> >> .close = ff_mjpeg_decode_end,
>> >> FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
>> >> .p.max_lowres = 3,
>> >> - .p.capabilities = AV_CODEC_CAP_DR1,
>> >> + .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
>> >> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
>> >> FF_CODEC_CAP_SETS_PKT_DTS,
>> >> };
>> >
>> > Can you test the sample that Michael mentioned here:
>> >
>> https://patchwork.ffmpeg.org/project/ffmpeg/patch/AS8PR01MB7944E105BE990A5D01EF89208FEF9@AS8PR01MB7944.eurprd01.prod.exchangelabs.com/
>> ?
>> > (I never got around to analyzing this, but if I am not mistaken, it
>> > shows that this decoder is not a simple one-in, one-out decoder, so that
>> > making it multithreaded will be more complicated than just adding the
>> > flag and using ff_thread_get_buffer/format.)
>>
>> Assuming this is the right file:
>> https://trac.ffmpeg.org/attachment/ticket/1915/not_interleaved.avi
>>
>> It does not decode for me at all, with or without this patch applied:
>>
>> > [mjpeg @ 0x562e81877c80] No JPEG data found in image
>> > Error while decoding stream #0:0: Invalid data found when processing
>> input
>>
>>
>> _______________________________________________
>> 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".
>>
>
_______________________________________________
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".
^ permalink raw reply [flat|nested] 13+ messages in thread
* [FFmpeg-devel] [PATCH 2/2] avcodec/mjpegdec: add support for frame threading
2022-12-07 11:43 [FFmpeg-devel] [PATCH 1/2] lavc: convert frame threading to the receive_frame() pattern Timo Rothenpieler
@ 2022-12-07 11:43 ` Timo Rothenpieler
0 siblings, 0 replies; 13+ messages in thread
From: Timo Rothenpieler @ 2022-12-07 11:43 UTC (permalink / raw)
To: ffmpeg-devel; +Cc: Timo Rothenpieler
In my tests, this lead to a notable speed increase with the amount
of threads used. Decoding a 720p sample gave the following results:
1 Thread: 1428 FPS
2 Threads: 2501 FPS
8 Threads: 7575 FPS
Automatic: 11326 FPS (On a 16 Core/32 Threads system)
---
libavcodec/jpeglsdec.c | 2 +-
libavcodec/mjpegdec.c | 11 ++++++-----
libavcodec/sp5xdec.c | 4 ++--
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/libavcodec/jpeglsdec.c b/libavcodec/jpeglsdec.c
index 2e6d018ea6..c0642e8e30 100644
--- a/libavcodec/jpeglsdec.c
+++ b/libavcodec/jpeglsdec.c
@@ -559,7 +559,7 @@ const FFCodec ff_jpegls_decoder = {
.init = ff_mjpeg_decode_init,
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
- .p.capabilities = AV_CODEC_CAP_DR1,
+ .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
FF_CODEC_CAP_SETS_PKT_DTS,
};
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 9b7465abe7..54605e04cb 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -54,6 +54,7 @@
#include "exif.h"
#include "bytestream.h"
#include "tiff_common.h"
+#include "thread.h"
static int init_default_huffman_tables(MJpegDecodeContext *s)
@@ -713,7 +714,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
s->avctx->pix_fmt,
AV_PIX_FMT_NONE,
};
- s->hwaccel_pix_fmt = ff_get_format(s->avctx, pix_fmts);
+ s->hwaccel_pix_fmt = ff_thread_get_format(s->avctx, pix_fmts);
if (s->hwaccel_pix_fmt < 0)
return AVERROR(EINVAL);
@@ -729,7 +730,7 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
}
av_frame_unref(s->picture_ptr);
- if (ff_get_buffer(s->avctx, s->picture_ptr, AV_GET_BUFFER_FLAG_REF) < 0)
+ if (ff_thread_get_buffer(s->avctx, s->picture_ptr, AV_GET_BUFFER_FLAG_REF) < 0)
return -1;
s->picture_ptr->pict_type = AV_PICTURE_TYPE_I;
s->picture_ptr->key_frame = 1;
@@ -3020,7 +3021,7 @@ const FFCodec ff_mjpeg_decoder = {
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
.flush = decode_flush,
- .p.capabilities = AV_CODEC_CAP_DR1,
+ .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.p.max_lowres = 3,
.p.priv_class = &mjpegdec_class,
.p.profiles = NULL_IF_CONFIG_SMALL(ff_mjpeg_profiles),
@@ -3050,7 +3051,7 @@ const FFCodec ff_thp_decoder = {
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
.flush = decode_flush,
- .p.capabilities = AV_CODEC_CAP_DR1,
+ .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.p.max_lowres = 3,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
FF_CODEC_CAP_SETS_PKT_DTS,
@@ -3068,7 +3069,7 @@ const FFCodec ff_smvjpeg_decoder = {
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
.flush = decode_flush,
- .p.capabilities = AV_CODEC_CAP_DR1,
+ .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.caps_internal = FF_CODEC_CAP_EXPORTS_CROPPING |
FF_CODEC_CAP_SETS_PKT_DTS | FF_CODEC_CAP_INIT_CLEANUP,
};
diff --git a/libavcodec/sp5xdec.c b/libavcodec/sp5xdec.c
index 394448c5a9..8b08dc672a 100644
--- a/libavcodec/sp5xdec.c
+++ b/libavcodec/sp5xdec.c
@@ -101,7 +101,7 @@ const FFCodec ff_sp5x_decoder = {
.init = ff_mjpeg_decode_init,
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
- .p.capabilities = AV_CODEC_CAP_DR1,
+ .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.p.max_lowres = 3,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
FF_CODEC_CAP_SETS_PKT_DTS,
@@ -118,7 +118,7 @@ const FFCodec ff_amv_decoder = {
.close = ff_mjpeg_decode_end,
FF_CODEC_RECEIVE_FRAME_CB(ff_mjpeg_receive_frame),
.p.max_lowres = 3,
- .p.capabilities = AV_CODEC_CAP_DR1,
+ .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP |
FF_CODEC_CAP_SETS_PKT_DTS,
};
--
2.34.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".
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2023-09-07 17:20 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-05 13:39 [FFmpeg-devel] [PATCH 1/2] avcodec/thread: add support for frame threading receive_frame based decoders Timo Rothenpieler
2022-12-05 13:39 ` [FFmpeg-devel] [PATCH 2/2] avcodec/mjpegdec: add support for frame threading Timo Rothenpieler
2022-12-05 14:15 ` Andreas Rheinhardt
2022-12-05 14:28 ` Paul B Mahol
2022-12-05 23:02 ` Timo Rothenpieler
2023-09-07 17:17 ` Paul B Mahol
2023-09-07 17:28 ` Paul B Mahol
2022-12-06 14:37 ` [FFmpeg-devel] [PATCH 1/2] avcodec/thread: add support for frame threading receive_frame based decoders Anton Khirnov
2022-12-06 14:39 ` Timo Rothenpieler
2022-12-06 14:43 ` Anton Khirnov
2022-12-06 15:08 ` Timo Rothenpieler
2022-12-06 16:00 ` Anton Khirnov
2022-12-07 11:43 [FFmpeg-devel] [PATCH 1/2] lavc: convert frame threading to the receive_frame() pattern Timo Rothenpieler
2022-12-07 11:43 ` [FFmpeg-devel] [PATCH 2/2] avcodec/mjpegdec: add support for frame threading Timo Rothenpieler
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