Printable Version of Topic
Click here to view this topic in its original format
Unofficial VirtualDub Support Forums > Testing / Bug Reports > Vdxa Slows Down Processing


Posted by: fvisagie Aug 18 2012, 03:20 PM
VDXA (Options -> Preferences -> 3d accel -> uncheck Enable 3D...) seems to slow down VirtualDub processing, even when no obvious graphics display process is in progress.

Transcoding a 0:11:38 PAL DV AVI clip to Lagarith with both input and output video displays disabled:
VDXA disabled: 0:03:13
VDXA enabled: 0:03:46

The time ratio remains roughly the same with different file sizes and in/output formats.

VirtualDub 1.9.11 and Windows 7 32-bit Professional SP1, 2.6GHz Intel Core i5-2540M with 4GB RAM.

VirtualDub configuration:
VirtualDub.audio.SetSource(1);
VirtualDub.audio.SetMode(0);
VirtualDub.audio.SetInterleave(1,500,1,0,0);
VirtualDub.audio.SetClipMode(1,1);
VirtualDub.audio.SetConversion(0,0,0,0,0);
VirtualDub.audio.SetVolume();
VirtualDub.audio.SetCompression();
VirtualDub.audio.EnableFilterGraph(0);
VirtualDub.video.SetInputFormat(0);
VirtualDub.video.SetOutputFormat(15);
VirtualDub.video.SetMode(1);
VirtualDub.video.SetSmartRendering(0);
VirtualDub.video.SetPreserveEmptyFrames(1);
VirtualDub.video.SetFrameRate2(0,0,1);
VirtualDub.video.SetIVTC(0, 0, 0, 0);
VirtualDub.video.SetCompression(0x7367616c,0,10000,0);
VirtualDub.video.SetCompData(1,"AA==");
VirtualDub.video.filters.Clear();
VirtualDub.audio.filters.Clear();

Posted by: phaeron Aug 19 2012, 12:07 AM
Strange, I can't explain this. There is only one use of that flag in the entire codebase: whether 3D accelerated formats are exposed to video filters. All of the other acceleration code only activates if there are filters running in 3D acceleration mode. Obviously, neither code path executes if there aren't any filters.

Any chance you might have done some of the tests differently where one of the tests wrote a fresh file and another test wrote on top of an old one? There will be differences between these two because in one case the OS filesystem has to periodically extend the file whereas in others it simply overwrites in place. File extension is expensive on NTFS because it is a synchronous operation.

Posted by: fvisagie Aug 19 2012, 02:47 PM
QUOTE (phaeron @ Aug 19 2012, 02:07 AM)
Any chance you might have done some of the tests differently where one of the tests wrote a fresh file and another test wrote on top of an old one? There will be differences between these two because in one case the OS filesystem has to periodically extend the file whereas in others it simply overwrites in place. File extension is expensive on NTFS because it is a synchronous operation.

You're right. Retesting and writing to distinct files in the two cases produced identical times.

Sorry for the false alarm!

Powered by Invision Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)