From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 7B32E49A20 for ; Mon, 26 Feb 2024 15:54:50 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id F357368C825; Mon, 26 Feb 2024 17:54:43 +0200 (EET) Received: from shout01.mail.de (shout01.mail.de [62.201.172.24]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 07FDD68C7F8 for ; Mon, 26 Feb 2024 17:54:35 +0200 (EET) Received: from postfix01.mail.de (postfix01.bt.mail.de [10.0.121.125]) by shout01.mail.de (Postfix) with ESMTP id 7563F2409F3 for ; Mon, 26 Feb 2024 16:54:34 +0100 (CET) Received: from smtp01.mail.de (smtp01.bt.mail.de [10.0.121.211]) by postfix01.mail.de (Postfix) with ESMTP id 5D809801CB for ; Mon, 26 Feb 2024 16:54:34 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp01.mail.de (Postfix) with ESMTPSA id 2D5BF240D02 for ; Mon, 26 Feb 2024 16:54:34 +0100 (CET) Message-ID: Date: Mon, 26 Feb 2024 16:54:33 +0100 MIME-Version: 1.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20240205194142.37049-1-thilo.borgmann@mail.de> <20240205194142.37049-3-thilo.borgmann@mail.de> In-Reply-To: X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-purgate-size: 4431 X-purgate-ID: 154282::1708962874-CADB0670-95A19DF4/0/0 Subject: Re: [FFmpeg-devel] [PATCH v10 2/5] libavcodec/webp: add support for animated WebP X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Thilo Borgmann via ffmpeg-devel Reply-To: FFmpeg development discussions and patches Cc: Thilo Borgmann Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Hi, Am 19.02.24 um 17:50 schrieb Andreas Rheinhardt: > Thilo Borgmann via ffmpeg-devel: >> From: Josef Zlomek >> >> Fixes: 4907 >> >> Adds support for decoding of animated WebP. >> >> The WebP decoder adds the animation related features according to the specs: >> https://developers.google.com/speed/webp/docs/riff_container#animation >> The frames of the animation may be smaller than the image canvas. >> Therefore, the frame is decoded to a temporary frame, >> then it is blended into the canvas, the canvas is copied to the output frame, >> and finally the frame is disposed from the canvas. >> >> The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported. >> The background color is specified only as BGRA in the WebP file >> so it is converted to YUVA if YUV formats are output. >> >> Signed-off-by: Josef Zlomek >> --- >> Changelog | 1 + >> libavcodec/codec_desc.c | 3 +- >> libavcodec/version.h | 2 +- >> libavcodec/webp.c | 704 +++++++++++++++++++++++++++++++++++++--- >> 4 files changed, 654 insertions(+), 56 deletions(-) >> > >> +static int webp_decode_frame(AVCodecContext *avctx, AVFrame *p, >> + int *got_frame, AVPacket *avpkt) >> +{ >> + WebPContext *s = avctx->priv_data; >> + AVFrame *canvas = s->canvas_frame.f; >> + int ret; >> + int key_frame = avpkt->flags & AV_PKT_FLAG_KEY; >> + >> + *got_frame = 0; >> + >> + if (key_frame) { >> + // The canvas is passed from one thread to another in a sequence >> + // starting with a key frame followed by non-key frames. >> + // The key frame reports progress 1, >> + // the N-th non-key frame awaits progress N = s->await_progress >> + // and reports progress N + 1. >> + s->await_progress = 0; >> + } >> + >> + // reset the frame params >> + s->anmf_flags = 0; >> + s->width = 0; >> + s->height = 0; >> + s->pos_x = 0; >> + s->pos_y = 0; >> + s->has_alpha = 0; >> + >> + ret = webp_decode_frame_common(avctx, avpkt->data, avpkt->size, got_frame, key_frame); >> + if (ret < 0) >> + goto end; >> + >> + if (s->vp8x_flags & VP8X_FLAG_ANIMATION) { >> + // VP8 decoder might have changed the width and height of the frame >> + AVFrame *frame = s->frame; >> + ret = av_frame_copy_props(canvas, frame); >> + if (ret < 0) >> + return ret; >> + >> + ret = ff_set_dimensions(s->avctx, canvas->width, canvas->height); >> + if (ret < 0) >> + return ret; >> + >> + s->avctx->pix_fmt = canvas->format; >> + } >> + >> + ff_thread_finish_setup(s->avctx); > > 1. Up until now, when decoding a series of stand-alone WebP pictures, > the multiple decoder instances don't wait for each other (because the > WebP decoder had no update_thread_context callback). You added such a > callback and now you are calling it after the main picture has already > been decoded, effectively serializing everything. You can test this for > yourself: Create lots of files via ffmpeg -i -c:v libwebp -f > webp%d.webp and decode them (don't use -stream_loop on a single input > picture, as this will flush the decoder after every single picture, so > that everything is always serialized). > 2. To fix this, ff_thread_finish_setup() needs to be called as soon as > possible. This means that you have to abandon the approach of letting > the inner VP8 decoder set the frame dimensions and then overwriting them > again in the WebP decoder. so I tried to move the ff_thread_finish_setup() call and avoid updating the AVCodecContext after decoding. With the integrated decoder like here, ff_vp8_decode_frame() writes into the AVCodecContext while decoding, so ff_thread_finish_setup() can only be called afterwards -> quasi sequentially. I do see decoding speed for many files at once dropping from 100x to 16x compared to master. With the decoder decoupled, I can actually move ff_thread_finish_setup() before send_packet() (in contrast to v9) -> next thread can start before decoding the frame. I don't see a penalty with that way on decoding many files at once compared to master, as expected. Is that reason enough to actually decouple the vp8 decoder? Thanks, Thilo _______________________________________________ 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".