4

VoIP音声品質監視アプリケーションの場合、着信RTPオーディオストリームを参照信号と比較する必要があります。信号の比較自体には、既存の専用ツールを使用します。他の部分（パケットキャプチャを除く）については、Gstreamerライブラリが適切な選択であるように思われました。次のパイプラインを使用して、最低限のVoIPクライアントをシミュレートします。

filesrc location=foobar.pcap ! pcapparse ! "application/x-rtp, payload=0, clock-rate=8000"
  ! gstrtpjitterbuffer ! rtppcmudepay ! mulawdec ! audioconvert
  ! audioresample ! wavenc ! filesink location=foobar.wav

pcapファイルには、単一のRTPメディアストリームが含まれています。元の400個のUDPデータグラムのうち50個が欠落しているキャプチャファイルを作成しました。与えられたオーディオサンプル（私の例では8秒の長さ）の場合：

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

一定量の連続したパケット損失があると、次のようなオーディオ信号が出力されると思います（' -'は無音を示します）。

[XXXXXXXXXXXXXXXXXXXXXXXX-----XXXXXXXXXXX]

ただし、実際にオーディオファイルに保存されるのは次のとおりです（私の例では1秒短くなっています）。

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

このアプリケーションの重要な部分であるジッターバッファが正しく機能していないようです。これは、要素との非互換性/pcapparse要素の欠点である可能性がありますか？時間の同期を確保するために、パイプラインの重要な部分が欠落していますか？他に何がこれを引き起こしている可能性がありますか？

4

2 に答える 2

2

GStreamerは、デジッターバッファーを使用して、（オーディオ）出力に向かう途中のパケットをスムーズにすることができます。これは珍しいことではなく、デジッタの最低限の定義です。

順不同のパケットを並べ替えたり、重複を削除したりすることもできますが、パケット損失の隠蔽（シナリオ）は非常に複雑になる可能性があります。

基本的な実装では、最後に受信したパケットを複製するだけですが、より高度な実装では、最後に受信したパケットのトーンを分析および再構築して、音声を滑らかにします。

アプリケーションのパフォーマンスは損失隠蔽の正確な実装に依存するように思われるため、GStreamerが「何か」を行ったとしても、詳細に理解しない限り、結果への影響を定量化するのは難しいかもしれません。

おそらく、いくつかの順序が狂って重複しているパケットでpcapを試して、GStreamerが少なくともそれらを並べ替え/削除するかどうかを確認することができます。これは、何が起こっているのかを明確にするために何らかの形で役立ちます。

于 2011-01-11T03:10:18.957 に答える
2

この問題は、パイプラインを少し変更することで解決できます。「必要に応じてサンプルを挿入またはドロップして完全なストリームを生成する」audiorate前に、要素を追加する必要があります。ただし、これはパケット損失イベントを受信した場合にのみ機能します。このためには、のプロパティをtrueに設定する必要があります。wavencaudioratedo-lostgstjitterbuffer

修正されたパイプラインは次のとおりです。

filesrc location=foobar.pcap ! pcapparse
  ! "application/x-rtp, payload=0, clock-rate=8000"
  ! gstrtpjitterbuffer do-lost=true ! rtppcmudepay ! mulawdec
  ! audioconvert ! audioresample ! audiorate ! wavenc
  ! filesink location=foobar.wav
于 2011-01-13T15:48:50.850 に答える