设备 MFT 设计指南

Windows 中的视频捕获堆栈支持 DMFT 形式的用户模式扩展。 这是 IHV 提供的按设备扩展组件，捕获管道在捕获后作为第一个转换插入。 DMFT 从设备接收处理后的帧。 可以在 DMFT 内对帧执行进一步的后处理操作。 DMFT 可以从设备的所有流接收帧，并且可以根据需要公开任意数量的输出流。

本文概述了在用户模式下运行的设备范围扩展的设计，该扩展可用于执行所有流通用的后处理。

术语

术语	说明
KS	内核流式处理驱动程序
AVStream	音频视频流驱动程序模型
筛选器	表示设备实例的对象
设备 MFT	IHV 提供的用户模式捕获驱动程序扩展
Devproxy	MF <-> AVStream 封送处理器
DTM	管理 devproxy 和设备 MFT 的设备转换管理器。 表示 MF 管道中的设备。

设计目标

• 与设备筛选器具有相同生存期的设备筛选器范围的用户模式扩展

• 支持来自设备的任意数量的输入

• 支持任意数量的输出（当前要求为三个流：预览、记录和照片）

• 将所有设备控件路由到设备 MFT（可以选择处理或将其传递给设备）

• 捕获的流的并行后处理

• 允许独立于帧速率的 3A 处理

• 允许一个流中的元数据在其他流中共享

• 访问 GPU 资源

• 访问 MF MMCSS 工作队列

• 访问 MF 分配器

• 简单接口（类似于 MFT）

• 适用于 IHV/OEM 可扩展性的灵活内部体系结构

设计约束

• Capture API 图面没有更改

• 完全向后兼容性。 例如，在使用旧应用和方案时没有回归。

捕获堆栈体系结构

本文介绍对捕获驱动程序的筛选器范围的用户模式扩展的支持。 此组件有权访问 MF API、线程池、GPU 和 ISP 资源。 筛选器宽扩展提供了在自身和设备 Ks 筛选器之间拥有任意数量的流的灵活性。 这种灵活性可在用户模式扩展和驱动程序之间实现无缝带外通信，可用于专用元数据和 3A 处理流。

设备转换管理器 (DTM)

捕获堆栈引入了一个系统提供的新组件，即设备转换管理器 (DTM)。 它位于 DeviceSource 中，管理 Devproxy MFT 和设备 MFT。 DTM 执行 MediaType 协商、示例传播和所有 MFT 事件处理。 它还将 IMFTransform 接口公开给 DeviceSource 和 DeviceSource 管理设备流所需的其他必要的专用接口。 此组件从管道中提取 Devproxy 和设备 MFT。 管道仅将 DTM 视为设备，而 DTM 中的流作为设备流。

Devproxy

Devproxy 是一个异步 MFT，它在 AVStream 相机驱动程序和 Media Foundation 之间封送命令和视频帧。 这是由 Windows 提供的，并且支持来自相机驱动程序的 n 个输出。 此外，它还拥有设备公开的所有引脚的分配器。

设备 MFT

设备 MFT 是捕获驱动程序的用户模式扩展。 这是 m x n 个异步 MFT。 它随捕获驱动程序一起安装在系统上，由捕获驱动程序供应商提供。

设备 MFT 的输入流数必须与设备公开的 KS 引脚数相同。 设备 MFT 的输入流支持的媒体类型必须与 KS 引脚公开的媒体类型相同。

设备 MFT 公开的输出流的数量是由 DeviceSource 和捕获堆栈、捕获 API 和应用程序看到的流，可以是一个、两个或三个流。 设备 MFT 的输入和输出流计数不需要相同。 此外，输入和输出流不需要具有相同的媒体类型，并且通常具有不同的媒体类型。 媒体类型的数量也不需要匹配。

在用户模式下由 Devproxy 的输出流表示的第一个 KS 引脚与设备 MFT 的第一个输入流相关联，在用户模式下由 Devproxy 的输出流表示的第二个 KS 引脚与设备 MFT 的第二个输入流相关联，以此类推。

