Gstreamer：RTPジッタバッファがパケットロスで正常に動作していませんか？

Question

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

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メディアストリームが含まれています。私は、最低限のVoIPクライアントをシミュレートするために、次のパイプラインを使用します。元の400のUDPデータグラムの50が欠けているキャプチャファイルを作成しました。所定のオーディオサンプルについて（私の例えば8秒の長さ）：私はこのような音声信号が出力されることを期待したい連続したパケット損失の一定量の

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX] 

（「-は」沈黙を表す）：

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX] 

ジッタバッファ、このアプリケーションの重要な部分であることを思わ：

[XXXXXXXXXXXXXXXXXXXXXXXX-----XXXXXXXXXXX] 

は、しかし、どのような実際のオーディオファイルに保存されていることは、この（私の例のための短い1S）であります正しく動作しません。これはpcapparse要素との互換性/欠点ですか？時間同期を確保するためにパイプラインの重要な部分が欠けていますか？それ以外の原因は何でしょうか？

Answer 1

パイプラインを少し変更することで問題が解決する可能性があります。 wavencの前に "produces a perfect stream by inserting or dropping samples as needed"の要素を追加する必要があります。 ただし、これはパケット損失イベントを受信した場合にのみ有効です（audiorate）。このため、do-lostのプロパティーはgstjitterbufferに設定する必要があります。

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 

Answer 2

GStreamerはデジッタバッファを使用して（オーディオ）出力への途中のパケットを平滑化することができます。これは珍しいことではないでしょう。それはデジッタリングの最小限の定義です。

パケットの順序を変更したり、重複を削除したりすることはできますが、パケット損失の隠蔽（シナリオ）はかなり複雑になる可能性があります。

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

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

おそらく、いくつかのアウトオブオーダーと重複したパケットでpcapを試し、GStreamerが少なくともそれらを並べ替え/削除するかどうかを確認することができます。