裝置 MFT 設計指南

Windows 中的視訊擷取堆疊支援 DMFT 形式的使用者模式擴充功能。 這是 IHV 提供的個別裝置擴充元件，而擷取管線會插入作為第一個轉換後擷取。 DMFT 會從裝置接收後續處理的畫面格。 在 DMFT 內可以執行框架的進一步後處理作業。 DMFT 可以從裝置的所有數據流接收畫面，而且可以根據需求公開任意數目的輸出數據流。

本文概述在使用者模式中執行的全裝置擴充功能設計，可用來執行所有數據流通用的後續處理。

辭彙

詞彙	描述
KS	核心串流驅動程式
AVStream	音訊視訊串流驅動程式模型
篩選器	物件，表示裝置實例
裝置 MFT	IHD 所提供的使用者模式擷取驅動程序擴充功能
Devproxy	MF <-> AVStream 封送處理器
DTM	管理 devproxy 和 Device MFT 的裝置轉換管理員。 表示 MF 管線中的裝置。

設計目標

• 裝置篩選範圍的使用者模式擴充功能，其存留期與裝置篩選器相同

• 支援來自裝置的任意數目輸入

• 支援任意數目的輸出（目前的需求為三個資料流：預覽、記錄和相片）

• 將所有裝置控制項路由傳送至裝置 MFT（選擇性地處理或將它傳遞至裝置）

• 擷取數據流的平行後處理

• 允許 3A 處理與幀速率無關

• 允許一個數據流的元數據在其他數據流之間共用

• 存取 GPU 資源

• 存取 MF MMCSS 工作佇列

• 存取 MF 配置器

• 簡單介面（類似於 MFT）

• 適用於IHV/OEM擴充性的彈性內部架構

設計條件約束

• 擷取 API 介面中沒有變更

• 完成回溯相容性。 例如，在處理舊版應用程式和案例時，沒有回歸。

擷取堆疊架構

本文說明對擷取驅動程式的全篩選使用者模式擴充功能支援。 此元件可以存取 MF API、線程集區、GPU 和 ISP 資源。 篩選寬延伸模組提供在本身與裝置 Ks 篩選之間擁有任意數目數據流的彈性。 此彈性可在使用者模式擴充功能與驅動程式之間順暢地進行頻外通訊，可用於專用元數據和 3A 處理數據流。

裝置轉換管理員 （DTM）

擷取堆疊引進新的系統提供元件 Device Transform Manager （DTM）。 這位於 DeviceSource 內，並管理 Devproxy MFT 和 Device MFT。 DTM 會執行 MediaType 交涉、範例傳播，以及所有 MFT 事件處理。 它也會向 DeviceSource 公開 IMFTransform 介面，以及 DeviceSource 管理裝置串流所需的其他必要私人介面。 此元件會從管線擷取 Devproxy 和 Device MFT。 管線只會將 DTM 視為裝置，而從 DTM 流出數據流作為裝置串流。

Devproxy

Devproxy 是異步 MFT，可封送處理 AVStream 相機驅動程式與媒體基礎之間的命令和視訊畫面。 這是由 Windows 提供，並支援 來自相機驅動程式的 n 個輸出數目。 此外，這會擁有裝置所公開之所有針腳的配置器。

裝置 MFT

裝置 MFT 是擷取驅動程式的使用者模式擴充功能。 這是 m x n 異步 MFT。 它已安裝於具有擷取驅動程式的系統上，並由擷取驅動程式廠商提供。

裝置 MFT 的輸入數據流數目必須與裝置所公開的 Ks 針腳數目相同。 裝置 MFT 輸入數據流支援的 mediatype 必須與 KS 針腳所公開的媒體類型相同。

Device MFT 公開的輸出數據流數目是 DeviceSource 和擷取堆疊、擷取 API 和應用程式的數據流，而且可以是一、二或三個數據流。 裝置 MFT 的輸入和輸出數據流計數不需要相同。 此外，輸入和輸出數據流不需要具有相同的 mediatype，而且通常有不同的 mediatype。 mediatype 的數目也不需要相符。

