[FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue

[Stefano Sabatini]

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.