On Sat, Apr 29, 2023 at 08:27:32PM +0200, Anton Khirnov wrote:
> Quoting Nicolas George (2023-04-29 19:11:52)
> > Anton Khirnov (2023-04-29):
> > > As far as I can see, there are exactly two places in the codebase that
> > > produce JSON: af_loudnorm and ffprobe.
> > 
> > I think I remember finding a few other places, but it does not matter
> > much.
> > 
> > Users have been askingš for parse-friendly output from filters for years,
> > and JSON is often the format they prefer. Therefore, all the filters
> > that log useful information are candidates where a JSON writing API is
> > useful.
> 
> libavfilter is a C library with a C API. Any structured output from
> filters should be in the form of a C object, typically a struct. I do
> not see why are you so in love with strings, they make for terrible
> APIs.

There are many projects which use libavcodec, format, filter
Human users use these projects

If the standarization is at a C struct level only then the human interface
for each application can be different.
Thats fine if the 2 cases use fundamentally different interfaces like a
GUI draging, droping and connecting components vs some command line
interface.
But if 2 applications both use command line / string based interfaces
it would be nice to the human user if she could use/learn the same syntax
and transfer a working example / script from one to the other.

So i think strings do matter for C libs because of that.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The day soldiers stop bringing you their problems is the day you have stopped 
leading them. They have either lost confidence that you can help or concluded 
you do not care. Either case is a failure of leadership. - Colin Powell