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 E15B34F3BC for ; Mon, 16 Jun 2025 17:27:04 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id A7A6468DD92; Mon, 16 Jun 2025 20:27:01 +0300 (EEST) Received: from btbn.de (btbn.de [144.76.60.213]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id DB5D468D62F for ; Mon, 16 Jun 2025 20:26:55 +0300 (EEST) Received: from [authenticated] by btbn.de (Postfix) with ESMTPSA id 62C6328190F35 for ; Mon, 16 Jun 2025 19:26:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rothenpieler.org; s=mail; t=1750094813; 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=rRA2Xpgpdma+MO9QMJorpHqqSuWM5/XFsifmHEKH0KY=; b=Q3XhAp6BlOy9+uTuW+PPV0Ga3V4lp+UenJnU3fyp5eknOBxF6oU7Lq7cxVdzePg87BLjr/ /87egf0endHW6di3z99cgMcZLHErZgP/TOAba3xi+8XvndN4MY60OXJ921HS9/82NGzgHL zgmDBhQgmMQ0cM5NOa2Vd66aQ0X+OMSRP9HM1OQPOQo7kaucwBB8PD0VBQo2Y1/IRjG6Qq QfU0GKCWrjoGORiCs3pbsGFeaQUSaPCGhpoYg3QoByt4ieT+RjpGi2sDFqvS3YmTALsUBL 0LulFv6osrEHqQ1J7rOfiBrjXjEASmTD9glkhcAsxlZQpi3f/CHVL4UZbl/f/A== Message-ID: <629167d5-1140-426b-bf70-74c998966646@rothenpieler.org> Date: Mon, 16 Jun 2025 19:26:48 +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> Content-Language: en-US From: Timo Rothenpieler In-Reply-To: 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 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. _______________________________________________ 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".