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 ACC154DA5F for <ffmpegdev@gitmailbox.com>; Wed, 23 Apr 2025 00:31:45 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2F827688146; Wed, 23 Apr 2025 03:31:40 +0300 (EEST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 95D15687DCF for <ffmpeg-devel@ffmpeg.org>; Wed, 23 Apr 2025 03:31:33 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id DAE8043185 for <ffmpeg-devel@ffmpeg.org>; Wed, 23 Apr 2025 00:31:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1745368293; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kGorreYRFIjxHzerhshX8ZBvx58GORLYEAxCIinxs/c=; b=L0mX2TEjHws4dHuxC0K8LytjhP9wzBRITDfyuJfqWoL693JhLgxm+B1wzDLrt6vF7k0Ivw KGUlg9vNx1Yd6AW7bmt1YjV226JUlcSBFXr46lCK8QZFdvyKcnZWi0qbDk8NvEwXc1Wpzd N2kdPDtfdjtFYccp/EbSZaTM9kgdMJb6nEZgiiC/lUtXfPkutZ9GlwL6h7Qh3sa+J35gEr Loa5NFXTBRP5pXjc5zxzv4OrWc+h/3h1ezb9QbJvkjfewWD/s/eTvh/L3FyR/z+y+0vTRS 4ltXhgObPDT3J/gRCqXP8JG3B3kPGx5RPQsYn3BIX2grVhzBD3UBpk26guhNeQ== Date: Wed, 23 Apr 2025 02:31:31 +0200 From: Michael Niedermayer <michael@niedermayer.cc> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Message-ID: <20250423003131.GQ4991@pb2> References: <20250420022929.724535-1-michael@niedermayer.cc> <5c3978fd-41e4-d686-e17e-b9beb96a657b@passwd.hu> MIME-Version: 1.0 In-Reply-To: <5c3978fd-41e4-d686-e17e-b9beb96a657b@passwd.hu> X-GND-State: clean X-GND-Score: -70 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvgeehudekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculdeftddmnecujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefoihgthhgrvghlucfpihgvuggvrhhmrgihvghruceomhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtqeenucggtffrrghtthgvrhhnpeeigeektdejudffjefhteegjedtgeettefggedthfejgfevhfetgeekjedtvdfhveenucfkphepgedurdeiiedrieejrdduudefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgedurdeiiedrieejrdduudefpdhhvghloheplhhotggrlhhhohhsthdpmhgrihhlfhhrohhmpehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgdpnhgspghrtghpthhtohepuddprhgtphhtthhopehffhhmphgvghdquggvvhgvlhesfhhfmhhpvghgrdhorhhg X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH] avutil/map: [WIP] Introduction 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: multipart/mixed; boundary="===============1604253988057771861==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org> Archived-At: <https://master.gitmailbox.com/ffmpegdev/20250423003131.GQ4991@pb2/> List-Archive: <https://master.gitmailbox.com/ffmpegdev/> List-Post: <mailto:ffmpegdev@gitmailbox.com> --===============1604253988057771861== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="U5DFg8KP0feZGDzS" Content-Disposition: inline --U5DFg8KP0feZGDzS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi On Mon, Apr 21, 2025 at 09:55:33PM +0200, Marton Balint wrote: >=20 >=20 > On Sun, 20 Apr 2025, Michael Niedermayer wrote: >=20 > > Note, help is welcome. > > Time i spend on this, i cannot spend on other things > >=20 > > Note2: i intend to push AVMap after the release unless the release > > ends up delayed alot for other reasons, theres no real reason > > to hurry here except that i seem to keep workig on it when > > people ask for some non trivial changes/improvments :) > > so dont ask, send patch yourself if its not a trivial change :)) > >=20 > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > > --- > > libavutil/map.h | 86 +++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 86 insertions(+) > >=20 > > diff --git a/libavutil/map.h b/libavutil/map.h > > index 8211a05ec8d..0d3f7eab9ac 100644 > > --- a/libavutil/map.h > > +++ b/libavutil/map.h > > @@ -31,6 +31,92 @@ > > #include "tree.h" > >=20 > > /** > > + * @file > > + * > > + * AVMap is a simple and fast key -> value map. >=20 > Is this intended to be an AVDictionary replacement? Yes. In how far a "automatic" replacement is possible iam not sure > Because as far as I > remember AVDictionary keeps key insertion order, and we even rely on this > behaviour sometimes, so an ordered-by-compare-function list is likely not > going to work as an instant drop-in replacement... What do you mean by "keeps key insertion order" ? this isnt documented, or is it ? In fact i dont think thats supposed to be guranteed by AVDictionary I think the order coming out of av_map_iterate() will match the order elements where added. Is that what you meant ? >=20 > > + * > > + * ---------- Creating AVMaps ------------------ > > + * > > + * AVMap *map =3D av_map_alloc(strcmp, AV_MAP_CMP_CASE_SENSITIVE + AV_= MAP_CMP_KEY, NULL, NULL); > > + * > > + * This creates a case sensitve string based map using strcmp(). It wi= ll not allow > > + * multiple entries with the same key. > > + * or > > + * > > + * AVMap *map =3D av_map_alloc(av_map_strcmp_keyvalue, AV_MAP_CMP_CASE= _SENSITIVE + AV_MAP_CMP_KEYVALUE, NULL, NULL); > > + * > > + * This is like the previous, but it will allow multiple entries with = the same key > > + * the difference here is that the compare function compares the value= too when > > + * the key is equal. > > + * All entries in a map must always be different. So by comparing the = value > > + * too we can have multiple entries with the same key > > + * > > + * The remaining 2 pointers in av_map_alloc() are for a function copyi= ng an element > > + * and one for freeing it. That is only needed for complex objects, no= t for strings. > > + * > > + * > > + * ----------- Adding entries ----------------- > > + * > > + * av_map_add_strings(map, "cat", "neko", 0); // add new entry or do n= othing >=20 > What "or do nothing" means here? That it will not overwrite a key by > default? This is a different semantics than AVDictionary, where you need = to > explicitly set DONT_OVERWRITE flag for such. yes, we can flip the default around if people prefer I really picked this solely because i felt negated flags with "DONT" in the= ir name are suboptimal design >=20 > I think we should use function names and flags similar to what we have in > AVDictionary. Like av_map_set_strings() instead of av_map_add_strings(), = or > AV_MAP_DONT_OVERWRITE. So our users won't have to use different mindset f= or > similar stuff. like i said i dont like the "DONT" flag, i think we should avoid such names in new designs. Maybe AV_MAP_PRESERVE would be an alternative ? av_map_set_strings() implies setting a key to a value. When this in reality= is more flexibl, depending on flags and setup >=20 > > + * > > + * av_map_add_strings(map, "cat", "neko", AV_MAP_REPLACE); // add new = entry or replace existing > > + * > > + * > > + * ----------- Removing entries ----------------- > > + * > > + * Removing entries does by default not rebuild the map. That is, whil= e access will always > > + * be O(log n) when n becomes smaller, memory consumption will not dec= rease until > > + * AV_SET_ALLOW_REBUILD is used. Note if you use AV_SET_ALLOW_REBUILD,= all previously > > + * returned elements become invalid. > > + * > > + * av_map_del(map, "cat", 0); // remove one entry matching "the key" > > + * > > + * av_map_del(map, "cat", AV_SET_ALLOW_REBUILD); // remove one entry m= atching "the key" and rebuild the map to re >=20 > Do you specify a key, or a concatenated key + \0 + value? Or you can spec= ify > both? it depends on the flags (which select the compare function) In fact it can be an arbitrary struct instead of a string, if the compare function during setup compares the specific struct. av_map_del(map, "cat\0katze", AV_MAP_CMP_KEYVALUE); av_map_del(map, "cat", AV_MAP_CMP_KEY); >=20 > In general I believe the public API should not use const char * for keyva= lue > types, that would be very fragile. A string constant is not a valid > concatenated keyvalue for example, and the compiler will not catch such > isses. Therefore public functions should always use separate key and > separate value parameters. about "const char *", we could use a typedef or struct or something completely droping keyvalue from public API is not an option because AVMapEntry always provides you with a keyvalue already and requiring to copy it on every use is dumb. so we need to find a smarter solution here thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad --U5DFg8KP0feZGDzS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCaAg03AAKCRBhHseHBAsP qw0jAJ9IXH8OcTrBcGjjfbet4v5PeDf6RACfWl5F0xTx+0cDJGHH/gHdxDUnktc= =X/7E -----END PGP SIGNATURE----- --U5DFg8KP0feZGDzS-- --===============1604253988057771861== 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". --===============1604253988057771861==--