From: Marvin Scholz <epirat07-at-gmail.com@ffmpeg.org> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avformat/tee: refactor option processing Date: Fri, 04 Jul 2025 16:52:26 +0200 Message-ID: <A7E9AB26-C15A-4AF3-B910-1232BB55D771@gmail.com> (raw) In-Reply-To: <aGZIcPZuEJgLbJhh@phare.normalesup.org> On 3 Jul 2025, at 11:08, Nicolas George wrote: > Marvin Scholz (HE12025-06-25): >> Would you be fine with just the removal of the messing with >> the AVDictionary entries then, leaving the macros in place, >> essentially removing STEAL_OPTION and doing a copy in CONSUME_OPTION? >> >> IMHO saving two copies of a string does not justify abusing the >> AVDictionary API in such a way. This isnt a hot code path either >> where this would make sense... > > It is not just a matter of saving a few cycles. What you propose > requires writing more code, including error checks and an occasion for > failure. If copying two strings fails here, it is highly unlikely any of the following code, needing much more memory, would have any chance of succeeding. > > If it was new code, I would consider it, but changing existing code that > has been working for years to make it more verbose, more failure prone Yes it introducers two copies which could fail but the chance for that happening is so small that I dont think it justifies using hacks like this, which also introduce risk of turning into more serious issues when the AVDictionary code is changed and someone is unaware of this hack here. > and less efficient, no, thanks. We are talking about copying two option strings here, during setup, not per frame, not every few seconds. > > Let us just document that it is a valid use. > I disagree making this hack official. It will make any further changes to AVDictionary even harder if we have to consider the user messing with it in such ways. Let's not sacrifice code quality and proper APIs for the sake of 'efficiency'. The main reason I want to get rid of this is so that av_dict_get's return value can be made const which is only blocked by this one use here. Nowhere else in ffmpegs code do we do this, I really see no sufficient justification to do it here. Regards, Marvin Scholz > Regards, > > -- > Nicolas George > _______________________________________________ > 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". _______________________________________________ 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".
prev parent reply other threads:[~2025-07-04 14:52 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-06-24 22:08 Marvin Scholz 2025-06-24 22:08 ` [FFmpeg-devel] [PATCH 2/2] avformat/tee: fix multiple bsfs in tee Marvin Scholz 2025-06-25 9:56 ` Nicolas George 2025-06-26 15:42 ` Marvin Scholz 2025-06-25 11:23 ` [FFmpeg-devel] [PATCH 1/2] avformat/tee: refactor option processing Nicolas George 2025-06-25 12:04 ` Marvin Scholz 2025-07-03 9:08 ` Nicolas George 2025-07-04 14:52 ` Marvin Scholz [this message]
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=A7E9AB26-C15A-4AF3-B910-1232BB55D771@gmail.com \ --to=epirat07-at-gmail.com@ffmpeg.org \ --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