虚拟摄像头驱动必须用C语言基于WDK开发，不可用C++；实际可行方案是用户态注入，如OBS-VirtualCam（Windows）、v4l2loopback（Linux）、AVCaptureScreenInput（macOS）或C++/WinRT的IMediaFrameSource接口。
虚拟摄像头驱动不是用 C++ 写用户态程序
直接用 C++ 开发“虚拟摄像头驱动”几乎不可行——Windows 上真正的摄像头驱动属于内核模式，必须用 C 编写，遵循 WDK（Windows Driver Kit）规范，且需通过 Microsoft 的签名认证才能加载。C++ 在内核驱动中受限极多（禁用异常、RTTI、STL、new/delete 等），实际项目中几乎不被允许。你真正能落地的方案，是绕过驱动层，走用户态视频源注入路径。
用 OBS-VirtualCam 或 v4l2loopback 做视频源注入
绝大多数“虚拟摄像头”需求（如 Zoom / Teams 推自定义画面、录屏推流、AI 滤镜）根本不需要写驱动。主流做法是复用成熟虚拟设备：
- Windows：安装
OBS-VirtualCam插件后，OBS 输出会自动注册为VideoCaptureSource设备，任何调用MediaFoundation或DirectShow的应用都能选它 - Linux：加载
v4l2loopback内核模块（sudo modprobe v4l2loopback video_nr=10 card_label="MyCam"），再用ffmpeg或GStreamer向/dev/video10写入 YUV/RGB 流 - macOS：用
AVCaptureScreenInput+AVCaptureSession构建虚拟源，或借助syphon+camtwist类工具链
如果硬要从用户态模拟摄像头设备，用 Windows Runtime API
Windows 10+ 提供了 Windows.Media.Capture.Frames 和 IMediaExtension 接口，允许 C++/WinRT 应用注册自定义帧源。但这不是驱动，而是作为 UWP 或桌面桥接应用运行：
- 实现
IMediaFrameSource和IMediaFrameReader，把内存中的SoftwareBitmap或IDirect3DSurface封装成帧流 - 调用
MediaFrameSourceGroup::FindAllAsync()可发现你的源，但仅限于使用 WinRT 媒体栈的应用（如新版 Teams、部分 UWP 视频会议软件） - 传统 Win32 应用（如老版本 Zoom）仍无法识别——它们依赖 DirectShow Filter 或 MediaFoundation Transform，不走这套 WinRT 路径
别碰 KMDF 驱动开发，除非你有签名和测试环境
真要写内核驱动（例如模拟 UVC 设备），必须用 WDK + C + KMDF 框架，且面临三重硬门槛：
立即学习“C++免费学习笔记（深入）”；
- 驱动必须用 EV 证书签名，否则 Windows 10/11 默认禁止加载（
STATUS_INVALID_IMAGE_HASH错误） - 调试依赖双机 Windbg + KDNET，单机 Hyper-V 调试配置复杂，蓝屏风险高
- UVC 协议栈需完整实现控制请求（
GET_CUR/SET_CUR）、流端点描述符、ISO 传输处理，一个URB_FUNCTION_ISOCH_TRANSFER处理错就卡死
连微软官方示例（usbvideo）都只提供框架，不包含可运行的虚拟摄像头逻辑。实际工程中，99% 的所谓“虚拟摄像头 SDK”都是包装上述用户态方案，而非驱动。
真正卡住人的从来不是代码怎么写，而是 Windows 对视频设备的权限模型、签名策略和兼容性分层——这些比 memcpy 多写两个字难得多。
