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 032AF4383F for ; Wed, 31 Aug 2022 19:28:27 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 59D3068BA3B; Wed, 31 Aug 2022 22:28:24 +0300 (EEST) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E7DAE68B988 for ; Wed, 31 Aug 2022 22:28:17 +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 27VJSH9q024296 for ; Wed, 31 Aug 2022 21:28:17 +0200 Received: by phare.normalesup.org (Postfix, from userid 1001) id 2B697E0101; Wed, 31 Aug 2022 21:28:17 +0200 (CEST) Date: Wed, 31 Aug 2022 21:28:17 +0200 From: Nicolas George To: FFmpeg development discussions and patches Message-ID: References: <20220824151828.24218-1-george@nsup.org> <5520bdbb-0f14-8409-32c6-92c14fb8e8eb@gmail.com> <016b2b74-2f94-e2e6-e1cc-e0bcb409c162@gmail.com> MIME-Version: 1.0 In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Wed, 31 Aug 2022 21:28:17 +0200 (CEST) Subject: Re: [FFmpeg-devel] [PATCH] lavu: header and documentation for AVWriter 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="===============1331904694821709488==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============1331904694821709488== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eM2TLysSUjXA9zvA" Content-Disposition: inline --eM2TLysSUjXA9zvA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Andreas Rheinhardt (12022-08-31): > He is not only stack-allocating AVWriter, he also intends to > stack-allocate the actual writers like AVDynbufWriter, AVBufWriter > (AVWriter is just a wrapper around the underlying writers). This means > that no allocations need to be performed for AVBufWriter at all (and due > to the inherent small-string optimization of an AVBPrint, it can also be > avoided for AVDynbufWriter in lots of cases). > If you return pointers to an AVWriter struct, you need to allocate this > struct somewhere, which means that your init/av_dynbuf_writer_wrap has > an allocation that can fail and therefore needs to be checked; and the > struct needs to be freed lateron. Thanks. I could have been more precise. AVWriter itself uses a new kind of mini decentralized object system, where all objects are a pair of pointers, first a const pointer to the structure of primitive methods and second the structure itself, and are passed by value. It does not require any future extension, it just works that way. This scheme allows to add methods on an existing structure without altering it. So, any kind of side data, for example, can become an object with serialize methods, or an object with ref/unref methods, etc. The various implementations of AVWriter are also designed to be allocated on the stack by the caller. This time, to avoid being encumbered by sizeof(struct) for compatibility, I use a different trick: one of the first field of the structure is its own size, set by whoever allocated it. Currently, the code only checks that the size is at least the original size. If we later extend the structure, the code will have to check if the fields it tries to access are below the reported size, and if they are not it will have to manage without them, use a fallback value. For writers, need for extending the structure is very unlikely. But for the methods structures, it can happen. Methods structures defined by earlier applications will just behave as if these methods are unimplemented. The ability to allocate on the stack is essential to AVWriter, since it needs to be lightweight enough that we never have to hesitate to use it. Of course, it can always be allocated dynamically. I wonder if I should include functions to allocate dynamically and init av_dynbuf_writer() at least. Regards, --=20 Nicolas George --eM2TLysSUjXA9zvA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE6ooRQGBoNzw0KnwPcZVLI8pNxgwFAmMPtk8ACgkQcZVLI8pN xgxHUA/8CUGPtOynFl/qy0w989IlcjTcGvsoxHh016WkEO8ItJyZIy7yJ0WXmjDy PlxjbtwVVVrcN6EHYyNjOXlYwOtPWvw2rg3472NpvK2dz9R7igcnyrOfRoiZ00ia c4Ll54+lf7gPZx+Iz3NYQo2GmLMzb7MRHM9DbL0vsWkkN9T0M8JjVubsrTWyT4u+ WlnEB6Jsr+8EWDNlYJsghu44nM3VA7HuTE7bwQ5sJP9jfOizBVHAK+AhDzOv6AGr gPcn2PxU1ZtBQoMxm3MI2c3bHRlqoSWvpnd9PXnyMMdTsKXcBrXU4O8RSWyqTpBb jz+jxCSx/MjgofOvwhOakZCb53vFtgIsFyIIT/PxmzmRw8V5PyMWLkHEVjEYKkEd ekTJNk6FwEsvjXnalvBFQ9H6v7nZiLboT7847jA2Qc5NVKTiZFpfDRr9LaPT8s2z VaVUf983aORt4hj8k1Hk9eSGpuJ6NcC5zH8y81zH3ijhaOrrWlnQ6+XkUviyfpCi X7NZO/UU3vl8qBNGJNzGeDlYMTyZ0leM1fWvpTaQqT36JBP7HM4j4//TGyfxOb0I 1LZsL7jI8m3ANo03XU8cpRWKJCkXbSiBjLzi1e63BhK+DevZl78OhD0yrYqfJJVY 5/PoAQOHEHoxtuQmbQzjQ+eTkKxoxkKb20K0RD67Wqvz+MNEE9o= =hesD -----END PGP SIGNATURE----- --eM2TLysSUjXA9zvA-- --===============1331904694821709488== 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". --===============1331904694821709488==--