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 8E1304A3BC for ; Wed, 27 Mar 2024 12:35:47 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id DA73468D65E; Wed, 27 Mar 2024 14:35:43 +0200 (EET) Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 90F0A68D60B for ; Wed, 27 Mar 2024 14:35:36 +0200 (EET) Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-6e6f69e850bso6049358b3a.0 for ; Wed, 27 Mar 2024 05:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711542934; x=1712147734; 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=nMlPbP4fPh7iygXbT/90WpWUPKCkhCJgZwR24m05/pI=; b=BOC4XNBztT0lGdgMW2y/4KY8PRDvv7cdl80KRTL3pL5OYv1lEBMxnjmuFiGfp9VcgM PLjnku6c+QytnGE1fjXnTrX54lISxoi7QiuHozXE46tPA6/thBdsDtv8jXnLDN0XPuAs yFPDEBiDa6e4iINI/3URBPpuAOZxTS5iUGpDuTQy5Y/qUtOz5UGxCkBLqkZOAg40KhVJ BsH9iSCpohS7OX86Qa6I6xT/eTjFC7FFoegXhe9Y/EADbywebM9LZSPeCxeHqXQkkOld O2eukwQIqEC9D8Mf+Xk+aAvwPvAODJTGiRLbzheaLN4+19diwvwc60gXoFSbO8Wp5L3Y i6Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711542934; x=1712147734; 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=nMlPbP4fPh7iygXbT/90WpWUPKCkhCJgZwR24m05/pI=; b=YwcaA5TJfVi508SInKkhmzkdm076UYzDqilvz93nfgijzeCXiKpgrZ5rhdggTo+gJ+ Bcn+IcLzQ8J2a3mEtB3Aj7b58yHkDRijezNDaUE9mUP05o8Us4WIInGPOjAQ3vo9hlpF 1EKfXeJMFaAwVwpA4wSYggAA8zrnbDjlM85gj3+CR7ejSWnaO1trkV0VbyMWmg6Kihty 4MD1UagSbIqdszEaIm9MBJEwa2xJkU+S0Fmzc3D/oAe5X/3CM9Tofva1wKjRTfEhcXdS SxCmtaYyfU+V7tKKfoj+G+nOQS62ZshThfkaTrla+ElrGLVfhN7fkaABh7BI6iSRIirF Y1Fg== X-Gm-Message-State: AOJu0Yw4uMmOqiFK+G9sg49Vo+wn0f7uLXnMgHis+bushxtkXK/pf0CD 07kAjkQqlaxhD2arGdcacNg8Mz7ZM3cpqdeSdVsqfICnw4SAj5AN2hZCqXJS X-Google-Smtp-Source: AGHT+IE6Mq1Dg/fxkwdM7rOwvDvtgzJFVKraT4EhJ/mb6PWVWqp4/VeR/ePC5iFPuVviWS1e60HFJQ== X-Received: by 2002:a05:6a00:2e08:b0:6ea:8c33:db10 with SMTP id fc8-20020a056a002e0800b006ea8c33db10mr4534725pfb.22.1711542933681; Wed, 27 Mar 2024 05:35:33 -0700 (PDT) Received: from [192.168.0.15] ([190.194.167.233]) by smtp.gmail.com with ESMTPSA id k10-20020aa790ca000000b006e6b12d650asm7691375pfk.31.2024.03.27.05.35.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Mar 2024 05:35:33 -0700 (PDT) Message-ID: <7f5602ce-0326-44ce-99b5-b7ff4fc24190@gmail.com> Date: Wed, 27 Mar 2024 09:35:35 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: ffmpeg-devel@ffmpeg.org References: <20240325200602.63020-1-jamrial@gmail.com> <20240325200602.63020-4-jamrial@gmail.com> <171152531453.7287.8553456080667008312@lain.khirnov.net> Content-Language: en-US From: James Almer In-Reply-To: <171152531453.7287.8553456080667008312@lain.khirnov.net> Subject: Re: [FFmpeg-devel] [PATCH 4/6 v2] avutil/mastering_display_metadata: add a new allocator function that returns a size 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 4:41 AM, Anton Khirnov wrote: > Quoting James Almer (2024-03-25 22:13:25) >> On 3/25/2024 6:02 PM, Andreas Rheinhardt wrote: >>> James Almer: >>>> I don't mind a function like that being added to simplify future >>>> additions, but this API is orthogonal to the frame side data one. It's >>>> also used in packets, for example, and right now lavf is using >>>> sizeof(AVMasteringDisplayMetadata) because >>>> av_mastering_display_metadata_alloc() is not useful. >>>> >>> >>> The API proposed by me is supposed to make API like >>> av_mastering_display_metadata_alloc_size() redundant and therefore these >>> two additions are not orthogonal. >> >> Just because there's a frame side data type for MDM does not make the >> new alloc function redundant. > > The commit message says: > >> av_mastering_display_metadata_alloc() is not useful in scenarios where you need to >> know the runtime size of AVMasteringDisplayMetadata. > > In what scenarios besides side data do you need to know the size of this > struct? None within our libraries that i can think of, but library users can have scenarios we need to provide for. MDM is a standalone API, so lets not try to make its usability depend on a separate one. I'm replacing a helper with a better one, it should not be so controversial. _______________________________________________ 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".