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 E026648F90 for ; Tue, 30 Jan 2024 18:39:20 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id CFDEB68D0B0; Tue, 30 Jan 2024 20:39:16 +0200 (EET) Received: from shout01.mail.de (shout01.mail.de [62.201.172.24]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id B92DC68CEFD for ; Tue, 30 Jan 2024 20:39:10 +0200 (EET) Received: from postfix01.mail.de (postfix01.bt.mail.de [10.0.121.125]) by shout01.mail.de (Postfix) with ESMTP id 7EEC5240B98 for ; Tue, 30 Jan 2024 19:39:09 +0100 (CET) Received: from smtp01.mail.de (smtp04.bt.mail.de [10.0.121.214]) by postfix01.mail.de (Postfix) with ESMTP id 66B1280298 for ; Tue, 30 Jan 2024 19:39:09 +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 BED9D24054B for ; Tue, 30 Jan 2024 19:39:07 +0100 (CET) Message-ID: <18fe4a45-06f6-48b9-9c2e-34ce2a48a108@mail.de> Date: Tue, 30 Jan 2024 19:39:07 +0100 MIME-Version: 1.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20231231123018.59035-1-thilo.borgmann@mail.de> <20231231123018.59035-3-thilo.borgmann@mail.de> <170617704310.8914.705271194770221831@lain.khirnov.net> <4ae8bd17-1589-4a7f-93fc-db7db53c33c5@mail.de> <170643776251.8914.9919833129719060471@lain.khirnov.net> In-Reply-To: <170643776251.8914.9919833129719060471@lain.khirnov.net> 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: 1758 X-purgate-ID: 154282::1706639948-057EB338-3DC46305/0/0 Subject: Re: [FFmpeg-devel] [PATCH v9 2/6] avcodec/webp: separate VP8 decoding 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: Am 28.01.24 um 11:29 schrieb Anton Khirnov: > Quoting Thilo Borgmann via ffmpeg-devel (2024-01-25 16:39:19) >> Am 25.01.24 um 11:04 schrieb Anton Khirnov: >>> Quoting Thilo Borgmann via ffmpeg-devel (2023-12-31 13:30:14) >>>> --- >>>> libavcodec/webp.c | 50 +++++++++++++++++++++++++++++++++++++++++------ >>>> 1 file changed, 44 insertions(+), 6 deletions(-) >>>> >>>> diff --git a/libavcodec/webp.c b/libavcodec/webp.c >>>> index 4fd107aa0c..58a20b73da 100644 >>>> --- a/libavcodec/webp.c >>>> +++ b/libavcodec/webp.c >>>> @@ -194,6 +194,7 @@ typedef struct WebPContext { >>>> AVFrame *alpha_frame; /* AVFrame for alpha data decompressed from VP8L */ >>>> AVPacket *pkt; /* AVPacket to be passed to the underlying VP8 decoder */ >>>> AVCodecContext *avctx; /* parent AVCodecContext */ >>>> + AVCodecContext *avctx_vp8; /* wrapper context for VP8 decoder */ >>> >>> Nested codec contexts are in general highly undesirable and should be >>> avoided whenever possible. >> >> AFAICT we do it that way in the other codecs as well (cri, ftr, imm5, >> tdsc, tiff). So what do you suggest to do to avoid having it nested? > > Integrating the two decoders directly, as is done now. > > With nesting it is very tricky to handle all the corner cases properly, > especially passing through all the options to the innner decoder, like > direct rendering, other user callbacks, etc. It should only be done as a > last resort and there should be a strong argument to do it this way. IIUC that was what the patch still did some some versions ago. It brought us the data races in animated files, decoupling the decoder solving the issue. -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".