Non-Rectangular Video Cropping with FFMpeg

Re:Non-Rectangular Video Cropping with FFMpeg by _Gyan_ on Monday December 30, 2019 @03:54AM (#21911866)

The CLI syntax design reflects the N-inputs --> N-outputs capability and no. of options reflects the number of components e.g. there are 300+ demuxers and 400+ filters available.

This is not to say there isn't scope for improvement. A couple of areas for improvement is the consistency of options naming across filters that implement the same feature within those filters, and a clearer syntax to identify the target of an option i.e. protocol, demuxer, decoder..etc

[ Parent | on HN ]

Re:Non-Rectangular Video Cropping with FFMpeg by the8472 on Monday December 30, 2019 @06:10AM (#21912540)

perhaps a declarative config file instead of CLI arguments would help. With a config file you could lay things out in a more tree-like manner, have lists etc.

And it's not just N inputs, M outputs. 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.

[ Parent | on HN ]

Re:Non-Rectangular Video Cropping with FFMpeg by _Gyan_ on Monday December 30, 2019 @09:32AM (#21913539)

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

[ Parent | on HN ]

Re:Non-Rectangular Video Cropping with FFMpeg by the8472 on Monday December 30, 2019 @09:43AM (#21913597)

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.

[ Parent | on HN ]

Re:Non-Rectangular Video Cropping with FFMpeg by _Gyan_ on Monday December 30, 2019 @10:38AM (#21913997)

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.

[ Parent | on HN ]

Re:Non-Rectangular Video Cropping with FFMpeg by the8472 on Monday December 30, 2019 @11:09AM (#21914267)

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.

[ Parent | on HN ]