次の方法で共有


デバイス MFT 設計ガイド

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

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

用語

Term 説明
KS カーネル ストリーミング ドライバー
AVStream オーディオ ビデオ ストリーミング ドライバー モデル
フィルター デバイスのインスタンスを表すオブジェクト
デバイス 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 処理ストリームに使用できます。

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

デバイス MFT アーキテクチャ。

デバイス変換マネージャー (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 を開始します。

Note

デバイス 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 自体がストリーミング状態である限り、入力ストリームがストリーミングされる可能性があります。

デバイス MFT パイプライン プレビュー シーケンス。

デバイス MFT 写真撮影シーケンス。

デバイス 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 チェーン。

カメラ ドライバーから 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}) の結果レジストリ キーのスクリーン ショットです。

レジストリ エディター DMFT チェーン。

  • 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 登録

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\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