libavfilter conflict, technical resolution and maintainership

--===============0774758064806304446==
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="PO/3xW18zK1Cs/cZ"
Content-Disposition: inline


--PO/3xW18zK1Cs/cZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi all,

Yesterday's conflict around libavfilter and premultiplied-alpha support has=
 reached a point where we risk losing valuable contributors. I would like e=
veryone to lower the temperature and focus on resolving both the technical =
issue and the underlying maintainership problem.

First, some relevant facts:

* Nicolas is currently listed in MAINTAINERS for the libavfilter framework =
and orphaned filters.
* Nicolas has substantially more historical experience with the common liba=
vfilter framework code.
* Niklas has contributed substantially more to that code in the last two ye=
ars.
* Nicolas raised objections to the premultiplied-alpha changes in July and =
August 2025:
  https://ffmpeg.org/pipermail/ffmpeg-devel/2025-July/347102.html
  https://ffmpeg.org/pipermail/ffmpeg-devel/2025-August/347335.html
* In December 2025, commit 978a0821eeb909d7b2cb777bed03a8fc380e9503 changed=
 the format-negotiation retry behavior. Nicolas objected.
* On April 25, Nicolas proposed reverting it and argued that scale should p=
erform the required conversion instead.
* On May 1, Nicolas offered Niklas time to implement a proper replacement a=
nd asked how much time he needed. No timeframe was agreed.
* On July 27, after approximately three months, Nicolas pushed the revert a=
s commit cd9d265344b1d39c7b65eb018acac0478c5d736a.
* The revert exposed or caused failures in FATE and the EXR paths. Nicolas =
restored a green FATE run by disabling the affected tests, while I submitte=
d PR #23928 to fix the EXR and alpha-conversion problems:
  https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/23928
* At the end of the day, the reverted change was reapplied.

This history matters. Nicolas's technical objections were not new and shoul=
d not have remained unresolved for months. At the same time, knowingly leav=
ing master with broken functionality or disabling substantial test coverage=
 is not a safe way to resolve the disagreement. Immediately reapplying the =
disputed change over the listed maintainer's objection also does not resolv=
e the underlying technical or organizational problem.

We need to stop the revert/re-revert cycle now.

My current technical assessment is that scale should remain the general con=
version filter for video-link properties, including alpha-mode conversion. =
If scale performs that conversion, the additional avfiltergraph retry intro=
duced by 978a0821e should not be necessary.

I updated PR #23928. The resulting approach leaves avfiltergraph.c in its o=
riginal form, uses scale as the conversion filter, passes FATE, and fixes t=
he reported EXR tests. This needs to be evaluated through normal technical =
review, including tests and analysis of the negotiation invariants.

For the immediate issue, I propose the following:

1. No further revert or reapplication of this disputed framework change sho=
uld be pushed while the replacement is under review.
2. I ask Nicolas and Niklas to review it.
3. Reviews should address concrete technical properties: termination and st=
ability of negotiation, filter insertion, alpha-mode correctness, compatibi=
lity with existing graphs, and FATE coverage.
4. Everyone should stop using insults, personal accusations, ultimatums or =
claims of exclusive control. They make technical resolution harder and incr=
ease the chance that contributors leave.

There is also a maintainership question that we can no longer avoid.

The MAINTAINERS file currently assigns the libavfilter framework to Nicolas=
=2E That means his objections to framework changes must receive serious tec=
hnical consideration and cannot simply be ignored. It does not mean that an=
y maintainer may knowingly leave master broken, prohibit all other develope=
rs from working on the code, or make decisions without review.

Conversely, substantial recent contributions do not by themselves override =
the listed maintainer or unresolved technical objections.

Therefore, I would like clear answers to these questions:

* Nicolas, are you willing to continue maintaining the libavfilter framewor=
k?
* Niklas, are you willing to continue working on libavfilter through review=
 and technical consensus with its maintainers?
* Should additional co-maintainers be added for the framework?
* If Nicolas is no longer willing to maintain it, who is specifically willi=
ng and qualified to take responsibility for it?

Any proposed maintainership change should be made explicitly through a MAIN=
TAINERS patch/PR and discussed on the mailing list. It should not happen in=
directly through competing pushes into our shared repository.

FFmpeg benefits greatly from both Nicolas's long-term knowledge of the fram=
ework and Niklas's recent work. The best outcome is that neither leaves and=
 that we establish a process in which both can work effectively without rep=
eating this conflict.

Please let us resolve the code first and the maintainership structure immed=
iately afterward.

Thanks,

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri

--PO/3xW18zK1Cs/cZ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCamjNwAAKCRBhHseHBAsP
q6cBAKCEfFAptH9BpO7fcI4EkCyljkV/OACfdYos4I54bEmNwgCUUbqJ8PE+emY=
=6Zxs
-----END PGP SIGNATURE-----

--PO/3xW18zK1Cs/cZ--

--===============0774758064806304446==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]

--===============0774758064806304446==--