设备 MFT 被赋予一个指向 Devproxy、DX 设备和 MF WorkQueue ID 的指针。 来自设备的帧作为 MF 样本直接馈送到相应的设备 MFT 的输入。 借助所有这些功能，设备 MFT 可以对捕获的样本进行后期处理，并将样本提供给预览、记录和照片引脚。

所有发送到设备的命令和控制都会重新路由到设备 MFT。 设备 MFT 通过 Devproxy 处理控件或将其传递给驱动程序。 这简化了捕获驱动程序堆栈的命令处理。

功能概述

在捕获管道的初始化时，如果设备有设备 MFT，DeviceSource 会实例化 DTM。 它将表示设备的 Devproxy 实例传递给 DTM 的初始化例程。 DTM 共同创建设备 MFT 并执行基本验证，例如，验证 Devproxy 的输出引脚数与设备 MFT 的输入引脚数、对必需接口的支持等相同。

DeviceSource 查询 DTM 以获取支持的输出媒体类型。 DTM 从设备 MFT 的输出引脚获取此 ID。 DeviceSource 基于此信息向捕获管道公开演示描述符和流描述符。

SourceReader 使用 DeviceSource 公开的媒体类型，并在每个流上设置默认媒体类型。 反过来，DeviceSource 在 DTM 的输出流上设置默认媒体类型。 DTM 使用 SetOutputStreamState 方法在设备 MFT 的输出流上设置媒体类型。

调用 SetOutputStreamState 时，设备 MFT 会将消息发布到 DTM，以根据所选输出媒体类型更改其输入流的媒体类型并等待。 为了响应此消息，DTM 使用 GetPreferredInputStreamState 查询设备 MFT 输入流的首选输入媒体类型。 这会在 Devproxy 的相应输出流上设置媒体类型。 如果成功，DTM 将使用 SetInputStreamState 将相同的媒体类型设置为设备 MFT 的输入流。 收到此调用后，设备 MFT 将完成 SetOutputStreamState。

CaptureEngine 通过在 DeviceSource 上启用特定流来选择单个流。 DTM 通过 SetOutputStreamState 调用传播到设备 MFT。 设备 MFT 将特定输出流置于请求状态。 如上所述，设备 MFT 还会通知 DTM 需要启用的必要输入流。 这会导致 DTM 将流选择传播到 Devproxy。 此过程结束时，Devproxy 和设备 MFT 中的所有必要流都已准备好进行流式传输。

当 CaptureEngine 调用 ReadSample 时，SourceReader 将启动 DeviceSource。 反过来，DeviceSource 通过发送 MFT_MESSAGE_NOTIFY_BEGIN_STREAMING 和 MFT_MESSAGE_NOTIFY_START_OF_STREAM 消息来启动 DTM，指示管道的开始。 DTM 通过传播 MFT_MESSAGE_NOTIFY_BEGIN_STREAMING 和 MFT_MESSAGE_NOTIFY_START_OF_STREAM 消息来启动 Devproxy 和设备 MFT。

注意

在开始流式处理而不是设备 MFT 初始化时分配必要的资源。

DTM 使用流式处理状态参数在设备 MFT 的输出上调用 SetOutputStreamState。 设备 MFT 开始在这些输出流中流式传输。 DTM 在已设置有效媒体类型集的 Devproxy 输出流上启动流式处理。 Devproxy 分配示例并从设备提取它们。 这些示例将馈送到相关输入引脚中的设备 MFT 中。 设备 MFT 处理这些示例，并向 DeviceSource 提供输出。 从 DeviceSource 中，示例通过 SourceReader 流向 CaptureEngine。

CaptureEngine 通过 DeviceSource 上的内部接口禁用单个流来停止单个流。 这会转换为通过 SetOutputStreamState 在设备 MFT 上禁用的特定输出流。 反过来，设备 MFT 可能会请求通过 METransformInputStreamStateChanged 事件禁用特定输入流。 DTM 将此传播到相应的 Devproxy 流。

