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

[Andreas Rheinhardt]

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 at 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.

- Andreas