デバイス MFT 設計ガイド

[アーティクル]
04/03/2024

Windows のビデオキャプチャスタックでは、DMFT 形式のユーザーモード拡張機能がサポートされています。これは IHV が提供するデバイスごとの拡張コンポーネントで、キャプチャパイプラインはキャプチャ後の最初の変換として挿入されます。 DMFT は、デバイスから後処理されたフレームを受信します。 DMFT の内部では、フレームに対してさらなる後処理を行うことができます。 DMFT は、デバイスのすべてのストリームからフレームを受信でき、要件に従って任意の数の出力ストリームを公開できます。

このトピックでは、すべてのストリームに共通する後処理を実行するために使用できる、ユーザーモードで動作するデバイス全体の拡張機能の設計について説明します。

用語

用語	説明
KS	カーネルストリーミングドライバー
AvStream	オーディオビデオストリーミングドライバーモデル
Assert	デバイスのインスタンスを表すオブジェクト
デバイス MFT	IHV が提供するユーザーモードキャプチャドライバ拡張機能
Devproxy	MF <-> AvStream マーシャラー
DTM	devproxy とデバイス MFT を管理するデバイス変換マネージャー。 MF パイプライン内のデバイスを表します。

設計目標

デバイスフィルターと同じ有効期間を持つデバイスフィルター全体のユーザーモード拡張機能
デバイスから送信される任意の数の入力をサポートします。
任意の数の出力をサポートします (現在の要件は、プレビュー、記録、写真の 3 つのストリームです)。
すべてのデバイス制御をデバイス MFT にルーティングします (オプションでそれを処理またはデバイスに渡します)。
キャプチャされたストリームの並列後処理
フレームレートに依存しない 3A 処理を許可します。
あるストリームのメタデータを他のストリーム間で共有可能です。
GPU リソースへのアクセス
MF MMCSS 作業キューへのアクセス
MF アロケーターへのアクセス
シンプルなインターフェイス（MFTに類似）
IHV/OEM 拡張性のための柔軟な内部アーキテクチャ

設計上の制約

キャプチャ API サーフェイスに変更はありません。
完全な下位互換性。たとえば、レガシーアプリやシナリオでの作業中にリグレッションが発生することはありません。

キャプチャスタックアーキテクチャ

このトピックでは、キャプチャドライバーに対するフィルター全体のユーザーモード拡張機能のサポートについて説明します。このコンポーネントは、MF API、スレッドプール、GPU、ISP リソースにアクセスできます。フィルター全体の拡張機能は、フィルター自体とデバイス Ks フィルターの間に任意の数のストリームを配置する柔軟性を提供します。この柔軟性により、ユーザーモード拡張機能とドライバー間のシームレスな帯域外通信が可能になり、専用のメタデータや 3A 処理ストリームに使用できます。

capture stack architecture.

device mft architecture.

デバイス変換マネージャー (DTM)

キャプチャスタックには、新しいシステム提供コンポーネントであるデバイス変換マネージャー (DTM) が導入されています。これは DeviceSource 内に存在し、Devproxy MFT と Device MFT を管理します。 DTM は、MediaType ネゴシエーション、サンプル伝達、およびすべての MFT イベント処理を行います。また、DeviceSource に対する IMFTransform インターフェイスや、DeviceSource がデバイスストリームを管理するために必要なその他のプライベートインターフェイスも公開します。このコンポーネントは、パイプラインから Devproxy と Device MFT を抽象化します。パイプラインは、DTM をデバイスとして、DTM からストリームをデバイスストリームとして捉えます。

Devproxy

Devproxy は、AvStream カメラドライバーと Media Foundation の間でコマンドとビデオフレームをマーシャリングする非同期 MFT です。これは Windows によって提供され、カメラドライバーからのn 個の出力をサポートします。また、これはデバイスによって公開されるすべてのピンのアロケーターを所有します。

デバイス MFT

デバイス MFT は、キャプチャドライバーのユーザーモード拡張機能です。 m x n非同期 MFT です。キャプチャドライバと一緒にシステムにインストールされ、キャプチャドライバベンダーによって提供されます。

デバイス MFT の入力ストリームの数は、デバイスによって公開される Ks ピンの数と同じである必要があります。デバイス MFT の入力ストリームでサポートされるメディアタイプは、KS ピンによって公開されるメディアタイプと同じである必要があります。

