外部应用修改DirectShow虚拟摄像头的跨进程数据访问方案咨询

你当前需要解决的核心问题分为两部分：单DLL支持多虚拟摄像头实例、虚拟摄像头内核模块与外部管理程序的跨进程状态通信，以下是经过生产环境验证的可行方案，按推荐优先级排序：

1. 命名共享内存（性能最优，适配高频参数/帧数据交互） #

这是音视频类DirectShow Filter跨进程通信的最常用方案，无额外COM封送开销，延迟极低，完全满足动态帧率调整、状态同步甚至帧数据共享的需求：

• 实现逻辑：
  • 在虚拟摄像头DLL的DllMain入口，或第一个CStreamSource实例初始化时，调用CreateFileMapping创建带固定全局名称的共享内存段，名称必须加Global\前缀，避免Windows会话隔离导致普通权限下运行的CameraManager无法访问。
  • 共享内存内自定义结构体，按虚拟摄像头实例索引存储配置：每个实例对应DSLR的设备ID、当前输出帧率、是否被下游应用拉帧、空闲降帧阈值、帧格式等运行参数。
  • CameraManager启动后调用OpenFileMapping打开同名共享内存段，即可直接读写所有实例的配置；CStreamSource的采集线程每次循环读取对应实例的配置，调整采集行为，参数修改可以做到毫秒级生效。
• 注意事项：共享内存读写必须搭配同名互斥锁（通过CreateMutex创建），读写前先获取锁，避免多进程同时写入导致的数据错乱。
• 额外收益：你可以直接在共享内存中划分帧缓冲区，不需要走COM接口做帧拷贝，整体CPU占用会比原有方案低很多。

2. 自定义COM接口（符合DirectShow原生设计规范） #

既然你已经在开发COM组件，完全可以遵循DirectShow的扩展逻辑实现配置通信，不需要自己处理内存同步：

• 实现逻辑：
  • 给你的虚拟摄像头Filter新增自定义配置接口（比如IVirtCamConfig），暴露SetOutputFramerate、GetIdleState、BindDSLR这类配置方法。
  • 不需要为每个相机单独编译DLL、分配独立CLSID：单DLL即可支持任意数量的虚拟摄像头实例，注册时仅需要为每个实例生成独立的实例ID，写入设备枚举的注册表项即可，应用枚举摄像头设备时会自动识别到多个实例，新增相机不需要重新编译代码。
  • CameraManager通过系统设备枚举器枚举所有虚拟摄像头实例的Moniker，调用BindToObject拿到每个实例的IVirtCamConfig接口指针，直接调用接口方法即可修改参数，跨进程调用的封送逻辑由COM底层自动处理。
• 适用场景：如果只需要传递低频率的配置参数（帧率调整、设备绑定、开关控制），不需要跨进程传帧，这个方案的维护成本最低，完全符合Windows平台的开发规范，出问题更容易排查。

3. 注册表存储（仅适合静态配置，绝对不要用于运行时动态参数） #

你提到对注册表机制不熟悉，这里明确说明适用边界：

• 注册表仅适合存储启动时读取的静态配置：比如虚拟摄像头实例的默认绑定DSLR ID、默认分辨率/帧率、设备友好名这类不会在运行中频繁修改的参数，可以存在HKLM\SOFTWARE\你的虚拟摄像头程序名\Instances路径下，每个实例建一个子项存储键值。
• 绝对不要用注册表存储运行时动态参数：注册表读写本质是磁盘IO，延迟高，还存在UAC权限问题、注册表虚拟化问题，频繁写入不仅性能差，还容易出现配置不同步、权限不足报错的问题。

额外架构优化建议 #

针对你提到的扩展性差、CPU占用高的问题，可以同步做两个调整：

• 把空闲检测逻辑直接内置在CStreamSource层：如果CSourceStream::FillBuffer方法连续超过设定阈值没有被下游调用（说明OBS等应用没有拉取该摄像头的帧），自动将对应DSLR的采集帧率降到1fps以下甚至暂停采集，不需要等CameraManager下发指令，资源占用可以直接降到极低水平。
• 废弃单相机单DLL的注册逻辑：参考成熟虚拟摄像头的多实例实现，单DLL通过注册表写入不同实例的Moniker来枚举多个设备，新增相机只需要CameraManager写一条注册表记录即可，不需要重新编译注册新DLL。

内容的提问来源于stack exchange，提问作者Steve De Haes