Encoding with VirtualDub the second time around is very slow

[Megahurts]

If I start to encode a file and abort then make changes and start to encode again, the 'Video rendering rate' is 1/5th the speed of 1st encodeing. This also happens when no changes are made.

To overcome this, I have to restart VD then make changes.

Is this normal?

[jagabo]

No -- unless by "make changes" you mean adding more filters. I don't know what might be causing the problem though. Is it limited to a particular filter or video?

[Megahurts]

jagabo,

This happens weather or not making changes, or using filters or not.

Have you tried encoding a file and abort and encoding again? Does it encode at the same rendering rate?

[jagabo]

Have you tried encoding a file and abort and encoding again? Does it encode at the same rendering rate?

Many, many times! And I don't think I've ever seen what you described.

Some things you might try to diagnose the problem:

Bring up Task Manager (Ctrl+Alt+Del) and watch the CPU Usage meter (Performace tab). It should be near 0 before you start encoding, go up as high as 100 when you start encoding, back to 0 when you abort, then back up as high as before when you restart. If it doesn't go down to 0 look at the Processes tab too see what program is eating CPu time. If it doesn't go back up... I don't know what this might suggest! Verify that no other programs are eating up CPU time while VirtualDub is encoding.

Check/change the Processing Thread Priority (in the little status window) when the program slows down. If you go to higher priority does it speed up? (If no other programs are running increasing the priority should speed the program up.)

Try using a different codec. Maybe there's something about the codec you're using. Keep in mind that different codecs encode at different speeds so always compare a codec to itself, not another codec.

Try deleting the aborted output file and creating a new one rather than overwriting it.

Try different filters. See if you can isolate the problem to a particular filter.

Try disabling the audio channel to rule out an audio problem.

Try Video -> Direct Stream Copy and/or Fast Recompress mode to see if behavior is any different.

Try a different version of VirtualDub. An older one, a newer one, VirtualDubMod VirtualDubMPEG2. See if there's any difference.

These things might help you isolate the problem.

[sambat]

If nothing turns up, VirtualDub's Creator hangs out here:

http://forums.virtualdub.org/index.php?s=6be37011b6c31912723854f6a6dcc4dd

[jagabo]

Oh, and one more thing: if you are using a multithreaded encoder and have the ability to set the number of threads (Xvid for example) make sure you don't set the number of threads higher than the number of cores you have. For example, if you have a dual core CPU don't set the number of threads higher than 2.

[Megahurts]

Thanks for all the responses.

I've narrowed the problem down to using AviSynth scripts with 'DirectShowSource' to open M2TS files in VD. The first attempt to encode, the rendering rate is normal but the second attempt is one fifth the speed.

Also I noticed using scripts with DirectShowSource to open files in MPC that it will play normal. If I pause and play, the frame rate will stay normal. But once stopped then played again, the frame rate will drop drastically.

Is this a bug or a feature? Using DirectShowSource.dll v2.5.8.1.

[jagabo]

It's a DirectShow (Microsoft), or M2TS file reader or codec (whoever provided those) problem. I would try using DgIndex and Mpeg2Source() instead.

[Megahurts]

Tried another computer with simular setup and it worked fine. Turns out the DirectShowSource.dll was v2.5.8.0 which is from AviSynth alpha (070518) release, an earlier version.

The DirectShowSource.dll v2.5.8.1 is from the AviSynth alpha (070518) release.

Copied the older dll to the other computer and all is fine.

[jagabo]

Good bit of sleuthing!