Device MFT によって公開される出力ストリームの数は、DeviceSource、キャプチャスタック、キャプチャ API、およびアプリケーションによって認識されるストリームであり、1 つ、2 つ、または 3 つのストリームになります。デバイス MFT の入力ストリームと出力ストリームの数は同じである必要はありません。また、入力ストリームと出力ストリームが同じメディアタイプである必要はなく、通常は異なるメディアタイプを持つことになります。メディアタイプの数も一致する必要はありません。

Devproxy の出力ストリームによってユーザーモードで表される最初の Ks ピンは、Device MFT の最初の入力ストリームに関連付けられ、Devproxy の出力ストリームによってユーザーモードで表される 2 番目の Ks ピンは、Device MFT の 2 番目の入力ストリームに関連付けられます。

デバイス MFT には、Devproxy、DX デバイス、および MF WorkQueue ID へのポインターが与えられます。デバイスから送信されるフレームは、対応するデバイス MFT の入力に MF サンプルとして直接供給されます。これらすべてにより、デバイス MFT はキャプチャしたサンプルを後処理し、プレビュー、記録、写真のピンにサンプルを提供できます。

デバイスへのすべてのコマンドと制御は、デバイス MFT にリルートされます。デバイス MFT は、制御を処理するか、Devproxy を介してドライバーに渡します。これにより、キャプチャドライバースタックによるコマンド処理が効率化されます。

機能の概要

キャプチャパイプラインの初期化時に、デバイスのデバイス MFT がある場合、DeviceSource は DTM をインスタンス化します。デバイスを表す Devproxy のインスタンスを DTM の初期化ルーチンに渡します。 DTM は Device MFT を共同作成し、Devproxy の出力ピンの数が Device MFT の入力ピンの数と同じであること、必須インターフェースのサポートなど、基本的な検証を行います。

DeviceSource はサポートされている出力メディアタイプを取得するために DTM をクエリします。 DTM は、デバイス MFT の出力ピンからこれらを取得します。 DeviceSource は、この情報に基づいてプレゼンテーション記述子とストリーム記述子をキャプチャパイプラインに公開します。

SourceReader は、DeviceSource の公開されたメディアタイプを使用し、各ストリームにデフォルトのメディアタイプを設定します。一方、DeviceSource は DTM の出力ストリームにデフォルトのメディアタイプを設定します。 DTM は、SetOutputStreamStateメソッドを使用して、デバイス MFT の出力ストリームにメディアタイプを設定します。

SetOutputStreamStateが呼び出されると、デバイス MFT は、選択された出力メディアタイプに基づいて入力ストリームのメディアタイプを変更するメッセージを DTM に送信し、待機します。このメッセージに応答して、DTM はGetPreferredInputStreamStateを使用して、デバイス MFT の入力ストリームの優先入力メディアタイプをクエリします。これにより、Devproxy の対応する出力ストリームにメディアタイプが設定されます。成功した場合、DTM は SetInputStreamState を使用して、同じメディアタイプをデバイス MFT の入力ストリームに設定します。この呼び出しを受信した後、デバイス MFT は SetOutputStreamState を完了します。

CaptureEngine は、DeviceSource で特定のストリームを有効にすることで、個々のストリームを選択します。これは、SetOutputStreamState 呼び出しを介して DTM によってデバイス MFT に伝達されます。デバイス MFT は、特定の出力ストリームを要求された状態に配置します。前述のとおり、Device MFT は、有効にする必要がある入力ストリームについても DTM に通知します。これにより、DTM によってストリーム選択が Devproxy に伝達されます。このプロセスの最後に、Devproxy と Device 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 と Device MFT を開始します。

注: デバイス MFT の初期化ではなく、ストリーミング開始時に必要なリソースを割り当てます。

DTM は、ストリーミング状態パラメーターを使用して、デバイス MFT の出力に対して SetOutputStreamState を呼び出します。デバイス MFT は、これらの出力ストリームでストリーミングを開始します。 DTM は、有効なメディアタイプセットを持つ Devproxy 出力ストリームでストリーミングを開始します。 Devproxy はサンプルを割り当て、デバイスからそれらをフェッチします。これらのサンプルは、関連する入力ピンのデバイス MFT に供給されます。デバイス MFT は、これらのサンプルを処理し、DeviceSource に出力を提供します。 DeviceSource から、サンプルは SourceReader を経由して CaptureEngine に流れます。