Devproxy 輸出數據流以使用者模式表示的第一個 Ks Pin 會與 Device MFT 的第一個輸入數據流相關聯、Devproxy 輸出數據流與 Device MFT 的第二個輸入數據流，以使用者模式表示的第二個 Ks Pin 等等。

裝置 MFT 會提供 Devproxy、DX 裝置和 MF WorkQueue 識別碼的指標。 裝置輸出的畫面會直接饋送至對應的裝置 MFT 輸入作為 MF 範例。 裝置 MFT 可以張貼所擷取的範例，並將範例提供預覽、記錄和相片釘選。

移至裝置的所有命令和控件都會重新路由傳送至裝置 MFT。 裝置 MFT 會處理控制項，或透過 Devproxy 將它們傳遞至驅動程式。 這可簡化擷取驅動程式堆疊的命令處理。

功能概觀

在擷取管線的初始化時，如果有裝置的裝置 MFT，DeviceSource 就會具現化 DTM。 它會將 Devproxy 的實例傳遞至 DTM 的初始化例程。 DTM 會共同建立裝置 MFT 並執行基本驗證，例如，驗證 Devproxy 的輸出針腳數目與裝置 MFT 的輸入針腳數目相同、支持強制介面等等。

DeviceSource 會查詢 DTM 以取得支持的輸出媒體類型。 DTM 會從裝置 MFT 的輸出針腳取得此專案。 DeviceSource 會根據此資訊向擷取管線公開簡報描述元和數據流描述元。

SourceReader 會使用 DeviceSource 的公開媒體類型，並在每個數據流上設定預設媒體類型。 接著，DeviceSource 會在 DTM 的輸出數據流上設定預設媒體類型。 DTM 會使用 SetOutputStreamState 方法，在 Device MFT 的輸出數據流上設定 mediatype。

呼叫 SetOutputStreamState 時，Device MFT 會將訊息張貼至 DTM，以根據選取的輸出媒體類型並等候變更其輸入數據流的 mediatype。 為了回應此訊息，DTM 會使用 GetPreferredInputStreamState 查詢裝置 MFT 輸入數據流的慣用輸入媒體類型。 這會在 Devproxy 的對應輸出數據流上設定 mediatype。 如果成功，DTM 會使用 SetInputStreamState 將相同的媒體類型設定為裝置 MFT 的輸入數據流。 收到此呼叫之後，Device MFT 會 完成 SetOutputStreamState。

CaptureEngine 會啟用 DeviceSource 上的特定數據流，以選取個別串流。 這會透過 SetOutputStreamState 呼叫，透過 DTM 傳播至裝置 MFT。 裝置 MFT 會將特定輸出數據流置於要求的狀態。 如上所述，裝置 MFT 也會通知 DTM 需要啟用的必要輸入數據流。 這會導致 DTM 將數據流選取範圍傳播至 Devproxy。 在此程序結束時，Devproxy 和 Device MFT 中所有必要的數據流都已準備好進行串流。

SourceReader 會在 CaptureEngine 呼叫 ReadSample 時啟動 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和Device MFT。

注意

在開始串流時配置必要的資源，而不是裝置 MFT 初始化。

DTM 會使用串流狀態參數在裝置 MFT 的輸出上呼叫 SetOutputStreamState 。 裝置 MFT 會開始串流處理這些輸出數據流。 DTM 會在已設定有效 mediatype 的 Devproxy 輸出數據流上啟動串流。 Devproxy 會配置範例，並從裝置擷取它們。 這些範例會送入相關輸入針腳中的 Device MFT。 裝置 MFT 會處理這些範例，並將輸出提供給 DeviceSource。 從 DeviceSource，範例會流經 SourceReader 以擷取Engine。

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 介面。 呼叫裝置 MFT 關>機之後，裝置 MFT 的任何其他介面呼叫都必須傳回MF_E_SHUTDOWN錯誤。

記憶體類型

畫面格可以根據相機驅動程式的喜好設定，擷取到系統記憶體緩衝區或 DX 記憶體緩衝區。 相機驅動程式中傳出的任何緩衝區都會直接送入裝置 MFT 以進行進一步處理。

