Niklas Haas (HE12025-02-17): > From: Niklas Haas <g...@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_type=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_type=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. > 2. graphdump.c does not know anything about buffersrc/buffersink filters or > input/output names, which is why this implementation has to live inside > ffmpeg_filter.c. I find this a very feeble reason to duplicate the feature. > It's possible that we could instead move this implementation to graphdump.c as > well, though that would require some sort of explicit callback to get the > names > for buffer sources / sinks, to avoid breaking the first design goal. It would be enough to add “const char *name_in, *name_out;” to AVFilterLink. Or a single parsed_name field to AVFilterPad. Regards, -- Nicolas George _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
