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 <jamr...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
