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