From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH v2 5/6] libavutil: Add AVMap
Date: Tue, 15 Apr 2025 23:11:34 +0200
Message-ID: <20250415211134.GV4991@pb2> (raw)
In-Reply-To: <Z_6wIk52_3NeQBlv@phare.normalesup.org>
[-- Attachment #1.1: Type: text/plain, Size: 2044 bytes --]
On Tue, Apr 15, 2025 at 09:14:42PM +0200, Nicolas George wrote:
> Michael Niedermayer (HE12025-04-15):
> > Where exactly would that benefit FFmpeg ?
> > Dictionaries generally are used to move stuff aorund, like metadata or
> > options.
> > Or may be used in the future to keep track of some mappings like
> > timestamps to file positions during demuxing or muxing
> > Or maybe codecs/formats lookup from name
> > None of these are confined to a single local function
>
> AVMap opts = av_map_create(cmp, NULL, NULL);
> av_map_add(opts, "threads", "12");
> av_map_add(opts, "crf", "18");
> av_map_add(opts, "preset", "veryslow");
> av_map_assert_small(opts);
> ret = av_codec_open3(ctx, codec, opts);
Allocating and creating 12 threads and encoding a x264 video
(i guess this is x264) with "preset", "veryslow" will overshadow the
25 nanoseconds of a malloc() call
or is the goal to avoid the error handling?
I think the 12 threads encoder will fail if the map run out of memory
also in the specific example
av_codec_open3(ctx, codec, NULL);
will no longer work as NULL is a pointer and AVMap here looks like
it would not be
>
> > i like av_map_new() because "new" is short
>
> The exact name does not matter to me. I forgot that we usually use
> _alloc() for the case you implemented, so _new() is absolutely fine for
> this.
>
> av_map_assert_small() should assert that no dynamic allocation happened,
> and at assert level 2 that the internal buffer is less than halfway full.
>
> > and sizeof(AVMap) is not public API
>
> It should be public API like I did for BPrint, that is my point.
AVMap should be public but the implementation should not be any more
public than needed.
That way users cannot by mistake mess with internals and we can
improve the internal implementation without ABI/API breakage
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
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:[~2025-04-15 21:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 18:14 [FFmpeg-devel] [PATCH v2 1/6] avutil/tree: av_tree_find2() to also find the first and last elements comparing equal Michael Niedermayer
2025-04-15 18:14 ` [FFmpeg-devel] [PATCH v2 2/6] avutil/tree: Add av_tree_move Michael Niedermayer
2025-04-15 18:14 ` [FFmpeg-devel] [PATCH v2 3/6] avutil/tree: Make av_tree_find2() non recursive Michael Niedermayer
2025-04-15 18:14 ` [FFmpeg-devel] [PATCH v2 4/6] avutil/tree: Make tree_find_next() " Michael Niedermayer
2025-04-15 18:14 ` [FFmpeg-devel] [PATCH v2 5/6] libavutil: Add AVMap Michael Niedermayer
2025-04-15 18:45 ` Nicolas George
2025-04-15 19:06 ` Michael Niedermayer
2025-04-15 19:14 ` Nicolas George
2025-04-15 21:11 ` Michael Niedermayer [this message]
2025-04-15 21:24 ` Nicolas George
2025-04-15 18:14 ` [FFmpeg-devel] [PATCH v2 6/6] [NOT for git] avutil/tests/map: benchmark code Michael Niedermayer
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=20250415211134.GV4991@pb2 \
--to=michael@niedermayer.cc \
--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