只要设备 MFT 本身处于流式处理状态，它就可以请求任何输入流以转换为任何有效的 DeviceStreamState。 例如，它可以将其发送到 DeviceStreamState_Stop、DeviceStreamState_Run 或 DeviceStreamState_Pause 等，而不会影响其他流。

但是，输出流转换由捕获管道控制。 例如，捕获管道启用或禁用预览、记录和照片流。 即使禁用了输出，只要设备 MFT 本身处于流式处理状态，输入流仍可能进行流式处理。

设备 MFT 的生存期

创建 KS 筛选器后加载设备 MFT。 在 KS 筛选器关闭之前，它已被卸载。

从管道的角度来看，创建 DeviceSource 时，将创建设备 MFT；当 DeviceSource 关闭时，设备 MFT 将同步关闭。

若要支持关闭，设备 MFT 必须支持 IMFShutdown 接口。 调用 Device MFT->Shutdown 后，对设备 MFT 的任何其他接口调用都必须返回 MF_E_SHUTDOWN 错误。

内存类型

根据相机驱动程序的首选项，帧可以捕获到系统内存缓冲区或 DX 内存缓冲区中。 任何从相机驱动程序传出的缓冲区都直接馈送到设备 MFT 中，以便进一步处理。

Devproxy 根据驱动程序的首选项分配缓冲区。 我们需要设备 MFT 使用 MF 分配器 API 来分配非位置转换的输出引脚所需的样本。

流式传输时媒体类型更改

SourceReader 的客户端能够将设备 MFT 的输出流公开的媒体类型视为本机支持的媒体类型。 更改本机媒体类型后，SourceReader 会通过 DeviceSource 将媒体类型通知调用发送到设备 MFT。 设备 MFT 负责从该流的队列中刷新所有挂起的样本，并及时切换到该流上的新媒体类型。 如果有必要更改输入媒体类型，则应将当前输入媒体类型更改为该类型。 DTM 从设备 MFT 的输入流中获取当前媒体类型，并在每个本机媒体类型更改后在 Devproxy 的输出流和设备 MFT 的输入上设置它。

设备 MFT 中的输入媒体类型更改

由于这是 m x n MFT，因此在输出流式处理引脚的媒体类型或状态更改时，输入流式处理引脚的媒体类型和状态更改可能会有影响。 具体来说，发生以下更改时：

• 输出媒体类型更改

  • 当应用程序更改本机媒体类型时，它会在输出引脚媒体类型更改时通过捕获堆栈级联到设备 MFT。

  • 输出媒体类型更改时，它可以触发输入媒体类型更改。 例如，假设所有输出引脚都在 720p 处流式传输。 这会导致以 720p 的速度从相机流式传输。 接下来，假设记录流将其本机媒体类型更改为 1080p。 在这种情况下，将数据提取到记录流的设备 MFT 输入流之一必须更改其媒体类型。

• 输出引脚已禁用

  • 当应用程序在多个输出共享同一输入时禁用设备 MFT 的输出之一时，为了优化，输入可能必须更改媒体类型。 例如，如果 1080p 输出流停止，并且所有其他流（共享一个输入）正在以 720p 的速度流式传输，则输入流应将其媒体类型更改为 720p，以节省电源并提高性能。

DTM 处理来自设备 MFT 的 METransformInputStreamStateChanged 通知，以在这些条件下更改设备 MFT 输入和 Devproxy 输出上的媒体类型和状态。

设备 MFT 的首选输出媒体类型

我们建议设备 MFT 使用 NV12 格式生成输出媒体类型。 YUY2 是次佳选择。 不建议使用 MJPEG 和 RGB 媒体类型。

刷新设备 MFT

管理设备 MFT 时需要两种类型的刷新：

