Using ffmpeg in command line with D

[cy via Digitalmars-d-learn]

On Monday, 21 March 2016 at 17:26:09 UTC, Karabuta wrote:

> Will this work

Yes.

> 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).