第一步是调用CoInitializeEx(COINIT_APARTMENTTHREADED)初始化COM，再通过CoCreateInstance(CLSID_SystemDeviceEnum)获取ICreateDevEnum实例；接着用CreateClassEnumerator分别传CLSID_VideoInputDeviceCategory或CLSID_AudioInputDeviceCategory枚举设备；遍历IMoniker时通过BindToStorage获取IPropertyBag读取L"Description"获取友好名称，设备路径由GetDisplayName获得；释放时须按IBaseFilter→IMoniker→ICreateDevEnum顺序，且CoUninitialize必须在所有对象释放后调用。
用 ICreateDevEnum 获取设备枚举器是第一步
DirectShow 设备枚举依赖 COM，必须先初始化 COM 库（CoInitializeEx），再通过 CoCreateInstance 创建 ICreateDevEnum 实例。这个接口不是用来直接列设备的，而是用来获取更具体的枚举器——比如音视频输入设备各需不同子类枚举器。
常见错误是跳过 CoInitializeEx 或传错参数（比如用 COINIT_MULTITHREADED 却没处理线程模型匹配），导致后续 CoCreateInstance 返回 REGDB_E_CLASSNOTREG 或 CO_E_NOTINITIALIZED。
- 必须用
COINIT_APARTMENTTHREADED（尤其在 UI 线程） -
ICreateDevEnum的 CLSID 是CLSID_SystemDeviceEnum，别手写字符串 - 调用后记得
AddRef保存引用，否则可能被提前释放
区分 FindMoniker 的类别参数：音频 vs 视频输入
拿到 ICreateDevEnum 后，调用 CreateClassEnumerator，关键在第二个参数 dwType：视频输入用 CLSID_VideoInputDeviceCategory，音频输入用 CLSID_AudioInputDeviceCategory。这两个是预定义 GUID，不能互换，也不能用 CLSID_AudioRendererCategory 替代——后者是输出设备。
如果枚举结果为空，大概率是类别填错，或系统没启用对应设备（比如 BIOS 关了摄像头、USB 麦克风未插稳）。Windows 10/11 上部分 Realtek 声卡驱动会把麦克风注册在 CLSID_AudioInputDeviceCategory 下，但某些旧驱动可能漏注册，此时需 fallback 到 CLSID_AudioRendererCategory + 反向检查 IAMAudioInputMixer 接口（不推荐，兼容性差）。
立即学习“C++免费学习笔记（深入）”；
- 视频设备类别：
CLSID_VideoInputDeviceCategory - 音频设备类别：
CLSID_AudioInputDeviceCategory - 返回
S_FALSE表示该类别下无设备，不是错误
从 IMoniker 提取友好名称和设备路径
枚举器返回的是 IEnumMoniker，遍历得到每个 IMoniker，再调用其 BindToObject 获取 IBaseFilter，进而用 IPersistPropertyBag::Load 或更简单的 IMoniker::GetDisplayName 拿显示名。但注意：GetDisplayName 返回的是内部路径（如 @device:pnp:\?pci#ven_8086&dev_9d71...），不是用户看到的“Logitech C920”。
真正可读的名称得靠 IMoniker::GetDisplayName 配合 ICreateDevEnum::CreateClassEnumerator 的 dwFlags 参数（设为 0），或者更可靠的方式：调用 IMoniker::BindToStorage 获取 IPropertyBag，再读 L"Description" 或 L"FriendlyName" 属性。有些设备（尤其是 USB 音频）只填了 Description，而 FriendlyName 为空。
- 必读属性名：
L"Description"（比FriendlyName更通用） -
IPersistPropertyBag::Load需要自己构造IPropertyBag，不如用IMoniker::BindToStorage直接 - 设备路径（
GetDisplayName结果）可用于后续IGraphBuilder::AddSourceFilter
释放顺序和线程安全容易出问题
DirectShow 对象释放有隐含依赖：比如 IMoniker 必须在对应的 IBaseFilter 释放后才能安全释放；ICreateDevEnum 要最后释放。在多线程中，如果一个线程正在枚举，另一个线程调用了 CoUninitialize，会导致所有 COM 接口调用崩溃（AV 或 RPC_E_CHANGED_MODE）。
典型坑是把枚举逻辑封装成函数，局部变量存 IMoniker*，函数返回后直接释放——但此时 IBaseFilter 可能还没创建，IMoniker 还被内部引用着。稳妥做法是：枚举时把 IMoniker 和提取出的名称、路径一起存进结构体，之后统一管理生命周期。
- 释放顺序：先
IBaseFilter→ 再IMoniker→ 最后ICreateDevEnum - 不要跨线程传递未
AddRef的接口指针 -
CoUninitialize必须在所有 DirectShow 对象释放后调用
设备名称和路径的提取逻辑看似简单，但不同厂商驱动对 PropertyBag 属性的实现差异很大，建议对空 Description 做 fallback 显示设备路径片段（比如截取 ven_XXXX&dev_YYYY 部分），至少让用户能区分设备。
