On date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote: > Anton Khirnov (12023-12-14): [...] > > I have to strongly disagree. This is neither practically workable, > > nor a good goal to aim at. > > And I strongly agree with Stefano. Having the tools just thin wrappers > around the libraries is the only way to ensure the libraries are > maximally useful for other applications. Otherwise, useful code will > only reside in the tools and be only available through a clumsy > command-line interface. > > > This mindset IMO inevitably leads to (among > > other problems):
> > * endless scope creep Scope creep is a general tendency in software, as it tends to grow with more functionality and use cases in mind (FFmpeg itself started as an MPEG decoder). OTOH there is good and bad scope creep, it is bad if the functionality goes beyond the original design and core use case, or if the extension is not carefully designed and suffers from assumptions which limit how the software can be used. For example, making constraints about where the main thread can be executed. (Unrelated note: I greatly appreciate Anton's threaded architecture endeavor, and I'm fine with the idea that something can result broken as a consequence of a major redesign, but I also think we should fix what can be fixed rather than just dismiss that as "not useful". Also this is a community project, so it's not only Anton's responsibility to fix that, since we all benefit from his work). > > * bloated, inefficient, and buggy libraries, trying (and failing) to > > support every use case under the sun > > * myopic API design aimed at fulfilling the needs of precisely one > > caller; this is a problem e.g avfilter badly suffers from, and to a > > lesser extent avformat Note that these two statements conflicting. If you try to support most of the use cases, it will be flexible by definition. For example, if we design the API to be only usable from ffmpeg.c, it will be limited in scope and usefullness. Desigining something which is generic, flexible, and efficient at the same time is hard, but that does not mean that it cannot be done. > I see no argument supporting this opinion of yours. Quite the opposite, > over the years, Stefano and others, including me, have made some headway > in this direction without hitting these pitfalls. Same here, these sound like vague statements, and I fail to see how they are related to that very generic design vision. _______________________________________________ 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".
