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

[Anton Khirnov <anton@khirnov.net>]

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-request@ffmpeg.org with subject "unsubscribe".