Jean-Baptiste Kempf (12022-08-18): > Those plans files become outdated very quickly and are often not maintained. > Or they become infinite unicorn-wishlist things. > Or they become a blocking task for the project.
Or I might be hit by a bus. Or I might decide to try heroin and overdose because it was cut with fentanyl. Or… If we always focus on the worst-case scenario, we never go forward. Worst case scenario here? It becomes blocking, we discuss to remove it, wasted a little time. Less worst case scenario: it becomes an unicorn-wishlist, somebody finds something doable in it and starts contributing to the project. Anyway… > I have NO opinion on AVWriter, but just show the API and documentation before > implementing it. > Once people agree on the API need and form, just implement it, I don't see > the need for a plans.md file for that. Hum, I like that idea. For AVWriter, much of the API itself is macros and inline functions, but it is a minor issue that I can work around. “Once people agree” means applying it; I hope nobody will bikeshed the idea of pushing a .h file with no implementation I insist that I am not doing this to “preemptively shield [my] code from criticism”, like Anton disingenuously said. If that was the case, I would not have written “The resulting patches will be subject to technical review like any other patches”. What I am trying to do is to find a way to discuss broad strokes before investing time in details, because without it the project is condemned to immobility because of naysayers. It is not specific to AVWriter, it is not specific to me. If we had that procedure at the time the new channel layout API was implemented, then we could have discussed it to take into account the needs of users, filters, advanced formats and devices and now have a great channel layout API. Instead, we had to salvage one that was not designed with these considerations in mind, but because it was a series of 279 patches, nobody dared send it back for complete redesign as we should have. I find this borderline dishonest. Depending on the responses to this mail, I will send a patch to add avwriter.h and doc/avwriter.md and start the actual discussion. Regards, -- Nicolas George
signature.asc
Description: PGP 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".