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 1EC5547332 for ; Tue, 5 Sep 2023 11:52:56 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id CB8A268C77C; Tue, 5 Sep 2023 14:52:53 +0300 (EEST) Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id D01E468C4DB for ; Tue, 5 Sep 2023 14:52:47 +0300 (EEST) Received: by mail-oi1-f178.google.com with SMTP id 5614622812f47-3aa14d8641cso1668662b6e.3 for ; Tue, 05 Sep 2023 04:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693914766; x=1694519566; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=+IIjj++Z7fJ+TJSB87UcJ09buWir80bU0z1rc11P0eo=; b=GJwm5XVi88Dvl0Jd8KOS7Wawu8BYR37yLb6fFx/SLzUNl3yOq6UmQ7OL7arQy7mcMA u64p8gsUwU4dLb/MoNoft0P1szTaj55EIkdxT+qqRY0ndl237Bb88o/wMVfrAhTqdJH3 ErevY0eQIWe92p0ezdFZEC0H2xxdimM/AZMVPFi6Xy70s/dEYwZHVkw3ApxxCyxPpFtA jgur6DfCmgU3cpAXxjMJu6X3gSjHRWGLmx5Wv+OULj5Ufa1kOBIGWyiaf7RLxTXdsXNT V9nsInAqfgpG5zpAjKhWzn/RTdq7DYgrlrtHvxtV4rf8mvE9ZdDD0YXJT53ZJYZtqtHe +wmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693914766; x=1694519566; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+IIjj++Z7fJ+TJSB87UcJ09buWir80bU0z1rc11P0eo=; b=hjXFJB+0isUNeu8HQ++tVqWXXIzYdNFW/c044QARXGpfHSB6iUgH19ZETFyo7+w18p yDQ+9i4e0xnyfgGjNwfUJi7xqKisLH5wVNsE5gRs9I5s83xZpLCSa6nPunRS6wHTEP1A 7p16695TsT9YUqqmWabRwfviqwl5NvJX1VuITuy3WDrSp+vmu5UGDs8D3LvlYxfyf+RH HFCRM1WSvHPeYraWqaw58g4Bh6iLioYyENN4jIItw4ew8R/NdpdbGR0VDEgYv+wxXgw4 9c7c9itTVCipWMi1yoku1RluxrwCIQP2cVRGU5l4Hu9R807r4ehj+tj/qw4ojys85lqr p/Pg== X-Gm-Message-State: AOJu0Yw6JB1uxjT5JQSSJC8cId4XUJ0hrVaB7IuMxfWIl91LXayIynpZ /KX+j30g8Duf7XsHw/5gzlcZPfSkxx0= X-Google-Smtp-Source: AGHT+IEB3FAZPiM3KfOPJvEXDiEWVHNKAaUduSful9pJruGMppXYaehaiw90B7CsjP2XNyeQ01FnnQ== X-Received: by 2002:a05:6808:2091:b0:3a5:a607:650d with SMTP id s17-20020a056808209100b003a5a607650dmr15757465oiw.45.1693914765701; Tue, 05 Sep 2023 04:52:45 -0700 (PDT) Received: from [192.168.0.10] (host197.190-225-105.telecom.net.ar. [190.225.105.197]) by smtp.gmail.com with ESMTPSA id u16-20020a056808115000b003a862e70bcbsm5824134oiu.13.2023.09.05.04.52.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Sep 2023 04:52:45 -0700 (PDT) Message-ID: <84287a00-4971-4b7b-bd98-29c742974788@gmail.com> Date: Tue, 5 Sep 2023 08:52:43 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20230904150411.56777-2-jamrial@gmail.com> <20230904220848.21900-1-jamrial@gmail.com> <169391205232.20400.15738564387019560241@lain.khirnov.net> <169391383896.20400.12256334212156878188@lain.khirnov.net> From: James Almer In-Reply-To: <169391383896.20400.12256334212156878188@lain.khirnov.net> Subject: Re: [FFmpeg-devel] [PATCH 01/17] avcodec/avcodec: add side data to AVCodecContext 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 9/5/2023 8:37 AM, Anton Khirnov wrote: > Quoting James Almer (2023-09-05 13:26:22) >> On 9/5/2023 8:07 AM, Anton Khirnov wrote: >>> Quoting James Almer (2023-09-05 00:08:48) >>>> This will allow the propagation of global side data within the AVCodecContext >>>> instead of having to do it inside packets, and thus be available during init(). >>>> Global and frame specific side data will therefore be distinct. >>> >>> This commit message is misleading - there is already >>> AVCodecContext.coded_side_data for exactly this purpose. And after the >>> changes from the last iteration I see even less of a reason to replace >>> it with a new field. >> >> I insist the new field in the form of a set is better, for the sake of >> unified helpers that can be used in avctx, codecpar, avstream, and >> potentially others in the future. > > The big problem with this is that AVPacket is left as is. And since > changing it would be a huge break for very little gain, we'll have > different handling for packets and everything else for the foreseeable > future. Packets and frames have their own helpers, so there will be a distinction between those and side data set helpers initially used in structs meant for global side data. The API user doesn't need to access the fields directly. > > I think you'd get almost the same benefits with downsides by making the > helpers accept array+count as parameters. It's slightly less elegant, > but not hugely so IMO. > >> It will also be the packet counterpart of Jan's frame side data set >> field. coded_side_data is currently used only to export CPB props, so >> the amount of users is probably very small (Maybe only lavf, even). I >> think the benefits in the long run outweigh the cons from the breakage >> that would mean replacing coded_side_data. >> >> Also, my interpretation of coded is still that it refers to a coded >> stream, much like we make a distinction between coded and raw for >> bits_per_sample, and in decoding scenarios, side data entries would have >> information that refer to the decoded raw stream (hdr, etc). > > The intent was for it to be a direct counterpart to AVStream.side_data, Since that one is being deprecated and removed, doing the same with its less used counterpart should not be that much of a problem. > as is mentioned in the relevant commit message, so your interpretation > is objectively wrong. Fair, but i question your choice of name :p > >> That said, I don't want to keep delaying this set much longer, so if >> you're really against that change I'll try to remove it from the set and >> keep the rest. > > I'd appreciate more opinions on this, from whoever cares. Ok, but like i mentioned, i really doubt there are many coded_side_data users out there, for being limited to only exporting CPB props. _______________________________________________ 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".