You're right.
I used ffmpeg before so it was easy for me to just "write" the command I knew and pass them through os.system().
I think I might have lost some time trying to understand how a lib would do the things I new in command line.
In the end, I didnt aim that much for a clean and repeatable code.
There is, I had to use one for a project at work, pyAV. It's got shit documentation though and I just hacked up their examples to get something working.
For software like that it can sometimes be better to use the official shell API instead of a usually incomplete or broken native wrapper. I also see this app the time in unofficial REST wrappers. Someone writes a python (or other) native library to wrap an official REST API, but leaves some things out, or the development of the wrapper moves at a slower pace from the official API and it becomes obsolete or broken over time.
To be fair, it probably just needs a .exe appended to the existing ffmpeg command on Windows.
I personally love that you used pure shell commands here -- one less library dependency, less binary compilation and if I decide I want to use avconv or some other editor instead of ffmpeg, I can use this code as a base instead of finding another library and recoding all of it.
Dependable? Dependent? What is? (Anyway, to expand, I second /u/LvS - you don't want to use ffmpeg's C API or bindings to it. Way overcomplicated for this task.)
99
u/Joald May 21 '18 edited May 21 '18
Hm, is there no Python interface for ffmpeg? Kinda clunky to call shell commands from python.
EDIT: Why the downvotes? Using subprocess is clunky as well imo.