Am 13.12.23 um 17:28 schrieb Anton Khirnov:
Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 13:50:09)
Am 13.12.23 um 13:39 schrieb 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.
That would unnecessarily limit the user of the -stats_* option to a
specific format if the user also wants to use this filter later.
Either sacrificing the other info the user wanted to process from the
file created or having to run the same command (with distinct format
strings for the -stats_* option) twice. Or do the conversion from his
extensive format into the fixed format manually - without errors.
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.
Very much like for av_parse_ratio().
In contrast to av_get_known_color_name() which actually has just one specific
caller, the CLI.
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.
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.
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.
If the problem is limiting ffmpeg CLI users to a specific stats format,
then you could extend these options to allow writing multiple stats
files with different formats.
This would allow for the same use-case without moving the code to libavutil for
the price of a less versatile filter.
And some non-standard behaviour in the CLI where multiple equal options
override each other, usually.
I find this even less preferable than a fixed forced format.
-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".
