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 44D8946B50 for ; Mon, 3 Jul 2023 19:24:28 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D611468BE1B; Mon, 3 Jul 2023 22:24:25 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id D083668C520 for ; Mon, 3 Jul 2023 22:24:18 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 5EF1B2404EC for ; Mon, 3 Jul 2023 21:24:18 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ho8tTeKQ0vvg for ; Mon, 3 Jul 2023 21:24:17 +0200 (CEST) Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 9AC272404EA for ; Mon, 3 Jul 2023 21:24:17 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id 20AA91601B2; Mon, 3 Jul 2023 21:24:16 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: =?utf-8?q?=3CGV1P250MB0737A11936371A3FDCA7CE6E8F20A=40GV1P250MB?= =?utf-8?q?0737=2EEURP250=2EPROD=2EOUTLOOK=2ECOM=3E?= References: <20230620141608.31759-1-anton@khirnov.net> <20230620141608.31759-4-anton@khirnov.net> =?utf-8?q?=3CGV1P250MB0737A11936?= =?utf-8?q?371A3FDCA7CE6E8F20A=40GV1P250MB0737=2EEURP250=2EPROD=2EOUTLOOK=2E?= =?utf-8?q?COM=3E?= Mail-Followup-To: FFmpeg development discussions and patches Date: Mon, 03 Jul 2023 21:24:16 +0200 Message-ID: <168841225609.542.11783738741726137438@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 4/9] lavc: add generic-decode-layer private data 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: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Quoting Andreas Rheinhardt (2023-06-24 21:34:58) > > diff --git a/libavcodec/internal.h b/libavcodec/internal.h > > index dceae182c0..b672092ac4 100644 > > --- a/libavcodec/internal.h > > +++ b/libavcodec/internal.h > > @@ -49,7 +49,14 @@ > > # define STRIDE_ALIGN 8 > > #endif > > > > +typedef struct DecodeContext DecodeContext; > > + > > typedef struct AVCodecInternal { > > + /** > > + * Generic decoding private data. > > + */ > > + DecodeContext *d; > > This approach has the downside of adding unnecessary indirecations; it > furthermore adds pointers to DecodeContext and EncodeContext to > AVCodecInternal, as if both could be valid at the same time. > > The above could be overcome by using the typical approach to access > these extra fields, as is used for FFStream etc. > > Furthermore, I do not really think that is worth it: The number of > fields affected by it are just so small. Has encoder code ever tried to > set nb_draining_errors? True, for decoding there are currently very few fields. But there are many more that are encoding-only - I am not handling more of them in this set because some of them are not trivial and I did not want to make this patchset overly large, as its point is fixing the FATE test in 9/9. And I belive there is a strong case for hiding generic-layer private state from individual decoders/encoders, as it is prone to being misunderstood and misused (e.g. AVCodecInternal.draining is currently used in ways it most likely should not be). Since the overhead of having a private decode context in addition to a private encode context is very small, I prefer adding it now, at least for consistency. Otherwise I'd have to add a shared encode-decode context, which would be about the same amount of code. -- 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".