Devproxy 會根據驅動程式的喜好設定來配置緩衝區。 我們需要裝置 MFT 使用 MF 配置器 API，為非就地轉換配置其輸出針腳所需的樣本。

串流時的 Mediatype 變更

SourceReader 的客戶端能夠將 Device MFT 輸出數據流公開的 mediatype 視為原生支援的媒體類型。 當原生媒體類型變更時，SourceReader 會透過DeviceSource將mediatype通知呼叫傳送至Device MFT。 裝置 MFT 負責排清該數據流佇列中所有擱置中的樣本，並及時切換到該數據流上的新媒體類型。 如果有必要變更輸入媒體類型，則它應該將目前的輸入媒體類型變更為該類型。 DTM 會從 Device MFT 的輸入數據流取得目前的媒體類型，並在每個原生媒體類型變更之後，於 Devproxy 的輸出數據流和裝置 MFT 的輸入上設定它。

裝置 MFT 中的輸入媒體類型變更

由於這是 m x n MFT，因此當輸出串流釘選的 mediatype 或狀態變更時，輸入串流釘選的媒體類型和狀態變更可能會產生影響。 具體來說，發生下列變更時：

• 輸出 Mediatype 變更

  • 當應用程式變更原生媒體類型時，它會透過擷取堆疊串連到 Device MFT，做為輸出針腳媒體類型變更。

  • 當輸出 mediatype 變更時，它可以觸發輸入媒體類型變更。 例如，假設所有輸出針腳都在720p串流。 這會導致從相機串流到 720p。 接下來，假設記錄數據流將其原生媒體類型變更為 1080p。 在此情況下，將數據擷取至記錄數據流的其中一個裝置 MFT 輸入數據流必須變更其 mediatype。

• 輸出釘選已停用

  • 當應用程式停用其中一個裝置 MFT 的輸出時，當相同輸入由多個輸出共用時，為了優化，輸入可能必須變更 mediatype。 例如，如果 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 會藉由要求 METransformInputStreamStateChanged 至 DTM 並處理 IMFDeviceTransform：：SetInputStreamState 方法來達成此目的。

可變相片序列

透過此架構，相片序列會透過相機設備驅動器和裝置 MFT 實作，大幅降低相機設備驅動器的複雜度。 開始和停止相片序列觸發程式會傳送至 Device MFT，並更輕鬆地處理相片序列。

相片確認

裝置 MFT 支援透過 IMFCapturePhotoConfirmation 介面進行相片確認 。 管線會透過 IMFGetService：：GetService 方法擷取此介面。

中繼資料

Devproxy 會查詢驅動程式的元數據緩衝區大小，並配置元數據的記憶體。 來自驅動程式的元數據仍由範例上的 Devproxy 設定。 裝置 MFT 會取用範例的元數據。 元數據可以透過其輸出數據流傳遞至範例，或用於其後置處理。

透過裝置 MFT 支援任意數目的輸入，專用輸入針腳只能用於元數據或頻外元數據。 此針腳的 mediatype 是自定義的，而驅動程式會決定緩衝區的大小和數目。

此元數據數據流會公開至 DTM 以外。 當裝置 MFT 開始串流時，數據流可以放入串流狀態。 例如，選取輸出數據流進行串流處理時，裝置 MFT 也可以要求 DTM 啟動一或多個視訊串流，以及使用 METransformInputStreamStateChanged 事件來啟動元數據數據流。

注意：不需要輸入針腳數目符合此模型中的輸出針腳數目。 有個別的針腳專用於元數據或 3A。

裝置轉換管理員 （DTM） 事件處理

裝置轉換管理員事件 定義於下列參考文章中：

• METransformFlushInputStream

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformNeedInput

IMFDeviceTransform 介面

IMFDeviceTransform 介面的定義是與裝置 MFT 互動。 此介面可協助管理 m 輸入和 n 輸出裝置 MFT。 與其他介面一起，裝置 MFT 必須實作此介面。

一般事件傳播

當 Devproxy（或裝置內部）發生事件時，我們需要將事件傳播到裝置 MFT 和 DeviceSource。

裝置 MFT 需求

介面需求

