[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 13:15:27)
> Am 13.12.23 um 13:08 schrieb Anton Khirnov:
> > Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 13:05:35)
> >> Am 13.12.23 um 13:00 schrieb Anton Khirnov:
> >>> Quoting Thilo Borgmann via ffmpeg-devel (2023-12-11 16:07:22)
> >>>> ---
> >>>>    fftools/ffmpeg.h          |  31 +------
> >>>>    fftools/ffmpeg_enc.c      |   3 +-
> >>>>    fftools/ffmpeg_mux_init.c | 152 +++-----------------------------
> >>>>    libavutil/parseutils.c    | 176 ++++++++++++++++++++++++++++++++++++++
> >>>>    libavutil/parseutils.h    | 102 ++++++++++++++++++++++
> >>>>    libavutil/version.h       |   2 +-
> >>>>    6 files changed, 296 insertions(+), 170 deletions(-)
> >>>
> >>> Absolutely not.
> >>>
> >>> This is application code and does not belong in the libraries.
> >>
> >> How else do we not have a redundant copy of all that and make sure that -stats_* options and the filter understand the same {..} directives?
> > 
> > Why does that filter need to understand the same directives? No other
> > filter does.
> 
> Because it is meant to use the file(s) the -stats_* option writes out. The most convenient and most error resilient way is to use the very same format string for -stats_* option as well as for the filter.
> 
> Otherwise it could be a 'usual' scanf-format, but then the user has to translate it from one format into the other - without making mistakes.
> But that would also mean to update the filter (if someone realizes it) if the option ever changes.

Why does it need a dynamic format at all? Just postulate a fixed format
for its input like every other filter and none of this complexity is
needed.

-- 
Anton Khirnov