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

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

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of softworkz .
> Sent: Dienstag, 29. April 2025 20:07
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Shaping the AVTextFormat API Surface
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@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.



Additional thoughts:

[Stefano]
> > 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.
[Nicolas]
> 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.


This illustrates the kind of misunderstanding that appears to
exist, and in this regard, I think, it's important to clear up about 
which kind of API we are talking about and which purposes it is meant
to serve and which not:


The AVTextFormat feature allows to create output data in a wide range
of formats from a generic API that is agnostic to the format.
It is not a format-specific API providing full-featured formatting for
any format.
That's the nature of this API and it won't change as it cannot change.


> it must be usable for all the
> places we are already producing XML. Otherwise it does not make sense

How do you come to that idea? It's a generic, format-agnostic 
text formatting API. It is not an XML API.

I didn't even get it in the first place that that's what you mean,
it's somewhat far off... Hence I also need to clarify this:
Where I said above that it should be able to cover all use cases, I 
meant "all use cases that need multi-format text output".
But not: all cases that need full-featured XML output PLUS all cases
that need full-featured JSON output PLUS all cases that need full-
featured CSV output PLUS all cases that need full-featured YAML 
output, etc.


If you want to create a full-featured XML writer that's fine, it's 
just something different from the AVTextFormat API.


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-request@ffmpeg.org with subject "unsubscribe".