Left pane of profiler window in all tests where VD window active, "null transform" not listed is pretty interesting, although it shows up in main bottom pane.
#Warpsharp 2 filter video code
Probably because so many code changes have affected things, and maybe because I'm using a faster processor now, used to use the T4200 - smaller caches etc., but same laptop. In fact, using HuffYUV some time around VD 1.10.4, the active window effect was reversed to what it is now. The only time I don't see that is as above testing with RAW file. I noticed the big difference in V.Decode figure and thought that it had something to do with utvideo, but HuffYUV does the active window effect too. Changing any of the above still no change to bottleneck etc. It's the best performance I can squeak out of it no matter what happens as per filter bottleneck/active window effect. I used to set VD's Preferences -> Threading -> "auto" threads and frames (with "1" for compression threads), but have since tuned it to Threading -> 4 threads and frames, with "1" comp threads as usual, including some buffer tweaking too. Important: Note that in every test run where VD window active, "null transform" in left pane not listed.Īll tests with selected frames 0 -> 10,000, using Tools -> Benchmark analyse with same source file, decoding ut-encoded file.ĬPU is Intel T9900 dual core.
#Warpsharp 2 filter video windows
Test pic shows everything seems to take that little bit longer, but VD only task running, no swapfile, minimal services, no superfetch, no windows event log, defrag etc.
#Warpsharp 2 filter video 64 Bit
Possible buffers allocated at start of dubbing run not at 64 bit boundaries on 圆4 architecture or some corruption after some editing/mucking about? Just a wild guess as I don't know how PeeCee memory is allocated. Have also discovered a similar slowdown in processing which seems to occur randomly when using codec AND 2 filters as above on 50% of test runs. Seems using a single filter is choking something in processing. This is the case whether codec used or not and VD window active or not.
"Win" means desktop clicked active ~1s after test begun.įound if a single filter is used in the filter chain, it causes a larger speed hit than itself followed by an almost zero process filter, such as "null transform". "HUFFVD_Active" means benchmark analyse with HuffYUV compressed with VD window active. Occurs with both utvideo and HuffYUV 2.1.1, albeit HuffYUV to a lesser extent, probably because it's slower but therefore similar FPS percentage. It seems that when using a codec for compression/decompression (except MPEG2.vdf apparently), if any of VD's windows is active -> slower.Īs above but desktop or any other app window active -> faster. Re: processing auto task priority reversed After more testing, I have additional info. I must congratulate Anton for his six-axis color correction filter, as it has very fine adjustments.
:/Īgain for everyone's benefit, if you're converting RGBA32 screen captures to YUV420 (YV12), you might notice the resulting images slightly redder, or lacking green. I don't know what MSharpen does to cause this, but there's the workaround in case you didn't know, which I discovered yesterday. If you must use it at the end of the filter chain, you can use the internal "null transform" filter after it without any parameters and processing will be faster. :)Īlso for everyone reading, if you're using MSharpen 1.2.1 (by Donald Graft), placing it last in the filter chain creates a big speed hit, about 15-20% on my setup. Sorry Anton, I know you've got a lot on your plate. This may not impact "Capture AVI" as it auto sets priority high on capture start.įor the benefit of those reading, start VD2 processing a video, then click on the desktop (away from any VD2 window) and it should run faster, at least until this is rectified. This internal priority change doesn't show up in Task Manager or visible anywhere on VD while dubbing. This is now reversed and has been for quite some time, likely long before you took on the project, I can't remember but I forgot about this problem. Original VirtualDub used to have its processing (dubbing) priority set to launch (usually Windows normal) priority when VD's window was active, and set itself low to aid multitasking when in background or when user clicked on desktop.
0 kommentar(er)