CaptureEngine は、DeviceSource 上の内部インターフェイスを介して個々のストリームを無効にすることで、個々のストリームを停止します。これは、SetOutputStreamState を介してデバイス MFT上で特定の出力ストリームが無効になるように変換されます。一方、Device MFT は、METransformInputStreamStateChangedイベントを通じて、特定の入力ストリームを無効にするよう要求することができます。 DTM は、これを対応する Devproxy ストリームに伝達します。

デバイス MFT 自体がストリーミング状態である限り、有効な DeviceStreamState のいずれかに遷移するように任意の入力ストリームを要求できます。たとえば、他のストリームに影響を与えずに、DeviceStreamState_Stop、DeviceStreamState_Run、DeviceStreamState_Pauseなどに送信できます。

ただし、出力ストリームの遷移はキャプチャパイプラインによって制御されます。たとえば、プレビュー、記録、写真のストリームは、キャプチャパイプラインによって有効または無効にされます。出力が無効になっている場合でも、デバイス MFT 自体がストリーミング状態である限り、入力ストリームがストリーミングされる可能性があります。

device mft pipeline preview sequence.

device mft take photo sequence.

デバイス MFT の有効期間

デバイス MFT は、KS フィルターが作成された後にロードされます。 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 入力ストリームの 1 つは、そのメディアタイプを変更する必要があります。
出力ピンが無効になります。
- 同じ入力が複数の出力で共有されているときにアプリケーションがデバイス MFT の出力の 1 つを無効にすると、最適化のために入力ではメディアタイプを変更する必要がある場合があります。たとえば、1080p の出力ストリームが停止し、1 つの入力を共有する他のすべてのストリームが 720p でストリーミングされている場合、入力ストリームは、電力を節約し、パフォーマンスを向上させるために、そのメディアタイプを 720p に変更する必要があります。

DTM は、デバイス MFT からの METransformInputStreamStateChanged 通知を処理して、これらの条件下でデバイス MFT 入力と Devproxy 出力のメディアタイプと状態を変更します。

デバイス MFT の優先出力メディアタイプ

デバイス MFT は NV12 フォーマットを使用して生成することを強くお勧めします。 YUY2 は、次に最適な代替手段です。 MJPEG および RGB メディアタイプは推奨されません。

デバイス MFT のフラッシュ

デバイス MFT の管理には、次の 2 種類のフラッシュが必要です。

グローバルフラッシュ
- デバイス 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 メソッドを使用してこのインターフェイスを取得します。

Metadata

Devproxy は、ドライバーにメタデータバッファーサイズのクエリを実行し、メタデータのメモリを割り当てます。ドライバから送られてくるメタデータは、サンプル上の Devproxy によって設定されたままです。デバイス MFT は、サンプルのメタデータを使用します。メタデータは、出力ストリームを介してサンプルと共に渡されるか、後処理に使用されます。

任意の数の入力をサポートする Device MFT では、メタデータまたは帯域外メタデータの専用の入力ピンを使用できます。このピンのメディアタイプはカスタムであり、ドライバーはバッファーのサイズと数を決定します。

このメタデータストリームは DTM を超えて公開されます。デバイス MFT がストリーミングを開始すると、ストリームをストリーミング状態にすることができます。たとえば、出力ストリームがストリーミング用に選択されている場合、デバイス MFT は、METransformInputStreamStateChanged イベントを使用して、1 つ以上のビデオストリームとメタデータストリームを開始するように DTM に要求できます。

注: このモデルの出力ピンの数と一致する入力ピンの数に関する要件はありません。メタデータ専用または 3A 専用の別のピンを使用できます。

デバイス変換マネージャー (DTM) イベント処理

デバイス変換マネージャーイベントは、次のリファレンストピックで定義されています。

IMFDeviceTransform インターフェイス

IMFDeviceTransform インターフェイスは、デバイス MFT と対話するように定義されています。このインタフェースは、m入力およびn出力デバイス MFT の管理を容易にします。デバイス MFT は、他のインターフェイスと共にこのインターフェイスを実装する必要があります。

一般的なイベントの伝達

Devproxy (またはデバイス内) でイベントが発生した場合は、そのイベントをデバイス MFT と DeviceSource に伝達する必要があります。

デバイス MFT の要件

インターフェイスの要件

デバイス MFT は、次のインターフェイスをサポートする必要があります。

