Quick report on SetMTmode(5) ...
Yes, with 2026 it generally works. That's a big and important improvement! The only drawback seems to be that it somehow uses more memory. It's not the "private bytes" and not the "working set" in Taskmanager, those values are about the same. It's the "virtual memory" which seems to be ~200 MB bigger, compared to using mpeg2source.
Now, 200MB is not quite trivial ... I assume that's the reason why some scripts with SetMemoryMax(bigvalue) still crash, though they work with mpeg2source: private bytes and working set are sufficiently below 2GB, but the virtual memory could exceed. (Though, I never saw that value actually exceed ... the crashes came earlier, while the memory value was increasing quickly.)
Edit:
Some more toying-around reveals it is related to the number of instances of DG[Multi]Source. Each single instance is using a good bunch of memory. (The above numbers happened to be with 3 source calls present.)
With a script like this:
Code:
SetMTMode(5,6)
SetMemoryMax(1024)
v1 = DGsource(...) # or mpeg2source, respectively
v2 = ...
v3 = ...
...etc...
v1 + v2 + v3 + ...
SetMTMode(2)
TGMC_b2(1,1,1)
return( last )
Trying with 1, 2, 4, 6, 8, 10 source calls, TaskManager shows the following numbers for "virtual memory" of VirtualDub 1.9.9 :
Code:
source mpeg2source DGSourcce
calls
1 1'186'116 1'250'288
2 1'209'072 1'320'428
4 1'252'808 1'454'332
6 1'297'636 1'584'588
8 1'342'396 1'716'780
10 1'385'896 1'845'544
Seeing that, it becomes understandable that DGDecodeNV runs out of memory much sooner than mpeg2source.
It's very good news that SetMTMode(5) finally works.
Now, if you could find a way to minimize allocation of virtual memory, it would be
even better.
