0

DSPACKコンポーネントライブラリを使用してDelphi6で記述されたDirectShowフィルターがあります。これは、私も書いた外部の協力プロセスからソースフレームを受け取るプッシュソースビデオフィルターです。

FiltersのFillBuffer（）呼び出しを呼び出すワーカースレッドが作成されて実行されると、グラフが起動したときに、そのワーカースレッドから最初に行うことは、AllocateHWND（）を使用して非表示のウィンドウを作成し、外部を含むWM_COPYDATAメッセージを処理することです。生成されたフレーム。スレッドが破棄される直前に、非表示のウィンドウを破棄します。つまり、非表示のウィンドウは、FillBuffer（）を呼び出すワーカースレッドの実行コンテキストで作成および破棄されます。私の意図は、FillBuffer（）がWM_COPYDATAまたはWM_QUITメッセージを待機するときにブロックすることです。外部の協力プロセスは、WM_COPYDATAメッセージと非表示のウィンドウのWndProcc（）へのハンドルを使用して、フレームをフィルターに送信します。ピンのInactive（）メソッドのオーバーライドにWM_QUITメッセージを投稿します（そのヒント@RomanRに感謝します）。

私の質問は、このシナリオでは、FillBuffer（）呼び出しからPeekMessage（）またはGetMessage（）を呼び出しても安全ですか？または、DirectShowグラフの実行のコンテキストでこれが発生することから発生する可能性のある潜在的な落とし穴はありますか？また、ここでの私の全体的なアプローチに、考慮する必要のある欠陥がありますか？

4

1 に答える 1

1

安全ですが、あまり合理的ではありません。FillBuffer通常、ウィンドウがないバックグラウンド ワーカー スレッドで呼び出されています。メッセージループを実装するのは、おそらくあなたのウィンドウだけでしょう。そして、ウィンドウはメッセージを受信するためだけにここにありWM_COPYDATAます。うまくいくように思えますが、名前付きファイル マッピングとイベントを介してアプリケーション間でデータを渡すことにより、ヘルパー ウィンドウがなくても、はるかに簡単に実行できるでしょう。ビデオの場合 (オーディオがありますよね?)、パフォーマンスのオーバーヘッドが小さいことも評価できます。

于 2011-12-25T22:43:08.327 に答える