From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ffmpeg-devel-bounces@ffmpeg.org> Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 0AA9F4E1F1 for <ffmpegdev@gitmailbox.com>; Tue, 29 Apr 2025 08:31:09 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 23CF468AF86; Tue, 29 Apr 2025 11:31:04 +0300 (EEST) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 06A2E688146 for <ffmpeg-devel@ffmpeg.org>; Tue, 29 Apr 2025 11:30:56 +0300 (EEST) X-ENS-nef-client: 129.199.129.80 ( name = phare.normalesup.org ) Received: from phare.normalesup.org (phare.normalesup.org [129.199.129.80]) by nef.ens.fr (8.14.4/1.01.28121999) with ESMTP id 53T8UtjW002737 for <ffmpeg-devel@ffmpeg.org>; Tue, 29 Apr 2025 10:30:56 +0200 Received: by phare.normalesup.org (Postfix, from userid 1001) id C2C6829536; Tue, 29 Apr 2025 10:30:55 +0200 (CEST) Date: Tue, 29 Apr 2025 10:30:55 +0200 From: Nicolas George <george@nsup.org> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Message-ID: <aBCOPyA3Bt1aFnbj@phare.normalesup.org> References: <DM8P223MB036504CFC0521633C2ADCCE3BABB2@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> <aApw6eiupyMBT5mm@phare.normalesup.org> <aA4B0eruJJhLzfpq@mariano> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <aA4B0eruJJhLzfpq@mariano> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Tue, 29 Apr 2025 10:30:56 +0200 (CEST) Subject: Re: [FFmpeg-devel] [RFC] Shaping the AVTextFormat API Surface X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches <ffmpeg-devel.ffmpeg.org> List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe> List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel> List-Post: <mailto:ffmpeg-devel@ffmpeg.org> List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help> List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe> Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org> Archived-At: <https://master.gitmailbox.com/ffmpegdev/aBCOPyA3Bt1aFnbj@phare.normalesup.org/> List-Archive: <https://master.gitmailbox.com/ffmpegdev/> List-Post: <mailto:ffmpegdev@gitmailbox.com> Stefano Sabatini (HE12025-04-27): > Elaborating on this. ffprobe/textformat is based on a notion of > hierarchical tree-like data No, this is not true. FFprobe and all its supporting code is based on one level of hierarchy. Just one level, not a real hierarchical structure. > Considering this, there is probably no need to extend the API to cover > each possible format full semantics - this at least it is my view. If we add XML-writing code in libavutil, it must be usable for all the places we are already producing XML. Otherwise it does not make sense. > As I wrote, this was not the purpose of the ffprobe formats in the > first place. MOV/DASH requires a specific use of an XML encoder. In > theory it might be done using the textformat API in the current form, > but it would be probably pretty awkward. We might want to factorize a > few generic utilities (e.g. escaping) to avoid code duplication > though. You are going at it backwards. The goal is not to cram this text writers API forcefully into libavutil and then see if it might serve other purposes, which is what softworkz is doing. The API must be able to handle all our use cases from the start. Until then, it goes back to the design board. > It might be if we want to make this a generic tool for library users, > and for purposes outside of the scope for which it was designed. But I > don't think this should be a real blocker - and we might even keep the > API private to enable libav* cross-librariers but not > external-libraries usage. I can concede making a generic API for external users is not blocking. Reluctantly. But I will not budge on internal uses: this API must serve all our current use cases or it stay outside the libraries. Regards, -- Nicolas George _______________________________________________ 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".