From: James Almer <jamrial@gmail.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 4/6 v2] avutil/mastering_display_metadata: add a new allocator function that returns a size
Date: Wed, 27 Mar 2024 09:45:04 -0300
Message-ID: <4b17ee6c-192e-4a4a-924d-b46892739c5e@gmail.com> (raw)
In-Reply-To: <171154325969.7287.3577300184736876535@lain.khirnov.net>
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
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2024-03-27 12:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 20:05 [FFmpeg-devel] [PATCH 1/6 v2] avutil/frame: add a flag to not create duplicate entries in a side data array James Almer
2024-03-25 20:05 ` [FFmpeg-devel] [PATCH 2/6 v2] avutil/frame: add helper for adding side data w/ AVBufferRef to array James Almer
2024-03-27 19:16 ` [FFmpeg-devel] [PATCH 02/10] " James Almer
2024-03-27 19:22 ` [FFmpeg-devel] [PATCH 2/6 v3] " James Almer
2024-03-25 20:05 ` [FFmpeg-devel] [PATCH 3/6 v2] avutil/frame: add helper to remove side data of a given type from an array James Almer
2024-03-25 20:06 ` [FFmpeg-devel] [PATCH 4/6 v2] avutil/mastering_display_metadata: add a new allocator function that returns a size James Almer
2024-03-25 20:40 ` Andreas Rheinhardt
2024-03-25 21:00 ` James Almer
2024-03-25 21:02 ` Andreas Rheinhardt
2024-03-25 21:13 ` James Almer
2024-03-27 7:41 ` Anton Khirnov
2024-03-27 12:35 ` James Almer
2024-03-27 12:40 ` Anton Khirnov
2024-03-27 12:45 ` James Almer [this message]
2024-03-25 20:06 ` [FFmpeg-devel] [PATCH 5/6 v2] avcodec/decode: make the AVFrameSideData helper wrappers not depend on frames James Almer
2024-03-25 20:06 ` [FFmpeg-devel] [PATCH 6/6 v2] avcodec/hevcdec: export global side data in AVCodecContext James Almer
2024-03-27 8:05 ` [FFmpeg-devel] [PATCH 1/6 v2] avutil/frame: add a flag to not create duplicate entries in a side data array Anton Khirnov
2024-03-27 11:49 ` James Almer
2024-03-27 11:55 ` James Almer
2024-03-27 12:25 ` Anton Khirnov
2024-03-27 19:10 ` [FFmpeg-devel] [PATCH 1/6 v3] avutil/frame: add a flag to allow overwritting existing entries James Almer
2024-03-28 3:25 ` Michael Niedermayer
2024-03-28 3:27 ` James Almer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4b17ee6c-192e-4a4a-924d-b46892739c5e@gmail.com \
--to=jamrial@gmail.com \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git