問題タブ [dspack]

複数の入力ピン間で単純なオーディオ ミキシングを行い、マージされたデータを単一の出力ピン (多対 1) に配信する DirectShow フィルターを実装しています。オーディオ データのミキシングについては理解しましたが、メディア以外のデータストリーム メッセージをどうするかについて意見を求めたいと思います。たとえば、DSPACK DirectShow コンポーネント ライブラリから取得した以下のコードを変更し、Delphi 6 アプリで使用しているとします。

ご覧のとおり、現在、ストリーム メディア データメッセージではない入力ピンの配信をすぐに出力ピンに渡しています。これは、すべての入力ピンが次のオーディオ データ バッファーを配信するまで保持するオーディオ データを受信し、そのオーディオ データをミキシングしてから、唯一の出力ピンに対して単一の Receive 呼び出しを行う場合とは対照的です。私の質問は次のとおりです。

1. オーディオ データの受信を処理するときに入力ピンの配信をバッチ処理し、メディア以外のデータの受信にはすぐに渡すと、どのような影響がありますか? このようなメッセージのリストは、次の MSDN ドキュメントにあります。

http://msdn.microsoft.com/en-us/library/windows/desktop/dd373500(v=vs.85).aspx

1. このアプローチによって、ダウンストリーム フィルターが混乱したり破損したりすることはありますか? もしそうなら、オーディオデータを混合するフィルターに現在接続されている入力ピン間で非ストリームメディアデータの受信を調停するには、どのような手法を採用する必要がありますか?

Delphi 6 と DSPACK ライブラリを使用して DirectShow Transform フィルタを作成しました。DSPACK の基本 Filter クラスと、変換フィルターの例である「WAV Dest」サンプル アプリに属する​​コードを調べました。私が知る限り、Transform フィルターのソース IMediaSample または宛先 IMediaSample パラメーターの受信フィルターによってメモリが割り当てられていませんが、宛先 IMediaSample の長さが IMediaSample.SetActualLength() を使用して調整される可能性があります。

DirectShow API 仕様の一部である場合、これら 2 つのパラメーターに既にメモリが割り当てられている Transform フィルターを呼び出すコードに依存できることを確認したいだけなので、そうする必要はありません。それ以外の場合は、CoTaskMemAlloc() を使用して自分でその割り当てを行う必要があると思います。誰かがここで決定的な答えを教えてくれますか?

DSPACK コンポーネント ライブラリを使用して Delphi 6 で記述された DirectShow Transform フィルタがあります。新しい接続が試行されるたびに新しい入力ピンを作成する単純なオーディオ ミキサーです。メディア形式が設定されると、その入力ピンまたは単一の出力ピンへのすべての接続がそのメディア形式に準拠するように強制されるため、単純と言います。フィルター チェーンを手動で構築し、すべてのピン接続を自分で明示的に行います。望ましくない動作 (私の場合) を誤ってトリガーする方法がない限り、「インテリジェント レンダリング」呼び出しは使用しません。

注: キャプチャ フィルターは、アプリケーションの外部にある標準の DirectShow フィルターです。プッシュ ソース オーディオ フィルタと単純なオーディオ ミキサー フィルタは、プライベートで未登録のフィルタとして使用されており、アプリケーションの内部にあります。

ミキサーに複数の入力接続を作成しようとしたときにのみ発生する奇妙な問題が発生します。これは実際にそれらを受け入れます。現在、キャプチャ フィルタとカスタム プッシュ ソース オーディオ フィルタの両方をミキサー フィルタに接続しようとしています。それをしようとすると、2 番目のアップストリーム フィルター接続が失敗します。Capture Filter を最初に接続するか、Push Source オーディオ フィルターを最初に接続するかに関係なく、2 番目のアップストリーム フィルター接続は常に失敗します。

私が実行した最初のテストは、Capture Filter だけをミキサーに接続することでした。それはうまくいきました。

私が実行した 2 番目のテストは、Push Source オーディオ フィルターのみをミキサーに接続することでした。それはうまくいきました。

しかし、両方を実行しようとするとすぐに、「中間フィルターの組み合わせが見つかりませんでした」というエラーが表示されます。グラフ ビルダーからフィルタにヒットするメディア ネゴシエーション コールを数時間掘り下げたところ、問題が見つかりました。何らかの理由で、フィルタ グラフが古い「Indeo (R) Audio Software」コーデックをチェーンに引きずり込んでいます。

