Silverlight の上にオーディオ ビデオ コラボレーション アプリケーションを実装し、それを調整しようとしています。私たちが経験している問題の 1 つは、パケットがドロップされるたびにストリーム レイテンシが増加することです。パケット損失が検出され、要求され、失われたパケットが再送信されるまで待機する必要があります。もちろん、これはオーディオ ストリームの一貫性に大きく影響します。(できれば UDP に切り替えたいと思いますが、Silverlight はそのブラウザー内でサポートしていません。また、Nagle アルゴリズムも無効にしているため、一般的に、送信する byte[] 配列を送信するとすぐに、それは送信され、単一のパケットで送信されます. TCP パケット サイズ != 送信されるデータの量であることは承知していますが、Nagle アルゴリズムを無効にすると、それに近い値になります. また、適応型ジッタ バッファがあるので、失われたパケットに対処しますが、TCP/IP 経由でパケットが失われると、バッファする必要があるオーディオの量が大幅に増加し、したがって遅延が増加します)。
そのため、パケットの送信方法を最適化して、ドロップされたパケットの影響を軽減する方法があるかどうかを確認しようとしています. 現在、実装を検討しているいくつかの競合するソリューションがあります。
(1) パケットを大きくしようとすることができます。現在、同じ TCP ストリームを介して、大きい (~1024 バイトのビデオ) パケットと小さい (~70 バイトのオーディオ) パケットを組み合わせて送信しています。しかし、オーディオ データとビデオ データを一緒に多重化することもできます。つまり、余裕があるときはいつでもビデオ データの一部をオーディオ パケットに添付することができます。これにより、個々のパケットがいくらか大きくなりますが、パケットの総数は削減されます。
(2) オーディオとビデオを 2 つの別個の TCP ストリームに分割できます。これは、パケットが失われたためにビデオ ストリームが停止した場合でも、オーディオ ストリームは停止しないことを意味し、その逆も同様です。もちろん、オーバーヘッドがわずかに増加し、送信されるパケットの総数が減少することはありません。
(3) 音声を複数の個別の TCP ストリームに逆多重化し、それらを相手側で再構成することができます。これにより、事実上、単一の UDP スタイルのパケット配信を「偽造」することができます。8 つのオーディオ ストリームがあり、そのうちの 1 つがパケット損失のために停止した場合、他のストリームは時間どおりにデータを配信でき、オーディオ パケットの 1/8 を処理するだけで済みます。停止したストリームが追いつくまで利用できません。もちろん、これは理想的ではありませんが、ストリーム全体が停止して、失われたパケットが再送信されるまでパケットを再生できないよりも、より良いエクスペリエンスが得られる可能性があります。
これらの可能性について何か考えはありますか？他の提案はありますか？それとも、3 つすべてをコーディングしてからテストする必要があるのでしょうか。