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 994E7486B3 for ; Thu, 14 Dec 2023 05:24:01 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id AD64068CF7F; Thu, 14 Dec 2023 07:23:57 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9DA9068D15C for ; Thu, 14 Dec 2023 07:23:50 +0200 (EET) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 356482405ED; Thu, 14 Dec 2023 06:23:50 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id DgKVVtPFo26K; Thu, 14 Dec 2023 06:23:49 +0100 (CET) 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 A17EE2400AC; Thu, 14 Dec 2023 06:23:49 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id 4360B1601B9; Thu, 14 Dec 2023 06:23:47 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: References: <20231211150725.46473-1-thilo.borgmann@mail.de> <20231211150725.46473-3-thilo.borgmann@mail.de> <170246885429.8914.10051704276943894799@lain.khirnov.net> <170246928230.8914.12754643765966025844@lain.khirnov.net> <170247117981.8914.16828787197695281420@lain.khirnov.net> <170248489636.8914.14641721027481345642@lain.khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches , Thilo Borgmann Date: Thu, 14 Dec 2023 06:23:47 +0100 Message-ID: <170253142724.8914.2591211066924714059@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 2/5] fftools/ffmpeg: move parsing of -stats_* specifiers to lavu/parseutils 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: Thilo Borgmann 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 Thilo Borgmann via ffmpeg-devel (2023-12-13 19:17:04) > Am 13.12.23 um 17:28 schrieb Anton Khirnov: > > It is bad practice to design library features around the needs and > > limitations of a single specific caller. > > The callers here would be the CLI and this filter. First, public APIs should be designed for general classes of use cases, not specific callers. Second, you just said above that the reason you are moving this code into libavutil is specifically because ffmpeg CLI currently behaves in a certain way. This is the opposite of proper design, AKA an ad-hoc hack. > Very much like for av_parse_ratio(). > In contrast to av_get_known_color_name() which actually has just one specific caller, the CLI. No, not at all like any of these. A ratio or a color are generic concepts that are not tied to a specific use. By contrast this code is very much speficic to current ffmpeg CLI processing model. I know this, because I wrote it. > Other parsing functions have more callers, some including the CLI. > And it makes only sense if we offer the same format anywhere for reading/writing the same thing. > > This approach follows what we already do. It most certainly does not. It _might_ make slightly more sense if it were a generic pattern decoupled from specific properties being parsed and used across many filters and/or other modules. But that's now what is happening here. > > Many of the directives supported by -stats* make sense only in the > > context of the ffmpeg CLI, and we may want to add many more in the > > future. We definitely do not want to hardcode them into libavutil public > > API. > > At least three of them are already useful for this filter outside of > the CLI. Out of 18. > Others might be useful for other/new uses cases as well and > all of them would be useful if you'd want e.g. overlay them on top of > the video. "Someone might want to use it somehow" is generically true of any definable value at all, and so does not work as an argument for why these specific values should be particularly useful to users of this specific API. -- 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".