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 CB21F4C3BA for ; Fri, 26 Jul 2024 08:43:51 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0D3E568D68B; Fri, 26 Jul 2024 11:43:48 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id EB41A68D63B for ; Fri, 26 Jul 2024 11:43:40 +0300 (EEST) Authentication-Results: mail0.khirnov.net; dkim=pass (2048-bit key; unprotected) header.d=khirnov.net header.i=@khirnov.net header.a=rsa-sha256 header.s=mail header.b=iSwep9JJ; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 988C1240DB7; Fri, 26 Jul 2024 10:43:40 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id raqi7ckieQ3o; Fri, 26 Jul 2024 10:43:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1721983419; bh=Gsg/6hlaPXPNJsTIHj5zNRbdv8APO+kLi291REpaGy0=; h=Subject:From:To:Cc:In-Reply-To:References:Date:From; b=iSwep9JJmTgsykT/HvZvR9JBGzVBr+sGJaCutxnMSBk6QiegN2A+uz0rNvTebwLp9 /Y/TRhuHzWJ/Qa+z1FFqN9E/cXT5tZvRXnU1u+LsmQVCSkJMQYBCEj1OzvnThWaXCM 0gSGSDS4rWJsv0yO8a9SYT9jxlGIcp/ofHA/Ps8p17J6s1MtuvUIT/c5VIhkWVU005 UzM56qlAX2qTGMGLz0XE+185qLo0gzbOzL9nGKOwbKgA8qvowCen2s/DeeaiIlsiNq cMKELv9vyRw8UKPYWT+lGwl69Z4Wna3dK/vDxyHhGqxMOkIM0Vje6ZXdlHSTmpOZY5 PHRbBUKZpvDfQ== 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 E79F5240695; Fri, 26 Jul 2024 10:43:39 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id CFA0B1601B9; Fri, 26 Jul 2024 10:43:39 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: <0656152d-6c99-4d3e-ac0f-6dc28faaa953@lynne.ee> References: <20240726064216.893951-1-dev@lynne.ee> <172198003078.21344.2362190110390447941@lain.khirnov.net> <0656152d-6c99-4d3e-ac0f-6dc28faaa953@lynne.ee> Mail-Followup-To: FFmpeg development discussions and patches , Lynne Date: Fri, 26 Jul 2024 10:43:39 +0200 Message-ID: <172198341982.21344.10503309806713123166@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] lavu/tx: stop using av_log(NULL, ) 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 Cc: Lynne 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 Lynne via ffmpeg-devel (2024-07-26 10:33:24) > On 26/07/2024 09:47, Anton Khirnov wrote: > > Quoting Lynne via ffmpeg-devel (2024-07-26 08:42:11) > >> Its not feasible to add an AVClass in the main context, as > >> it would waste space, as the main context is recursive, and > >> every bit of assembly would need to be changed. > >> > >> While its true that on paper av_log has access to the main > >> context, that functionality is not used as no options are > >> available for setting. No options will be exposed either, > >> and it makes no sense. > >> > >> mpv has recently started warning if a NULL AVClass is used > >> as an FFmpeg bug. While I don't fully agree nor disagree with > >> this, this is a simple patch which fixes the issue. > > > > No, it just hides the issue for the time being. > > If this means "it may get broken eventually, its not forbidden > anywhere", then IMO we should just codify the current behavior such that > it won't, unless there's some use-case you can think of. It means "you're offloading fixing this issue properly on someone else", which is a bad thing in my book. In my understanding of the API, it _is_ forbidden and UB. > > I am against this patch, just add a proper AVClass. AVTXContext is > > entirely opaque, so it should definitely be feasible. > I'd like to avoid adding a pointer and allocating it if it can't be > helped. And properly integrating each context into the AVClass system as > a child of the parent context. Consider the possibility that if your code depends on fixed layout of a big and complex struct, then your code is...suboptimal. If it's about offsets for SIMD, you could either * generate them at build time * move the things used by SIMD into a smaller struct embedded in the main context > If you think a NULL av_log is valid (you implied that a year ago), then > I'm more than happy to drop this patch. I didn't and I don't. To the contrary, I consider av_log(NULL) a mispattern that we should be rid of. -- 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".