从手机到PC的视频流转换：DroidCam Windows实战

手机变专业摄像头：DroidCam在Windows上的真实技术落地手记

去年给一所高职做网课系统升级时，我遇到一个典型困境：20台老旧联想ThinkPad X230，自带720p摄像头模糊、自动对焦失效、弱光下全是噪点。采购新USB摄像头预算被砍，而临时租用PTZ云台摄像机又涉及布线、供电、驱动兼容等一堆问题。最后我们试了DroidCam——用学生人手一台的Pixel 6和小米13，三天内全班上线1080p双机位直播课。没有新增硬件，没改一行代码，只靠一套软件，就把“手机”变成了Windows系统里一块被原生信任的视频采集卡。

这件事让我重新审视DroidCam：它不是个“小工具”，而是一条绕过传统硬件接口限制、直插Windows视频子系统核心的软硬协同通道。今天这篇笔记，不讲安装步骤，不堆参数表格，就带你钻进它的驱动层、传输栈和色彩管线，看看它是如何把Android摄像头的算力，稳稳地“嫁接”到OBS、Zoom、Teams这些严肃应用里的。

它为什么能在Windows里“假装”成一台真摄像头？

很多用户第一次在Zoom里看到“DroidCam Source”出现在摄像头列表时会愣一下——这玩意儿既没插USB线（Wi-Fi模式），也没走RTSP流（像普通IP摄像头那样），Windows怎么就认出它是个“视频设备”？

答案藏在droidcam.sys这个内核驱动里。

Windows从Vista开始就有一套严格的视频设备接入规范：你得是Kernel-Mode Video Miniport Driver，得实现IKsPropertySet、IMoniker、IAMStreamConfig这些COM接口，还得向系统注册标准的KS Filter Topology（带Video Capture Pin）。DroidCam没走捷径，它老老实实照着微软WDK文档写了一套miniport驱动，注册后系统就把它当成了“另一个罗技C920”。

关键不在“注册”，而在“喂数据”的方式。

传统虚拟摄像头（比如有些OBS插件）靠用户态DLL hookCreateFile或ICaptureGraphBuilder2，再伪造帧数据往里塞——这种方案在Win11上极易被HVCI（Hypervisor-protected Code Integrity）拦截，且帧时间戳抖动大，OBS一开“渲染延迟补偿”就疯狂丢帧。

DroidCam的选择更底层：它在内核里建了一个固定大小的Ring Buffer物理内存页（默认3帧，每帧按1080p RGB24算约6MB），Windows Client解码完的RGB帧，不经过任何用户态memcpy，直接用MmMapIoSpace()映射到该缓冲区的物理地址上。驱动的KSPIN_DISPATCH::Process回调函数每毫秒轮询一次，只要检测到新帧写入，立刻打上精确KSTIME时间戳，推入Streaming Int