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.
I don't believe the kitchen sink approach is better, either. Some things really don't belong in our libraries.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.
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.
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
