多引脚相机上的驱动程序 MFT 的注意事项（UWP 设备应用）

Windows 8.1 为 IHV 和系统 OEM 提供了以媒体基础转换 (MFT) 形式创建视频处理插件的功能，即相机驱动程序 MFT。 安装后，UWP 设备应用可以使用这些驱动程序 MFT 来启用特殊的视频效果。 有些相机会针对预览、捕获和静态图像提供单独的引脚。 这些多引脚相机对开发人员带来了独特的挑战。 本主题介绍在多引脚相机上开发相机驱动程序 MFT 时要考虑的一些要点。 有关创建驱动程序 MFT 的详细信息，请参阅创建相机驱动程序 MFT。

介绍

驱动程序 MFT 也称为 MFT0，表示它是在源读取器中运行的第一个 MFT。 捕捉源上的每个引脚都会连接一个单独的 MFT0 实例。 对于某些系统 OEM，AVStream 捕获驱动程序必须支持预览引脚、捕获引脚和静态引脚。 这意味着可能有三个 MFT0 实例。 此图显示了这种体系结构，其中包含 IHV 插件 MFT 的三个副本，每个流一个。

MFT0 的典型方案可能会带来挑战。 MFT0 的两个常用功能包括：

• 分析视频流，为相机提供反馈，以改进捕获（例如基于主机的自动对焦和自动曝光）

• 添加视频效果

单引脚网络摄像头

一直以来，相机都是作为单个捕获引脚接入 Windows 的。 此图表示单引脚网络摄像头的工作原理：

在这种情况下，相机控件和视频效果都能按设计工作，因为在应用相机控制和视频效果后，预览和静止图像都会从捕获引脚发回。 这样做的结果是，保存的文件或用户的聊天好友将看到与用户在预览中看到的相同的视频效果，而且相机控制功能只有一个实例。 如果存在关联的 UWP 设备应用，则该应用通过捕获引脚与 MFT0 连接，因此 MFT0 可从应用（即用户）获取控制信息。

三引脚网络摄像头

三引脚相机可能具有多达三个 MFT0 实例，具体取决于应用程序需求。 此图表示三引脚相机的工作方式：

这种情况提出了一些挑战。 首先，基于主机的自动曝光解决方案需要直接控制相机传感器和 ISP 设置，在这种情况下，可能会有三台 MFT0 同时尝试控制相机。 这会中断控制系统。

其次，可能会有三个视频效果实例。 除了产生三倍的计算成本外，MFT0 的三个实例现在还必须进行通信，以确保每个视频帧在完全相同的状态中始终具有相同的效果。 否则，用户看到的内容不是保存或共享的内容。

此外，还有两个最终复合因素：

• 可以随时创建或关闭 MFT0 的每个实例

• UWP 设备应用仅连接到 MFT0 的一个实例

压缩视频

网络摄像头或系统 OEM 可以选择先压缩视频，然后再将其提供给捕获引脚（即网络摄像头本身）。 将压缩卸载到网络摄像头可以让低功耗电脑保存和共享高清视频。 这种压缩视频流一般无法进行分析以支持相机控制，也不能应用视频效果。 这就需要让 MFT0 的所有实例（以及 Microsoft Store 设备应用，如果有的话）意识到不会对捕获流应用任何效果。 此图表示压缩后的视频：

如果用户将视频效果应用于预览流，则无法将其应用于捕获流或静态引脚。 因此，用户看到的视频效果并没有应用到保存或流式传输的视频中。 如果预览流已停止，Microsoft Store 设备应用将尝试连接到捕获流。 当用户流式传输压缩视频时，很多功能将无法使用。

MFT0 实例之间的通信

如果 MFT0 的三个实例可以相互通信，这可以解决大多数问题。 这些实例如何相互发现取决于 IHV。 一旦所有 MFT0 都能通信，连接到 Microsoft Store 设备应用的 MFT0 实例就能让其他实例知道正在应用的效果及其当前状态。 此外，这三个实例还可以确定哪个实例应用相机控制。 最后，预览引脚可以确定捕获引脚是否是正在流式传输编码视频。 然后，预览引脚可以禁用视频效果。

虽然 MFT0 实例之间的通信解决了主要的用户体验问题，但三个视频效果实例仍必须同时运行。 某些视频效果会占用大部分可用的 CPU 资源，尤其是在同时预览和捕获全屏视频时。 这些都是严重的问题。 出于性能原因，每个 ISV 都应考虑哪些处理可一次性执行（如人脸检测），并与 MFT0 的所有实例共享。