Quoting James Almer (2024-03-27 13:35:35) > On 3/27/2024 4:41 AM, Anton Khirnov wrote: > > Quoting James Almer (2024-03-25 22:13:25) > >> On 3/25/2024 6:02 PM, Andreas Rheinhardt wrote: > >>> James Almer: > >>>> I don't mind a function like that being added to simplify future > >>>> additions, but this API is orthogonal to the frame side data one. It's > >>>> also used in packets, for example, and right now lavf is using > >>>> sizeof(AVMasteringDisplayMetadata) because > >>>> av_mastering_display_metadata_alloc() is not useful. > >>>> > >>> > >>> The API proposed by me is supposed to make API like > >>> av_mastering_display_metadata_alloc_size() redundant and therefore these > >>> two additions are not orthogonal. > >> > >> Just because there's a frame side data type for MDM does not make the > >> new alloc function redundant. > > > > The commit message says: > > > >> av_mastering_display_metadata_alloc() is not useful in scenarios where you > >> need to > >> know the runtime size of AVMasteringDisplayMetadata. > > > > In what scenarios besides side data do you need to know the size of this > > struct? > > None within our libraries that i can think of, but library users can > have scenarios we need to provide for. MDM is a standalone API, so lets > not try to make its usability depend on a separate one. > I'm replacing a helper with a better one, it should not be so controversial.
Breaking API to benefit hypothetical use cases IS a controversial change in my view. -- Anton Khirnov _______________________________________________ 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".