> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Nicolas
> George
> Sent: Dienstag, 29. April 2025 10:31
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Shaping the AVTextFormat API Surface
>
> Stefano Sabatini (HE12025-04-27):
> > Elaborating on this. ffprobe/textformat is based on a notion of
> > hierarchical tree-like data
>
> No, this is not true. FFprobe and all its supporting code is based on
> one level of hierarchy. Just one level, not a real hierarchical
> structure.
>
> > Considering this, there is probably no need to extend the API to cover
> > each possible format full semantics - this at least it is my view.
>
> If we add XML-writing code in libavutil, it must be usable for all the
> places we are already producing XML. Otherwise it does not make sense.
>
> > As I wrote, this was not the purpose of the ffprobe formats in the
> > first place. MOV/DASH requires a specific use of an XML encoder. In
> > theory it might be done using the textformat API in the current form,
> > but it would be probably pretty awkward. We might want to factorize a
> > few generic utilities (e.g. escaping) to avoid code duplication
> > though.
>
> You are going at it backwards.
>
> The goal is not to cram this text writers API forcefully into libavutil
> and then see if it might serve other purposes, which is what softworkz
> is doing.
No, this is not my intention. I thought I had laid it out a number of
times already, but in case it didn't come through clearly, let me
reiterate the agenda that I'm following and proposing:
1. Extract the text formatting from ffprobe.c and transform it into
a generic API
2. Give that API a temporary home inside fftools as a staging area
3. Refine and polish the API inside fftools while adding additional
use cases (like graph printing)
4. Brainstorm and discuss which further changes and refinements are
needed to serve all the use cases that we are envisioning for the
future and apply those changes
5. Move it to avutil once we believe that it's ready for this
=> 1 and 2 are done, 3 is in progress
I'm not proposing to do 5 before 4.
> The API must be able to handle all our use cases from the start. Until
> then, it goes back to the design board.
I never had any different intentions, albeit it can happen that there's
some very specific case that it would not be able to serve.
But it should be able to serve the vast majority of cases, that goes
without saying.
A fundamental point from my point of view though, is that the API
must remain to be built around the sections concept at its core. It's
a strong concept that enables the exchangeability of the text formatters
independent from the individual use case. It has a number of
shortcomings (as has been mentioned already) in terms of how certain
data maps to the schema of individual formats, but there's sufficient
room to extend the sections concept in a way that makes it possible
to get better control of the way how it is represented in certain
output formats (like XML).
Being able to add new formats in a way that these become immediately
available for all use cases is a high value that must not be
sacrificed. Not every format makes sense for all use cases, but
the ability to use all formats without any (or just little) extra
work is (and must remain to be) a key capability of the API.
A YML formatter is already in the pipeline and another very interesting
area is generation of charts in a similar way like the mermaid
diagram formatter.
In that regard I consider it counter-productive to start any new
work that is focused on specific formats (xml, json) only. Any work
for improvement should rather be done on the current formatters
and the existing API (or at least should be compatible with it).
Best regards
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".