• 全局刷新

  • 设备 MFT 范围的刷新。 当 DTM 即将停止流式处理消息发送到设备 MFT 时，通常会发生这种情况。

  • 设备 MFT 应从其输入和输出队列中删除所有样本，并同步返回。

  • 设备 MFT 不应在新的可用输出上请求新的输入或发送通知。

• 本地刷新

  • 输出特定于引脚的刷新。 这通常在流停止时发生。

设备 MFT 管理器会删除在刷新之前发布的所有事件。 刷新后，设备 MFT 会重置其内部 METransformHaveOutput 跟踪计数。

设备 MFT 的排出

设备 MFT 不会收到单独的排出消息，因为实时捕获源中无需排出。

照片触发器

在此模型中，不会将照片触发器和照片序列启动和停止触发器直接发送到驱动程序，而是重新路由到设备 MFT。 设备 MFT 根据需要处理触发器或将其转发到相机驱动程序。

热启动

DeviceSource 尝试通过将流转换为暂停状态来热启动特定的输出流。 反过来，DTM 在设备 MFT 上调用 IMFDeviceTransform::SetOutputStreamState 方法，以转换特定输出流以暂停状态。 这会导致将相应的输入流置于暂停状态。 设备 MFT 通过向 DTM 请求 METransformInputStreamStateChanged 并处理 IMFDeviceTransform::SetInputStreamState 方法来实现此目的。

可变照片序列

使用此体系结构，照片序列通过相机设备驱动程序和设备 MFT 实现，大大减少了相机设备驱动程序的复杂性。 开始和停止照片序列触发器将发送到设备 MFT，并更轻松地处理照片序列。

照片确认

设备 MFT 支持通过 IMFCapturePhotoConfirmation 接口进行照片确认。 管道通过 IMFGetService::GetService 方法检索此接口。

元数据

Devproxy 查询驱动程序以获取元数据缓冲区大小，并为元数据分配内存。 来自驱动程序的元数据仍由 Devproxy 在示例中设置。 设备 MFT 使用示例的元数据。 元数据可以通过其输出流与示例一起传递，也可以用于后期处理。

借助支持任意数量的输入的设备 MFT，专用输入引脚仅用于元数据或带外元数据。 此引脚的媒体类型是自定义的，驱动程序决定缓冲区的大小和数量。

此元数据流在 DTM 之外公开。 当设备 MFT 开始流式处理时，该流可以置于流式处理状态。 例如，选择用于流式传输的输出流时，设备 MFT 还可以使用 METransformInputStreamStateChanged 事件请求 DTM 启动一个或多个视频流和元数据流。

注意：不需要输入引脚数来匹配此模型中的输出引脚数。 可以有一个单独的引脚专用于元数据或 3A。

设备转换管理器 (DTM) 事件处理

设备转换管理器事件在以下参考文章中定义：

• METransformFlushInputStream

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformNeedInput

IMFDeviceTransform 接口

IMFDeviceTransform 接口定义为与设备 MFT 交互。 此接口有助于管理 m 输入和 n 输出设备 MFT。 与其他接口一起，设备 MFT 必须实现此接口。

常规事件传播

在 Devproxy（或设备内部）中发生事件时，需要将事件传播到设备 MFT 和 DeviceSource。

设备 MFT 要求

界面要求

设备 MFT 必须支持以下接口：

• IMFDeviceTransform

• IKsControl

  • 这允许所有 ksproperties、事件和方法通过设备 MFT。 这使设备 MFT 能够处理设备 MFT 中的这些函数调用，或只是将它们转发到驱动程序。 如果处理 KsEvent 方法，则设备 MFT 必须执行以下步骤：

    • 如果设备 MFT 处理任何 KSEVENT_TYPE_ONESHOT 事件，则在收到 KSEVENT_TYPE_ENABLE 时复制句柄。

    • 完成设置或引发事件后，它会在重复的句柄上调用 CloseHandle。

    • 如果设备 MFT 处理非 KSEVENT_TYPE_ONESHOT 事件，那么当它接收到 KSEVENT_TYPE_ENABLE 时，它会复制句柄，当通过调用 KsEvent 函数禁用 ks 事件时，通过将第一个参数（ks 事件 ID）和第二个参数（事件长度）设置为零，在复制的句柄上调用 CloseHandle。 事件数据和长度有效。 事件数据唯一标识特定的 ks 事件。

    • 如果设备 MFT 处理非 KSEVENT_TYPE_ONESHOT 事件，那么当它收到 KSEVENT_TYPE_ENABLE 时，它会复制句柄，当通过调用所有参数都设置为零的 KSEVENT 函数禁用 ks 事件时，会对复制的句柄调用 CloseHandle。

