From: James Almer <jamrial@gmail.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 1/6 v2] avutil/frame: add a flag to not create duplicate entries in a side data array
Date: Wed, 27 Mar 2024 08:55:43 -0300
Message-ID: <9f757163-d08d-4e28-927f-a4d40299b0d0@gmail.com> (raw)
In-Reply-To: <2ab7ec0b-20db-411e-a4e3-543c69bc9b9d@gmail.com>
On 3/27/2024 8:49 AM, James Almer wrote:
> On 3/27/2024 5:05 AM, Anton Khirnov wrote:
>> Quoting James Almer (2024-03-25 21:05:57)
>>> +/**
>>> + * Remove existing entries before adding new ones.
>>> + */
>>> #define AV_FRAME_SIDE_DATA_FLAG_UNIQUE (1 << 0)
>>> +/**
>>> + * Don't add a new entry if another of the same type exists.
>>> + */
>>> +#define AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND (1 << 1)
>>
>> I don't really like this API, because it leaves too much work to the
>> user.
>>
>> With my descriptor set, we know when it makes sense to have duplicate
>> side data. So the cases that can occur when adding side data of type T
>> are:
>> * T not present, call succeeds
>> * T present, then
>> * T does not have a MULTI prop, then user decides whether to
>> replace or do nothing (or perhaps fail)
>
> av_frame_side_data_new() returns an entry, so for non-MULTI types, it
> should return the existing one. There's no "do nothing" scenario, and i
> don't particularly like failing, more so now that 7.0 is branched so we
> can't stealthly change behavior and for example define EEXIST error code
> as "did nothing".
Err, error code would be for av_frame_side_data_clone().
av_frame_side_data_new() can either return an entry or NULL, which the
user will consider a failure.
>
>> * T does have a MULTI prop, then user decides whether to replace,
>> add, or do nothing
>>
>> I think the default behaviour for MULTI types should be adding, and the
>> other two cases should be covered by the user explicitly.
>>
>> Then we only need a single flag, which only applies to non-MULTI types,
>> and chooses whether to replace or not.
>
> I don't follow. How does a single flag let you choose between all these
> scenarios?
_______________________________________________
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 11:55 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 20:05 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
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 [this message]
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=9f757163-d08d-4e28-927f-a4d40299b0d0@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