デバイス MFT 設計ガイド

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

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

用語

設計目標

• デバイス フィルターと同じ有効期間を持つデバイス フィルター全体のユーザー モード拡張機能

• デバイスから送信される任意の数の入力をサポートします

• 任意の数の出力をサポートします (現在の要件は、プレビュー、レコード、写真の 3 つのストリームです)

• すべてのデバイス制御をデバイス MFT にルーティングします（オプションで処理するか、デバイスに渡すことができます）。

• キャプチャされたストリームの並列後処理

• フレーム レートに依存しない 3A 処理を許可する

• あるストリームのメタデータを他のストリーム間で共有できるようにする

• GPU リソースへのアクセス

• MF MMCSS 作業キューへのアクセス

• MF アロケーターへのアクセス

• シンプルなインターフェイス (MFT に似ています)

• IHV/OEM 拡張性のための柔軟な内部アーキテクチャ

デザインの制約

• Capture API サーフェイスに変更はありません

• 下位互換性が完全です。 たとえば、レガシ アプリやシナリオの操作中に回帰はありません。

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

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

デバイストランスフォームマネージャー (DTM)

キャプチャ スタックには、新しいシステム提供コンポーネントである Device Transform Manager (DTM) が導入されています。 これは DeviceSource 内に存在し、Devproxy MFT と Device MFT を管理します。 DTM は、MediaType ネゴシエーション、サンプル伝達、およびすべての MFT イベント処理を行います。 また、デバイス ストリームを管理するために DeviceSource に必要なその他のプライベート インターフェイスと、DeviceSource に IMFTransform インターフェイスを公開します。 このコンポーネントは、パイプラインから 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 Pin は、デバイス MFT の最初の入力ストリームに関連付けられます。Devproxy の出力ストリームでユーザーモードに表現される2番目の Ks Pin は、デバイス MFT の2番目の入力ストリームに関連付けられます。このように続きます。

デバイス 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 の出力ピンからこれを取得します。 DeviceSource は、この情報に基づいてプレゼンテーション記述子とストリーム記述子をキャプチャ パイプラインに公開します。

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

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

CaptureEngine は、DeviceSource で特定のストリームを有効にすることで、個々のストリームを選択します。 これは 、SetOutputStreamState 呼び出しを介して DTM によってデバイス MFT に伝達されます。 デバイス MFT は、特定の出力ストリームを要求された状態に配置します。 前述のように、デバイス 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 を開始します。

DTM は、ストリーミング状態パラメーターを使用して、デバイス MFT の出力で SetOutputStreamState を呼び出します。 デバイス MFT は、これらの出力ストリームでストリーミングを開始します。 DTM は、有効な mediatype が設定されている 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 の有効期間

デバイス MFT は、KS フィルターが作成された後に読み込まれます。 KS フィルターが閉じられる前にアンロードされます。

パイプラインの観点からは、DeviceSource が作成されると、デバイス MFT が作成され、DeviceSource がシャットダウンされると、デバイス MFT が同期的にシャットダウンされます。

シャットダウンをサポートするには、デバイス MFT が IMFShutdown インターフェイスをサポートする必要があります。 デバイス MFT >Shutdown が呼び出された後、デバイス MFT へのその他のインターフェイス呼び出しは、MF_E_SHUTDOWN エラーを返す必要があります。

メモリの種類

フレームは、カメラ ドライバーの設定に従って、システム メモリ バッファーまたは DX メモリ バッファーにキャプチャできます。 カメラ ドライバーから出てくるバッファーは、さらに処理するためにデバイス MFT に直接供給されます。

Devproxy は、ドライバーの設定に基づいてバッファーを割り当てます。 デバイス MFT では、MF アロケーター API を使用して、非プレース変換の出力ピンに必要なサンプルを割り当てる必要があります。

ストリーミング中の Mediatype の変更

