From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 746F24BAFF for ; Tue, 1 Jul 2025 18:49:34 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id B602268F09D; Tue, 1 Jul 2025 21:49:30 +0300 (EEST) Received: from btbn.de (btbn.de [144.76.60.213]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id 4EBEB68EC39 for ; Tue, 1 Jul 2025 21:49:24 +0300 (EEST) Received: from [authenticated] by btbn.de (Postfix) with ESMTPSA id C738F2819124D for ; Tue, 01 Jul 2025 20:49:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rothenpieler.org; s=mail; t=1751395762; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VDxFII4qd6J5hecmrLOWPQTXXavJy+sn4j7UJDzpJvI=; b=kObbwhJ5Rqiki8lg8zh7SrwCX4Iq4Cm2lh0YEyAruOI1fS+1btXVEgiOgxnPu9InhE6DRR Az/OAjNMMG0bZ+L+3Krq3t62xulExNjTM5evfjU5+SSDMTJ8G9HTfnQ/DEkR2HTrHPD0vq VLyO1i2WkLIF7NjAwX8Hk0SzwNzt4w4uVMC2M7bC/4wEPKHDk8pjgONYJVdDeXlRv5ZgWw FUHEsXE7cJK8pRmTjjLFQveM4EoC6gjaY7HvFzbHsyGqJLCB3HbH6H+pRaXE0NA/8+3frV AiHsqSfNBCy/mLJOuvbD6R45wULwteGh56xF/gBQjVL5oF//QnCpnUibZbFJug== Message-ID: Date: Tue, 1 Jul 2025 20:49:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: ffmpeg-devel@ffmpeg.org References: <20250607213509.16424-1-timo@rothenpieler.org> <57ffc654-1acf-4bb4-8304-e30646ed427d@gmail.com> <224b0f55-d991-4098-a12b-ddd4a85b226b@rothenpieler.org> <7afbb7e5-b32e-4001-aa3f-7cd0d44cd859@rothenpieler.org> <629167d5-1140-426b-bf70-74c998966646@rothenpieler.org> <49bc1d7b-a359-41bc-b56c-4988bacf28b0@rothenpieler.org> Content-Language: en-US From: Timo Rothenpieler In-Reply-To: <49bc1d7b-a359-41bc-b56c-4988bacf28b0@rothenpieler.org> Subject: Re: [FFmpeg-devel] [PATCH 1/7] avutil: add an API to handle 3D Reference Displays Information 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 23.06.2025 17:44, Timo Rothenpieler wrote: > On 16.06.2025 20:26, Andreas Rheinhardt wrote: >> Timo Rothenpieler: >>> On 16.06.2025 14:55, James Almer wrote: >>>> On 6/16/2025 9:38 AM, Timo Rothenpieler wrote: >>>>> On 13/06/2025 16:07, Timo Rothenpieler wrote: >>>>>> On 10/06/2025 00:09, Andreas Rheinhardt wrote: >>>>>>> James Almer: >>>>>>>> On 6/9/2025 5:59 PM, Timo Rothenpieler wrote: >>>>>>>>> On 08.06.2025 17:45, James Almer wrote: >>>>>>>>>> On 6/8/2025 11:29 AM, Andreas Rheinhardt wrote: >>>>>>>>>>> Timo Rothenpieler: >>>>>>>>>>>> From: James Almer >>>>>>>>>>>> >>>>>>>>>>> I don't like that you add another allocator for this; instead >>>>>>>>>>> we should >>>>>>>>>>> add a generic allocator for the frame side-data types. >>>>>>>>>> >>>>>>>>>> Wont work for packet side data. And i purposely didn't add yet >>>>>>>>>> another allocator that inserts the result into a frame, like >>>>>>>>>> there's >>>>>>>>>> in so many other modules, because eventually the generic one >>>>>>>>>> would be >>>>>>>>>> introduced. >>>>>>>>>> >>>>>>>>>> You said you wanted to take over my work on the generic >>>>>>>>>> allocator, >>>>>>>>>> but not sure if you did anything with it. The core issue was >>>>>>>>>> handling >>>>>>>>>> more complex types that didn't just have an extra nb_blocks >>>>>>>>>> argument. >>>>>>>>> >>>>>>>>> So, what is the conclusion here? >>>>>>>>> I'd like to push this set if you can come to an agreement. >>>>>>>>> >>>>>>>>> I haven't looked into it much, but implementing av_tdrdi_alloc() >>>>>>>>> in a >>>>>>>>> generic way does seem a bit hacky. And other types might need even >>>>>>>>> more info for the allocation. >>>>>>>> >>>>>>>> The set LGTM. A custom frame side data allocator does not imply an >>>>>>>> allocator is required for this struct. Frames are not the only >>>>>>>> user. >>>>>>>> >>>>>>> >>>>>>> I was thinking about a generic side data allocator (for the >>>>>>> AVFrameSideDataType stuff, but it is not meant to be AVFrame >>>>>>> specific), >>>>>>> so that it can be used by more than just AVFrames. Will write one >>>>>>> tomorrow. >>>>>> >>>>>> Would you be okay to for now pushing this with the API turned into >>>>>> an internal one, so the public API can then be decided and >>>>>> implemented later? >>>>> >>>>> Will apply soon with the new public APIs turned into an ff_ symbol. >>>> No, the allocator is required, and an internal function like you >>>> suggest would need a separate internal header, and will make the >>>> struct virtually unusable outside lavu for non frame side data users. >>> >>> It's only meant as a temporary measure until the final public API is >>> figured out, so the rest can move on. >> Sorry for being an asshole and forgetting about this. Will really send a >> patch for what I intend tomorrow. > > ping > > Or did I simply miss the patch? ping _______________________________________________ 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".