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 7DA5E4F37E for ; Mon, 16 Jun 2025 12:38:04 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 5ABEE68DC9D; Mon, 16 Jun 2025 15:38:00 +0300 (EEST) Received: from btbn.de (btbn.de [144.76.60.213]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id DA12D68DA8C for ; Mon, 16 Jun 2025 15:37:53 +0300 (EEST) Received: from [authenticated] by btbn.de (Postfix) with ESMTPSA id 5752E28190F35 for ; Mon, 16 Jun 2025 14:37:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rothenpieler.org; s=mail; t=1750077473; 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=/rRJZ9IYIIlD111PpRXvUm3oG9i+gB3XzGuXNb8y7IA=; b=pta0E/q0eMH1CYkFO827wL5acrNbrUizWPQvR7b3L+SCIJV86RnEWVVYtIHzvSSWI7YmDx lJ+rMKCVJWa0wMDtFJyDxfJvBJLjvIzY5ZdnSoKO0gNukuuQEbypNKQbn3Ru304JqOvH6I EY5yZEIBrsrcwrkB8L5DpCrB62Hal3AFkG9HnjT7RYtCCS7OHn4u8T/4A8U7cQC+wwBUft NwmsXoqKH3KtAqHAsmlDsX8o5BQFPzZA0Ug5RPdV8kSxWGgrIpDZ6eEi5rN4EmBlkQwzQt IGsdClOPzsYFcRQ/y3/kFxaEbPc5/i1vgXdGgjoj119V3QAM5ZNPd4AeRmP9bQ== Message-ID: Date: Mon, 16 Jun 2025 14:38:05 +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, de-DE From: Timo Rothenpieler In-Reply-To: <7afbb7e5-b32e-4001-aa3f-7cd0d44cd859@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 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. _______________________________________________ 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".