IMFDeviceTransform
IKsControl
- これにより、すべての ksproperties、イベント、メソッドがデバイス MFT を通過できます。これにより、デバイス MFT はこれらの関数呼び出しを Device MFT 内部で処理したり、ドライバに転送したりすることができます。 KsEvent メソッドを処理する場合、デバイス MFT は次の操作を行う必要があります。
  - デバイス MFT が KSEVENT_TYPE_ONESHOTイベントを処理する場合、KSEVENT_TYPE_ENABLE を受信するとハンドルを複製します。
  - イベントの設定または発生が完了すると、重複したハンドルに対して CloseHandle 呼び出します。
  - デバイス MFT が非 KSEVENT_TYPE_ONESHOT イベントを処理する場合、KSEVENT_TYPE_ENABLE を受信したときにハンドルを複製し、最初のパラメーター (ks イベント ID) と 2 番目のパラメーター(イベントの長さ)がゼロに設定された KsEvent 関数を呼び出して ks イベントが無効にするときに、複製されたハンドルに対して CloseHandle を呼び出す必要があります。イベントデータと長さは有効になります。イベントデータは、特定の ks イベントを一意に識別します。
  - デバイス MFT が非 KSEVENT_TYPE_ONESHOT イベントを処理する場合、KSEVENT_TYPE_ENABLE を受信したときにハンドルを複製し、すべでのパラメーターがゼロに設定された KsEvent 関数を呼び出して ks イベントが無効にするときに、複製されたハンドルに対して CloseHandle を呼び出す必要があります。
IMFRealTimeClientEx
IMFMediaEventGenerator
IMFShutdown
IMFSampleAllocatorControl

通知要件

デバイス MFT は、サンプルの可用性、入力ストリームの状態の変化などについて DTM に通知するために、次のメッセージを送信する必要があります。

スレッドの要件

デバイス 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 エントリーの結果、以下のレジストリキーが入力されます。

Note

これは例です（実際のレジキーではありません）。

[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 は、Windows でカメラ機能を拡張するために、IHV および OEM に推奨されるユーザーモードプラグインメカニズムです。

Windows 10 バージョン 1703 以前、カメラパイプラインは 1 つの DMFT 拡張プラグインのみをサポートしていました。

Windows 10 バージョン 1703 以降、Windows カメラパイプラインは、最大 2 つの DMFT を持つオプションの DMFT チェーンをサポートします。

Windows 11 バージョン 22H2 以降、Windows カメラパイプラインは、最大 4 つの DMFT を持つオプションの DMFT チェーンをサポートします。

これにより、OEM と IHV は、カメラストリームの後処理の形式で付加価値を提供する柔軟性が向上します。たとえば、デバイスは PDMFT を IHV DMFT および OEM DMFT とともに使用できます。

次の図は、DMFT のチェーンを含むアーキテクチャを示しています。

DMFT chain.

カメラドライバーから 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 ビット DMFT と 64 ビット DMFT の両方を登録する必要があります。 USB カメラが任意のシステムに接続される可能性があることを考えると、「外部」(または非受信トレイ) の USB カメラの場合、USB カメラベンダーは 32 ビット DMFT と 64 ビット DMFT の両方を提供する必要があります。

DMFT チェーンの構成

カメラデバイスは、オプションで受信トレイ USBVideo.INF のセクションを使用するカスタム INF ファイルを使用して、DLL 内の DMFT COM オブジェクトを提供できます。

カスタム .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 つの CLSID が許可されます。最初の CLSID は DevProxy に最も近く、最後の CLSID はチェーンの最後の 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%
- 以下は、プラットフォーム DMFT を使用した USB カメラとチェーン内の DMFT (GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}) の結果レジストリキーのスクリーンショットです。

Registry editor DMFT chain.

IHV/OEM DMFT0 <-> IHV/OEM DMFT1
- CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,

Note

CameraDeviceMftCLSIDChainは、最大 2 つの CLSID を持つことができます。

カメラ CameraDeviceMftCLSIDChain が構成されている場合、レガシ CameraDeviceMftCLSID 設定は DTM によってスキップされます。

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 オブジェクトは、グローバルに登録されるのではなく、デバイスキーの下に登録されるようになります。これにより、コンテナー内からの 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 登録：

以前	クリック後
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\WowAA32Node\CLSID\{clsid}\... HKR,Classes\WowAA32Node\CLSID\{clsid}\...

OS のバージョンに基づいて区別するための INF 構文については、「プラットフォーム拡張機能とオペレーティングシステムのバージョンの組み合わせ」を参照してください。 Windows 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

次の方法で共有