• IMFRealTimeClientEx

• IMFMediaEventGenerator

• IMFShutdown

• IMFSampleAllocatorControl

通知要求

设备 MFT 必须使用以下消息通知 DTM 示例的可用性、任何输入流状态更改等。

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformFlushInputStream

线程要求

设备 MFT 不得创建自己的线程。 相反，它必须使用媒体基础工作队列，这些队列基于通过 IMFRealTimeClientEx 接口传递到 DMFT 的 ID 进行分配。 这是为了确保设备 MFT 中运行的所有线程都获得捕获管道运行的正确优先级，并避免线程优先级反转。

InputStream 要求

流计数

• 设备 MFT 中的输入流数必须与驱动程序支持的流数相同。

MediaTypes

• 设备 MFT 输入支持的媒体类型和实际媒体类型数必须与驱动程序支持的媒体类型的数量和类型相匹配。

• 仅当设备 MFT 的输入支持的媒体类型是驱动程序支持的媒体类型的子集时，数字才能有所不同。

• 设备 MFT 的驱动程序和输入支持的媒体类型可以是标准媒体类型或自定义媒体类型。

如何注册设备 MFT

相机设备 INF 必须具有以下设备接口条目，该条目指定设备 MFT 的 CoClass 的 CLSID。

[CaptureAvstrm.Device.NTarm.Interfaces]
AddInterface = %KSCATEGORY_VIDEO_CAMERA%, %Capture.FilterDescBack%, Capture.FilterBack

[Capture.FilterBack]
AddReg = Capture.FilterBack.AddReg, PinNames.AddReg

[Capture.FilterBack.AddReg]
HKR,,FriendlyName,,%Capture.FilterDescBack%
HKR,,CameraDeviceMftClsid,,%CameraDeviceMFT.Clsid%

这些 INF 条目会导致输入以下注册表项：

注意

这只是一个示例（而不是实际的注册表项）

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\{E5323777-F976-4f5b-9B55-B94699C46E44}\##?#USB#VID_045E&PID_075D&MI_00#8&23C3DB65&0&0000#{E5323777-F976-4f5b-9B55-B94699C46E44}\#GLOBAL\Device Parameters]
"CLSID"="{17CCA71B-ECD7-11D0-B908-00A0C9223196}"
"FriendlyName"="USB Video Device"
"CameraDeviceMftClsid"="{3456A71B-ECD7-11D0-B908-00A0C9223196}"<<< Device MFT CoClass ID >>>

设备 MFT 链接

设备 MFT 是 IHV 和 OEM 的建议用户模式插件机制，用于扩展 Windows 上的相机功能。

在 Windows 10 版本 1703 之前，相机管道仅支持一个 DMFT 扩展插件。

从 Windows 10 版本 1703 开始，Windows 相机管道支持最多两个 DMFT 的可选 DMFT 链。

从 Windows 11 版本 22H2 开始，Windows 相机管道支持最多四个 DMFT 的可选 DMFT 链。

这为 OEM 和 IHV 提供了更大的灵活性，以后处理相机流的形式提供增值功能。 例如，设备可以使用 PDMFT 以及 IHV DMFT 和 OEM DMFT。

下图说明了涉及 DMFT 链的体系结构。

捕获样本从相机驱动程序流向 DevProxy，然后通过 DMFT 链。 链中的每个 DMFT 都有机会处理样本。 如果 DMFT 不想处理样本，它可以充当直通——只需将样本传递给下一个 DMFT。

