Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: add -print_filter_graph option

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

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Montag, 17. Februar 2025 13:43
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: add -
> print_filter_graph option
> 
> Niklas Haas (HE12025-02-17):
> > From: Niklas Haas <git@haasn.dev>
> >
> > This developer tool is especially handy when debugging filter graph
> > auto-negotiation, although it can be useful in whatever scenario to
> > get a canonical dump of the fully settled filter graph.
> >
> > To make the result slightly more useful, we omit buffersrc/buffersink
> > filters and instead print the corresponding input/output name. Sadly, this
> > is lossy w.r.t. the link names used in the original filter graph, although
> > the result has the advantage of being in a normalized format.
> >
> > As an example, the following filter graph (taken from FATE):
> >
> >   sws_flags=+accurate_rnd+bitexact;
> >   split [main][over];
> >   [over] scale=88:72, pad=96:80:4:4 [overf];
> >   [main][overf] overlay=240:16:format=yuv422
> >
> > Results in this output:
> >
> > Filter graph:
> >   [0:0] split=thread_type=0x00000000 [L0] [L1];
> >   [L1]
> scale=w=88:width=88:h=72:height=72:flags=+accurate_rnd+bitexact:thread_t
> ype=0x00000000 [L2];
> >   [L2]
> pad=width=96:w=96:height=80:h=80:x=4:y=4:thread_type=0x00000000
> [L3];
> >   [L4] [L3] overlay=x=240:y=16:format=2 [#0:0];
> >   [L0]
> scale=w=iw:width=iw:h=ih:height=ih:flags=+accurate_rnd+bitexact:thread_typ
> e=0x00000000 [L4];
> > Filter links:
> >   L0: yuv420p 352x288 [SAR 0:1] csp:unknown range:tv
> >   L1: yuv420p 352x288 [SAR 0:1] csp:unknown range:tv
> >   L2: yuva422p 88x72 [SAR 0:1] csp:unknown range:tv
> >   L3: yuva422p 96x80 [SAR 0:1] csp:unknown range:tv
> >   L4: yuva422p 352x288 [SAR 0:1] csp:unknown range:tv
> >
> > I do acknowledge the overlap between this and avfilter/graphdump.c, but
> there
> > are a couple of important deviations:
> >
> 
> > 1. graphdump.c prints a "pretty printed" ASCII art graph for human
> consumption,
> >    but the goal here is to print it in a format that can be passed back to
> >    -filter_complex.
> 
> The ASCII art output is shitty indeed. But notice that
> avfilter_graph_dump() takes an options argument that is set from the
> argument of the dumpgraph option. This is precisely meant to allow
> future different output formats.

Well, then the question would be when or whether this future will become a reality?

Or maybe the solution rather lies in the past?

IIRC, I had already submitted a patchset with a complete solution:

- It includes absolutely all relevant information
  - filter string from the command line
  - filter name and description
  - parsed options
  - formats, hw context
  - all input and output pads/connections
    including all format information

- It prints using the same method like FFprobe, so it can print as
  - default
  - xml
  - json
  - csv

- Here's an example JSON output:

https://gist.github.com/softworkz/2a9e8699b288f5d40fa381c2a496e165


I can resubmit it, it's the most comprehensive implementation in this regard.

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