自研DirectShow采集源滤镜无法在Skype等软件中显示为采集设备求助

Hey there! I've dealt with this exact headache when building custom DirectShow capture filters, so let me break down the key requirements that apps like Skype look for when enumerating capture devices:

• Correct Filter Category Registration
  Your filter must be registered under the official DirectShow capture categories. For video devices, this means using CLSID_VideoInputDeviceCategory (GUID: {860BB310-5D01-11D0-BD3B-00A0C911CE86}). Double-check your dll.cpp registration code—ensure you're passing this GUID in the AMOVIESETUP_FILTER struct's clsCat field. A common mistake is registering under the wrong category (like a generic filter category instead of input devices).

• Proper Implementation of IAMStreamConfig
  Apps like Skype rely heavily on this interface to query supported formats (resolutions, frame rates, pixel formats) and set active formats. In your Filter.cpp, make sure you correctly implement:

  • GetNumberOfCapabilities: Returns the number of supported format profiles
  • GetStreamCaps: Returns detailed media type info for each profile
  • SetFormat: Accepts and applies valid media types
    Stick to standard media subtypes like MEDIASUBTYPE_RGB24, MEDIASUBTYPE_I420, or MEDIASUBTYPE_MJPEG—custom subtypes are often ignored by consumer apps.

• Expose Mandatory Capture Interfaces
  Beyond the base IBaseFilter, your filter needs to expose interfaces that signal it's a proper capture device:

  • For video filters: Implement IVideoCaptureFilter
  • For audio filters: Implement IAudioCaptureFilter
    Optional interfaces like IAMCameraControl or IAMVideoProcAmp aren't required, but some apps use them to validate "real" camera hardware, so adding them can help with compatibility.

• Valid Friendly Name and Registry Entries
  Ensure your filter has a clear, non-empty friendly name set in the AMOVIESETUP_FILTER struct's szName field. Skype pulls this name to display in its device list. You can also verify manually by checking the registry:
  Navigate to HKEY_CLASSES_ROOT\CLSID\<YourFilterCLSID> and confirm:

  • The Category subkey contains the correct capture category GUID
  • The Instance\FriendlyName value is set and readable

• 32-bit/64-bit Architecture Match
  Many consumer apps (including older Skype versions) are 32-bit. If you compiled your filter as 64-bit, 32-bit apps won't see it at all. Compile both 32-bit and 64-bit versions of your DLL, and register the appropriate one for your target app's architecture.

• Code Signing (for Modern Windows)
  Windows 10+ blocks unsigned kernel-mode components and some user-mode filters (especially for UWP or Microsoft Store apps like new Skype). If your filter isn't digitally signed with a valid code signing certificate, Windows might prevent it from loading, making it invisible to apps. For testing, you can temporarily disable driver signature enforcement, but signing is mandatory for production use.

Start by verifying the category registration and IAMStreamConfig implementation—those are the most common culprits for this issue. If you're still stuck, check the registry entries manually to ensure everything is registered correctly.

内容的提问来源于stack exchange，提问作者Mark