On 6/16/2025 2:26 PM, Timo Rothenpieler wrote:
> 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.

Again, what's the point? I'm not trying to block the set, i'm trying to 
get it pushed as is because the struct needs its own, standalone allocator.

Whatever we do with frame side data is out of scope for this set and 
should not affect it.