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 2ADCD4A379 for ; Wed, 27 Mar 2024 08:06:01 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 5DB9168D61B; Wed, 27 Mar 2024 10:05:59 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id B1B5A68D5A3 for ; Wed, 27 Mar 2024 10:05:52 +0200 (EET) Authentication-Results: mail0.khirnov.net; dkim=pass (2048-bit key; unprotected) header.d=khirnov.net header.i=@khirnov.net header.a=rsa-sha256 header.s=mail header.b=YH2UwR/G; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 6F0FB240DAC for ; Wed, 27 Mar 2024 09:05:52 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id 7KuatPCnJG55 for ; Wed, 27 Mar 2024 09:05:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1711526751; bh=abR7n292V1o3Jwq0xzc2j7Ta7xKRNjaDNBcz/JbcbIs=; h=Subject:From:To:In-Reply-To:References:Date:From; b=YH2UwR/GTT8G04NtZlpegEynm8eyKGAeHdJuboOKY4LFX8ucsICwwM7wfmhR+9tmj u19PG52prUstW6r2ALqR9Hw+Ilg4MIHyZlM3401Kw2wmnnMuvs7x+QRwOQ4giBhPEA 6aDfAgaCHS3xEvaKtiv654H4yfa1UtQOJkTtOPM0B83vwHIHO+fjkJWGlO2ZlP0LRi WF4Fu22F4PXdE8tG2QpMKX603nx80lqi1CNQQF401hxFhqa4A43bGVHPblrGBFUsxb 5k+9c0O58SVE7HVURFnugnD9vF343Q+qJq11OT7GuZ8ix8mPJclZpaL3E+ACncXaEg /q327J35G7ZyA== Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id E43BD2404AF for ; Wed, 27 Mar 2024 09:05:51 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id C0D551601B9; Wed, 27 Mar 2024 09:05:51 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: <20240325200602.63020-1-jamrial@gmail.com> References: <20240325200602.63020-1-jamrial@gmail.com> Mail-Followup-To: FFmpeg development discussions and patches Date: Wed, 27 Mar 2024 09:05:51 +0100 Message-ID: <171152675176.7287.1643281874746299286@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 1/6 v2] avutil/frame: add a flag to not create duplicate entries in a side data array 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Quoting James Almer (2024-03-25 21:05:57) > +/** > + * Remove existing entries before adding new ones. > + */ > #define AV_FRAME_SIDE_DATA_FLAG_UNIQUE (1 << 0) > +/** > + * Don't add a new entry if another of the same type exists. > + */ > +#define AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND (1 << 1) I don't really like this API, because it leaves too much work to the user. With my descriptor set, we know when it makes sense to have duplicate side data. So the cases that can occur when adding side data of type T are: * T not present, call succeeds * T present, then * T does not have a MULTI prop, then user decides whether to replace or do nothing (or perhaps fail) * T does have a MULTI prop, then user decides whether to replace, add, or do nothing I think the default behaviour for MULTI types should be adding, and the other two cases should be covered by the user explicitly. Then we only need a single flag, which only applies to non-MULTI types, and chooses whether to replace or not. -- Anton Khirnov _______________________________________________ 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".