SourceReader のクライアントは、Device MFT の出力ストリームによって公開されているメディアタイプをネイティブでサポートされているメディアタイプとして確認できます。 ネイティブ メディアタイプが変更されると、SourceReader は DeviceSource を介して Mediatype 通知呼び出しをデバイス MFT に送信します。 デバイス MFT は、そのストリームのキューから保留中のすべてのサンプルをフラッシュし、そのストリームの新しいメディアタイプにタイムリーに切り替える必要があります。 入力メディアタイプを変更する必要がある場合は、現在の入力メディアタイプをそのメディアタイプに変更する必要があります。 DTM は、デバイス MFT の入力ストリームから現在のメディアタイプを取得し、ネイティブ メディアタイプの変更後に Devproxy の出力ストリームとデバイス MFT の入力に設定します。

デバイス MFT での入力メディアタイプの変更

これは m x n MFT であるため、出力ストリーミング ピンのメディアタイプまたは状態の変更時に、入力ストリーミング ピンのメディアタイプと状態の変化に影響が生じ得ます。 具体的には、次の変更が発生した場合です。

• Mediatype の変更を出力する

  • アプリケーションがネイティブ メディアタイプを変更すると、出力ピンのメディアタイプが変更されると、キャプチャ スタックを介してデバイス 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 メソッドを使用してこのインターフェイスを取得します。

メタデータ

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

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

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

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

Device Transform Manager (DTM) イベント処理

Device Transform Manager イベント は、次のリファレンス記事で定義されています。

• 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以外のイベントを処理する場合は、 1 番目のパラメーター (ks イベント ID) と 2 番目のパラメーター (イベントの長さ) を 0 に設定して KsEvent 関数を呼び出すことによって ks イベントが無効になったときに、KSEVENT_TYPE_ENABLEを受信したときにハンドルを複製し、重複したハンドルで CloseHandle を呼び出す必要があります。 イベント データと長さが有効です。 イベント データは、特定の ks イベントを一意に識別します。

    • デバイス MFT がKSEVENT_TYPE_ONESHOT以外のイベントを処理する場合は、 KSEVENT_TYPE_ENABLE を受け取ったときにハンドルを複製し、すべてのパラメーターが 0 に設定された KsEvent 関数を呼び出して ks イベントが無効になっている場合は、重複するハンドルに 対して CloseHandle を呼び出す必要があります。

• IMFRealTimeClientEx

• IMFMediaEventGenerator の

• IMFShutdown

• IMFSampleAllocatorControl の

通知の要件

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

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformFlushInputStream

スレッドの要件

デバイス MFT で独自のスレッドを作成することはできません。 代わりに、 MEDIA Foundation Work Queue を使用する必要があります。これは、 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 は、Windows でカメラ機能を拡張するために、IHV および OEM に推奨されるユーザー モード プラグイン メカニズムです。

Windows 10 バージョン 1703 より前では、カメラ パイプラインでサポートされた DMFT 拡張機能プラグインは 1 つだけです。

Windows 10 バージョン 1703 以降、Windows カメラ パイプラインでは、最大 2 つの DMFT を含む DMFT のオプション チェーンがサポートされています。

Windows 11 バージョン 22H2 以降、Windows カメラ パイプラインでは、最大 4 つの DMFT を含む DMFT のオプション チェーンがサポートされています。

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

次の図は、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 ビット 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 に最も近く、最後の 1 つはチェーン内の最後の 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 と DMFT (GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}) がチェーン内にある USB カメラの結果レジストリ キーのスクリーンショットを次に示します。

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

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

CameraDeviceMftCLSIDChain が構成されている場合、従来の CameraDeviceMftCLSID 設定は DTM によってスキップされます。

CameraDeviceMftCLSIDChain が構成されておらず、従来の CameraDeviceMftCLSID が構成されている場合、チェーンは次のようになります: (カメラが USB で、プラットフォーム 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 オブジェクトがデバイス キーに登録されます。 これにより、コンテナー内からの 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 クラスを手動でインストールしました。

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