[HN Gopher] Show HN: Typed-FFmpeg 3.0-Typed Interface to FFmpeg ...
___________________________________________________________________
Show HN: Typed-FFmpeg 3.0-Typed Interface to FFmpeg and Visual
Filter Editor
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)
Author : lucemia51
Score : 309 points
Date : 2025-05-29 04:23 UTC (18 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| TechDebtDevin wrote:
| Good work!
| yurifury wrote:
| Great idea. Personally looking forward to a typescript version of
| this.
| CyberDildonics wrote:
| Typescript isn't mentioned anywhere.
| yurifury wrote:
| Yes.
| CyberDildonics wrote:
| What are you answering yes to?
| internetter wrote:
| 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
| CyberDildonics wrote:
| No.
| matt-attack wrote:
| I agree would love to see a typescript version.
| teaearlgraycold wrote:
| God's native tongue
| mikelinsi wrote:
| Cool!
| BGZq7 wrote:
| 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?
| pbmahol wrote:
| Unrelated, but my C++ solution:
| https://github.com/richardpl/lavfi-preview
| pietz wrote:
| That looks awesome.
| cb321 wrote:
| 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!
| plussed_reader wrote:
| For the unitiated where was the conflict?
| cb321 wrote:
| 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
|
| 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.).
| aidenn0 wrote:
| 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 wrote:
| 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 wrote:
| 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!
| sedatk wrote:
| 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.
| ape4 wrote:
| It seems that there should be a machine-readable description of
| the ffmpeg command line to generate this in multiple languages.
| dejobaan wrote:
| 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!
| mertleee wrote:
| 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 wrote:
| 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.
| Daiz wrote:
| 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/
___________________________________________________________________
(page generated 2025-05-29 23:00 UTC)