[FFmpeg-devel] [PATCH 2/5] fftools/ffmpeg: move parsing of -stats_* specifiers to lavu/parseutils

[Anton Khirnov]

Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 19:17:04)
> Am 13.12.23 um 17:28 schrieb Anton Khirnov:
> > It is bad practice to design library features around the needs and
> > limitations of a single specific caller.
> 
> The callers here would be the CLI and this filter.

First, public APIs should be designed for general classes of use cases,
not specific callers.

Second, you just said above that the reason you are moving this code
into libavutil is specifically because ffmpeg CLI currently behaves in a
certain way. This is the opposite of proper design, AKA an ad-hoc hack.

> Very much like for av_parse_ratio().
> In contrast to av_get_known_color_name() which actually has just one specific caller, the CLI.

No, not at all like any of these. A ratio or a color are generic
concepts that are not tied to a specific use. By contrast this code is
very much speficic to current ffmpeg CLI processing model. I know this,
because I wrote it.

> Other parsing functions have more callers, some including the CLI.
> And it makes only sense if we offer the same format anywhere for reading/writing the same thing.
> 
> This approach follows what we already do.

It most certainly does not. It _might_ make slightly more sense if it
were a generic pattern decoupled from specific properties being parsed
and used across many filters and/or other modules. But that's now what
is happening here.

> > Many of the directives supported by -stats* make sense only in the
> > context of the ffmpeg CLI, and we may want to add many more in the
> > future. We definitely do not want to hardcode them into libavutil public
> > API.
> 
> At least three of them are already useful for this filter outside of
> the CLI.

Out of 18.

> Others might be useful for other/new uses cases as well and
> all of them would be useful if you'd want e.g. overlay them on top of
> the video.

"Someone might want to use it somehow" is generically true of any
definable value at all, and so does not work as an argument for why
these specific values should be particularly useful to users of this
specific API.

-- 
Anton Khirnov