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