My point is not to just assume the process we called directly from MB3 is the one we want to SUSPEND/RESUME.Ī couple of semi-easy ways to handle this could be a config option in admin: So ideally, we should try and keep this in mind from the start. In this case the real ffmpeg would continue to run but the 'communication layer' gets shut down messing everything up. So we can't just suspend the 'ffmpeg.exe' process because it could end up being the intercept program and not ffmpeg itself. As far as MB3 is concerned it thinks IT IS talking to ffmpeg but instead is talking to the 'man in the middle'. The intercept then in turn calls/runs ffmpeg on the same or different computers. So it disguises itself as ffmpeg.exe (on windows) and receives the commands on the command line from MB3. In a nutshell it's a 'proxy or intercept' EXE.

We have a side project in the works that is going to be useful for both distributed encoding and hopefully soon 'GPU' assisted transcoding. It's now 'to simple' so I'm gonna throw a monkey wrench into things. So between the two mechanisms we should be able to handle this well. It should be simple to come up with a clean library to pause/resume as well as change priority and/or cores/affinity of any process. I'm liking this solution myself because it SHOULD JUST WORK with no grief compared to using -ss and -t commands with ffmpeg which could be much more prone to errors with different codec or builds of ffmpeg (much more to test, ect). We then use async language features to read the stdouts of those processes and write to their stdins.I played around and both methods worked fine for me on Windows to pause ffmpeg. In this blog post, we run shell commands as child processes in Node.js.

Ffmpeg command intercept