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 601A543018 for ; Fri, 17 Jun 2022 14:58:04 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 1D17068B8D0; Fri, 17 Jun 2022 17:58:03 +0300 (EEST) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9E84D68B8BF for ; Fri, 17 Jun 2022 17:57: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 25HEvtqL005877 for ; Fri, 17 Jun 2022 16:57:56 +0200 Received: by phare.normalesup.org (Postfix, from userid 1001) id A377AE1DC8; Fri, 17 Jun 2022 16:57:55 +0200 (CEST) Date: Fri, 17 Jun 2022 16:57:55 +0200 From: Nicolas George To: FFmpeg development discussions and patches Message-ID: References: <20220615205649.GD11679@mariano> <20220616230127.GA173404@mariano> MIME-Version: 1.0 In-Reply-To: <20220616230127.GA173404@mariano> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Fri, 17 Jun 2022 16:57:56 +0200 (CEST) Subject: Re: [FFmpeg-devel] The case for a good string API 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: multipart/mixed; boundary="===============7380268152581243590==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============7380268152581243590== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8gLNFS2KmWsB2M8B" Content-Disposition: inline --8gLNFS2KmWsB2M8B Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Stefano Sabatini (12022-06-17): > I was thinking about mempool (and no, I don't think it's really > neeeded for this use case). >=20 > I still had to read the implementation, now I think I got what this is > about. You have touched the main difference between AVWriter and BPrint. BPrint is a specific implementation, it works the way it works and return the string as a pointer and a length field. If you are not happy with it, you must take it anyway. AVWriter is a layer of abstraction. A very thin, very lightweight layer. Very ffmpeg. You can make an AVWriter out of anything, as long as it is something where writing to it text makes sense. You just need to write a few low-level callbacks to write bits of string, and benefit from the high-level features of AVWriter. There is already an AVWriter that will let you have a static-or-dynamic buffer allocated with av_realloc(). In fact it is a BPrint inside of it, because no need to duplicate the code. There is already an AVWriter that will use a buffer you already have. There is already an AVWriter that will write the text to the logs without storing it. If you are writing an application that is partially in Rust, you can make an AVWriter that will store the text in a Rust String object. Same goes with Perl, Java, whatever language. If you are writing a GUI application, you can make an AVWriter that will store the text directly in a text widget. You can make an AVWriter that will change the character encoding of the text, or compress it, or encrypt it, and write the result to another AVWriter. Your imagination is the limit. But if you only want good old C strings, you do not need to know any of that, just use one of the built-in AVWriter as shown in the documentation and you are good to go. I have to confess, I am rather proud of the ideas I have had to make an abstraction layer that is lightweight, nimble and future-proof at the same time. Eventually, I would like to go further in that direction, for example with side data types describing themselves how they can be serialized / duplicated / referenced. But later. Regards, --=20 Nicolas George --8gLNFS2KmWsB2M8B Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE6ooRQGBoNzw0KnwPcZVLI8pNxgwFAmKslnEACgkQcZVLI8pN xgxWPw//cgYm7zAt18Lvmho3919rPRTAVhc0Nxa2qUS+m7PXtRQHQ/i+eWdL4wpF NJOEA34jdQ2uLJ+n9swSrDgzcwaSF8i7GWdcb4nxnbU9fxE0y/XNH7cLKh5BzEPb FW1yD3st6fC+INUsyLy4vwCkyg/iBLndq0T1hcC0ovxGGdiiTzBxF0es8law2UPy Yr/zZrNR7FshLvw97sMD1yfUWZEh5S+1c789yviy7GCPqkRpS7s840ggPhSShAfD ct284jfTLQjbwuhg/qBcxDau08k8S1nb6FTC6tesBjJwv0UJJ7uxZylNjdacn+Oh vmBCGFpEl0mzAqDnBixavRI3zMrhCfurJiKAMZTUJDNB6Xw4qEsDxniffnVDEDKg CD1mnDWb2TtvnLR3s1sYGjfB5wYQQohY3t5DAHiRgGNjjBZn0JceBENHYS9b9FrQ SHRxXdYuR9Smz0nMD0Mtw+83HJ6LVniEdhOGK1Csx4qX5aoczySGOEU6OGRXpIIo yqFizpxPHK8KZSZkkd1XgnmjuHqWtiFCsvjoVKB7DPCR291airZAbJsLpnuT+2js koBe388JmItOSNYGP8O9Q6vHYfOEEGyEuxkypIUuX5xhNgdsQd7KGGvAaipPg+vU cSHR1HU8fROQNlDZKQjAN67amEGwIi2a3CJHSzMC5FVMNQWDgh0= =INZv -----END PGP SIGNATURE----- --8gLNFS2KmWsB2M8B-- --===============7380268152581243590== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============7380268152581243590==--