[FFmpeg-devel] [PATCH 2/3] fftools/ffmpeg_graphprint: Add options for filtergraph printing

[Nicolas George]

Soft Works (HE12025-02-24):
> Accepted. I'll outfactor the writers first. It's a valid point of course; 
> I just wasn't sure whether you would dislike me doing it.

I dislike the fact that it will be done on top of a pedestrian or clumsy
strings API, but I know precisely where to lay the blame for that
absurdity and it is not you.

> Should each writer go into a separate code file, or all in one?

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.

The writes make arbitrary decisions about how the data will be
represented. Not much in JSON, but for XML the choices of what is an
attribute and what is an element are very arbitrary. The XML writer in
ffprobe cannot output any (basic) XML file.

That part of the code is not duplicated in your patch anyway. What is
duplicated is the low-level code. So this is where you would be better
off starting.

That would mean something like this:

Move the low-level JSON writing code into lavu, with a low-level API
specific to JSON. Bonus points if the API can be used without dynamic
allocations when the data structure is not too deep.

Use the newly introduced av_json_write API in ffprobe; the JSON writer
becomes a trivial wrapper around it.

Also use it in your patch.

Later, possibly somebody else: do the same with XML. The low-level API
will need to be a little more complex, because XML has more room for
tweaks.

At some point in the future: unify the JSON, XML and other writers in
libavutil under a common API, but one that can be tweaked for any kind
of input data structure, not just a list of streams/packets/frames with
flat attributes.

Regards,

-- 
  Nicolas George