对于像 KsProperty 这样的控件，调用会向上游进行 — 链中的最后一个 DMFT 会首先得到调用。 可以在该处处理调用，也可以传递给链中的前一个 DMFT。

错误从 DMFT 传播到 DTM，然后传播到应用程序。 对于 IHV/OEM DMFT，任何一个 DMFT 无法实例化都是 DTM 的致命错误。

DMFT 的要求：

• DMFT 的输入引脚计数必须与以前的 DMFT 的输出引脚计数匹配。 否则，在初始化期间 DTM 会失败。 但是，同一 DMFT 的输入和输出引脚计数不需要匹配。

• DMFT 需要支持接口 - IMFDeviceTransform、IMFShutdown、IMFRealTimeClientEx、IKsControl 和 IMFMediaEventGenerator；如果已配置 MFT0，或者链中的下一个 DMFT 需要 IMFTransform 支持，则可能需要支持 IMFTransform。

• 在不使用帧服务器的 64 位系统上，必须注册 32 位和 64 位 DMFT。 鉴于 USB 相机可能插入任意系统，对于“外部”（或非收件箱）USB 相机，USB 相机供应商应同时提供 32 位和 64 位 DMFT。

配置 DMFT 链

相机设备可以选择使用自定义 INF 文件在 DLL 中提供 DMFT COM 对象，该文件使用收件箱 USBVideo.INF 的部分信息。

在自定义 .INF 文件的“Interface AddReg”部分，通过添加以下注册表项来指定 DMFT CLSID：

CameraDeviceMftCLSIDChain (REG_MULTI_SZ) %Dmft0.CLSID%,%Dmft.CLSID%,%Dmft2.CLSID%

如下面的示例 INF 设置中所示（将 %Dmft0.CLSID% 和 %Dmft1.CLSID% 替换为用于 DMFT 的实际 CLSID 字符串），Windows 10 版本 1703 中最多允许 2 个 CLID，第一个 ID 最接近 DevProxy，最后一个是链中的最后一个 DMFT。

平台 DMFT CLSID 为 {3D096DDE-8971-4AD5-98F9-C74F56492630}。

一些示例 CameraDeviceMftCLSIDChain 设置：

• 无 IHV/OEM DMFT 或平台 DMFT

  • CameraDeviceMftCLSIDChain = ""（或不需要指定此注册表项）

• IHV/OEM DMFT

  • CameraDeviceMftCLSIDChain = %Dmft.CLSID%

• 平台 DMFT <-> IHV/OEM DMFT

  • CameraDeviceMftCLSIDChain = "{3D096DDE-8971-4AD5-98F9-C74F56492630}",%Dmft.CLSID%

  • 下面是链中 USB 相机的结果注册表项的屏幕截图，其中包含平台 DMFT 和 DMFT（包含 GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}）。

• IHV/OEM DMFT0 <-> IHV/OEM DMFT1

  • CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,

注意

CameraDeviceMftCLSIDChain 最多可以有 2 个 CLSID。

如果配置 CameraDeviceMftCLSIDChain，DTM 将跳过旧的 CameraDeviceMftCLSID 设置。

如果未配置 CameraDeviceMftCLSIDChain，但配置了旧版 CameraDeviceMftCLSID，则链将如下所示（如果其 USB 相机由平台 DMFT 支持，并且平台 DMFT 已启用）DevProxy <–> 平台 DMFT <–> OEM/IHV DMFT，或者（如果相机不受平台 DMFT 支持或平台 DMFT 被禁用）DevProxy <-> OEM/IHV DMFT。

INF 文件设置示例：

