Re: DGAvcDecDI crashes when playing mkv-file
Posted: Mon Jan 10, 2011 5:42 pm
OK, I have some results for you. I have Win7 running on an E8500 dual core. Comments follow the results.
Test 1: No MT
----------------
loadplugin("D:\DGAVCDecDI\DGAVCDecodeDI.dll")
DGSource("00271.dgi")
Tweak(sat=0.0)
assumefps(5000) # to make VirtualDub play at maximum possible rate
Playing in VirtualDub gives 23.4 fps @ 100% CPU.
Test 2: SetMTMode(2,0) at top of script
-----------------------------------------------
SetMTMode(2,0)
loadplugin("D:\DGAVCDecDI\DGAVCDecodeDI.dll")
DGSource("00271.dgi")
Tweak(sat=0.0)
assumefps(5000) # to make VirtualDub play at maximum possible rate
Playing in VirtualDub gives 17.9 fps @ 100% CPU.
Test 3: SetMTMode(5,0) and SetMTMode(2,0)
-----------------------------------------------------
SetMTMode(5,0)
loadplugin("D:\DGAVCDecDI\DGAVCDecodeDI.dll")
DGSource("00271.dgi")
SetMTMode(2,0)
Tweak(sat=0.0)
assumefps(5000)
Playing in VirtualDub gives 3.2 fps @ 100% CPU. The MT documentation warns that SetMTMode(5,0) is very slow. Here you can see it.
Comments
------------
When the filters accessing the source filter are multithreaded, then the filter will receive nonlinear (not monotonically increasing) frame number requests. This will lead to poor performance due to random access being invoked. You can see it in the results. If you must have multithreading, then you can *try* the Test 2 setup and hope that the multithreading in the remainder of the script makes up for the loss due to random accesses in the source filter.
Note that I also ran Tests 1 and 3 on my fast WinXP machine at the stream's display rate of 23.976. With no threading (Test 1) I got about 13% CPU utilization. With threading as in Test 3, the CPU utilization went to 100% but the frame rate was radically degraded, just as shown above for the Win7 machine. The MT support page clearly warns about not optimizing for CPU utilization but rather for rendering rate. Now it's clear to me that that warning is spot on.
Finally, at no time did I ever experience any crashes during this testing. If you are seeing crashes then in the absence of any other people reporting it I have to assume you have some system-specific problem.
I don't know what more I can say or do for you on this.
Test 1: No MT
----------------
loadplugin("D:\DGAVCDecDI\DGAVCDecodeDI.dll")
DGSource("00271.dgi")
Tweak(sat=0.0)
assumefps(5000) # to make VirtualDub play at maximum possible rate
Playing in VirtualDub gives 23.4 fps @ 100% CPU.
Test 2: SetMTMode(2,0) at top of script
-----------------------------------------------
SetMTMode(2,0)
loadplugin("D:\DGAVCDecDI\DGAVCDecodeDI.dll")
DGSource("00271.dgi")
Tweak(sat=0.0)
assumefps(5000) # to make VirtualDub play at maximum possible rate
Playing in VirtualDub gives 17.9 fps @ 100% CPU.
Test 3: SetMTMode(5,0) and SetMTMode(2,0)
-----------------------------------------------------
SetMTMode(5,0)
loadplugin("D:\DGAVCDecDI\DGAVCDecodeDI.dll")
DGSource("00271.dgi")
SetMTMode(2,0)
Tweak(sat=0.0)
assumefps(5000)
Playing in VirtualDub gives 3.2 fps @ 100% CPU. The MT documentation warns that SetMTMode(5,0) is very slow. Here you can see it.
Comments
------------
When the filters accessing the source filter are multithreaded, then the filter will receive nonlinear (not monotonically increasing) frame number requests. This will lead to poor performance due to random access being invoked. You can see it in the results. If you must have multithreading, then you can *try* the Test 2 setup and hope that the multithreading in the remainder of the script makes up for the loss due to random accesses in the source filter.
Note that I also ran Tests 1 and 3 on my fast WinXP machine at the stream's display rate of 23.976. With no threading (Test 1) I got about 13% CPU utilization. With threading as in Test 3, the CPU utilization went to 100% but the frame rate was radically degraded, just as shown above for the Win7 machine. The MT support page clearly warns about not optimizing for CPU utilization but rather for rendering rate. Now it's clear to me that that warning is spot on.
Finally, at no time did I ever experience any crashes during this testing. If you are seeing crashes then in the absence of any other people reporting it I have to assume you have some system-specific problem.
I don't know what more I can say or do for you on this.