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 297344A4A0 for ; Thu, 28 Mar 2024 14:00:56 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 108CB68D586; Thu, 28 Mar 2024 16:00:53 +0200 (EET) Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id EB8FE68BE7C for ; Thu, 28 Mar 2024 16:00:46 +0200 (EET) Received: by mail-pf1-f173.google.com with SMTP id d2e1a72fcca58-6ea8ee55812so983756b3a.0 for ; Thu, 28 Mar 2024 07:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711634444; x=1712239244; 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=uSLIfxag/Kbn1tKKCr9ntE4IaG66i3fogd5eNUI9+YA=; b=M6zWEX8cCT9uFlO5Rppu+VifooXXFvGa5nyCKn2RbsVOvQCq585TurRISxyrbmR93H r2Dd70xYaB48tq8wxwyvMTn1A2AbBKzf8iI9jZ73BGLaVc+isN73VUaxhlPkIwnwJUTt OYUh6RvukZXlpNGGY1gg2sWMVzL5W84eI6H64Gt8HeJowAPX/dEfKD06dUsGgLPLLqHt JgoXKGJz/MLy+pt5n8DXCvl7oGDH6o8xaH1ltia2rQi0WUElrjBs8H8hG8V/DIEZqqBf C2EMIMXP/4lkrFASqgyIa46iXQD34cqy31JCd8/JYHxycmR5zzGpTyeaqHQRjdufZnot AGKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711634444; x=1712239244; 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=uSLIfxag/Kbn1tKKCr9ntE4IaG66i3fogd5eNUI9+YA=; b=EMjoQVMq4tcG5mLxj691IPUFUZmUzIpLRclSi/tfdtky2UkYeJj9SRMpLISj6gWZvb l4jn1O5iAkZbxSUJk3t+c7y2XL+0DVInal8Wi6lnCQIWFELG8aOHPNUcgGoEK3i0/tzT BswCRyYnJcbe0EFZSfT4W7UVGTLynZjTvh+zGw4dVCapu1Qziv+E3yBRxA9drI/Xa8KN L+xiyoPOE3JhlL9pA/ni2d/gyzkU3lnq3mWY5Ug7dUVbCYu3da6Xjkwkj3WyW1uoOHQu 4zBWgbrA4MPLkrAHG9mu5HPzp2fPGaVcjIwmYeNV8Upfr4GJvxCLg94ZzvFm1K3S76ry GJtQ== X-Gm-Message-State: AOJu0YxVgaVJ36qDsQhcbv6sGjywawzBZypRZIzVLwy7slAm6w1+RyOo PVeGwnQgxllcQvxrojKnh4T3NO1NaC01vQ/LzpPYZPRr9+F4Z6rdPIlX4A52 X-Google-Smtp-Source: AGHT+IEyIf4iC/uWL+PF3cxhnbB+lyViLNIAiQylwogOO7cns5YkDLG14HVF1ZXB/pw1whQmzSk9IA== X-Received: by 2002:a05:6a00:148d:b0:6ea:ad01:3590 with SMTP id v13-20020a056a00148d00b006eaad013590mr3855055pfu.24.1711634444561; Thu, 28 Mar 2024 07:00:44 -0700 (PDT) Received: from [192.168.0.15] ([190.194.167.233]) by smtp.gmail.com with ESMTPSA id r2-20020aa78442000000b006ea6d1d3134sm1381036pfn.119.2024.03.28.07.00.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Mar 2024 07:00:43 -0700 (PDT) Message-ID: Date: Thu, 28 Mar 2024 11:00:47 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: ffmpeg-devel@ffmpeg.org References: <20240328031210.21407-1-jamrial@gmail.com> <20240328031210.21407-2-jamrial@gmail.com> <171162527283.7287.16403425396625504098@lain.khirnov.net> <91096d51-c7c3-4d46-85ce-61fee7e3be0c@gmail.com> <171162836725.7287.11280806609859440632@lain.khirnov.net> Content-Language: en-US From: James Almer In-Reply-To: <171162836725.7287.11280806609859440632@lain.khirnov.net> Subject: Re: [FFmpeg-devel] [PATCH 2/7 v4] avutil/frame: add helper for adding side data w/ AVBufferRef to 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/28/2024 9:19 AM, Anton Khirnov wrote: > Quoting James Almer (2024-03-28 12:49:08) >> On 3/28/2024 8:27 AM, Anton Khirnov wrote: >>> Quoting James Almer (2024-03-28 04:12:05) >>>> Signed-off-by: James Almer >>>> --- >>>> libavutil/frame.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++ >>>> libavutil/frame.h | 34 ++++++++++++++++++++++++++++++ >>>> 2 files changed, 87 insertions(+) >>>> >>>> diff --git a/libavutil/frame.c b/libavutil/frame.c >>>> index d9bd19b2aa..a165e56a64 100644 >>>> --- a/libavutil/frame.c >>>> +++ b/libavutil/frame.c >>>> @@ -834,6 +834,59 @@ AVFrameSideData *av_frame_side_data_new(AVFrameSideData ***sd, int *nb_sd, >>>> return ret; >>>> } >>>> >>>> +AVFrameSideData *av_frame_side_data_add(AVFrameSideData ***sd, int *nb_sd, >>>> + enum AVFrameSideDataType type, >>>> + AVBufferRef **pbuf, unsigned int flags) >>>> +{ >>>> + const AVSideDataDescriptor *desc = av_frame_side_data_desc(type); >>>> + AVFrameSideData *sd_dst = NULL; >>>> + AVBufferRef *buf; >>>> + >>>> + if (!sd || !pbuf || !*pbuf || !nb_sd || (*nb_sd && !*sd)) >>> >>> Overzealous checks like these tend to hide bugs. Any of these conditions >>> being false means the caller is insane and we should crash. >> >> I'll remove some, but others simplify the code below (like knowing >> beforehand that *pbuf is not NULL). > > You can just assume them all to be true. Or use av_assert0(). > >>>> diff --git a/libavutil/frame.h b/libavutil/frame.h >>>> index 2ea129888e..3e5d170a5b 100644 >>>> --- a/libavutil/frame.h >>>> +++ b/libavutil/frame.h >>>> @@ -1048,6 +1048,10 @@ void av_frame_side_data_free(AVFrameSideData ***sd, int *nb_sd); >>>> * Don't add a new entry if another of the same type exists. >>>> */ >>>> #define AV_FRAME_SIDE_DATA_FLAG_REPLACE (1 << 1) >>>> +/** >>>> + * Create a new reference instead of taking ownership of the passed in one. >>>> + */ >>>> +#define AV_FRAME_SIDE_DATA_FLAG_NEW_REF (1 << 2) >>> >>> Who needs this? >> >> Someone who wants to keep the reference around, like when attaching a >> buffer to several outputs (global to individual output frames). > > Is that a common enough use case to warrant this flag? It complicates > the code quite substantially. > > And if you're making some side data instance global, what is the point > of also attaching it to frames? To pass it to API that does not handle global entries, like currently happens with filtergraphs. I can remove the flag for now in any case. It can be added later trivially. _______________________________________________ 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".