1

GMFBridgeを使用して複数のストリームバッファグラフを切り替えようとしていますが、2つの問題があるようです。

グラフの図は次のとおりです。http：//massivefailure.net/dshowgraphsalt.jpg

  1. ブリッジレンダリンググラフに接続されているブリッジソースグラフのVMRは非常に不安定で、4〜5秒ごとに新しいフレームが表示されます。

  2. ブリッジレンダリンググラフに接続されているブリッジソースグラフを探すと、すべての出力（接続されているブリッジソースとレンダリンググラフのVMR、および外部レンダラーの出力）が約1分間停止します。問題＃1からの途切れが再開されると、なくなります。

シークする前にブリッジレンダリンググラフを切断して停止し、シーク後に再接続して実行しようとしましたが、フリーズするか、接続されたブリッジソースグラフのVMRに約10秒ごとにフレームが表示されるという問題があります。

ある種の重要でない問題：

私は、VMRがプレビューピンに接続された無限のTシャツがあるスマートTシャツを持っていましたが、シークした後、ライブストリームに追いつくまで、通常の1.5〜2倍の速度で再生しました。スマートティーに戻ることができるようにそれを修正するための正しい方法はありますか？

4

1 に答える 1

3

ストリーム時間は2つのグラフで同じではないため、ブリッジはレンダリンググラフに入るサンプルのタイムスタンプを調整します。ただし、infteeフィルターは、同じサンプルを両方の出力に送信します。そのため、ソースグラフのVMRは、（場合によっては）タイムスタンプがレンダリンググラフで調整されたサンプルをレンダリングするように求められます。表示される再生の途切れは、VMRが追いつくのに失敗した結果です。

変更されたタイムスタンプがソースグラフに表示されないように、データをコピーするか、少なくともメタデータをコピーする必要があります。非圧縮のビデオデータでこれを行う最も簡単な方法は、色空間コンバーターなどのコピー変換を挿入することです（おそらくinfteeとブリッジシンクの間に）。

このような問題のデバッグに役立てるために、空のファイルc：\ gmfbridge.txtを作成すると、ブリッジコードによってタイムスタンプの調整と遅延を含むログが作成されます。

GMFBridgeサンプルは、タスクを非常に少ないオーバーヘッドで複数の個別のグラフに分割できることを示しています。そのため、データのコピーや配信パイプラインへの新しいスレッドの導入を回避できます。ただし、一部のタスクでは、これは非常に複雑であり、ワーカースレッドがダウンストリームにあるバッファーのプールなど、より単純で分離されたソリューションの方が適切です。

もう1つの問題は、スマートTシャツがプレビュー出力からタイムスタンプを削除するため、Tシャツの下流のサンプルが到着するとすぐにレンダリングされることです。通常のキャプチャグラフでは、サンプルにはキャプチャ時間のタイムスタンプが付けられます。これらをレンダラーに直接渡すと、サンプルは常にレンダリングに遅れます。適切な解決策は、キャプチャからレンダリングまでのレイテンシのタイムスタンプを調整することですが、ほとんどの場合、タイムスタンプを削除するという大まかな解決策が機能します。スマートティーは、IMediaSampleオブジェクトを複製することによってこれを行いますが、同じデータバッファーを指します（したがって、メタデータをコピーしますが、データはコピーしません）。スマートティーは、キャプチャ出力が遅れていると（1996年のヒューリスティックに従って）考えた場合、プレビュー出力のサンプルも破棄することに注意してください。

G

于 2009-09-18T08:42:26.083 に答える