softworkz . (HE12025-04-22): > AVTextFormatter Implementations > > - print_section_header > - print_section_footer > - print_integer > - print_string
> TextFormat API > > - avtext_context_open > - avtext_context_close > - avtext_print_section_header > - avtext_print_section_footer You are ignoring one of the main reasons I gave: this API is far from acceptable as is in libavutil because it is way too specific to ffprobe. ffprobe has a concept of sections, and no more. XML does not have a concept of sections. JSON does not have a concept of sections. CSV does not have a concept of sections. Other parts of FFmpeg that could benefit from it do not, or they may have subsection, subsubsections, etc. Applications that may use this API even more so. The proper way to go at it involves two steps. These steps might overlap, but not by much. The first one is rather easy but long. The second one can be quick but it is much harder. The first step is adding each format into libavutil separately, with distinct APIs tailored for the specificities of each format. The APIs should run parallel whenever possible, i.e. use similar names and prototypes for things that make sense in multiple contexts. But other parts will be completely unique to certain formats. So: av_json_enc_…(): adding objects (dictionaries), arrays, strings, numbers, booleans, null values; controlling the indentation, the kind of quotes, the encoding. av_xml_enc_…(): similar, but: no concept of numbers, booleans, null; and: control over attributes / nested elements, CDATA sections, comments. av_csv_enc_…()… For each API, the parts of ffmpeg already do the same should be converted to use it. That means the ffprobe writers of course, but not only. If the XML writing code is not usable by dashenc, movenc, smoothstreamingenc, vf_signature, ttmlenc, etc., back to the design step. We might skip that for the formats that are entirely invented here. Or some of them. The second step is designing a common interface for all the formats. That means finding an almost-common denominator to all the formats, finding a way to express it even in formats that are not powerful enough, but also finding ways to tweak the output when the format is more powerful. This is hard. I have some ideas on what the common API needs to look like to encompass XML and JSON, and I think that with those two done the others could be made to work, bit it is not as clear in my mind as other plans I have. Anyway, the first step is already enough work to occupy somebody for some time. Also: these APIs can end up being used by things like the showinfo filters, and called once per frame. That means they must be fast, and in particular they should not need dynamic allocations as long as the objects are small. -- Nicolas George _______________________________________________ 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".
