This is a long shot but if I could do this it would save me time and a hassle. I have a DirectShow video filter that is a typical external DLL (AX file) that feeds video to Skype. I already know how to use a filter privately. However, I don’t know if it’s possible to make a private filter, one that is embedded in an EXE and is not an external DLL, discoverable by external programs. As far as I know, the main way DirectShow filters are made visible is via registering them in the Registry as an ActiveX/COM control and with a private filter, I would think that can’t be done since there is no external DLL for the external program to load.
So, is there a clever way to finesse the DirectShow discovery system so that an external program, that only knows how to access DirectShow filter’s via their “friendly name” through enumeration, can use it? If not I’ll just keep sending data back and forth between my main app and an external version of my video filter, but I’d really prefer not to have to do that.
If an external applciation is to use your filter, it would need to instantiate it by loading your DLL with the fitler and creating an instance from there. If you put your filter into .EXE, you still can register it with the fitler list, but it won’t work out: an external app would just be unable to create an instgance of your filter.
So if you want external apps to use your filter, you need to put it into DLL. Note that if you put your filter into DLL, you don’t have to also register it with DirectShow: you might want to prefer to NOT register it and instantiate privately, in which case it will be able to work in your application and in the same time you leave an option to fully register it some time later and make it available to external apps.
If you want the filter to run in external program and in some way talk to your application, this can also be done but you are fully responsible for all interprocess commuinication which will be taking place (that is, you will need to implement it).