sda capture blog

first of all, some background: right now, i own three modern computers, all of which are powered by dual core processors. the brilliant among us will have already concluded that this means i have a total of six (6) processor cores available. all the computers share storage over a gigabit lan.

unfortunately, the high quality deinterlacing filter mvbob() is not multithreaded. this means it can only use one core at a time. in the past i have set up multiple instances of vdub with e.g. one fourth of the total segments in a run to each, then started them all at the same time, but of course not all the segments are identical in length, so there would always be inefficiency as some vdubs would finish their deinterlacing before others.

avisynth is a very useful tool, and it was only a matter of time before i used it to automate a process by which any given input could be split up across a given number of threads, then automatically recombined later. i call this process sumi-chan for lack of a more creative descriptor (if the name were to describe the software properly, it would be something like "avisynth filter virtual multithreading system" - so long! so boring!).

usage is simple - i just run sumichan.sh with the avisynth scripts' basename and the desired number of cpu cores across which to split up the work, then run the resulting batch files on each real machine (one batch file for each cpu core). thus, entering 6 for sumi-chan's second argument results in six sets of avisynth scripts and six batch files.

due to rounding errors, if the number of frames in the source material is not divisible by the number of cpu cores specified, a few frames will be "squeezed" to the final work unit. this is unlikely to result in any significant inefficiency, as mvbob() usually processes between 1 and 2 frames per second even in extremely complex scenes. changes in said complexity throughout each work unit will result in much more significant inefficiency (compared to a true multithreading solution whereby all cpu cores would be simultaneously busy or not busy).

sumi-chan will appear as an optional feature in anri-chan 3 (we're getting close to the release of 2 right now). it ought to make encoding d1 material much more realistic for most people.

incidentally, i'm using quantizer 1 vfw xvid (via vdub) for the nmf. i've been extremely pleased with both the cpu and disk costs associated with this codec (they are much smaller than those associated with lagarith - and it crashes less to boot!).

of course, i have to include the obligatory crap quality picture of my new virtual computer, dubbed "v6". cores 1 and 2 are in the macbook on the left, while cores 3, 4, 5 and 6 are monitored on the mac mini's screen, but are in reality split equally between v5 (my pc) and the mini. (the terminal windows lower down on the mini's screen are left over from working on the prime hunters run as discussed in the previous entry.)