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

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

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Mittwoch, 26. Februar 2025 15:43
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/3] fftools/ffmpeg_graphprint: Add
> options for filtergraph printing
> 
> 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.

HI Nicolas,

thanks a lot for your advice. I've looked into extracting only the JSON
part, but it has a number of things which are specific to the usage in 
ffprobe and I felt that it doesn't allow for a clean solution when trying
to keep the behavior and create a clean API in avutil at the same time.

Also, the JSON code is just a small part. The big elephant is the core
code, like you said and I so I chose to grab this thing at the root and 
fully generalize that code.

I have done it in a way that it's a public API in avutil, foremost in order
to be sure that it's fully clean and independent.
I'm not insisting that it has to be public. It's surely not there where
you like to have it, but I think it might serve as better basis for that.
Maybe the code can just live in fftools for the time being and serve
both, ffprobe and ffmpeg (graph printing)?

Please let me know what you think.

Thanks
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".