Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
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".

  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