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

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