设备 MFT 设计指南

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

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

术语

设计目标

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

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

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

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

• 捕获流的并行后处理

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

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

• 对 GPU 资源的访问

• 访问 MF MMCSS 工作队列

• 访问 MF 分配器

• 简单接口（类似于 MFT）

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

设计约束

• 捕获 API 图面没有更改

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

捕获堆栈体系结构

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

设备转换管理器 （DTM）

捕获堆栈引入了新的系统提供的组件设备转换管理器（DTM）。 这驻留在 DeviceSource 中，管理 Devproxy MFT 和 Device MFT。 DTM 执行 MediaType 协商、示例传播和所有 MFT 事件处理。 它还向 DeviceSource 以及 DeviceSource 管理设备流所需的其他必要专用接口公开 IMFTransform 接口。 此组件将 Devproxy 和设备 MFT 从管道中抽象出来。 管道只把 DTM 看作设备，而从 DTM 流出的流视为设备流。

Devproxy

Devproxy 是一个异步 MFT，负责在 AVStream 相机驱动程序和媒体基础架构之间封送命令和视频帧。 这由 Windows 提供，支持来自相机驱动程序的 n 个输出数。 此外，该设备拥有其公开的所有引脚的分配器。

设备 MFT

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

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

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

Devproxy 输出流以用户模式表示的第一个 Ks Pin 与设备 MFT 的第一个输入流相关联，第二个 Ks Pin 与设备 MFT 的第二个输入流相关联，以此类推。

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

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

功能概述

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

DeviceSource 查询 DTM 以获取支持的输出媒体类型。 DTM 接收此信息自 Device MFT 的输出引脚。 DeviceSource 基于此信息向捕获管道公开演示文稿描述符和流描述符。

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

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

CaptureEngine 通过在 DeviceSource 上启用特定流来选择单个流。 这会通过 SetOutputStreamState 调用传播到 Device 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。

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

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

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

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

设备 MFT 的寿命

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

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

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

内存类型

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

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

流式传输时媒体类型更改

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

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

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

• 输出媒介类型更改

  • 当应用程序更改原生媒体类型时，其更改会通过捕获堆栈级联到 Device MFT，作为输出引脚的媒体类型更改。

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

• 输出引脚已禁用

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

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

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

我们建议设备 MFT 使用 NV12 格式生成输出媒体类型。 YUY2 是下一个最好的替代方案。 不建议使用 MJPEG 和 RGB 媒体类型。

清除设备 MFT

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

• 全局刷新

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

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

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

• 本地刷新

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

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

设备 MFT 的排出

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

图像触发器

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

暖启动

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

可变照片序列

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

照片确认

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

Metadata

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

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

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

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

设备转换管理器 （DTM） 事件处理

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

• METransformFlushInputStream

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformNeedInput

IMFDeviceTransform 接口

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

常规事件传播

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

设备 MFT 要求

接口要求

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

• IMFDeviceTransform

• IKsControl

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

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

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

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

    • 如果 Device 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 的可选链。

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

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

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

捕获的数据样本从相机驱动程序传递到 DevProxy，然后经过 DMFT 链。 链中的每个 DMFT 都有机会处理样本。 如果 DMFT 不想处理样本，它可以作为中转，直接将样本传递给下一个 DMFT。

对于类似 KsProperty 的属性，调用会向上传递，先由链中最后一个 DMFT 处理。 可以在该处处理呼叫，或者传递到链中的前一个 DMFT。

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

关于 DMFTs 的要求：

• 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，DTM 会跳过旧的 CameraDeviceMftCLSID 设置。

如果未配置 CameraDeviceMftCLSIDChain，并且配置了旧版 CameraDeviceMftCLSID，则链将如下所示（如果其 USB 相机受平台 DMFT 支持并已启用）DevProxy <–> Platform 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 对象不是全局注册，而是在设备注册表项下注册。 这样，MFT COM 即可从容器内部注册并防止创建全局注册表项，从而保留驱动程序包隔离。 MFT 也出于类似原因在设备密钥下注册。

驱动程序 INF 的更改

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

MFT 注册

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 语法。 从 Windows 11 版本 25300 开始，INF 必须符合这些新的注册表项。 较旧的 OS 版本使用传统注册表项实现兼容性。 INF 必须在旧操作系统内部版本的旧位置设置这些注册表项，并在新操作系统内部版本的新位置创建新的注册表项。 例如，对于较旧版本的 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