You should really make a new update to the plugin and credit Eosin as that user seems to be gone at this point. This is too good to get buried in the discussion.
Yeah, I might do that if Eosin doesn't reappear. Though I'm not sure I'd do a lot of maintenance on it.
Can you explain in more detail how the multithreading works?
Here's the gist: Whenever a frame is finished rendering, I pass its final display texture to a thread pool. The next frame is then rendered into a different render texture. This rendering is still completely single-threaded. Within the thread pool, the texture is encoded to JPEG/PNG and then written to disk. Only that part is multithreaded. I limit the number of items that can be simultaneously processed by the thread pool at any time (the thread count option in the UI) using a semaphore, to limit the number of render textures required. Though these textures don't take up a lot of memory.
The first benefit of the thread pools is that the next frame can already be rendered while the previous one is still being encoded and written to disk. It decouples rendering from encoding, kind of like a pipeline. So even a thread count of 1 will help.
The second benefit comes from higher thread counts, but only if rendering is faster than encoding: Say that encoding a frame takes twice as long as rendering it. In that case, the (theoretical) optimum thread count is 2, as that means that two frames are encoded at the same time, which makes encoding exactly as fast as rendering. With less threads, rendering would have to wait for encoding to finish while all encoding threads are busy - a kind of "stall". More than 2 threads won't really help, because then the renderer doesn't produce new frames fast enough, so the additional threads just idle. That's why the optimum thread count depends a lot on the scene. Simple scenes that render fast benefit from more threads, while complex scenes are "saturated" with fewer threads.
Well, that's the theory at least. It all depends on processor core usage of course, and there's also the issue of disk writes not actually happening in parallel, so YMMV.
if you're open to enhancement requests, sometime back I asked for the plugin to write the audio out as mp3 instead of wav.
I have toyed with the idea of (optionally!) making the plugin do the video encoding live, instead of the intermediate output of masses of JPG/PNG files. That would make the whole process even faster and simpler again, specifically for videos that don't need additional editing. I would definitely need an external encoder library for that though, and I've never used anything like that before.
The obvious thing that comes to mind is FFmpeg or its libraries, which would open up the possibility of live audio encoding as well. But packaging and accessing these libraries from a VaM plugin sounds like a nightmare, not to mention VaM's security system which I suspect would block it. Calling an external FFmpeg executable sounds even more dubious from a security perspective.
Maybe I'll experiment with that if I'm especially bored. But don't hold your breath.
hub.virtamate.com
