[_Gyan_]

You also have a processing graph for the intermediate filters. So ideally you want graph nodes represented by some identifier which can then be referenced by other nodes.

Unless I misunderstand you, this is already the case. Simple or complex filtergraphs are declared as a string* by the user as an arg to -vf/-af (per-output) or -filter_complex/-lavfi (global). Filter outputs can have link labels, which allow their consumption by other filters.

*can also be read from a file

[the8472]

Yeah, but that's just part of the overall parameters. with a structured file format (toml, yaml, json... pick your poison) the filter arguments could also be structured themselves instead of having to be a single string, just another nesting level among the other params. The shell only so many ways of structuring things until you run out of seprator chars. And already has to deal with the impedance mismatch of translating space-separated args into an array of zero-terminated strings which results in its own escaping rules.

[_Gyan_]

Filtergraph declarations in files* can have whitespace so you can format it logically. Each option of a filter can be on different lines, if you like.

*via shell too, if the arg is quoted/escaped.

[the8472]

You may be missing the forest for the tree. I am not talking about the filter graph in isolation. I am talking about specifying all command line arguments (inputs, seeking, outputs, filters, codec options) etc. in a structured way. Filters would only be a part of that.

I think this might make use of ffmpeg less daunting than people attempting to battle a single-line shell input, ordering-sensitive parameters and escaping.

Well, maybe it's redundant, there already is vaporsynth after all.