Re: [FFmpeg-devel] [RFC] Shaping the AVTextFormat API Surface

["softworkz ." <softworkz-at-hotmail.com@ffmpeg.org>]

My previous response got sent out too early by accidence.
This is the complete one.

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Donnerstag, 24. April 2025 19:12
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@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-request@ffmpeg.org with subject "unsubscribe".