私がこれを発見したのは、コーデックがほぼすべての点 (メジャー タイプ、サブ タイプ、フォーマット タイプ、ウェーブ フォーマット パラメータ) でフィルターに一致するメディア フォーマットを持っていたにもかかわらず、pbFormat データの最後に余分な 2 バイトがあったためです。メンバーであり、それは対等に失敗するのに十分でしたテストは、各メディア タイプの cbFormat 値を比較することによって、ソースとターゲットの pbFormat 領域を比較するためです。Indeo コーデックの cbFormat 値は 20 ですが、フィルターの cbFormat 値は 18 です。これは _tWAVEFORMATEX データ構造のサイズです。20 バイト領域の最初の 18 バイトは、ミキサー フィルタがサポートするメディア タイプの pbFormat 領域と正確に等しいため、Indeo pbFormat の奇妙なサイズはある意味では良いことです。その異常がなければ、私は古代のコーデックがドラッグインされていることを知りませんでした.エクスプロイトと脆弱性が知られているので、それがまったくドラッグインされていることに驚いています. 最も紛らわしいのは、これが入力ピンの 1 つではなく、ミキサー フィルターの出力ピンで発生していることです。ピン接続を構築するときに、ダウンストリーム接続をまだ 1 つも作成していません。

キャプチャ フィルターとプッシュ ソース フィルターの両方の受信フィルターのメディア形式が同一であり、一致するため中間フィルターをまったく必要としないにもかかわらず、DirectShow がそのコーデックをドラッグしようとしている理由を誰か教えてください。ミキサー フィルタの入力ピンが正確にサポートするフォーマットは? この問題を解決するにはどうすればよいですか?

また、成功した上記の単一フィルター取り付けテストでも、私のミキサー出力ピンはメディア形式について引き続きクエリを受けていることに気付きました。前述したように、ピン接続を構築するこの時点で、ミキサー フィルターの出力ピンに何も接続していないのはなぜですか?

--------------------------- 更新: 1 -------------------- --------

IGraphBuilder.Connect() の代わりに IFilterGraph.ConnectDirect() を使用すると、「インテリジェント接続」の動作を完全に回避できることがわかりました。DirectConnect() に切り替えたところ、ミキサー フィルターの入力ピンが「既に接続されている」状態に戻っていることがわかりました。それが原因で、グラフ ビルダーが Indeo コーデック フィルターを引きずっている可能性があります。この新しい診断情報が得られたので、問題を修正し、この記事を結果で更新します。

DSPACK コンポーネント ライブラリを利用して、Delphi 6 で記述された DirectShow プッシュ ソース フィルタと DirectShow シンプル オーディオ ミキサー フィルタがあります。私のアプリでは、フィルタ グラフを手動で作成し、ピン接続には IFilterGraph.ConnectDirect() を使用して、DirectShow の「インテリジェント接続」テクノロジからの干渉を回避しています。これらのフィルターの両方を、プログラム内のプライベート/未登録フィルターとして使用しています。

作成したグラフには、グラフの先頭位置を共有するキャプチャ フィルターとプッシュ ソース オーディオ フィルターがあります。それらの出力ピンは私の単純なオーディオ ミキサーに接続されており、後者は複数の入力接続をサポートしています。ミキサーは、入力ピンと出力ピンへのすべての接続を、そのコンストラクターで事前に設定されているものとまったく同じメディア形式タイプに強制します。この場合、私が使用しているフォーマット設定は、サンプル レート 8000、サンプルあたり 16 ビット、および 1 チャネルの WAV フォーマットです。DecideBufferSize() を使用して、すべてのフィルターを 50 ミリ秒のバッファー サイズに設定していることに注意してください。これにより、400 バイト (200 サンプル) の大きさのバッファーが配信されます。

キャプチャ フィルターは、DirectShow API を使用して見つけた外部 COM オブジェクトです。現在、VOIP 電話をデバイス (モニカー) として割り当てています。奇妙な理由で、私のプッシュ ソース フィルタは、キャプチャ フィルタのちょうど 7 倍の速度でバッファを送り出しています。つまり、ミキサー フィルタは、キャプチャ フィルタから受け取るバッファごとに、プッシュ ソース フィルタから 7 つのバッファを取得しています。これは、ミキサー フィルターがバッファーを取得するたびに行をデバッグして出力し、バッファーのソースであるフィルターを特定するためです。

外部コードであるため、キャプチャ フィルターがどのようにタイムスタンプを形成しているかはわかりませんが、通常のスキームだと思います。私のプッシュ ソース フィルターはゼロから始まり、FillBuffer() 呼び出しごとに、DirectShow 参照時間形式のタイムスタンプをバッファーが表す時間だけインクリメントします。

ここに私の質問があります：

1)グラフを手動で作成している場合でも、タイムスタンプは重要ですか? グラフを完全に手動で作成したとしても、DirectShow はフィルターの中間に入り、何らかの方法でピン書き込み (受信呼び出し) のタイミングに影響を与える可能性がありますか?

