My previous response got sent out too early by accidence. This is the complete one.
> -----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" well to XML and JSON constructs. It also mapped surprisingly well to the Mermaid diagram format, which is why I wouldn't consider it that bad. > 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. Does it really need to be something entirely different from the current sections concept? I'm not sure about that part - I was thinking that it could be refined to better map to XML and JSON formats.. Thanks for your thoughts, sw _______________________________________________ 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".
