一、摄像头框架
在业务场景中,有许多是需要应用能够通过摄像头的方式来访问相关的音视频数据,比如美颜、摄像头多路复用、IP摄像头接入视频会议等。这些功能通过虚拟摄像头的方式来实现,是一个比较通用的解决方案。那么如何及选用哪种技术方案来开发虚拟摄像头呢?本文从windows角度评估其相关技术可行性。
回到问题:应用操作虚拟摄像头,我们可以从Windows的应用是如何操作摄像头来评估。
Windows发展史上,主要使用了以下框架来操作摄像头:
- VFW(Video Of Windows)这个是Windows最先使用的框架,也是最古老的,好处是接口函数够简单,在有些兼容或者小型用层场所用用也没什么问题。
- DirectShow,这个是横跨 WINXP, WIN7,WIN8,WIN10都得到很好支持的框架,然而接口函数也挺复杂。
- Media Foundation, 这个是WIN7之后,开发的新框架,目的是为了替换DirectShow,从而达到更好的性能和适应流媒体发展的需求。
二、应用现状
应用程序可以通过VFW、DirectShow、Media Foundation等一个或多个方式来操作摄像头。那么实际情况是如何的呢?
大量的操作摄像头的程序都是使用DirectShow框架,有小部分还在使用VFW框架。新近开发的程序或者对老版本程序的更新中,相当数量的程序使用Media Foundation框架代替了DirectShow。更有甚者,UWP框架的程序(就是Windows10平台新出来的,为了 “大一统“ 目的,这个目前也是小众,能否发展做大谁知道),对驱动级别的摄像头限制更大,已经不再支持老内核流框架。
所以,摄像头应用框架选择现状为:
- VFW:较少,一些古老的应用
- DirectShow:大量,慢慢迁移到Media Foundation
- Media Foundation:大量
- UWP:Win10应用,如Camera、Skype等
三、虚拟摄像头
3.1 应用层方式
3.2 驱动方式
1、VFW:Video for Windows,是一种趋于废弃的windows驱动模型。指Microsoft推出的关于数字视频的一个软件开发包,VFW的核心是AVI文件标准。围绕AVI文件,VFW推出了一整套完整的视频采集、压缩、解压缩、回放和编辑的应用程序接口。发展趋势:VFW(95) → WDM(98/2000/xp) → WDF(xp之后)。
2、UVC:USB Video Class,USB视频类,是一种为USB视频捕获设备定义的协议标准。是Microsoft与另外几家设备厂商联合推出的为USB视频捕获设备定义的协议标准,已成为USB org标准之一。事实上最新版本windows中,UVC自动加载usbvideo.sys,器内部也是使用ks.sys,即也是使用下面的Kernel Stream流驱动框架。参考:USB 视频类 (UVC) 相机实现指南
3、Kernel Streaming:内核流式传输 (KS) 指的是 Microsoft 提供的服务,支持对流式数据进行内核模式处理。Microsoft 提供了三种多媒体类驱动程序模型: port class、stream class和 AVStream。这些类驱动程序在系统文件 portcls.sys、 stream.sys和 ks.sys中 (内核模式 dll) 的导出驱动程序实现。 在 Windows XP 和更高版本中, ks.sys称为 AVStream。
4、AVStream:是Kernel Streaming三种多媒体驱动模型之一,也是最新版本模型,包含了音视频的部分。在 AVStream 驱动程序模型中,供应商提供与 Microsoft 提供的类驱动程序交互的微型驱动程序,如下图所示。
5、Windows USB摄像头驱动程序栈架构
从上面的图可以看到,厂商只提供硬件和固件,并且这个固件应该满足UVC规范,而其余的由Windows系统包圆了。其中ks.sys与AVStream、portclass.sys之间的关系如下:
- AVStream是ks.sys中的一部分,而ks.sys是其上层驱动。
- ks.sys的下层可以是portclass.sys实现的音频类,也可以是USB实现的音视频类。
- ks.sys文件中包含了全部的ks功能和AVStream功能
6、方案对比
驱动框架 |
说明 |
实现案例 |
VFW |
过时的技术,不推荐 |
无 |
UVC |
实现USB摄像头驱动 |
e2esoft的VCam |
Kernel Stream:Port Class |
主要是音频 |
无 |
Kernel Stream:Stream Class |
主要是视频,参考:Stream Class
|
|
Kernel Stream:AVStream |
音视频最新驱动框架,参考:AVStream
|
avshws、avscamera |
3.3 方案对比
类别 |
方案 |
平台兼容 |
应用兼容 |
实现难度 |
是否可以开关 |
是否需要管理员权限 |
应用层 |
direct show |
>=98 |
一般 |
中 |
是 |
否 |
|
mfd- MFCreateVirtualCamera |
>=win11 |
一般 |
中 |
是 |
创建、销毁需要 |
|
mfd - IMFMediaSource |
>=vista |
一般 |
较难 |
是 |
否 |
驱动层 |
VFW |
>=95 |
一般 |
难 |
否 |
安装需要 |
|
UVC |
>= xp sp2 |
最好 |
最难 |
否 |
安装需要 |
|
KS - Stream Class |
>= xp |
一般 |
较难 |
是 |
安装需要 |
|
KS - AVSteam |
>= xp |
较好 |
较难 |
是 |
安装需要 |
四、总结
如上图所示,无论应用层以哪种方式操作摄像头,最终都会汇聚于Kernel Streaming驱动层,而Kernel Streaming对于USB摄像头又依赖于UVC驱动。所以总结如下:
- 目前市面大部分应用操作摄像头使用DirectShow、Media Foundation框架,win10微软应用只支持UWP。从兼容层面看只有UVC、AVSteam两类驱动框架开发的虚拟摄像头才可以完全兼容。
- UVC由于在更底层,可以适配未来windows的版本变化,但开发难度极高;AVSteam在没有新的流媒体驱动框架出现前,是可以满足所有应用兼容,开发难度相对较好。
综上,建议选择AVSteam驱动框架开发虚拟摄像头。