[FFmpeg-devel] [PATCH v3 1/7] fftools/textformat: Extract and generalize textformat api from ffprobe.c

Stefano Sabatini stefasab at gmail.com
Sat Mar 8 16:36:34 EET 2025


On date Saturday 2025-03-01 10:01:58 +0000, softworkz wrote:
[...]

> +int avtext_context_open(AVTextFormatContext **ptctx, const AVTextFormatter *formatter, AVTextWriterContext *writer, const char *args,
> +                        const struct AVTextFormatSection *sections, int nb_sections,
> +                        int show_value_unit,
> +                        int use_value_prefix,
> +                        int use_byte_value_binary_prefix,
> +                        int use_value_sexagesimal_format,
> +                        int show_optional_fields,
> +                        char *show_data_hash);

writer -> writer_ctx?

I'm fine with changing this later to avoid massive rebase edits.

Also I notice there is some of the usual inconsistencies here:
av_X_Y against avXY and avX_Y that we have in the rest of the code.

Maybe let's stick to avX_Y or to av_X_Y.

Also this might be:
av_text_format_open(...)
av_text_format_close(...)
av_text_format_print_X(...)

Or to simplify we can just call the structure AVTextContext (I see
text as an evolution of a string, meant for structured formatted data,
which is implied by the fact that we need a formatter) and simplify
related functions naming to:
av_text_open(...)
av_text_close(...)
av_text_print_X(...)

av_text_formatter_...
av_text_writer_open...
av_text_writer_close...

In fact I don't think there is much gain in keeping "context" in the
name of the functions.

What do you think?

Again, since this is not public API (yet?) this should not be
considered a blocker (also I've been out of touch with FFmpeg and I
might be not aware of API conventions evolution).


More information about the ffmpeg-devel mailing list