Fooling Around

As mentioned before, new Skype 6 broke compatibility with all virtual DirectShow devices out there. Just oops, nothing works any longer if only it is not a full driver exposing virtual device through WDM.

Since quite some people are interested in details (Skype 6 Virtual Camera issues, Skype Client for Windows – SCW-3881 – Virtual cameras no longer work with Skype 6), here goes a bit of relevant information on the problem.

New Skype still uses DirectShow as API to interface capture devices and to discover such it enumerates them the way all decent applications do: Enumerating Devices and Filters. Presumably, there was a good reason to touch the video capture code and from moderately terrible it started being even worse. Skype guys decided that if a video device does not have a DevicePath property then it is not good enough for them.

The “DevicePath” property is not a human-readable string, but is guaranteed to be unique for each video capture device on the system. You can use this property to distinguish between two or more instances of the same model of device.

The documentation is unfortunately confusing in this part and perhaps developers thought they were doing the right thing, nevertheless multiple discussions online suggest a different approach.

Unfortunately, DevicePath is not a mandatory property. And it does not exist in virtual devices, and you cannot use it to distinguish between them. And Skype started – supposedly – skipping devices without it. And this is why all virtual devices were left overboard.

Virtual devices are not that rare. It might not only be a gate into IP camera, instead it might be a device that splits exclusive use type video camera device between applications, or something that adds an overlay onto captured image. That is, the whole class of devices failed to work with Skype from there. Including, of course, IP Video Source which is a virtual DirectShow device with the backend network connection into an IP camera or video encoder.

Adding missing DevicePath is the key to fix the problem and give Skype what it thinks is a must. Let’s hope we have a fix from Skype soon and there is no need in working things around any longer, but if someone needs a quick solution – it also exists (apart from rewriting everything into kernel mode driver, and other hackery).

Since the properties an application reads from IPropertyBag interface (which is in turn obtained from IMoniker when enumerating devices) are [partially] backed by system registry, it is sufficient to add “DevicePath” value into specific key of the registry and make the fake property available for those devices that don’t have kernel path.

The registry key is located under HKLM, SOFTWARE\Classes\CLSID\{860BB310-5D01-11d0-BD3B-00A0C911CE86}\Instance (note it’s SOFTWARE\Classes\Wow6432Node\CLSID... in 64-bit OS for 32-bit app space), where every subkey corresponds to a registered device (find yours there). Note that CLSID above is actually CLSID_VideoInputDeviceCategory.

Adding new value there will create a fake property on the property bag and improve compatibility with such picky software as Skype. Note that the value will be destroyed with re-registration of the device filter, and will have to be created once again.