[FFmpeg-devel] [PATCH v2 0/8] [RFC] avtextformat: Transform text writing into an independent API

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Freitag, 28. Februar 2025 14:52
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2 0/8] [RFC] avtextformat: Transform
> text writing into an independent API
> 
> ffmpegagent (HE12025-02-28):
> > This patchset doesn't aim to improve or change the API itself - that
> would
> > be a bit too much at once.
> 
> So you asked for advice, got come counsel from me and did exactly the
> opposite. Do not be surprised if the result is less than satisfactory.

Hi Nicolas,

I didn't do the opposite. I did what you mentioned in your last sentence as a future goal.

Your immediate suggestion was to extract a "low-level writer" for JSON in avutil. This isn't reasonably possible, because the JSON writing code strongly depends on types only present in ffprobe, namely: Writer, WriterContext, Section, SECTION_ID_*, WRITER_FLAG_*, SECTION_FLAG_*

A low-level writer that is independent from all of this would hardly contain much code anymore, because all of the implementation would have to remain in the ffprobe.c code which wraps it.
In turn, nothing would have been won in doing so. That's why I opted for a larger step.


> > * Public API isn't documented yet
> 
> When designing a public API, the user documentation, and in particular a
> quick-start guide with clear examples, should be the first thing you
> show, and probably even one of the very first things you write.
> 
> Without that, I can only repeat what I told you two days ago:
> 
> The writers in ffprobe are an ad-hoc construction to turn the shallow
> data structures produced by ffprobe into a common denominator of JSON,
> XML, CSV and a few custom formats. It is not a good candidate to be
> turned into an API.

I have turned it into something that is generally usable in other places without being specific to ffprobe requirements.

The reason why I haven't added documentation and examples yet (and marked it [RFC]) is because I'm
not sure whether it's ready in this form to become a public API and that's what was asking about.
If the answer would have been 'yes', then I would of course add all the things you mentioned.

But from your comment I figure that it's not. I will update the patchset by moving the text format API files to fftools for local use only. Then we can refine the API there until it is in a shape for becoming a public API and you are of course welcome to join the work on it and bring in all the things that you are envisioning.

Thanks
sw