Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Soft Works <softworkz-at-hotmail.com@ffmpeg.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] avutil/log: Replace addresses in log output with simple ids
Date: Thu, 6 Mar 2025 20:48:24 +0000
Message-ID: <DM8P223MB0365EF7CA61EF3C599A0CA4EBACA2@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <516140E4-A5BF-4B25-8A38-5D983B975461@gmail.com>



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Marvin
> Scholz
> Sent: Donnerstag, 6. März 2025 21:02
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avutil/log: Replace addresses in log
> output with simple ids
> 
> 
> 
> On 6 Mar 2025, at 20:27, Soft Works wrote:
> 
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Marvin
> >> Scholz
> >> Sent: Donnerstag, 6. März 2025 19:59
> >> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [PATCH] avutil/log: Replace addresses in
> log
> >> output with simple ids
> >>
> >>
> >>
> >> On 6 Mar 2025, at 19:16, Soft Works wrote:
> >>
> >>>> -----Original Message-----
> >>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> >> Marvin
> >>>> Scholz
> >>>> Sent: Donnerstag, 6. März 2025 18:49
> >>>> To: FFmpeg development discussions and patches <ffmpeg-
> >> devel@ffmpeg.org>
> >>>> Subject: Re: [FFmpeg-devel] [PATCH] avutil/log: Replace addresses
> in
> >> log
> >>>> output with simple ids
> >>>>
> >>>>
> >>>>
> >>>> On 6 Mar 2025, at 18:44, Soft Works wrote:
> >>>>
> >>>>>> -----Original Message-----
> >>>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> >>>> Marvin
> >>>>>> Scholz
> >>>>>> Sent: Donnerstag, 6. März 2025 18:38
> >>>>>> To: FFmpeg development discussions and patches <ffmpeg-
> >>>> devel@ffmpeg.org>
> >>>>>> Subject: Re: [FFmpeg-devel] [PATCH] avutil/log: Replace addresses
> >> in
> >>>> log
> >>>>>> output with simple ids
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 6 Mar 2025, at 18:02, Soft Works wrote:
> >>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf
> Of
> >>>>>>>> Nicolas George
> >>>>>>>> Sent: Donnerstag, 6. März 2025 11:09
> >>>>>>>> To: FFmpeg development discussions and patches <ffmpeg-
> >>>>>> devel@ffmpeg.org>
> >>>>>>>> Subject: Re: [FFmpeg-devel] [PATCH] avutil/log: Replace
> addresses
> >
> > [..]
> >
> >>>>>>
> >>>>>> First of all I want to say I like the idea of having cleaner
> logs,
> >>>>>> but...
> >>>>>>
> >>>>>> IMHO "complex" logging formatting should be handled by fftools
> >>>>>> especially if
> >>>>>> they need global state. Even though thats not the case right now,
> >> but
> >>>>>> just
> >>>>>> like Nicolas I also would prefer to not add even more global
> state
> >>>> for
> >>>>>> logging
> >>>>>> to the library...
> >>>>>>
> >>>>>> All the fancy log formatting should be done in a log callback in
> >> the
> >>>>>> fftools and the default library logging callback should just be a
> >>>> very
> >>>>>> basic
> >>>>>> one, is my opinion on this.
> >>>>>
> >>>>> That's all fine and probably reasonable. But is it fair to block a
> >>>> small change because some major rework would be desired at some
> >> point?
> >>>>>
> >>>>> When that change will be made, it will of course move out this
> >> little
> >>>> change as well.
> >>>>>
> >>>>> But are you really saying that this small change cannot be made
> >>>> because you don't like the general way of the current
> implementation?
> >>>>>
> >>>>
> >>>> Just to be clear, I am not blocking this, just wanted to give my
> >>>> perspective on the topic.
> >>>> So if others think its fine and want it, lets go for it.
> >>>
> >>> Thanks - and sorry for my retardation, I just realized why it's bad
> to
> >> do it this way with regards to library usage. I'll add a callback so
> >> that fftools can do the prefix formatting.
> >>>
> >>> For the idea of moving all the formatting to fftools, wouldn't this
> be
> >> a major breakage for library consumers who are used to getting the
> log
> >> output formatted like now?
> >>>
> >>
> >> Yeah, one of the reasons why I did not really do any work on this yet
> as
> >> I am really
> >> not sure whats the best way to go about this to not be too surprising
> >> for existing
> >> library users...
> >
> > I think, people _do_ want the formatting even when using the libs
> directly, so while separating formatting from the plain logging might
> make sense, it would probably still need to be in avutil - otherwise
> most consumers would probably be annoyed and have to copy the formatting
> code from fftools to their own code base (or similar) - which wouldn't
> be a win for anybody.
> 
> Right, I do think it might be useful to have helpers to make log
> formatting easier for library users (especially because as the final
> consumer you can then decide where to put some eventual state needed),
> and maybe also some to make it easier to obtain logging details from
> AVClass as this is right now somewhat hard to get right and I had to
> check the source code last time to figure out how its done.
> 
> > I see why the global state is bad with regards to this patchset's
> feature (and V3 will remedy), but avoidance of global state would be
> much easier and also make more sense if there was some kind of "local
> state" as a replacement, so that people could for example have separate
> log outputs when performing separate and independent operations.
> > I suppose that's not easy to achieve with the current architecture?
> 
> Yeah, I think the end goal should be to have a way to not have a global
> log callback, however that would require quite a bit of
> redesign. 

