Long video processing sessions with Virtualdub make computer hitchy,has to be rebooted

  • Thread starter Thread starter brassplyer
  • Start date Start date
B

brassplyer

I've noticed that if I do a long video processing project with
VirtualDub, it has an odd effect on the computer. It causes it to
intermittently seize or freeze. Not lock up altogether but if you drag
the mouse across the screen it moves - sticks - moves - sticks. Ditto
if you play an audio file - plays - glitches - plays - glitches.
Rebooting fixes it.

For example, I just processed a video that's almost 2 hours long with
a Deshaker filter in VirtualDub. Took over a day to process step 1, at
the end of step 1, it exhibited the above symptom. Rebooted, things
were okay. Then applied step 2 which is actually applying the filter
and saving the processed file which took over 6 hours, at the end of
which the machine exhibits the same symptom. And again, reboot, all is
back to normal.

Any idea why this is?

Running XP Home, P4 2.4 gig, Soyo Dragon mobo.

Thanks for all input
 
brassplyer said:
I've noticed that if I do a long video processing project with
VirtualDub, it has an odd effect on the computer. It causes it to
intermittently seize or freeze. Not lock up altogether but if you drag
the mouse across the screen it moves - sticks - moves - sticks. Ditto
if you play an audio file - plays - glitches - plays - glitches.
Rebooting fixes it.

For example, I just processed a video that's almost 2 hours long with
a Deshaker filter in VirtualDub. Took over a day to process step 1, at
the end of step 1, it exhibited the above symptom. Rebooted, things
were okay. Then applied step 2 which is actually applying the filter
and saving the processed file which took over 6 hours, at the end of
which the machine exhibits the same symptom. And again, reboot, all is
back to normal.

Any idea why this is?

Running XP Home, P4 2.4 gig, Soyo Dragon mobo.

Thanks for all input

Check that you have plenty of hard disk space and plenty of RAM.
Close down programs running in the background.
It's also a good idea to defreg your hard drive.
IMHO Visa is a better operating system when doing video work.

Regards Brian
 
I've noticed that if I do a long video processing project with
VirtualDub, it has an odd effect on the computer. It causes it to
intermittently seize or freeze. Not lock up altogether but if you drag
the mouse across the screen it moves - sticks - moves - sticks. Ditto if
you play an audio file - plays - glitches - plays - glitches. Rebooting
fixes it.

For example, I just processed a video that's almost 2 hours long with a
Deshaker filter in VirtualDub. Took over a day to process step 1, at the
end of step 1, it exhibited the above symptom. Rebooted, things were
okay. Then applied step 2 which is actually applying the filter and
saving the processed file which took over 6 hours, at the end of which
the machine exhibits the same symptom. And again, reboot, all is back to
normal.

Any idea why this is?

It simply sounds like the memory manager is having a hard time honouring
requests from the running application. The VirtualDub software is
probably leaking memory and/or managing its memory poorly. The glitches
etc are the periods when the memory manager is attempting to coalesce
small free fragments of memory into larger contiguous blocks. During this
time the CPU utilization will be very high.

Adding more RAM to your computer would be your best option.
 
Marty said:
It simply sounds like the memory manager is having a hard time honouring
requests from the running application. The VirtualDub software is
probably leaking memory and/or managing its memory poorly. The glitches
etc are the periods when the memory manager is attempting to coalesce
small free fragments of memory into larger contiguous blocks. During this
time the CPU utilization will be very high.

Adding more RAM to your computer would be your best option.

Except, in a 24 hour run, the program has probably churned through
many times a 4GB memory space. Adding RAM won't help, if this is
a problem with how the OS works. The best a person can do, is find tools
to dump resource usage, on the off chance you might stumble on what
it is out of.

http://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx

Some of the tools referenced in that article, are written by the author
of the article, and can be downloaded from here. Sysinternals was bought
by Microsoft, which is why it is now hosted on a Microsoft site. For
example, you can get "Process Explorer" from here.

http://www.sysinternals.com

Paul
 
Paul said:
http://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx

Some of the tools referenced in that article, are written by the author
of the article, and can be downloaded from here. Sysinternals was bought
by Microsoft, which is why it is now hosted on a Microsoft site. For
example, you can get "Process Explorer" from here.

http://www.sysinternals.com

Microsoft needed them more than anything else IMO, hopefully they
are being paid enough.

FWIW.
My recent favorite of their tools... Autoruns, useful in part for
the right-click pop-up menu "jump to" that efficiently gets you to
the registry entry.
 
"CLicker" wrote ...
...

Yes! XP Home, P4 2.4 gig

Unlikely. Since ALL "XP Home, P4, 2.5 gig" machines don't
exhibit these symptoms, the most likely variable is a memory
leak in the layered application: VirtualDub. Seems almost certain.
 
Except, in a 24 hour run, the program has probably churned through many
times a 4GB memory space. Adding RAM won't help, if this is a problem
with how the OS works. The best a person can do, is find tools to dump
resource usage, on the off chance you might stumble on what it is out
of.

In a video processing application, it is unlikely to be a resource leak
but rather a memory leak.

In a long run the application will have churned through a massive amount
of memory. As a consequence of the memory leak, more and more of the
physical memory is lost from the application heap which pushes the
machine into eventually spending most of its time thrashing.

Depending on the size of the memory leak, adding extra RAM might delay
the onset of the fragged heap sufficiently to complete the required
processing.
 
Back
Top