* [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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ messages in thread
end of thread, other threads:[~2023-09-07 17:20 UTC | newest] Thread overview: 12+ 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
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