Re: [FFmpeg-devel] [PATCH 1/7] avutil: add an API to handle 3D Reference Displays Information

From: Timo Rothenpieler <timo@rothenpieler.org>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 1/7] avutil: add an API to handle 3D Reference Displays Information
Date: Mon, 23 Jun 2025 17:44:47 +0200
Message-ID: <49bc1d7b-a359-41bc-b56c-4988bacf28b0@rothenpieler.org> (raw)
In-Reply-To: <GV1P250MB07377EA27A05A518A8AF49CD8F70A@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM>

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 <jamrial@gmail.com>
>>>>>>>>>>>
>>>>>>>>>> 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".