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.

-Thilo

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to