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 7715D4A397 for ; Wed, 27 Mar 2024 11:49:57 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 32FB868D63E; Wed, 27 Mar 2024 13:49:56 +0200 (EET) Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 90D7C68BF87 for ; Wed, 27 Mar 2024 13:49:50 +0200 (EET) Received: by mail-pg1-f178.google.com with SMTP id 41be03b00d2f7-5d8b887bb0cso4704667a12.2 for ; Wed, 27 Mar 2024 04:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711540188; x=1712144988; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=dHEigNrtI8MvEtovlf1Lf+ATvkkUc8TU8e0qPSrcTe4=; b=PA3XcvYZ13VwRBh+3TUwNHD+pzY0Wzxmu47HzY950R15hf9aCwm0mY9h9uBqOuQYTq Vu8BKiHEIAKKEQaOfChRjlKDEEhGJb6FVZx6ZcszjU7lpksNVBIqeL1EzCRSyv1iX9Lt uQ0jrBPSDsITDx1C4CYTKICko1Pve2FHO3JrFu8mDqpNra7ORHPojGduIMvSicyelKP7 YyeioOCOb+EOB6kPwkI5/tLUx4tBatYmRA1Vzu95AKZf3rO68t6TcX3zZziZgmtL1DvS pp+t8v/Pz4DcME3Ws63MLN24ToWwHoRw2QYaWEoFO7W1V8sU/6hqn6mXiGCfqvm4B9pk s3jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711540188; x=1712144988; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dHEigNrtI8MvEtovlf1Lf+ATvkkUc8TU8e0qPSrcTe4=; b=b4mkJnc54maCKeAH9R106/UsGui5gBNVx1E0nBUuLM82HyBcw5/WHBV+aNwMxqVnOp R9uJapYExeZJHc4WXQwHC54jv9RI2AWNWOIVINo+Ie4nDRHBijcd3CRTafF3TkTeLFNm D3QGFvoSUScVBnt85CeXPlgG22ic2FT+pIetzL4//eJe1K3/8lXIvgNhB5ootRMcYXsY kcvuo0G+eMqbJnXPQMGG83MqEbtP8AiGheSjgGiFHjD02+SKeSQfZpJOI0zlZvTUOo2N CuQ8cs3Nex9kdhr7WG8pGfOU2h3RED1I5Ylbn8DahZjLhNTlU15JIm9BdZVw4G6LTRYu J3hw== X-Gm-Message-State: AOJu0YyOUttw0BqZqhEOYBY9fMAxQ3JE0tQk2xhO2yxwBGldRjlJnMLf 5TYAcYNsnFFMiIWXGPF65fO9o47i2UUYLXHSjqV+/Qo6VLCnbD7hHlYyILKg X-Google-Smtp-Source: AGHT+IG9nY7iIAqPJ3LOEKe11Mz+2PdEgCkqrgwFCMe5/JF/1cLqxqZAKBRoWiXWx7r02JTl5/HWqw== X-Received: by 2002:a17:90b:1d0b:b0:2a1:f7af:8714 with SMTP id on11-20020a17090b1d0b00b002a1f7af8714mr373135pjb.9.1711540187719; Wed, 27 Mar 2024 04:49:47 -0700 (PDT) Received: from [192.168.0.15] ([190.194.167.233]) by smtp.gmail.com with ESMTPSA id hg23-20020a17090b301700b0029c73ed3748sm1459579pjb.6.2024.03.27.04.49.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Mar 2024 04:49:47 -0700 (PDT) Message-ID: <2ab7ec0b-20db-411e-a4e3-543c69bc9b9d@gmail.com> Date: Wed, 27 Mar 2024 08:49:49 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: ffmpeg-devel@ffmpeg.org References: <20240325200602.63020-1-jamrial@gmail.com> <171152675176.7287.1643281874746299286@lain.khirnov.net> Content-Language: en-US From: James Almer In-Reply-To: <171152675176.7287.1643281874746299286@lain.khirnov.net> 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 3/27/2024 5:05 AM, Anton Khirnov wrote: > 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) av_frame_side_data_new() returns an entry, so for non-MULTI types, it should return the existing one. There's no "do nothing" scenario, and i don't particularly like failing, more so now that 7.0 is branched so we can't stealthly change behavior and for example define EEXIST error code as "did nothing". > * 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. I don't follow. How does a single flag let you choose between all these scenarios? _______________________________________________ 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".