On 6/9/2025 7:09 PM, 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. Meant to say "isn't" here. >> > > 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. > > - Andreas Frame side data, be it inside frames or not, is not the only user. An allocator for this struct is needed regardless of what we do with that.