|
|
| famawizard |
| Posted: Dec 9 2002, 11:43 PM |
 |
|
Unregistered
|
I discovered that in win98se, for all versions of virtualdub, if i put more than 92 filter in the plugins directory than virtualdub will crash when selecting the compression menu.
This happens not only on my system but in every other system i tried (no problems with XP).
Moreover, i removed all filters and while adding them one at once, a noticed that some filters make some audio codecs disappear in the audio-compression menu (this time in win98se and XP).
I got 104 filters and i am investigating this problem...
No one had these problems?
Thanks (and excuse me for my bad English).
Lucio |
|
| phaeron |
| Posted: Dec 10 2002, 12:36 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Don't keep so many filters loaded.
All versions of Windows prior to Windows 2000 have a limitation in the number of Thread Local Storage (TLS) entries per process. Each module that is statically linked to the C Runtime Library consumes one TLS slot, of which there are 64 on Windows 95/NT4, ~96 in Windows 98 IIRC, and >2000 in Windows 2000/XP. Once you hit the limit DLLs start failing to load and you have major problems. Unfortunately, some video filters are statically linked and thus having them loaded on startup will consume TLS slots whether you are using the filters or not.
Filter authors can circumvent this problem by changing the code generation method for their filter to Multithreaded (DLL) -- however, this is not recommended for those using Visual Studio .NET since it will require distribution of MSVCR70.DLL. I believe Donald Graft has already done this for most of his filters.
|
|
| famawizard |
| Posted: Dec 10 2002, 12:25 PM |
|
|
Unregistered
|
I had the feeling that the problem was in the number of threads but i believed that video filters in virtualdub worked in other ways.
Well, i will keep only the more usefull filters....
Could you tell me if the same problems may arise with too much *.ax filters (I got 120 of them..) ?
Thank you very much.
Lucio |
|
| FrameMan |
| Posted: Dec 10 2002, 01:32 PM |
|
|
Unregistered
|
If loading the filters at startup may cause problems, why can't they be loaded as needed (only when the filters are used). VirtualDub could load at startup only the list of avaliable filters. If it is not possible, VirtualDub should display a warning when loading too many filters instead of crashing. |
|
| Spire |
| Posted: Dec 10 2002, 02:16 PM |
|
|
Unregistered
|
| QUOTE (FrameMan @ Dec 10 2002, 05:32 AM) | | If loading the filters at startup may cause problems, why can't they be loaded as needed (only when the filters are used). VirtualDub could load at startup only the list of avaliable filters. If it is not possible, VirtualDub should display a warning when loading too many filters instead of crashing. |
The filters need to be loaded at startup in order to get the display name. Of course, they could each be loaded to get the display name, quickly unloaded, and then reloaded later if and when they are actually used. But then this doesn't completely solve the crash problem; what if the user decides to use 100 filters at once? Crash time again.
Your too-many-filters warning is a very good idea, and I think it would work best if used in conjunction my suggestion above. Load-displayname-unload each filter upon VirtualDub startup, then simply gray out the Add... button once the maximum number of simultaneous filters is reached. Also, if the user is loading filters using a script, display a warning/error message if there too many filters are being requested.
This would all be predicated on VirtualDub's ability to correctly determine whether it is still possible to load another filter at any given time. So the burning question is: Is it possible to query how much TLS space is left? |
|
| FrameMan |
| Posted: Dec 10 2002, 02:53 PM |
|
|
Unregistered
|
I am not advanced enough to answer this, but I ponder, whether it could be done using the (pseudo)code:
x=TlsAlloc(); //Try to allocate space...
if (x==0xFFFFFFFF) { // Error - no more space, don't try to load the DLL( )
} else {
//ok. I have some space left.
TlsFree(x); //We do not actually need it
LoadTheDLL(); // might be dangerous - someone could have allocated the last element after the call to TlsFree ()
}
As I wrote before: I am NOT AN ADVANCED PROGRAMMER, so this code could be funny (wrong, stupid etc.) to someone, who is. I just hope, it could be used to come up with better solution. |
|
