Show HN: Typed-FFmpeg 3.0–Typed Interface to FFmpeg and Visual Filter Editor
40 comments
·May 29, 2025cb321
It is underappreciated that every single command-line option parser/toolkit is its own full configuration language with individual tools being "programs/configs" in that language. The lexical similarity of the zillion dialects (mostly due to Unix shells doing the word splitting for the eventual argv to be interpreted) masks what is really a dizzying diversity that for whatever reasons people think is much more uniform than it really is.
For example, I've done experiments running every single program in /usr/bin with --help and -h. The number of failures to get any useful help are a huge percentage. (The normalization of said percentage naturally is idiosyncratic to the exact system I ran that on).
Anyway, adding types to a complex one like ffmpeg may help more people realize this as well as offering practical benefits. So, great job!
aidenn0
I know it's not the point you were trying to make but I find "man foo" to be more reliable and useful than "foo --help" or "foo -h"
cb321
Fair enough. Finding documentation on the language is often step 1. :-) There are also giant POSIX PDFs around these days.
Also, I should have been more clear that while the CL parser toolkits are basically CfLangs/PLangs (maybe without loops, etc.), every command doing its own hand-rolled argv parser is basically its own totally unique language, probably doing only a subset of the 6..10 common conventions. It's probably not a great language, just something serviceable.
Basically, getopt wasn't good enough or easy enough or taught well enough, or done "soon enough". By the time it had come along, even within Bell Labs, they had probably grandfathered in old commands like `dd` and `find` (because "hey, I have a whopping 5 scripts that work with the old way!") with all their many & varied bespoke syntaxes.
Anyway, sadly, we only get our one try at "history" and many things are "sticky".
aidenn0
It was even worse on DOS; wildcard expansion happened in the program, not in the shell, so you didn't know if wildcard expansion was supported for an individual command!
plussed_reader
For the unitiated where was the conflict?
cb321
I'm not sure I understand your question. Are you asking for a list of the hundreds of commands which did nothing useful when run as cmd -h or cmd --help? I didn't save that, and as mentioned, it'd probably be different on your own systems/with your own packages.
If you want to try this at home, you should maybe either have GOOD BACKUPS HANDY OR DO IT WITHIN A VIRTUAL MACHINE/CONTAINER (EDIT: and almost certainly NOT AS SUPERUSER) also be ready to kill processes that are hanging waiting on stdin or somesuch. You're likely to have a least a few.
WITH THIS WARNING BEING GIVEN, you could just:
(for cmd in /usr/bin/*; do echo "CMD: $cmd"; "$cmd" -h; done) >/tmp/dash-h 2>&1
(for cmd in /usr/bin/*; do echo "CMD: $cmd"; "$cmd" --help; done) >/tmp/dashdash-help 2>&1
If you want to accumulate some stats yourself, then you'll probably want to postprocess those output files.. So, you might also adapt the embedded echos to make it easy for whatever you like to do for that. Or, alternatively, you could re-direct each output to a per-command file with a little ${cmd##} massaging.
EDIT: and if you're asking what the CL syntax conflict was, well, I only meant to refer to "How to get any help at all - command with no args, with -h, -help, --help, -?, etc." as that is kind of the "very first question" on a user's mind. There are other syntactic conflicts (combining bool flags, option-value separation, unique prefix matching, etc., etc.).
BGZq7
This is interesting, and it's good to see something that's actively developed, but it seems to have some of the same issues as ffmpeg-python:
- It doesn't appear to have any way of specifying filters that do not have inputs, such as "color"
- There is no way to provide flags to Popen, e.g. to specify subprocess.CREATE_NO_WINDOW to avoid CMD windows popping up in a GUI app on Windows. This isn't a big deal for running ffmpeg itself, because you can just ffmpeg.compile() then run it manually, but that can't be done for ffprobe with ffmpeg.probe().
Edit: OK, figured out the source filter thing, ffmpeg.sources.color. Is there a way to use arbitrary source filters, like vfilter/afilter can do for regular ones?
null
Daiz
If you're going to do script-based video processing in Python, I would highly recommend just going straight for Vapoursynth[1] instead. It's built for the purpose from the ground up, is actively maintained with a decent commmunity and tooling, and isn't tied to ffmpeg's CLI.
yurifury
Great idea. Personally looking forward to a typescript version of this.
barake
Prompted the Jules preview to see what would happen. The implementation is pretty naive - there are much easier to read approaches I can think of. So not _awful_ considering the very short prompt I used.
Changes are on this branch for the curious:
https://github.com/matt-hensley/typed-ffmpeg/tree/feature/mu...
matt-attack
I agree would love to see a typescript version.
teaearlgraycold
God’s native tongue
CyberDildonics
Typescript isn't mentioned anywhere.
ape4
It seems that there should be a machine-readable description of the ffmpeg command line to generate this in multiple languages.
dejobaan
The visual tool seems especially fantastic. FFMPEG seems an example of where modular/visual programming could really help, since I don't know all the bits FFMPEG offers. Minor UX note: I expected DEL to destroy nodes/edges (Win11/Chrome). But all in all: awesome!
userbinator
It took this long for someone to finally come up with something resembling MS' DirectShow GraphEdit.
mertleee
This is cool, but does it support piping frames between entire commands? In my opinion that's when you start to unlock the most interesting forms of FFMpeg flows.
pdyc
this is great! let me plug my tool as well, in case you want to edit videos visually you can also use this tool https://newbeelearn.com/tools/videoeditor/ it generates ffmpeg commands.
TechDebtDevin
Good work!
pietz
That looks awesome.
mikelinsi
Cool!
pbmahol
Unrelated, but my C++ solution: https://github.com/richardpl/lavfi-preview
chrisallick
this is what i was looking for: real time visual. very nice.
null
Hi HN,
I built typed-ffmpeg, a Python package that lets you build FFmpeg filter graphs with full type safety, autocomplete, and validation. It’s inspired by ffmpeg-python, but addresses some long-standing issues like lack of IDE support and fragile CLI strings.
What’s New in v3.0: • Source filter support (e.g. color, testsrc, etc.) • Input stream selection (e.g. [0:a], [1:v]) • A new interactive playground where you can: • Build filter graphs visually • Generate both FFmpeg CLI and typed Python code • Paste existing FFmpeg commands and reverse-parse them into graphs
Playground link: https://livingbio.github.io/typed-ffmpeg-playground/ (It’s open source and runs fully in-browser.)
The internal core also supports converting CLI → graph → typed Python code. This is useful for building educational tools, FFmpeg IDEs, or visual editors.
I’d love feedback, bug reports, or ideas for next steps. If you’ve ever struggled with FFmpeg’s CLI or tried to teach it, this might help.
Thanks! — David (maintainer)