> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Nicolas George > Sent: Donnerstag, 24. April 2025 19:12 > To: FFmpeg development discussions and patches <ffmpeg- > de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [RFC] Shaping the AVTextFormat API Surface > > 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.
Now it rather seems that you are ignoring that I have explicitly acknowledged that, by saying that in this form, it is not yet ready for becoming a public API in avutil, so we are kind of on the same page in this regard, albeit you seem to have some more radical changes in mind than I do, but that's fine - let's talk about it! > 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. Sure, neither XML, nor JSON nor YML formats have concepts which are the same like the sections of the text formatting APIs. But right now, the sections-concept already maps "more-or-less" > > 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". _______________________________________________ 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".
