2017-02-12 11 views
0

私はRAW H264ビデオフレームを受け取り、このプロトコルを使用してサーバー側からクライアント側に瞬時に送信する単純なUDPストリーミングプロトコルを持っています。ネットワークRTTレイテンシ(パケットの再送はしません。私は20msのレイテンシをサーバからクライアントに持っていれば、ビデオフレームをエンコーダの出力からクライアント側(デコードできる状態)に準備することができます。WebRTC最も低いatency

私の質問は次のとおりです。 - WebRTC(over UDP)がこの種の待ち時間になる可能性がありますか?エンコーディングとデコードの時間を考慮しないで、プロトコル層のためにWebRTCで取得できる最小レイテンシはどれくらいですか?

私はこの種の待ち時間が私の独自のプロトコルをより深く開発する必要があるかどうかはわかりません。私はビデオサーバ開発のためにWebRTCのような一般的なものに行くかもしれません。

よろしく、

答えて

0

WebRTCは、通常のSIP/RTPスタックと同じ低レイテンシを持つことができます。 WebRTCスタックベンダーは遅延を減らすために最善を尽くしています。

録音用と発送用に遅延がありません。スタックは、レコーダ装置から受信したパケットをすぐに送信し、選択したコーデックで圧縮します。一部のコーデック(および一部のコーデック設定)では、FECなどの一部の機能を有効にするためにここでいくつかの遅延が導入される場合があります。

受信側に関して: 最適な状況では、スタックはパケットの再生を遅らせるべきではないので、到着するとすぐに表示することができます。 しかし、最適ではない状況(ネットワーク遅延やパケット損失)でスタックにはjitter bufferが導入されます。ネットワーク品質が低いほど、ジッタバッファ長が長くなります。

ので、最低の遅延を達成するために、あなたは以下のことを行う必要があります:

  • は、FECを削除し、追加の遅延を引き起こす可能性のある他の設定を無効にする最小の処理時間とのコーデックを選択
  • ジッタバッファを削除する(ほとんどのWebRTCスタックにはこの設定がないため、コードを自分で変更する必要があるかもしれませんが、コードの一部を非アクティブにするだけで簡単に変更できます)
+0

ありがとう、このジッタバッファコードがどこにあるかわかりませんか? – user1428926

+0

これは、オーディオ再生モジュールと緊密に結合する必要があります。通常、ネットワークジッタバッファとオーディオバッファを混在させることができます(オーディオドライバにもプリバッファリングが必要なため) – Istvan

0

のWebRTCは普通UDPに比べペイロードの先頭にのみ小さな追加ヘッダを有する基礎となるメディアトランスポートとしてRTP使用。つまり、これは普通のUDPで達成したものと同じレベルでなければなりません。 RTPはリアルタイムオーディオやビデオ(SIP、H.323、XMPPのメディアトランスポート)などのレイテンシクリティカルな環境で頻繁に使用されるため、この目的のために十分なレイテンシを期待できます。

+0

しかし、この小さな追加ヘッダーはレイテンシとは何の関係もないかもしれませんが、私は最小遅延を引き起こす可能性のあるバッファがあれば... 500msと言いましょう。送信する。 – user1428926

+0

@ user1428926:まさに私が言っていることです。レイテンシーには影響しません。 *これは、あなたが普通のUDPで達成したものと同等でなければならないことを意味します。* –

関連する問題