On Monday, 21 March 2016 at 17:26:09 UTC, Karabuta wrote:
Will this work
and is it the right approach used by video convertor front-ends?
Well, yes, provisionally. When you invoke "ffmpeg" via
spawnProcess, that isolates ffmpeg as its own process, obviously.
From a security and maintenance standpoint, that is very, very
good. None of the code in ffmpeg has to be considered when
writing your own code, other than how it acts when you call it.
If ffmpeg scrambles its own memory, your program won't get messed
up. If your program scrambles its own memory, ffmpeg won't get
corrupted, and neither will your video file.
There are a few downsides though. It's expensive to set up that
very restricted, isolated interface (executing a process) but
considering the amount of number crunching involved in processing
videos it's a pretty negligible cost. If you're doing some sort
of web server that serves up a million generated pages a minute
though, all that executing can bog it down. But you wouldn't use
ffmpeg for that.
The extreme isolation of a separate process means that you're
restricted in what you can do with the video. You can do anything
that ffmpeg devs write in their interface, but that's it. If they
change the format of their command, all your stuff will break
until you fix that, but considering how old ffmpeg is, that's
probably not going to happen any time soon.
In some cases, there are resources that cannot be reused between
two processes, that are very expensive to set up and tear down.
You wouldn't use mpv like ffmpeg for instance, because it would
have to recreate the video display window every execution.
Instead, mpv has a "socket" interface that you can connect to
after launching one process, and use that to control the player.
So, for video conversion, yes it's the right approach. Your
mileage may vary if you want to display that video, or generate
videos on-demand from a high performance webserver. (in which
case the video processing will still be 99.999% of what slows you
down, not process execution).