From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <ffmpeg-devel-bounces@ffmpeg.org>
Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100])
by master.gitmailbox.com (Postfix) with ESMTPS id E8C964C6A4
for <ffmpegdev@gitmailbox.com>; Tue, 8 Apr 2025 22:24:46 +0000 (UTC)
Received: from [127.0.1.1] (localhost [127.0.0.1])
by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 52046689E81;
Wed, 9 Apr 2025 01:24:42 +0300 (EEST)
Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net
[217.70.183.193])
by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 39A02687C9A
for <ffmpeg-devel@ffmpeg.org>; Wed, 9 Apr 2025 01:24:36 +0300 (EEST)
Received: by mail.gandi.net (Postfix) with ESMTPSA id 897E14326A
for <ffmpeg-devel@ffmpeg.org>; Tue, 8 Apr 2025 22:24:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc;
s=gm1; t=1744151075;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=S1fkfiEVMhEc/xV/fIJs0kcZsCUOEM8cW/j2aV1T99w=;
b=AJjsWGEUjWCkiOqbUtG8W586Qx9kuKJmIyjz+KwDjcNX547fCg9NyXb2qvlUpNQg9S7SsI
z9i3dkGLbNg/iroUIz3oXLr5rhzxXdN2pWPf3vca8KUtRBeMMm6ovlib8RZ0VtSsoGXlzB
K6DUW2V13K/Bv3IEgv5YWCdgd+FROgqwF//ivFfOI9YHlrOzWz57htwSGUo07+xpIhVx2J
PzXHvGcdWIHGMuxguk5gR5u8+9LkpYE/G4HMHq0ZARj9bOx2yXDEbjf5W+/z/JkRXVWxye
JS49jgxAVqF8AkU/rZFpGIjcJuvUMIgwAzskTeog7XDqTgo+nd5nRe5zEI+XoQ==
Date: Wed, 9 Apr 2025 00:24:34 +0200
From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Message-ID: <20250408222434.GT4991@pb2>
References: <DM8P223MB0365066DF0B56E60A0E2C4E9BAAF2@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>
<c45a5869-e39e-bc20-0559-079f0b93ca37@passwd.hu>
<DM8P223MB03657732DC376984DF4ED8DBBAAF2@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>
<558752ee-492d-0f3a-6201-329741334f30@passwd.hu>
<DM8P223MB0365AB02BDABE09E48DD7F70BAAB2@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>
MIME-Version: 1.0
In-Reply-To: <DM8P223MB0365AB02BDABE09E48DD7F70BAAB2@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>
X-GND-State: clean
X-GND-Score: -90
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvtdegvdelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculddutddmnecujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpefoihgthhgrvghlucfpihgvuggvrhhmrgihvghruceomhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtqeenucggtffrrghtthgvrhhnpefhgedtjeefieetudffkeekgeekvdethfektdevudfhuedvieevveekvdetgfetvdenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhffhhmphgvghdrohhrghenucfkphepgedurdeiiedrieejrdduudefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgedurdeiiedrieejrdduudefpdhhvghloheplhhotggrlhhhohhsthdpmhgrihhlfhhrohhmpehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgdpnhgspghrtghpthhtohepuddprhgtphhtthhopehffhhmphgvghdquggvvhgvlhesfhhfmhhpvghgrdhorhhg
X-GND-Sasl: michael@niedermayer.cc
Subject: Re: [FFmpeg-devel] SW's Patchsets Overview
X-BeenThere: ffmpeg-devel@ffmpeg.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: FFmpeg development discussions and patches <ffmpeg-devel.ffmpeg.org>
List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>,
<mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe>
List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel>
List-Post: <mailto:ffmpeg-devel@ffmpeg.org>
List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help>
List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>,
<mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe>
Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Content-Type: multipart/mixed; boundary="===============8011809526677875080=="
Errors-To: ffmpeg-devel-bounces@ffmpeg.org
Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org>
Archived-At: <https://master.gitmailbox.com/ffmpegdev/20250408222434.GT4991@pb2/>
List-Archive: <https://master.gitmailbox.com/ffmpegdev/>
List-Post: <mailto:ffmpegdev@gitmailbox.com>
--===============8011809526677875080==
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="Sp5mZoBt4q+GJTRK"
Content-Disposition: inline
--Sp5mZoBt4q+GJTRK
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi
On Sun, Apr 06, 2025 at 09:12:00PM +0000, softworkz . wrote:
>=20
>=20
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Marton
> > Balint
> > Sent: Sonntag, 6. April 2025 23:05
> > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] SW's Patchsets Overview
> >=20
> >=20
> >=20
> > On Wed, 2 Apr 2025, softworkz . wrote:
> >=20
> > >
> > >
> > >> -----Original Message-----
> > >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Marton
> > >> Balint
> > >> Sent: Mittwoch, 2. April 2025 21:45
> > >> To: FFmpeg development discussions and patches <ffmpeg-
> > devel@ffmpeg.org>
> > >> Subject: Re: [FFmpeg-devel] SW's Patchsets Overview
> > >>
> > >>
> > >>
> > >> On Wed, 2 Apr 2025, softworkz . wrote:
> > >>
> > >>> Hello everybody,
> > >>>
> > >>> with freshly gained push access rights, I want to act responsibly
> > and
> > >>> carefully, and also avoid unexpected surprises so I'm not going to
> > >> rush
> > >>> things. Due to that change, I thought it might be good to post an
> > >>> overview of the patchsets I am intending to push in the near future:
> > >>
> > >> Thanks for the heads up.
> > >>
> > >> [...]
> > >>
> > >>> avutil/log: Replace addresses in log output with simple ids
> > >>>
> > >>> GitHub: https://github.com/ffstaging/FFmpeg/pull/59
> > >>> Patchwork:
> > >> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=3D14094
> > >>
> > >
> > > Hi Marton,
> > >
> > > thanks a lot for looking at the patchset.
> > >
> > >> To be honest, I don't like this at all. You duplicate a lot of code
> > from
> > >> avutil/log, and the implementation has quite a few problems, some of
> > >> them not really fixable.
> > >
> > > Originally, this was a patch against avutil/log. Nicolas objected that
> > > it was adding global state and Hendrik (and Nicolas) suggested that I
> > > should to this in fftools only - outside of the libs, in a was that
> > > fftools get their own logging implementation - with the potential of
> > > being able to do other things in the future that wouldn't make sense
> > in
> > > the lib code. Letting fftools have their own logging implementation of
> > > can of course only start from a copy in order to retain existing
> > > behavior. On top of that I applied that little change then.
> > >
> > >
> > >> - creating object IDs in the order the objects log something (what if
> > >> they do not? What if it depends on loglevel?)
> > >> - tracking object IDs based on their address - objects are
> > >> allocated and removed at runtime, it is possible that an address
> > will be
> > >> re-used for a different object later on
> > >
> > > The Ids are not meant to have much more value than the addresses
> > > currently shown - with an important difference: They are short and
> > > remain the same on repeated execution. Plus: they are counted by
> > > AVClass, that give a little additional value, but since they are just
> > > "indexing" the addresses, they are in fact prone to the same
> > > shortcomings like the addresses themselves, meaning that a re-
> > assignment
> > > might give you the same id for something different and also different
> > > addresses (in consequence the IDs as well) can reference the same
> > thing
> > > (e.g. with buffer refs).
> > >
> > >> - linear search of addresses. A long ffmpeg process can constantly
> > >> create
> > >> objects during runtime, eventually completely depleting the pool
> > and
> > >> causing an extensive search for all future logs.
> > >
> > > I have considered that case. There is a hard limit from when on no IDs
> > > are assigned anymore (all zeros).
> > >
> > >
> > >> So overall I don't think it's worth pursuing this, especially since
> > most
> > >> users won't care neither about the ID, nor about the address...
> > >
> > > Let me give two examples of where I find it useful to have those IDs:
> > >
> > > On startup decoders can be initialized multiple times, like first for
> > > probing and then for transcoding. Or when there are multiple streams
> > of
> > > the same type (codec), the log messages can be confusing when the log
> > > output from several identical ones gets mixed up. Being able to see
> > > "which is which" is quite of value at times.
> > >
> > > HW Device context can also get initialized multiple times and knowing
> > > which one has shut down already and which hasn't - is helpful. Also,
> > in
> > > case of complex filtergraphs with multiple derived and reverse-derived
> > > hw contexts, one can quickly get lost in understanding the logs.
> > >
> > >
> > > That being said - I don't want to insist on those IDs. We could also
> > > just hide the addresses (activatable by a log flag) and I'd still be
> > > happy about being able to do logfile diffs in the future without
> > trouble
> > > =F0=9F=98=8A
> > >
> > > In that case, the change could also be made just in avutil/log.
> > Probably
> > > also depends on what the consensus would be regarding the value of
> > > fftools having their own logging implementation - or rather not?
> > >
> > > I'm open for either direction.
> >=20
> > I think a log flag to completely hide the addresses makes sense, and can
> > be implemented cleanly and reliably in avutil/log. I can totally support
> > that.
> >=20
> > Thanks,
> > Marton
> > _______________________________________________
>=20
> Hi Marton,
>=20
>=20
> thanks a lot for your reply. As nobody has voiced in favor of the simple =
ID replacement, I'm fine to go that way.
>=20
> There's one point remaining though: The intention was to hide the address=
es by default and allow to enable them via flag. Two earlier commenters wer=
e seconding that, a third one not explicitly objecting. It was only said th=
at it must be possible to enable it again by flag.
In the long run maybe some
int instance_name_offset;
in AVClass that points to a place in each instance where the name is stored
This can then be set when the objects are allocated or initialized and could
also be overridden by the user application, storing other names
would everyone agree with that ?
thx
[...]
--=20
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
--Sp5mZoBt4q+GJTRK
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZ/WiHwAKCRBhHseHBAsP
q3qlAKCRI44t5c0obxtUid3qExRuQOjbuQCdEeLpl62tXgSiI7OEZhH/WotilyI=
=fmlQ
-----END PGP SIGNATURE-----
--Sp5mZoBt4q+GJTRK--
--===============8011809526677875080==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
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".
--===============8011809526677875080==--