[FFmpeg-devel] [TC] "Future Log Output Default"

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Michael Niedermayer
> Sent: Samstag, 26. April 2025 17:10
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: [FFmpeg-devel] [TC] "Future Log Output Default"
> 
> Hi all
> 
> This is just an announcement that the TC has been asked to look into
>     avutil/log: Add log flag to control printing of memory addresses
>     GitHub:    https://github.com/ffstaging/FFmpeg/pull/59
>     Patchwork:
> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=14094
>     ...
> 
> and the disagreement between people about it.
> 
> So far, Niklas, Martin and myself have commented, there have been no
> formal
> decissions and no votes, we just since yesterday send some comments.
> 
> From these to me it seems the TC members who spoke so far seem to
> agree
> that the addresses in the log are "mostly noise".
> 
> I wonder a bit if the TC discussions should/could be more public but
> thats
> a subject for a different thread. Myself summarizing will surely miss
> some
> fine points but iam trying anyway.
> 
> Niklas also brought up that item_name() is used in filters to
> disambiguate
> instances and that we maybe could add a const char *name and have
> fftools
> genrate a unique ID for each
> 
> Either way none of this is a TC decission or binding its just a
> partial
> summary of the things that TC members said
> 
> thx
> 
> --
> Michael     GnuPG fingerprint:



Thanks Michael,
hello everybody,

I would like to note that my reason for handing this over to the TC was not primarily about conflict resolution, it's rather that I feel that this decision is at least one size too big for me standing right in the front line.

Ideally, I think, it would be great when it would be backed by a majority, but I wouldn't know how to determine that other than a vote. The TC in turn has already been elected for making those decisions and so that seems to be the most natural way. I'm fine with any outcome, also open to do once another variant of implementation if that would be desired, or just keep the default to current behavior if that's the verdict.

Thanks
sw


-------------- next part --------------
An embedded message was scrubbed...
From: Michael Niedermayer <michael at niedermayer.cc>
Subject: Re: [FFmpeg-devel] [PATCH 1/2] tests: Add stream dump test API util, use it to dump stream data for chained ogg/{vorbis, opus, flac} streams.
Date: Sat, 26 Apr 2025 03:11:23 +0000
Size: 19273
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20250426/f1a871e9/attachment.eml>