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 86EB74BB4B for ; Tue, 1 Jul 2025 20:53:13 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 5B90468F1C0; Tue, 1 Jul 2025 23:53:10 +0300 (EEST) Received: from btbn.de (btbn.de [144.76.60.213]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id 5A6EA68F199 for ; Tue, 1 Jul 2025 23:53:04 +0300 (EEST) Received: from [authenticated] by btbn.de (Postfix) with ESMTPSA id AFDA62819124D for ; Tue, 01 Jul 2025 22:53:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rothenpieler.org; s=mail; t=1751403182; 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=nMIsKymlsqRrRAZKNnzL5vssrjPmGIRXhuoAf5ql5VQ=; b=TE46krHHVV/OWmhoRAYqu5K/OS/+xb8ucll6M2aiPr1lJwN8WWIgpqAiQPexY1vzfHUAz3 Oj/wS1SvJDpdS0Vam0Y8IpoE4mOTMOco1SsTMIBf/nQSRi7kG24Rbr30FWu0XDEcYUhVzG nK3eBxcBQPUShu4h6fZcuKc4x88k1ARwJiogtgx61lqZ9RpZBMJ9OdWcrRNiUoebXWuO1b Z2VWQPPfPnV1T1wYfQf3QUIRm4yLHFN/JGKZIugvgLHh09wrMGqJUNNKSSFK9waD7aXtaI JGlVb+H4hnH4mXtggOK9X1snw8iRTrHbPlOO+QxtLslQIxu3UQPHYNuPPo6GXA== Message-ID: Date: Tue, 1 Jul 2025 22:53:03 +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> <0087eb51-a81d-4d94-8f1f-512cd7f72aa5@gmail.com> Content-Language: en-US From: Timo Rothenpieler In-Reply-To: <0087eb51-a81d-4d94-8f1f-512cd7f72aa5@gmail.com> 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 01.07.2025 22:37, James Almer wrote: > On 7/1/2025 3:49 PM, Timo Rothenpieler wrote: >> 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 > > Please push it. I shouldn't repeat myself in that the struct needs its > own allocator regardless of what we do with frame side data. > sure, applied _______________________________________________ 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".