Alright I thought so, just questionmarked because - with my patterns of thinking being dominated by object-oriented logic - I've been sometimes surprised by approaches in procedural languages to achieve similar things.

> A sort of hacky way right now to do this is use of thread local storage
> and then "demultiplex" the messages in the log callback
> based on that. However that only works as long as the message does not
> come from a "child" thread internally spawned by FFmpeg.

That's probably only feasible in very specific cases where you (as the consumer) know that it works.

The absolute minimum of an approach I can think of would be something like a "context_id", but it would need to (more or less) "auto-propagate" from context to context for all contexts that are being created - which sounds like a major change.


So, down to earth, for V3 of the patchset I have added a callback (av_log_formatprefix_callback) and a function to register (av_log_set_formatprefix_callback()) to log.c and the actual formatting (plus global state) is done in fftools now.

I realize that this is a much better way. Thanks for the feedback.

sw






_______________________________________________
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-03-06 20:48 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-05 15:38 softworkz
2025-03-05 15:40 ` Nicolas George
2025-03-05 15:45   ` Soft Works
2025-03-05 15:48   ` Soft Works
2025-03-06 10:08     ` Nicolas George
2025-03-06 17:02       ` Soft Works
2025-03-06 17:38         ` Marvin Scholz
2025-03-06 17:44           ` Soft Works
2025-03-06 17:49             ` Marvin Scholz
2025-03-06 18:16               ` Soft Works
2025-03-06 18:58                 ` Marvin Scholz
2025-03-06 19:27                   ` Soft Works
2025-03-06 20:01                     ` Marvin Scholz
2025-03-06 20:48                       ` Soft Works [this message]
2025-03-06 20:56       ` Soft Works
2025-03-05 15:42 ` Soft Works
2025-03-05 16:23 ` Gyan Doshi
2025-03-05 16:30   ` Soft Works
2025-03-05 17:14     ` Gyan Doshi
2025-03-05 18:19 ` [FFmpeg-devel] [PATCH v2 0/3] " ffmpegagent
2025-03-05 18:19   ` [FFmpeg-devel] [PATCH v2 1/3] " softworkz
2025-03-05 18:19   ` [FFmpeg-devel] [PATCH v2 2/3] fftools/opt_common: add memaddresses log flag softworkz
2025-03-05 18:19   ` [FFmpeg-devel] [PATCH v2 3/3] doc/fftools-common-opts: document " softworkz
2025-03-06 10:04   ` [FFmpeg-devel] [PATCH v2 0/3] avutil/log: Replace addresses in log output with simple ids Nicolas George
2025-03-06 16:38     ` Soft Works
2025-03-06 16:43       ` Nicolas George
2025-03-06 17:05         ` Soft Works
2025-03-06 17:38           ` Soft Works
2025-03-06 20:59   ` [FFmpeg-devel] [PATCH v3 0/4] " ffmpegagent
2025-03-06 20:59     ` [FFmpeg-devel] [PATCH v3 1/4] avutil/log: Add callback for context prefix formatting softworkz
2025-03-06 20:59     ` [FFmpeg-devel] [PATCH v3 2/4] fftools/opt_common: add memaddresses log flag softworkz
2025-03-06 20:59     ` [FFmpeg-devel] [PATCH v3 3/4] fftools: Provide a log formatting callback for context prefixes softworkz
2025-03-06 20:59     ` [FFmpeg-devel] [PATCH v3 4/4] doc/fftools-common-opts: document memaddresses log flag softworkz

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=DM8P223MB0365EF7CA61EF3C599A0CA4EBACA2@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM \
    --to=softworkz-at-hotmail.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