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 2DC63404B1 for ; Wed, 22 Dec 2021 16:12:51 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E809868B0B8; Wed, 22 Dec 2021 18:12:48 +0200 (EET) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id B62EA68B079 for ; Wed, 22 Dec 2021 18:12:42 +0200 (EET) 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 1BMGCfc0008351 for ; Wed, 22 Dec 2021 17:12:42 +0100 Received: by phare.normalesup.org (Postfix, from userid 1001) id CD067E62AD; Wed, 22 Dec 2021 17:12:41 +0100 (CET) Date: Wed, 22 Dec 2021 17:12:41 +0100 From: Nicolas George To: ffmpeg-devel@ffmpeg.org Message-ID: MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Wed, 22 Dec 2021 17:12:42 +0100 (CET) Subject: [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="===============0179665115678546155==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============0179665115678546155== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1crdMR5MhpiJhHzL" Content-Disposition: inline --1crdMR5MhpiJhHzL Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I will try again proposing a good string API for the project. But this time, instead of showing the implementation code, I will ask about the principle. So, please, read the argument, and give your opinion on the principle. If we agree on the principle, we can discuss the code then. * Why we need a better string API Strings are not the bulk of what we do, but for the user interface of things we have a LOT of functions that return strings: to describe a color space or a channel layout or a set of options. When the returned string is short, we use the good old =E2=80=9Cchar *buf, size_t buf_size=E2=80=9D. When it is long, we return a dynamically-allocated buffer. When the string is almost always short but can actually be very long, and the conversion is used in speed-critical code, we are screwed. With a good string API, we could use the same API everywhere, it would automatically use the most efficient memory scheme. Furthermore, if all our object=E2=86=92string functions have the same proto= type, it makes it easier to use these functions as standardized callbacks and opens a whole lot of new possibilities of serialization features. Moreover, a good string API would bring quite a few extra benefits, with a few examples: easier to build strings from parts, less verbose and more robust error checking, the ability to use directly the string or buffering API of another library or language. So, even though strings are not the core of our thing, I think we should have a good string API, just like we have an API for efficient FFTs (which is the core of our thing). But let us discuss it further: * Objections and counter-objections - A string API adds complexity. Indeed, that is true. But the added complexity is clearly isolated in one or a few source files. In the rest of the code, it removes complexity (see less verbose error checking, easier to build strings =66rom parts above). String conversion functions can happen once per short frame, for example in the ashowinfo filter. We have pools for frames and for buffers: we already consider that avoid once-per-frame memory allocations is worth the added complexity. A string API is just a step in the same direction. - An unusual API is annoying for people who will use it. Unless we messed up, if they use strings more than just a little, the benefits of the API is way worth the cost of learning. But some people use strings just a little. For them, who would be happy with a plain C string, we should make sure the required learning is very very limited. And we can: =E2=80=9Cinstead of =E2=80=98buf, sizeof(buf)=E2=80=99, write =E2=80=98stri= ng_from_buffer(buf)=E2=80=9D. That is all, in one short line I have documented how to use the API with the old patterns. There is a little more to write for people who want a dynamic buffer for an unlimited string (error checks are always annoying), but we can keep it under three minutes. * What string API we should use We have AVBprint, but the API is ugly, and it only brings a few of the benefits I promised. I have a proposal: AVWriter. I posted it last spring, here is an introduction on how to use it (with the implementation in the same thread): https://ffmpeg.org/pipermail/ffmpeg-devel/2021-April/279383.html * Conclusion Well, I am convinced, but what about you? 1. Do you think FFmpeg needs a good string API? If not, please explain why? 2. Assuming we agree =E2=80=98yes=E2=80=99 on the previous question, do you= think AVWriter is a good candidate? If not, what else would you propose? Regards, --=20 Nicolas George --1crdMR5MhpiJhHzL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIyBAEBCgAdFiEE6ooRQGBoNzw0KnwPcZVLI8pNxgwFAmHDTncACgkQcZVLI8pN xgySOQ/4hFkaBQttrzC3XeLRZ5oVH6b9ickyMmpIw/0OErCBDvAvK/QHw3h/ypDS 7b5iwW56t23+5mM1WhsTD7TPNSCxpmQMs+bZPv50x6vyeixg9s6yonfnJzjNfM8J dbfpH6mt9x9Sr+v9tMjk3MVjGBKXGuvbltQyaBr9CbyW8a1IZ4QiE2DcExEHZWXw 0YJPE4Z8QoAdiNt8vrtUbvQZzlSx+TNfDC09WOKOIshVTcGcyK8twV6FVHlIW8Uu 5EmmjoE4mCI+NgeECIzSXPRxIsR9ScDmPAz/YyLvdZOd5DJR8Ao3Mz12Jc/Vw+7v PnoaLv3QdO83fE1u0mJ1v7UfyegLY3zd6SmSfMMAU/y1/pFX28JFTWLVovNhK/gm cil1dyuYj370SvwmZnQ9mWQLWM1iY68v2FQ1ANQYHymxdIph+iIJItnbiimM6N2L O1fAoBy/SgjS940+ERN9bFcRyCqViG19HDjM7hvsh7Q7eMHym7TgDKrcxeNDLL/0 IbYD3i16DDt1+JzPNxaDSn/4CE3EeGnOAWlwoN7XKNq/IasuiRqg2H589rxV6qv+ Jl8biOymJeY81NP5V5yopZoaFEbf9NMgM+b3K793yV5i98ziOi1/PxZZTbro67R3 q1srYr8qfDJi4usSLC5ORbmsrdjgf0LFqvgbbgEioyAhBr9pnw== =Znsf -----END PGP SIGNATURE----- --1crdMR5MhpiJhHzL-- --===============0179665115678546155== 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". --===============0179665115678546155==--