1

オンラインで udp を介してライブ オーディオをストリーミングするアプリケーションを構築しており、レイテンシを最小限に抑えたいと考えています。オーディオは生成されたまま送信されます。つまり、1 秒間のオーディオを生成するのに 1 秒かかります。オーディオ レートよりも速く送信することはできません。

私の最初のアイデアは、圧縮されたオーディオの小さなパケットを送信して、クライアントができるだけ早く再生を開始できるようにすることでした。Opus コーデックを使用すると、5 ミリ秒 (最小値は 2.5 ミリ秒) のオーディオのパケットを送信できるはずです。これは、ユーザーがすぐに再生を開始できることを意味します。たとえば、2 つのパケットが配信された後です。

ただし、このような小さなパケット サイズを使用すると、帯域幅のオーバーヘッドが大きくなります。オーディオの各 5ms パケットが 35 バイトで、ip ヘッダーと udp ヘッダーが合計 28 バイトを構成するとします。これは大量の余分なデータです。

私の質問は、より大きなパケットサイズでライブオーディオを送信する方法はありますか? たとえば、アプリケーションがデータの生成中にデータ (部分的な udp パケット) の送信を開始することは可能ですか? それとも、パケットのペイロード全体が生成されるまで待機する必要がありますか? (バイト単位の長さは事前にわかっています)。

その場合、より大きなパケットを使用できますが、データのストリーミングをさらに早く開始できます。

それとも、ネットワークのジッタが大きすぎて、とにかく 5 ミリ秒をはるかに超えてバッファリングする必要があるのでしょうか?

4

2 に答える 2

1

5 ミリ秒以上バッファリングすることは間違いありません。5 ミリ秒は、再生サウンド カード自体の場合でも、非常に低いバッファーです。特別なドライバー (ASIO など) を備えたサウンド デバイスのみが、これほど低くすることができます。配信を制御して優先順位を付けることができる独自の LAN 経由でこれらのパケットを送信していますか? それが実際にパフォーマンスを保証する唯一の方法です。Ethersound など、このために特別に構築されたレイヤー 2 プロトコルがあります。それは、構築するものと要件によって異なります。

ネットワーク ソフトウェアの一般的なバッファ サイズは約 1400 ~ 1500 バイトです。これは、一般的なイーサネット ネットワークでパケットごとに送信できる最大値に近い値です。これは、アプリケーションに推奨するものです。

于 2013-02-05T04:52:26.020 に答える
0

最大 534 バイトを使用することをお勧めします。断片化を避けたい場合は、これが限界であり、そのためにデータが失われる可能性があります。

于 2013-02-05T06:23:36.587 に答える