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 B3F5A4F904 for ; Mon, 23 Jun 2025 15:45:01 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 3606E68DB4E; Mon, 23 Jun 2025 18:44:56 +0300 (EEST) Received: from btbn.de (btbn.de [144.76.60.213]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id 4634A68BC9A for ; Mon, 23 Jun 2025 18:44:49 +0300 (EEST) Received: from [authenticated] by btbn.de (Postfix) with ESMTPSA id 2787127FFCEA1 for ; Mon, 23 Jun 2025 17:44:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rothenpieler.org; s=mail; t=1750693488; 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=lR8TpIv1+gVVVdNFfC4xO+sSClTyyn9mmWCVCZBqGjg=; b=MM8W2MY7u+LLuIKULpfy/aMz9U7LvGs77AQy9KoTlwxePYaTKHwEUMAW1s3zzs0Sy9jbDE zJSeM7VyPWaDsNrVjnBDX5jnyBO92PbKMV3eGi8FlC0SXfmx/ihYmRHEURGlhbV5OUgE4d z4kRsD5A+vUKD8UhY4LIm5al1E9Mf8/VW/upQHJyz42eSAA8EdXbujlrt8CLPJnbXaKUfb TAwBl4ruwRyniMkcINwMF52kTA9m516kdWhb4jy+XLz+1yUWQceNTq8EJgmcP/th1mylkI Fr1ZwU+yRN7UDBpMEdvxbYCDlZSillAwNdoHo+/26Ibmuhyo2nl4UXciv54/hg== Message-ID: <49bc1d7b-a359-41bc-b56c-4988bacf28b0@rothenpieler.org> Date: Mon, 23 Jun 2025 17:44:47 +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> 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 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? _______________________________________________ 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".