Attached.
Together with previous patch "Less CPU use in hwaccel MJPEG decoding"
the hwaccel mjpeg decoding uses about 90% less cpu than before.
>From 5960e16ae7561c6c6ad982c90f4e6ea1d30df91b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Llu=C3=ADs=20Batlle=20i=20Rossell?= <vi...@viric.name>
Date: Sun, 18 Aug 2024 14:14:50 +0200
Subject: [PATCH 2/2] Skip parsing of hwaccel mjpeg after decoding
This avoids completely the heaviest cpu work, find_marker, in case of
hwaccel.
---
libavcodec/mjpegdec.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 43583c1ccf..b835162fcd 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1774,15 +1774,28 @@ next_field:
if (s->avctx->hwaccel) {
int bytes_to_start = get_bits_count(&s->gb) / 8;
+ int bytes_left = s->raw_scan_buffer_size - bytes_to_start;
av_assert0(bytes_to_start >= 0 &&
s->raw_scan_buffer_size >= bytes_to_start);
ret = FF_HW_CALL(s->avctx, decode_slice,
s->raw_scan_buffer + bytes_to_start,
- s->raw_scan_buffer_size - bytes_to_start);
+ bytes_left);
if (ret < 0)
return ret;
+ /* The raw_scan_buffer includes all until end of jfif,
+ * so we can skip until 0xFF EOI, to avoid find_markers.
+ * Due to alignment, there can be multiple padding 0x00 at the end. */
+ for(int i = bytes_left - 9; i <= bytes_left - 2; ++i) {
+ const uint8_t *ptr = s->raw_scan_buffer + bytes_to_start + i;
+ if (i > 0 && ptr[0] == 0xff && ptr[1] == EOI) {
+ skip_bits(&s->gb, 8 * i);
+ av_log(s->avctx, AV_LOG_DEBUG,
+ "Skipping up to end EOI after hwaccel decode\n");
+ break;
+ }
+ }
} else if (s->lossless) {
av_assert0(s->picture_ptr == s->picture);
if (CONFIG_JPEGLS_DECODER && s->ls) {
--
2.44.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-requ...@ffmpeg.org with subject "unsubscribe".
