Important
设备元数据已弃用，并将在 Windows 的将来版本中删除。 有关替代功能的信息，请参阅驱动程序包容器元数据。
Windows 提供 IHV 和系统 OEM 以媒体基础转换（MFT）的形式创建视频处理插件（称为相机驱动程序 MFT）的功能。 安装后，UWP 设备应用使用这些驱动程序 MFT 来启用特殊视频效果。 某些相机为预览、拍摄和静态图像提供单独的按钮。 这些多引脚相机对开发人员带来了独特的挑战。 本文介绍在多引脚相机上开发相机驱动程序 MFT 时需要考虑的一些要点。 有关创建驱动程序 MFT 的详细信息，请参阅 创建相机驱动程序 MFT。
Introduction
驱动程序 MFT 也称为 MFT0，指示它是在源读取器中运行的第一个 MFT。 MFT0 的单独实例附加到捕获源上的每个引脚。 对于某些系统 OEM，AVStream 捕获驱动程序必须支持预览引脚、捕获引脚和仍固定。 这意味着可能有三个 MFT0 实例。 此图显示了此体系结构，其中包含 IHV 插件 MFT 的三个副本，每个流都有一个副本。
MFT0 的典型方案可能会带来挑战。 MFT0 的两个常用功能包括：
分析视频流，以向相机提供反馈，以便改进捕获（例如基于主机的自动焦点和自动曝光）
添加视频效果
One-pin webcam
从历史上看，相机作为单个捕获引脚暴露在 Windows 上。 此图表示单引脚网络摄像头的工作原理：
在这种情况下，相机控件和视频效果都按设计工作，因为在应用相机控件和视频效果后，预览和静止从捕获引脚播放。 结果是保存的文件或用户的聊天伙伴看到与用户在预览中看到的视频效果相同，并且只有一个相机控件功能的实例。 如果有关联的 UWP 设备应用，则应用连接到捕获引脚上的 MFT0，因此 MFT0 从应用（即用户）获取控制消息。
Three-pin webcam
三引脚相机可以有多达三个 MFT0 实例，具体取决于应用程序需求。 此图表示三引脚相机的工作方式：
这种情况提出了一些挑战。 首先，对于基于主机的自动曝光解决方案，这需要直接控制相机传感器和 ISP 设置，三个 MFT0 可能同时尝试控制相机。 这会中断控制系统。
其次，可能有三个视频效果实例。 除了产生三倍计算成本外，MFT0 的三个实例现在必须以一种方式进行通信，以确保每个视频帧在完全相同的状态中始终具有相同的效果。 否则，用户看到的内容不会是保存或共享的内容。
此外，还有两个最终复合因素：
可以随时创建或关闭 MFT0 的每个实例
UWP 设备应用仅连接到 MFT0 的一个实例
Compressed video
网络摄像头或系统 OEM 可能会选择压缩视频，然后再将其显示在捕获引脚上（即网络摄像头本身上）。 将压缩卸载到网络摄像头可以降低供电的电脑来保存和共享 HD 视频。 通常无法分析此压缩的视频流以支持相机控制，也不能应用视频效果。 此方案提出了使 MFT0 的所有实例（以及Microsoft应用商店设备应用（如果存在）意识到没有应用于捕获流的效果的挑战。 此图表示压缩的视频：
如果用户将视频效果应用于预览流，则无法将其应用于捕获流或仍固定。 因此，用户会看到未应用于已保存或流式传输的视频的视频效果。 如果预览流已停止，Microsoft应用商店设备应用将尝试连接到捕获流。 当用户流式传输压缩视频时，这不允许使用许多功能。
MFT0 实例之间的通信
如果 MFT0 的三个实例可以相互通信，这可以解决大多数问题。 这些实例如何相互发现，由 IHV 决定。 所有 MFT0 都可以通信后，连接到 Microsoft Store 设备应用的 MFT0 实例可以让其他实例知道正在应用哪些效果及其当前状态。 此外，这三个实例还可以确定哪个实例应用相机控制。 最后，预览引脚可以确定捕获引脚是否是流式传输编码的视频。 然后，预览图钉可以禁用视频效果。
尽管 MFT0 实例之间的通信解决了主要用户体验问题，但仍必须同时运行三个视频效果实例。 某些视频效果可以使用大多数可用的 CPU 资源，尤其是在同时预览和捕获全屏视频时。 这些都是严重的问题。 出于性能原因，每个 ISV 应考虑执行一次处理，并与 MFT0 的所有实例共享，例如人脸检测。