2

オーディオストリームに再アセンブルしたいRTPパケットがたくさんあります。パケットごとに、シーケンス番号、SSRC、タイムスタンプ、およびデータ自体を表すバイト配列があります。

現在、私はパケットの各サブセットをSSRCで取得し、タイムスタンプで並べ替え、バイト配列をその順序で組み合わせています。その後、バイト配列を混合しています。結果として得られるオーディオデータは素晴らしいように聞こえますが(つまり、すべてが間に合っていることを意味します)、パケット損失があまりないことが原因であることが心配です。

だから、いくつかの質問...

  1. 欠落しているパケットの場合、欠落しているシーケンス番号は、空のオーディオを少し追加する必要がある場所を示しています。シーケンス番号は頻繁に「ラップアラウンド」すると思うので、タイムスタンプを使用してサブセットに分割する必要があります。次に、それらのサブセットで欠落しているシーケンス番号を探し、必要に応じて追加できます。それは正しいことのように聞こえますか?

  2. タイムスタンプが他に何に適しているのかよくわかりません。既存のパケットを記録し、不足しているパケットを埋めているので、これについてそれほど心配する必要はないのでしょうか。

4

3 に答える 3

2

1)アルゴリズムでタイムスタンプを使用しないでください。不良クライアント(不適切なタイムスタンプ)からストリームを受信して​​いる場合、アルゴリズムは失敗します。また、「タイムスタンプの増分」値はコーデックタイプによって異なります。その場合、コーデックごとに異なるサブセットが必要になる場合があります。シーケンス番号に制限はありません。シーケンス番号は単調に増加します。シーケンス番号を使用すると、失われたパケットを簡単に追跡できます。

2)タイムスタンプは、オーディオとビデオ間の同期に使用されます。主にリップシンク用。同期を実現するために、オーディオとビデオのタイムスタンプ間の関係が確立されます。あなたの場合は唯一の音声なので、タイムスタンプの使用を避けることができます。

編集:RFC 3389(Real-time Transport Protocol(RTP)Payload for Comfort Noise(CN))に準拠

RTPを使用すると、任意のオーディオペイロード形式で不連続送信(無音圧縮)が可能になります。受信者は、RTPシーケンス番号が1つだけ増加した場合でも、RTPタイムスタンプが前のパケットでカバーされた間隔の終わりと隣接していないことを監視することにより、無音の後に受信した最初のパケットの無音抑制を検出できます。RTPマーカービットも通常、このようなパケットに設定されます。

于 2010-08-11T04:54:07.907 に答える
1

1)シーケンス番号がすぐに「ラップアラウンド」するとは思わない。これは 16 ビット値であるため、65536 メッセージごとにラップされ、メッセージが 10 ミリ秒ごとに送信されたとしても、10 分以上の転送が必要になります。パケットが長期間失われることはほとんどありません。したがって、私の意見では、シーケンス番号のみを確認する必要があります。タイムスタンプを確認しても意味がありません。

2) タイムスタンプについてはあまり気にする必要はないと思います。一部のプロトコルはこの値を埋めず、シーケンス番号のみを中継することを知っています。

于 2010-08-09T17:53:01.640 に答える
0

上記の彼の回答で Zulijn が得ているのは、パケットがキャプチャされた順序で保存されている場合、いくつかの単純なルールを使用して、順序が正しくないパケットを見つけることができるということです。たとえば、50 パケットを振り返って 50 パケットを転送します。そこにない場合は、失われたパケットとしてカウントされます。

これにより、シーケンス番号が循環する問題を回避できます。失われたパケットを処理するために使用できる多くの手法があるため、「オーディオ パケット損失」または「VOIP パケット損失の隠蔽」をググると便利です。Adam が述べているように、タイムスタンプはコーデックによって異なるため、使用する場合はこれを理解する必要があります。

実際のアプリケーションが何であるかについては言及していませんが、受信したオーディオが実際にどのように聞こえるかを理解しようとしている場合は、さらに情報、特にジッター バッファー サイズが必要です。パケットが失われたと判断する前に、順序が狂っています。これが意味することは、「現実世界」の受信機があきらめて再生しなかったシーケンス外のパケットがファイルにある可能性があるということです。つまり、ファイルからの再構築により、「実際の」時の体験。

双方向伝送の場合、遅延も非常に重要です (一定の遅延であり、ジッターやパケット損失に影響しない場合でも)。これは、一部の無線電話で使用されていたタイプの効果であり、一部の衛星電話 (または VoIP 電話) でまだ行われており、ユーザー エクスペリエンスに大きな影響を与える可能性があります。

最後に、さまざまなコーデックとクライアントがさまざまな手法を適用して、失われたパケットを修正し、オーディオのギャップ (会話の一時停止など) に「サイレント トーン」を挿入し、バックグラウンド ノイズを抑制します。

ユーザー エクスペリエンスの適切な感触をつかむには、同じコーデック、ジッター バッファー、およびレシーバーが使用したエラー修正/パケット損失技術を使用して、キャプチャしたパケットをできるだけ正確に「再生」する必要があります。

于 2010-08-11T11:39:30.110 に答える