Comment by utopiah
3 days ago
Have to admit, ffmpeg syntax is not trivial... but also the project is 24 years old and is basically the defacto industry standard. If you believe you will still be editing videos in 20 years with the CLI (or any other tool or any programming language) wrapping it then it's probably worth few hours learning how it actually works.
The syntax isn't too bad. The problem is that I have to use it a couple of times a year, on average. So every time I've forgotten and have to relearn. This doesn't happen with GUIs nearly as much, and it's why I prefer them over CLI tools for anything that I don't do at least once every week or two.
That’s why you write scripts, or put a couple snippets in your notes.
I do have snippets in my notes. The problem is that nearly every time I use it, I need to do something different than the previous time.
1 reply →
My question/curiosity is why do so many people use ffmpeg (frustrated by the syntax) when GStreamer is available?
`gst-launch-1.0 filesrc ! qt4demux ! matroskamux ! filesink...` people would be less frustrated maybe?
People would also learn a little more and be less frustrated when conversation about container/codec/colorspace etc... come up. Each have a dedicated element and you can better understand its I/O
I haven't tried GStreamer but I found FFmpeg to be extremely easy to compile as both a command line tool and library, plus it can do so much out of the box even without external libraries being present. It's already used in pretty much everything and does the job so it never occurred to me (or others) to look for alternatives.
Handbrake ( https://handbrake.fr/ ) and AviDemux ( https://www.avidemux.org/ ) is what the average user needs. Subler ( https://subler.org/ ) is also a good macOS app for muxing and tagging.
I did not know gstreamer wasm also exists, I'll check it out
Still has a way to go, but very exciting.
I agree, I suggest using this instead : https://github.com/kkroening/ffmpeg-python . While not perfect once you figure it out it is far easier to use and you can wrap more complicated workflows and reuse them later.
Kkroening's wrapper has been inactive for some time. I suggest using https://github.com/jonghwanhyeon/python-ffmpeg instead. It has proper async support and a better API.
Scratch that I thought it was a different version. The one you linked has no support for filtergraphs so isn't even comparable to the old one.
Thing is, if you want to use LLMs for mockups you got to use the old one.
I think that goes with almost every tool you want to use with llm. User should already know the tool ideally so mistakes by llm can be prevented before they happen.
Here making ffmpeg as "just another capability" allows it to be stitched together in workflows
true, companies like Descript, Veed, or Kapwing exist because no coders find this syntax intimidating. Plus, a CLI tool stands out of a workflow. We wanted to change that.
Don't "no coders" find the concepts described in this article imdimitating?
The article states that whatever the article is trying to describe "Takes about ~20-30 mins. The cognitive load is high....". while their literal actual step of "Googling "ffmpeg combine static image and audio."" gives you the literal command you need to run from a known source (superuser.com sourced from ffmpeg wiki).
Anyone even slightly familiar with ffmpeg should be able to produce the same result in minutes. For someone who doesn't understand what ffmpeg is the article means absolutely nothing. How does a "no coder" understand what a "agent in a sandboxed container" is?
we took a basic example and described it. (will try adding a complex one)
we have our designer/intern in our minds who creates shorts, adds subtiles, crops them,and merges the audio generated. He is aware of ffmpeg and prefers using a SaaS UI on top of it.
However, we see him hanging out on chatgpt, or gemini all the time. He is literally the no coder we have in mind.
We just combined his type what you want + ffmpeg workflows.
2 replies →
ffmpeg is pretty complicated, but at least it actually works.
The thing that helped me get over that ffmpeg bump, where you go from copying stack overflow answers to actually sort of understanding what you are doing is the fairly recent include external file syntax. On the surface it is such a minor thing, but mentally it let me turn what was a confusing mess into a programing language. There are a couple ways to evoke it but the one I used was to load the whole file as an arg. Note the slash, it is important "-/filter_complex filter_file"
https://ffmpeg.org/ffmpeg-filters.html#toc-Filtergraph-synta...
"A special syntax implemented in the ffmpeg CLI tool allows loading option values from files. This is done be prepending a slash ’/’ to the option name, then the supplied value is interpreted as a path from which the actual value is loaded."
For how critical that was to getting over my ffmpeg hump, I wish it was not buried halfway through the documentation, but also, I don't know where else it would go.
And just because I am very proud of my accomplishment here is the ffmpeg side of my project, motion detection using mainly ffmpeg, there is some python glue logic to watch stdout for the events but all the tricky bits are internal to ffmpeg.
The filter(comments are added for audience understanding):
and the ffmpeg evocation:
[dead]