QTcpSocket高頻度書き込みで転送速度が遅くなります

Question

私はストリーミングアプリケーションで作業していますが、フレームを取得し、h264にエンコードし、クライアントにtcp経由で送信し、クライアントはエンコードされたフレームを受信し、それを表示します。私が見つけたのは、小さい時間間隔でwriteメソッドを何度か呼び出すと、転送速度にかなりの影響があるということです。

インターバル時間は、フレームを取得してエンコードするのにかかる時間である12ms〜17msです。クライアントでは、1つのフレームと別のフレームを読み込むのにかかる時間を数えています。 12/17 msを使用すると、クライアントに到達するまでの時間は〜400 msです。しかし、書き込みでスリープ状態を追加すると、12/17ms〜150msと言うことができます。クライアントの時間は〜150msに短縮されます。

私は1つのフレームを送信しようとしました。クライアントがそれを受信すると、確認応答を送信し、サーバは次のフレームを取得します。この方法を使用すると、レイテンシは同じ〜150ミリ秒でした。

データを特定のサイズのチャンク（現時点で512バイトを使用）に分割しています。クライアントはチャンクを受信し、sha256を使用してそれらを組み立てます。情報が正しく到着したことを確認し、 ）を1200バイトから65kbに設定します。だから私の結論は、転送レートが影響を受ける書き込みの多くをソケットにストレスを与える場合、これは正しいですか、私は何か間違っている可能性がありますか？

さらに、150msは6fpsと似ていますが、VNCやその他のストリーミングアプリケーションはどのように機能しますか？彼らはいくつかのフレームをバッファリングし、それらを再生する？したがって、レイテンシはありますが、「経験」はより高いフレームレートになりますか？

おかげ

Answer 1

TCP/IPプロトコルスタックは、帯域幅対遅延をトレードオフするために、その動作を最適化して自由です。あなたは帯域幅が不足していることを実証しておらず、到着するデータをあなたが望んでいる頻度より少なくすることができます。 はプロトコル自体にはありません。これは、データが特定のサイズのチャンクで受信側に到着することを保証します。

したがって、QIODeviceの1つのwriteで各フレームを送信するとします。受信側は、このデータを1つ以上のチャンクで受信することができ、任意の遅延後にこのデータを受信することができる。それはあなたが見ているものです。

送信するデータの種類はパフォーマンスに影響しません。送信者の場合は10行のテストケースを作成し、受信者の場合は同様のサイズのテストケースを作成できるはずです。あなたが望むデータは、あなたが間違って予想しているよりも大きな塊になるだけです。それは正常で、正常です。ストリーミングを維持するには、受信側で十分な量のデータをあらかじめバッファリングする必要があります。