Vdub eats up all virtual memory during encoding

[goofrider]

For some reason I keep having this problem: I use Divx 5.05 and VirtualDub 1.5.2 and VirtualDubMod 1.5.1.1a for encoding, and on several occassions, VDub won't stop encoding (rendering rate becomes 0.0fps but estimated/elapsed timer continues counting) while start eating up memory to no end, soon the page file grows to an enormous size and the somputers slow to a crawl and requires either a hard reset or (if I'm lucky) terminating Vdub via Task Manager.

The problem is reproducable on my computer. The problem arises at the exact same place for the same video file. It usually happens @ 99% on the 2nd pass but not always.

Anyone has an idea what the issue is?

[goofrider]

It's been a couple weeks and still no reply. Is that really nobody who knows about this problem?

[echooff]

I have run into this problem with a number of encodes. I first noticed it after i started using vdub 153. I started using 154 yesterday and so far, no problem.

[Belgabor]

Are you sure it happens with VDubMod 1.5.1.1a? This was one of the major bugs introduced by Averys new internal dubbing code in 1.5.2 and which should be fixed in 1.5.4. VDubMod so far doesnt have that code.

[leadman584]

Yesterday, out of the blue, VDubMod crashed on me. I was doing a couple of passes to refine an encode. I mention this only because I have never seen this before. The cause stated concerned paging file overlimit. I only have 512 MB of RAM, and apparently I had set my virtual memory too low (256MB I believe). I installed GKnot .028.3beta to get my tools, but I always encode with individual components. The complete depletion of my available memory would suggest a memory leak somewhere. I read in forum that there was a previously reported leak in MPEG2DEC3, but I'm using version 1.06. I know there are a few upgraded versions of tools in GKnot, including dvd2avi 1.77 (always heard that it sucked, but apparently folks been fixing that),and avisynth 2.52. I've ordered another 512 MB of RAM to help compensate (hafta order the silly things in pairs because RDRAM requires pairs in a P4 system), but I was wondering if anyone else has experienced this situation. I don't honestly believe VDubMod is the cause, but I figured that if anyone else has seen this problem they would post in this forum, since it is the last program in the sequence.

[leadman584]

Nevermind. Solution appears to be mpeg2dec3 ver 1.07. Ran 2 passes, all is well.