[FFmpeg-devel] [PATCH v0] Implement promeg decoder.

[James Almer]

On 1/20/2025 11:30 AM, Nicolas George wrote:
> 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?

Partial support for MV-HEVC, partial support for IAMF (no rendering, 
only demuxing/muxing), partial support for tiled HEIF (no stitching), 
the new VVC decoder that's afaik not 100% complete, a PTS reorder bsf 
that's missing some edge cases and support for HEVC and VVC, plus other 
stuff i don't recall right now.

Things are partially implemented all the time.

> 
> 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.
I don't believe the kitchen sink approach is better, either. Some things 
really don't belong in our libraries.

And your strings API faced opposition (and not rejection, because no 
vote happened for that) not because it didn't belong in ffmpeg (There's 
one already, also by you), but because others either didn't consider it 
worth the complexity, or didn't like its design.
The way to move that forward is to address the concerns, changing the 
design if needed, or convincing the other parties that it's good as is, 
and if no consensus is reached, the TC can then be invoked to make a 
decision. And ultimately, the GA can be also invoked if someone wants 
that decision overruled, but i consider this excessive because the TC 
was precisely elected by the GA to handle this stuff.

I'd really like if we can stop with the "Everything's fucked, nothing 
can be done" mails every other week and instead make use of the 
framework we came up with, or if needed, change it and improve it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20250120/3c69c5cc/attachment.sig>