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

      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