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 ESMTP id 721814A3C2 for <ffmpegdev@gitmailbox.com>; Wed, 27 Mar 2024 12:45:13 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id F21D968D65F; Wed, 27 Mar 2024 14:45:10 +0200 (EET) Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 2477468D63E for <ffmpeg-devel@ffmpeg.org>; Wed, 27 Mar 2024 14:45:05 +0200 (EET) Received: by mail-pg1-f179.google.com with SMTP id 41be03b00d2f7-5dca1efad59so4134898a12.2 for <ffmpeg-devel@ffmpeg.org>; Wed, 27 Mar 2024 05:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711543502; x=1712148302; 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=vBVQ62OeQDRd6UopwSai237/vql5BIOXGbs6wArzJAk=; b=WiUiEjYFM2zSnzD0+mnVsopnt+mJTlB/JOp1dUDaWid3M6WV8PLTlody2GQC09MH4g THKlPU1QkGEnV+m6DuzTpGSAcXeJTjLFxfak9q9WBnukjIhi2j0nzDA2kWvotraEjb3E oL/9B22oFgCPM43SiUJrUGKQZN3RUGEo63NRqaW3iGJHxZOpBK8/Nt++5Ro+p6Ax8diP 6qrTXE6kq3Va89hYWtU4IyDMFLMVlpvAF1NA6Aqdt4vdvINJ29qZ9VHLR9/2zRR18nbS CJKYl8JiVkGI850Ka+WXBrjpJtTGk5O+lfEDpOmHUcis3kvE8m3cWARGbYFgQKkYBfxN Hozg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711543502; x=1712148302; 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=vBVQ62OeQDRd6UopwSai237/vql5BIOXGbs6wArzJAk=; b=XsD/WGiFd7jacxU5XZD8ppltJO3a3+5gq8c5GgLa1SOFuJEoUFZ4wWjfibJ28MvYsj 1wsrLRuxlIBoJ88KoaHDo1Ow9nacgL2r3zCgVnqbVJIKwYhv2pbMoEsh2+LubjoDP5G4 sMIUyuBs9Q7Vc22SfgsHzqxRuB/wrY8W6Vpcs1NGghNz4PvsCnvL+Sr3Joxz1bgf2u90 wuwJ9azTBnoj7Ym84bHwmANU8oZw+0IofRM0SsN3BVwURqf+LDJuVfuuD2nU15erTjIU 4IHZIf3cXg1E3Df2TUCcrw/HG51YygI1ODpo5d4vtLKcQq/EeUkQuSyghwNm4G9CVDNC tTOQ== X-Gm-Message-State: AOJu0YxKTVITYEjMUEf45Jyg+Vzg+aXwPs6OBY834fT1oCMdneVyIBPB qC01NKDwUO4MOG1jjQlhItIrgNCxWb5cf3j4Qp2g+KLcbEfUGsSvRRYH8gWA X-Google-Smtp-Source: AGHT+IEVI9x2st7yn3/q1ipu16HOc8RLXt3//W8PwHxkzf79IyvlFVlxJRj8cHTAubBBhQRlMIpOEw== X-Received: by 2002:a17:90a:f498:b0:2a0:4073:deda with SMTP id bx24-20020a17090af49800b002a04073dedamr4145367pjb.20.1711543502516; Wed, 27 Mar 2024 05:45:02 -0700 (PDT) Received: from [192.168.0.15] ([190.194.167.233]) by smtp.gmail.com with ESMTPSA id ca22-20020a17090af31600b0029bf9969afbsm1549600pjb.53.2024.03.27.05.45.01 for <ffmpeg-devel@ffmpeg.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Mar 2024 05:45:02 -0700 (PDT) Message-ID: <4b17ee6c-192e-4a4a-924d-b46892739c5e@gmail.com> Date: Wed, 27 Mar 2024 09:45:04 -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> <GV1P250MB07371F82E2AEB6DA4315E8218F362@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM> <f77f1819-3ed6-4d16-8f39-40c986394cfb@gmail.com> <GV1P250MB07371526EE42E2C2BD633A088F362@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM> <b11368a2-9476-46fc-9774-a847b86b8246@gmail.com> <171152531453.7287.8553456080667008312@lain.khirnov.net> <7f5602ce-0326-44ce-99b5-b7ff4fc24190@gmail.com> <171154325969.7287.3577300184736876535@lain.khirnov.net> Content-Language: en-US From: James Almer <jamrial@gmail.com> In-Reply-To: <171154325969.7287.3577300184736876535@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 <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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org> Archived-At: <https://master.gitmailbox.com/ffmpegdev/4b17ee6c-192e-4a4a-924d-b46892739c5e@gmail.com/> List-Archive: <https://master.gitmailbox.com/ffmpegdev/> List-Post: <mailto:ffmpegdev@gitmailbox.com> On 3/27/2024 9:40 AM, Anton Khirnov wrote: > Quoting James Almer (2024-03-27 13:35:35) >> 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. > > Breaking API to benefit hypothetical use cases IS a controversial change > in my view. Then I can leave the old on in place. But don't insist on telling people to use a frame side data specific alloc function if they want a MDM struct, because said function will not be usable for all side data types anyway (see video enc params, iamf params), so it's just making things more complex for the user for no reason. _______________________________________________ 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".