2) グラフ全体で均一なメディア形式が使用されているにもかかわらず、フィルタがバッファをあまりにも速く押し出す原因となるよくある間違いは何ですか?

DSPACK コンポーネント ライブラリを使用して Delphi 6 で記述された DirectShow アプリケーションがあります。互いに連携する 2 つのフィルター グラフがあります。

プライマリフィルター グラフの構造は次のとおりです。

1. バッファ サイズが 100 ミリ秒のキャプチャ フィルタ。
2. (接続先) Sample Grabber Filter。

「二次」フィルタ グラフには、この構造があります。

1. 管理するオーディオ バッファ ストアハウスに直接オーディオを受け入れるカスタム プッシュ ソース フィルタ。
2. (接続先) レンダー フィルター。

プッシュ ソース フィルターは、イベントを使用してオーディオの配信を制御します。その FillBuffer() コマンドはイベントを待機します。新しいオーディオ データがバッファに追加されると、Event が通知されます。

フィルタ グラフを実行すると、オーディオに小さな「ギャップ」が聞こえます。通常、この状態は、不適切に構築されたオーディオ バッファが埋められていないか、「ギャップ」があることと関連しています。しかし、テストとして、Tee フィルターを追加し、WAV Dest フィルターに続いて File Writer フィルターを接続しました。出力された WAV ファイルを調べると、完全に滑らかで連続しています。つまり、スピーカーから聞こえるギャップは、出力ファイルでは明らかではありません。

これは、キャプチャ フィルタからのオーディオが正常に伝播されているにもかかわらず、オーディオ バッファの配信が定期的に干渉を受けていることを示しています。私が聞く「ギャップ」は 1 秒間に 10 回ではなく、1 秒間に 2 回または 3 回のようで、短い間隔でまったくギャップがないこともあります。したがって、すべてのバッファで発生しているわけではありません。または、1 秒に 10 回のギャップが聞こえます。

私の最初の推測では、ロックの問題ですが、イベントに 150 ミリ秒のタイムアウトが設定されており、それが発生した場合は例外がスローされます。例外はスローされていません。また、アプリケーションで使用されるすべてのクリティカル セクションに 40 ミリ秒のタイムアウトを設定しましたが、いずれもトリガーしていません。OutputDebugString() ダンプと、非シグナル(ブロック) とシグナルの間の時間を確認しました(ブロックされていない) オカレンスは、94 ミリ秒と 140 ミリ秒の間で交互に変化するかなり一定のパターンを示しています。つまり、Push Source Filter の FillBuffer() 呼び出しは 94 ミリ秒、次に 140 ミリ秒ブロックされたままになり、それが繰り返されます。持続時間は少しずれますが、かなり規則的です。このパターンは、Windows スレッドの切り替えの気まぐれを考えると、100 ミリ秒間隔でオーディオ バッファーをプッシュ ソース フィルターにダンプするためにキャプチャ フィルターで待機しているスレッドと一致しているようです。

プッシュ ソース フィルターでダブル バッファリングを使用していると思うので、どのロック メカニズムも合わせて 200 ミリ秒以上かかっていなければ、オーディオ ストリームを中断するべきではないと考えています。しかし、これらの症状を引き起こすロックの問題以外には考えられません。何か間違ったことをしている場合に備えて、以下の Push Source Filter に DecideBufferSize() メソッドのコードを含めました。少し長くなりますが、効果がある可能性がある場合に備えて、タイムスタンプを生成する方法を示すために、以下の FillBuffer() 呼び出しも含めました。

すべてのオーディオ バッファがそのまま配信されているにもかかわらず、Render Filter へのオーディオ ストリームが途切れる原因は他に何が考えられますか?

質問: ダブル バッファリングを自分で実装する必要がありますか? DirectShow レンダー フィルターがそれを行うと考えました。そうしないと、カスタム プッシュ ソース フィルターなしで作成した他のフィルター グラフが正しく機能しなかったでしょう。しかし、フィルター グラフで別のロック/ロック解除状況を作成しているため、独自のダブル バッファリング レイヤーを追加する必要があるのではないでしょうか? もちろん、追加のレイテンシを回避するためにそれを避けたいので、私の状況に別の修正がある場合は知りたい.

DSPACK コンポーネント ライブラリを使用して Delphi 6 で記述され、Windows XP で実行される DirectShow アプリケーションがあります。フィルタ グラフの上部には、オーディオ キャプチャ フィルタがあります。キャプチャ フィルターは私の VOIP 電話に割り当てられており、ストリームのすぐ下にサンプル グラバー フィルターがあります。サンプル グラバー フィルターのコールバック メソッドで、同じタイムスタンプ (SampleTime) を持つサンプル グラバー フィルターから連続して 2 つのメディア サンプルを取得するたびに報告するコードを追加しました。その状態は非常に頻繁に発生し、時にはほぼ毎回発生します。キャプチャ フィルタのバッファ サイズは 100 ミリ秒で、サンプル レートは 8000 kHz です。ロジックは、同じサンプル時間で 2 つのサンプル配信を取得してはならず、常に 100 ミリ秒近く離れている必要があることを教えてくれます。しかし、それは起こっていることではありません。

