On 3/27/2024 9:40 AM, Anton Khirnov wrote:
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.
Then I can leave the old on in place. But don't insist on telling people
to use a frame side data specific alloc function if they want a MDM
struct, because said function will not be usable for all side data types
anyway (see video enc params, iamf params), so it's just making things
more complex for the user for no reason.
_______________________________________________
ffmpeg-devel mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
