sda capture blog

i had long suspected that the embarrassing "access violation" errors spewed by avisynth were the result of running out of memory, but this was very difficult to test, as they tended to occur randomly, even under low memory conditions. one of the reasons i suspected it was overshooting while allocating was that on my macbook, now with 2 gb of ram, i didn't see the problem on the same scale as i did on v5. the only alternative was bad ram in both of the machines (since it had happened at least once on both).

i finally uncovered the connection last month during a series of tests i was running for OPERATION ZWEI, an sda-related secret project some members of the sda team are working on right now (expect to see its release sometime this summer). these tests involved extremely memory-intensive avisynth scripts, and i later decided not to accomplish the effect in this way, because the avisynth system is simply broken when it comes to memory allocation (thanks, doom9 guys!). however, this situation afforded me repeated chances to see the exact same "access violation" error pop up -- again, pseudo-randomly -- but this time while watching the task manager intently.

i was able to distinguish two different types of access violation errors -- one thrown when the avisynth mother process reached doze's 2 gb allocation limit and another when the process would attempt to allocate memory beyond the total (3 gb) available to doze. it was at this point that i realized that radix had basically saved m2k2sda from these pesky access violations making their way into final encodes, because under normal conditions i don't use more than 1 gb of ram on v5. surely 2 gb free should be enough for any normal encode to allocate freely without the danger of running over the edge.

and indeed, i haven't seen or heard of a new encode afflicted with the problem since installing the new ram.