DirectShow キャプチャ フィルタが同じサンプル時間で 2 つの連続したメディア サンプルを送信することはどういう意味ですか? 前のサンプル時間と同じサンプル時間の 2 番目のサンプル配信を無視する必要がありますか? または、対処する必要がある別の問題がありますか?

私は、入ってくるサンプル時間を制御できないことに注意してください。それらはキャプチャ フィルタによって生成されています。

DSPACKコンポーネントライブラリを使用するDelphi6DirectShowプッシュソースビデオフィルターがあります。特定の操作を実行する前に、フィルターのどの側面でフィルターの状態をロックする必要がありますか？たとえば、フィルターのFillBuffer（）メソッドでは、ビットマップキャンバスを作成する前に、フィルターの共有状態をロックする必要がありますか？それとも、共有状態をロックする必要があるのは、フィルターピンの接続/切断イベントやメディアフォーマットネゴシエーションなどの操作だけですか？

DSPACKコンポーネントライブラリを使用してDelphi6で記述されたDirectShowフィルターがあります。プッシュソースのビデオフィルターです。フィルタは、ビデオフレームを生成する別のスレッドで通知されるイベントをブロックします。フレームの準備ができると、ブロックが解除されたときにFillBuffer（）メソッドがアクセスする共有メモリ領域に書き込まれます。フィルタがDirectShowによってシャットダウンされているときにFillBuffer（）スレッドのブロックを解除するためにピギーバックできる便利なDirectShowイベントはありますか？そうでない場合、この分野の「標準的な慣行」とは何ですか？

DirectShow DSPACK コンポーネント スイートを使用する Delphi 6 アプリケーションがあります。フィルタ グラフから画像をレンダリングする TVideoWindow コンポーネントがあります。TVideoWindow コンポーネントは、ページ コンポーネントのタブにあります。フィルタ グラフを実行したときにタブが表示されていれば、ビデオは問題なく表示されます。また、別のタブに切り替えて戻ってきても、ビデオは問題ありません。ただし、タブが表示されていないときにフィルター グラフを実行すると、そのタブに切り替えるとビデオ ウィンドウ領域が黒くなります。別のタブに切り替えて元に戻し、ホストフォームを最小化して復元しようとしましたが、黒のままです。これはウィンドウ/コンポーネント ハンドルのライフサイクルの問題でしょうか? どうすればこれを修正できますか?

DSPACK コンポーネント ライブラリで構築された Delphi 6 アプリケーションに DirectShow フィルタ グラフがあります。グラフの構造は次のとおりです。

• カスタム プッシュ ソース オーディオ フィルタ
• サンプルグラバー
• Tee Filter (ただし、WAV File Writer と Renderer の両方をオンにした場合のみ)
• レンダラー (優先 PC 出力デバイス)
• WAVファイルライター

レンダラー フィルターと WAV ファイル ライター フィルターの両方がオンになっている場合にのみ、ティー フィルターがグラフに追加されます。それ以外の場合は、オンになっているフィルターのみを Sample Grabber に直接接続します。

オーディオは、リアルタイムでオーディオをストリーミングしている WiFi 接続された RTSP オーディオ サーバーを介して配信されています。Wav File Writer をオンにしないと、ヘッドフォンから出力されるオーディオには、バッファリングされていないオーディオ ストリームに関連する典型的なポンピング サウンドと時折のクリック サウンドが含まれます。不思議なことに、WAV File Writer フィルターをオンにするとすぐに、音声がガラスのように滑らかになります。

私は WAV File Writer のソース コードを持っており、必要に応じて適切な WAV ファイル ヘッダーを出力し、必要に応じてオーディオ バッファーを書き込むタスクを基本的に処理します。特に、レンダラー (フィルター) の上流ではなく、レンダラーに沿ってティー フィルターの端にぶら下がっているピア フィルターであるため、これをオンにすると着信オーディオ ストリームがスムーズになるのは奇妙です。

File Writer フィルターをオンにすると、オーディオ配信がスムーズになるために何が起こっているのか、誰か教えてもらえますか? Tee Filter は固有のバッファリングを行いますか? File Writer がオンになっていないときにスムーズなオーディオが得られるように、同じメカニズムを複製したいと考えています。リアルタイム オーディオ ストリームに必要以上の遅延を追加したくないため、独自のバッファリングを追加しないようにしています。