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
_______________________________________________
ffmpeg-devel mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
