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 C9A1746318 for ; Wed, 13 Dec 2023 12:50:20 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 1343B68D09E; Wed, 13 Dec 2023 14:50:18 +0200 (EET) Received: from shout01.mail.de (shout01.mail.de [62.201.172.24]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 31F4168D087 for ; Wed, 13 Dec 2023 14:50:11 +0200 (EET) Received: from postfix01.mail.de (postfix01.bt.mail.de [10.0.121.125]) by shout01.mail.de (Postfix) with ESMTP id 9C3AC240CBD for ; Wed, 13 Dec 2023 13:50:10 +0100 (CET) Received: from smtp01.mail.de (smtp03.bt.mail.de [10.0.121.213]) by postfix01.mail.de (Postfix) with ESMTP id 83CFF80151 for ; Wed, 13 Dec 2023 13:50:10 +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 5A0C9240A2D for ; Wed, 13 Dec 2023 13:50:10 +0100 (CET) Message-ID: Date: Wed, 13 Dec 2023 13:50:09 +0100 MIME-Version: 1.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org 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> In-Reply-To: <170247117981.8914.16828787197695281420@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: 2204 X-purgate-ID: 154282::1702471810-0D6271F9-B5721B93/0/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: , 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 13.12.23 um 13:39 schrieb Anton Khirnov: > Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 13:15:27) >> Am 13.12.23 um 13:08 schrieb Anton Khirnov: >>> Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 13:05:35) >>>> Am 13.12.23 um 13:00 schrieb Anton Khirnov: >>>>> Quoting Thilo Borgmann via ffmpeg-devel (2023-12-11 16:07:22) >>>>>> --- >>>>>> fftools/ffmpeg.h | 31 +------ >>>>>> fftools/ffmpeg_enc.c | 3 +- >>>>>> fftools/ffmpeg_mux_init.c | 152 +++----------------------------- >>>>>> libavutil/parseutils.c | 176 ++++++++++++++++++++++++++++++++++++++ >>>>>> libavutil/parseutils.h | 102 ++++++++++++++++++++++ >>>>>> libavutil/version.h | 2 +- >>>>>> 6 files changed, 296 insertions(+), 170 deletions(-) >>>>> >>>>> Absolutely not. >>>>> >>>>> This is application code and does not belong in the libraries. >>>> >>>> How else do we not have a redundant copy of all that and make sure that -stats_* options and the filter understand the same {..} directives? >>> >>> Why does that filter need to understand the same directives? No other >>> filter does. >> >> Because it is meant to use the file(s) the -stats_* option writes out. The most convenient and most error resilient way is to use the very same format string for -stats_* option as well as for the filter. >> >> Otherwise it could be a 'usual' scanf-format, but then the user has to translate it from one format into the other - without making mistakes. >> But that would also mean to update the filter (if someone realizes it) if the option ever changes. > > Why does it need a dynamic format at all? Just postulate a fixed format > for its input like every other filter and none of this complexity is > needed. That would unnecessarily limit the user of the -stats_* option to a specific format if the user also wants to use this filter later. Either sacrificing the other info the user wanted to process from the file created or having to run the same command (with distinct format strings for the -stats_* option) twice. Or do the conversion from his extensive format into the fixed format manually - without errors. -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".