裝置 MFT 必須支援下列介面：

• IMFDeviceTransform

• IKsControl

  • 這可讓所有 ksproperties、事件和方法通過裝置 MFT。 這可讓 Device MFT 能夠處理裝置 MFT 內的這些函式呼叫，或只將它們轉送至驅動程式。 在處理 KsEvent 方法的情況下，裝置 MFT 必須執行下列步驟：

    • 如果 Device MFT 處理任何KSEVENT_TYPE_ONESHOT事件，則會在收到KSEVENT_TYPE_ENABLE時複製句柄。

    • 完成設定或引發事件時，它會在重複的句柄上呼叫 CloseHandle 。

    • 如果 Device MFT 處理非KSEVENT_TYPE_ONESHOT事件，則當它收到 KSEVENT_TYPE_ENABLE 時，它應該複製句柄，並在 ks 事件停用時呼叫 KsEvent 函式，並將第一個參數 （ks 事件標識符） 和第二個參數 （事件長度） 設定為零來呼叫 CloseHandle 。 事件數據和長度有效。 事件數據會唯一識別特定的 ks 事件。

    • 如果 Device MFT 處理非KSEVENT_TYPE_ONESHOT事件，則當它收到KSEVENT_TYPE_ENABLE時，它應該複製句柄，並在 ks 事件停用時呼叫 CloseHandle，方法是呼叫 KsEvent 函式，並將所有參數設定為零。

• IMFRealTimeClientEx

• IMFMediaEventGenerator

• IMFShutdown

• IMFSampleAllocatorControl

通知需求

裝置 MFT 必須使用下列訊息來通知 DTM 範例的可用性、任何輸入數據流狀態變更等等。

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformFlushInputStream

線程需求

裝置 MFT 不得建立自己的線程。 相反地，它必須使用媒體基礎工作佇列，根據透過IMFRealTimeClientEx介面傳遞至 DMFT 的標識符來配置。 這是為了確保在裝置 MFT 中執行的所有線程都取得正確優先順序，擷取管線正在執行，並避免線程優先順序反轉。

InputStream 需求

數據流計數

• 裝置 MFT 中的輸入資料流數目必須與驅動程式支援的數據流數目相同。

MediaTypes

• 設備 MFT 輸入所支援的 mediatype 和實際媒體類型數目必須符合驅動程式所支援的 mediatype 數目和類型。

• 只有當設備 MFT 輸入支援的 mediatypes 是驅動程式支援的 mediatypes 子集時，數位才能不同。

• 驅動程序支援的 mediatype 和 Device 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 專案會導致輸入下列登入機碼：

注意

這隻是一個範例（不是實際的 regkey）

[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 是 IHD 和 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。

• 在未使用 Frame Server 的 64 位系統上，必須註冊 32 位和 64 位 DMFT。 假設USB相機可能會插入任意系統，針對「外部」（或非收件匣）USB相機，USB相機廠商應該同時提供32位和64位 DMFT。

設定 DMFT 鏈結

相機裝置可以選擇性地使用使用收件匣 USBVideo.INF 區段的自定義 INF 檔案，在 DLL 中提供 DMFT COM 物件。

在自定義 中。INF 檔案的「介面 AddReg」區段，藉由新增下列登錄專案來指定 DMFT CLSID：

CameraDeviceMftCLSIDChain （REG_MULTI_SZ） %Dmft0.CLSID%%Dmft.CLSID%，%Dmft2.CLSID%

如下列範例 INF 設定所示（將 %Dmft0.CLSID% 和 %Dmft1.CLSID% 取代為您用於 DMFT 的實際 CLSID 字串串），Windows 10 版本 1703 中最多允許 2 個 CLSID，而第一個 CLID 最接近 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 和 Platform DMFT 支援）DevProxy – Platform DMFT – Platform DMFT <–>> OEM/IHV DMFT 或 （如果平臺 DMFT 或 Platform 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}\...	登入位置： 軟體密鑰\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語法。 從 Windows 11 25300 開始，INF 必須符合這些新的登錄機碼。 舊版OS會使用傳統的登錄機碼來相容。 INF 必須在舊版 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