理由を使用するために強制サードパーティのDirectShowフィルタ:サードパーティのフィルタでカスタムアロケータを使用するカスタムアロケータ
私はNUMAシステムを持っており、フィルタはパフォーマンスの問題で間違ったNUMAノード結果にメモリを割り当て、ドロップ持ちますカメラから受信した画像。
私の現在のアプローチ:
私はすべてのフィルタを反復処理し、その入力端子はアロケータを持っている場合はそれらを求める関数を書きましたよ。次に、私はこのアロケータに特別なアロケータインターフェイスを依頼し、最後にインターフェイスが見つからなければ新しいカスタムアロケータを作成し、以前のアロケータと同じプロパティを適用します。次に、入力ピンのNotifyAllocator
を呼び出して、新しいアロケータについて通知します。
私はこの機能をグラフビルディングで別々の時間に呼び出そうとしました。現在はIMediaControl::Pause
の直後で、IMediaControl::Run
の直前ですが、私のカスタムアロケータはサードパーティのフィルタでは使用されていません。サンプルは間違ったNUMAノードに存在します。
また、IMediaControl::Pause
呼び出し中に作成されたスレッドを追跡して、スレッドアフィニティを正しいCPUに変更するため、通常は実行中のCPUのNUMAノードに割り当てる必要があるように、これらのDirectShowフィルタには正しいNUMAノードが必要です。
私はそれを推測していましたが、どのようにサンプルが同じNUMAノードにあることを確認できますか?アロケータ・インタフェースまたは 'ALLOC_PROPERTIES'は、この種のプロパティを保証するオプションを持っていません。 多分、スレッドの親和性にもっと集中するべきですが、これは100%の作業の解決策ではありません。 –
NUMAについて何も知らない、既にビルドされたフィルタを使用して確実に達成できるかどうかはわかりません。カスタムフィルタを実行するオプションが増えるはずです。自然にアロケータを選択すると、作成したスレッドやスレッドをさらに制御できるようになります。 –
私たちが話しているサードパーティフィルタは、この場合のビデオ圧縮フィルタです。初期の計画では、カスタム圧縮フィルタを作成するのではなく、インストールされている圧縮フィルタからユーザーが選択できるようにしました。 私が考えることができる唯一の他のソリューションは、すべての処理がビデオメモリで行われていることです。しかし、私が正しく覚えていれば、私はMFTのすべてを書き直す必要があります。 –