Hi all, Yesterday's conflict around libavfilter and premultiplied-alpha support has reached a point where we risk losing valuable contributors. I would like everyone 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 libavfilter framework code. * Niklas has contributed substantially more to that code in the last two years. * 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 perform the required conversion instead. * On May 1, Nicolas offered Niklas time to implement a proper replacement and asked how much time he needed. No timeframe was agreed. * On July 27, after approximately three months, Nicolas pushed the revert as 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 submitted 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 should not have remained unresolved for months. At the same time, knowingly leaving 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 resolve 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 conversion filter for video-link properties, including alpha-mode conversion. If scale performs that conversion, the additional avfiltergraph retry introduced by 978a0821e should not be necessary. I updated PR #23928. The resulting approach leaves avfiltergraph.c in its original form, uses scale as the conversion filter, passes FATE, and fixes the 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 should 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 stability of negotiation, filter insertion, alpha-mode correctness, compatibility 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 increase 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. That means his objections to framework changes must receive serious technical consideration and cannot simply be ignored. It does not mean that any maintainer may knowingly leave master broken, prohibit all other developers 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 framework? * 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 willing and qualified to take responsibility for it? Any proposed maintainership change should be made explicitly through a MAINTAINERS patch/PR and discussed on the mailing list. It should not happen indirectly through competing pushes into our shared repository. FFmpeg benefits greatly from both Nicolas's long-term knowledge of the framework 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 repeating this conflict. Please let us resolve the code first and the maintainership structure immediately afterward. Thanks, -- 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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
