[FFmpeg-devel] [PATCH v0] Implement promeg decoder.
Nicolas George
george at nsup.org
Mon Jan 20 16:30:40 EET 2025
James Almer (12025-01-17):
> I don't see how the GA has anything to do with this when we're talking about
> one person, but you're not wrong in that rejecting a feature for being
> incomplete is not ideal.
> The codebase is not lacking in partially implemented features and protocols,
> and as long as it's stable, is not invasive, and gracefully rejects
> unsupported scenarios, IMO it should be ok.
How many partially implemented or experimental features can you quote
that have been added in the recent years, when the GA has been in
authority with the current structure?
Last year, there was the software-defined radio proposal. It was
big but non-invasive and easy to remove in case of issue. It was
rejected with an arbitrary “does not belong in ffmpeg”. It did not go to
vote, because it was so obvious for everybody involved that the
opponents had the numbers with a wide margin.
A little older, that I mention because it is close to me, there was the
ground-work necessary for enhancing the utility API: error reporting,
built-in documentation, uniform API for different types of objects,
etc.: rejected “does not belong in ffmpeg”, would have been a waste of
time to go to vote.
This last point is what convinced me to stop investing time on ffmpeg as
long as the GA has authority: why spend effort when a bunch of people
who barely understand the project can send all my efforts to waste
because they consider anything that does not profit them immediately and
might hypothetically make more work for them?
This “it does not belong in ffmpeg” attitude in the GA is killing the
project. It needs to stop. We need somebody in charge who understands
what ffmpeg really is.
--
Nicolas George
More information about the ffmpeg-devel
mailing list