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)
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!
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"
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".
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!
You still don't know if a Unix command would support processing multiple files even if the shell would expand wildcards. The tool might still process a single file and quit.
Another issue is that, around the same time getopt was appearing, the Bourne family of shells added `key1=val1 key2=val2 mycmd` syntax, accessed more simply with either `getenv("key1")`, etc. in a C program or simply `${key1-default1}` in a script, or in python `import os; E=os.environ.get; E("key1","default1")`. This is very lightweight on the mycmd impl as it can just start using the parameter wherever, possibly with string -> native value conversion, if needed.
So, though "shell specific" (right at a time when that started to mean anything), BOTH filename pattern matching aidenn0 mentions AND "long options of a sort" were built-in at the shell level on Unix. E.g., `help= mycmd` instead of `mycmd --help`. The inheritance of environment across fork/exec made these propagate which is both blessing (propagates through wrappers, so need not capture/repeat) and curse (have to worry about namespacing/re-use).
Basically, various timing effects had outsized influence - Unix & shell diversity and right around the time GNU introduced `mycmd --key[= ]value` combined with portability agendas, and possibly syntax/properties led to long options winning. The value proposition was "Use 'cmd --key=value', not 'key=value cmd' and users with any shell will have easy syntax". I dunno..It's also hard to attribute winning.
Today, for good or ill, most people seem to literally be unaware of `key=val mycmd` calling syntax even though for bash/POSIX "beat" the C shell/most things decades ago, around when bash added the better !! history and command-line editing that made tcsh popular because mistakes happen/etc. I believe the fish shell also dropped this syntax, though.
For the unitiated where was the conflict?
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:
Of course, you could try /bin if that's any different (for me it's a symlink to the same dir as /usr/bin these days). You could also do single dash help.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.).
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?
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.
[1] https://www.vapoursynth.com/
Great idea. Personally looking forward to a typescript version of this.
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...
I agree would love to see a typescript version.
God’s native tongue
Typescript isn't mentioned anywhere.
Yes.
What are you answering yes to?
The fact that this particular implementation doesn't involve typescript has nothing to do with the fact that OP wishes for a typescript implementation. Your original response was a statement of fact that the poster already knew, so they said "yes" to affirm their knowledge
No.
It seems that there should be a machine-readable description of the ffmpeg command line to generate this in multiple languages.
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!
It took this long for someone to finally come up with something resembling MS' DirectShow GraphEdit.
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.
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.
Good work!
That looks awesome.
Cool!
Unrelated, but my C++ solution: https://github.com/richardpl/lavfi-preview
this is what i was looking for: real time visual. very nice.
[flagged]
i really don't understand. what's the point of having an LLM comment on random HN posts? like, i get doing that somewhere like reddit because commenting brings karma and legitimacy to an account, which can later be used for astroturfing, or sold. but here? you're just polluting interesting conversations with polite and wholly uninteresting slop
Community driven RLHF, probably
By leaving this comment you've let the model know it's not sly. Down votes and flags / removals will do the same. Eventually it'll be sold as an auto-astroturf model ("50% fewer spam removals than the competition").
Or maybe it's just someone who gets a kick out of seeing how their prompt performs.
Better than impolite slop
is it tho? at least the impolite slop is born from a real person's heart and soul
[flagged]
yet another slop machine
Only going to get worse, I fear. Have seen how other communities are slowly replaced by bots, driving real humans out as we get more and more suspicious.