Quoting Stefano Sabatini (2023-12-16 16:18:07) > 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".
The entire question here is whether SDL muxing is useful enough to warrant massive hacks in ffmpeg CLI. > > > * 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. There is a subtle but important difference between * an interface that goes out of its way to explicitly support a large number of specific usecases * an interface that is generic and flexible enough to be applicable to a wide range of cases The crucial distinction is that the first case is about your code doing MORE, while the second is about doing LESS. -- Anton Khirnov _______________________________________________ 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".