[USBVideo.Interface.AddReg]
HKR,,CLSID,,%ProxyVCap.CLSID%
HKR,,FriendlyName,,%USBVideo.DeviceDesc%
HKR,,RTCFlags,0x00010001,0x00000010
HKR,,EnablePlatformDmft,0x00010001,0x00000001
HKR,,DisablePlatformDmftFeatures,0x00010001,0x00000001
HKR,,CameraDeviceMftCLSIDChain, 0x00010000,%Dmft0.CLSID%,%Dmft1.CLSID%

设备 MFT 的 Com 对象和 MFT 注册

驱动程序 COM 对象不是全局注册驱动程序 COM 对象，而是在设备键下注册驱动程序 COM 对象。 这样，MFT COM 即可从容器内部注册并防止创建全局注册表项，从而保留驱动程序包隔离。 MFT 也出于类似原因在设备键下注册。

驱动程序 INF 的更改

安装设备驱动程序后，INF 现在必须在设备键下进行所有 COM 对象和 MFT 注册。 MFT 和 COM 注册必须更改，如下所示：

MFT 注册

之前	之后
INF AddReg： HKCR, MediaFoundation\Transforms\{clsid}\...	基于实例设备软件 INF AddReg： HKR, MediaFoundation\Transforms\{clsid}\...
注册表位置： HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\...	注册表位置： software key\MediaFoundation\Transforms\{clsid}\...

COM 注册

在 Windows 26100 及更高版本中，设备 MFT 的所有 COM 注册都必须在 INF 中使用 AddComServer/AddComClass 指令。 下面是语法示例：

[AvsCamera.COM]
AddComServer = AvsCameraMFT,,AvsCamera.COMInstall

[AvsCamera.COMInstall]
ServerType = 1; in-proc
ServerBinary = %13%\AvsCameraDMFT.dll
AddComClass = %DMFT.CLSID%,, AvsCamera.COMClassInstall


[AvsCamera.COMClassInstall]
ThreadingModel = Both
Description = %AvsCamera.ComServerDescription%

早期版本的设备 MFT COM 注册使用 AddReg 手动安装 COM 类。

之前	之后
INF AddReg： HKLM,Software\Classes\CLSID\{clsid}\... HKCR,CLSID\{clsid}\... HKCR,Wow6432Node\CLSID\{clsid}\... HKCR,WowAA32Node\CLSID\{clsid}\...	基于实例设备软件 INF AddReg： HKR,Classes\CLSID\{clsid}\... HKR,Classes\CLSID\{clsid}\... HKR,Classes\Wow6432Node\CLSID\{clsid}\... HKR,Classes\WowAA32Node\CLSID\{clsid}\...

在将平台扩展与操作系统版本相结合时，可以找到基于 OS 版本的 INF 语法。 从 Window 11 25300 开始，INF 必须符合这些新的注册表项。 较旧的 OS 版本使用传统注册表项实现兼容性。 INF 必须在旧 OS 内部版本的旧位置设置这些注册表项，并在新 OS 内部版本的新位置创建新键。 例如，对于较旧版本的 MFT 注册，INF 会在以下注册表项下创建键：

HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\ 

对于新内部版本的 MFT 注册，INF 会在以下注册表项下创建键：

**software key**\MediaFoundation\Transforms\{clsid}\ 

此条目定义了软件键表示设备软件键的位置。

有关详细信息，请参阅打开设备的软件键。

下面显示了面向不同 OS 版本的语法示例：

[Manufacturer] 
%Msft% = Msft, NTamd64,NTamd64.10.0...25300 

; -------------- ; 
; Models Section ; 
; -------------- ; 

; Targets old builds
[Msft.NTamd64] 
%DeviceDesc% = ExampleDDInstall_Old, ExampleHardwareId

[ExampleDDInstall_Old]
 AddReg = MFT_Registration_Old

[MFT_Registration_Old]
; INF work for older build here

; Windows 10 build with build number equal to or greater than 25300 
[msft.ntamd64.10.0...25300]  
%DeviceDesc% = ExampleDDInstall_New, ExampleHardwareId

[ExampleDDInstall_new]
AddReg = MFT_Registration_new

[MFT_Registration_new]
; INF work for newer build here