🕓 🌝 🏡 Webcam Live Delay、Heartless You Bitch 🚵🏽 👲🏼 🙆🏻

この記事では、ブラウザからウェブカメラからオンラインブロードキャストを実行するときに発生する遅延について説明します。それが発生する理由、それを回避する方法、オンラインブロードキャストをリアルタイムで真にライブにする方法。

次に、 WebRTCの実装例を使用して遅延が発生することと、 WebRTCを使用する場合に、快適な通信に適した低レベルで遅延を維持する方法を示します。

遅延

すでに1〜3秒で通信にわずかな不快感が生じます。ラグはすでにはっきりと見えており、それに適応する必要があります。遅れがあることを知って、あなたはトランシーバーのように話し、それが向こう側に到達して答えが来るまで待ちます。このような遅延は、シーンからビデオリンクにアクセスする2人のジャーナリストを称えて、Roman-Tatyanaと呼ぶことができます。

-ローマ、聞こえますか？ 小説？

-3秒が経過しました

「完璧に聞こえます。」 タチアナ？

-3秒かかりました...

「ローマ、ここにFDIがあります...何が起こっているのです。」 小説？

一般的な遅延神話

以下は、Webでのビデオ伝送の遅延と品質に関する3つの一般的な誤解です。

100 mbpsあります

1. 100メガビットを持っていますが、問題はないはずです。

実際、プロバイダーが広告ブックレットでどれだけメガビットを使用したかは問題ではありません。デバイスとリモートサーバーまたはデバイスとの間の実際の帯域幅は、トラフィックが通過するすべてのノードを含めて重要です。プロバイダーは、インターネット上の任意のノードに対して100 Mbpsを物理的に編成できません。 1 Mbpsの速度でさえ保証されません。対談者が物理的にブラジルの遠隔地にあり、モスクワのデータセンターから放送しているとします。申し立てられたチャンネルがどれほど太くて高速であっても、最終目的地と同じではありません。

したがって、このような不快な事実が発生します-実際、あなたはあなたとあなたの対話者との間のチャネルの実際の帯域幅がわからない、そしてあなたのプロバイダーでさえそれを知りません。情報を交換します。

帯域幅に加えて、パケット到着の規則性（ ジッターなし ）も重要です。トレントから動画を高速でダウンロードしたり、 Speedtestサービスで良い結果を確認したりできますが、リアルタイムで最小限の遅延で再生する場合は、すべてのパッケージを時間通りに取得することが重要です。

パケットをデコードして画面に表示する必要がある正確なタイミングで到着した場合（ミリ秒あたり1ミリ秒）が理想的です。しかし、ネットワークは完全ではなく、 ジッターがあります。パケットが不規則に到着する-遅れているか、パックで届くため、スムーズな再生のために動的なバッファリングが必要です。大量にダンプすると、品質が低下します。大量にバッファリングすると、遅延が増加します。

したがって、誰かが（リアルタイムのビデオ伝送のコンテキストで）良好で高速なネットワークを持っていると言う場合、それを信じないでください。ホストはいつでも制限を適用でき、キュー内のビデオパケットのドロップまたは遅延を開始できますが、何も実行できません。パッケージパス内のすべてのノードにメッセージを送信して、 「おい、パケットをドロップしないでください。 最小限の遅延が必要です。」より正確には、これは特別な方法でパッケージにマークを付けることで実行できます。しかし、このパケットが通過するネットワークノードがそれを使用することは事実ではありません。

LANがあります

2.ローカルネットワークで遅延が発生しないようにする必要があります。

ローカルネットワークでは、トラフィックが通過するノードが少なくて済むため、実際には遅延が発生する可能性は低くなります。少なくとも3つのノード（送信側デバイス、ルーター、およびビデオ受信側デバイス）です。

これら3つのデバイスには、独自のオペレーティングシステム、バッファ、ネットワークスタックがあります。たとえば、送信者のデバイスが急流を積極的に配信するとどうなりますか？または、サーバーまたはCPUのネットワークスタックに他のタスクが読み込まれている場合、またはオフィスワイヤレスネットワークと複数の従業員が同時に720p解像度でYouTubeを視聴している場合はどうでしょうか。

かなり厚い（高ビットレートの）ビデオストリーム、約10 Mbpsでは、ルーターまたは他のノードがパケットの一部をドロップまたは遅延させる可能性が非常に高くなります。

したがって、ローカルネットワークの遅延も発生する可能性が高く、ビデオストリームのビットレートと、データ処理のためのこのネットワークのノードの機能に依存します。

ここでは、平均的なローカルネットワークでのこのような問題は、グローバルなネットワークでの問題よりもはるかに少なく、ほとんどの場合、ネットワークの輻輳またはハードウェア/ソフトウェアの問題が原因であることに注意してください。

その結果、 ローカルネットワークを含むネットワークは理想的ではなく、ビデオパケットが遅延してドロップされる可能性があり 、一般的な場合、ドロップされたパケットの強度と数に直接影響を与えることはできないと主張します。

UDPがあります

3.私はUDPを使用していますが、UDPプロトコルを使用する場合、遅延はありません。

UDPを介して送信されたパケットは、同じ方法でネットワークノードで遅延または損失する可能性があります。これらのパケットがビデオのアセンブリおよびデコードに十分でない場合、アプリケーションによって再度要求される可能性があり、再生が遅延します。

プロトコル

宇宙船がサーフィンしている間、私たちは2つのWeb転送プロトコル（ブラウザが動作するプロトコル）しか持っていないことを認識しています： TCPとUDP 。

TCPは保証された配信プロトコルです。これは、ネットワークへのパケットの送信が不可逆的な操作であることを意味します。ネットワークにデータを送信した場合、データは宛先に到達するか、タイムアウトによってTCP接続が切断されるまでそこを移動します。これが、TCPプロトコルを使用する際の遅延の主な理由です。

実際、パケットが遅延またはドロップされた場合、リモートパーティがパケットの到着の確認を送信し、この確認が送信者に届かないまで、パケットは何度も送信されます。

TCPプロトコルに基づいて、ライブビデオをWebに転送するために使用される次の高レベルのプロトコル/テクノロジーが使用されます。

RTSP（インターリーブモード）
RTMP
HTTP（HLS）
TLS上のWebRTC
ダッシュ

これらのプロトコルはすべて、ネットワークの問題に対する高遅延を保証します。これらの問題は、送信側または受信側ではなく、中間ノードのいずれかにある可能性があることに注意することが重要です。したがって、このような遅延の原因を特定しようとすると、多くの場合、ビデオストリームの送信者のネットワークと受信側のネットワークをチェックすることは役に立ちません。それらを使用すると、すべてが正常であると同時に、中間の何かによって5秒以上の遅延が発生します。

上記の声明を考慮してください： ネットワークは完全ではなく、ビデオパケットが遅延してドロップされる可能性があります。保証された最小遅延を得るには、TCPベースのプロトコルの使用を完全に放棄する必要があると結論付けています。

TCPを拒否することは必ずしも簡単ではありません。なぜなら、場合によっては、代替手段がありません。たとえば、企業ファイアウォールで443（https）を除くすべてのポートが閉じている場合、ビデオを転送する唯一の方法は、それをhttpsにトンネルし、TCPに基づいてHTTPSプロトコルを介してビデオパケットの転送を編成することです。この場合、予測できない遅延に我慢する必要がありますが、ビデオはとにかく配信されます。

UDPは、非保証パケット配信を使用するプロトコルです。つまり、ネットワークにパケットを送信すると、パケットが失われたり遅延したりする可能性がありますが、その後、他のパケットを送信したり、受信者に送信して受信したりすることはできません。

このアプローチの利点は、TCPの場合のように、プロトコルレベルで受信者からの保証された確認を待機して、パケットが繰り返し送信されないという事実です。受取人は、すべての荷物が正しい順序で収集されたときに待つか、何を処理するかを決定します。 TCPでは、受信者にはそのような自由はありません。

UDPでビデオを送信するためのWebプロトコルは多くありません。

UDP上のWebRTC
RTMFP

ここでWebRTCとは、この技術STUD、ICE、DTLS、SRTPのUDPベースのプロトコルスタック全体を意味し、UDP上で動作し、最終的にSRTP経由でビデオ配信を提供します。

したがって、UDPを使用すると、部分的な損失を伴うパケットを迅速に配信できます。たとえば、送信されたパケットの5％を長時間失うか、遅延させます。利点は、アプリケーションレベルで、時間どおりに受信したパケットの95％がビデオを正しく表示するのに十分であるかどうかを判断でき、必要に応じてアプリケーションレベルで失われたパケットを再度要求し、必要な回数だけ要求できることです）必要なビデオ品質を達成するb）遅延を許容可能な低いレベルに維持する。

その結果、UDPプロトコルはパケットを送信する必要性を軽減しませんが、パケットの損失と遅延に依存するビデオ品質のバランスを取りながら、より柔軟に送信を実装できます。 TCPでこれを行うことはできません。保証されたデザイン配信がそこに縫い付けられています。

輻輳制御

これに先立ち、ネットワークは完全ではなく、ビデオパケットが遅延してドロップされる可能性があり、これに影響を与えることはできないというステートメントを作成しました。

プロトコルのレビューでは、右側に満足のいく笑顔は得られませんでしたが、 低レイテンシではUDPプロトコルを使用してパケット送信を実装し、ビデオ品質のバランスを取る必要があるという結論に達しました。

実際、ネットワーク上でパケットがドロップまたは遅延した場合、おそらく単位時間あたりの送信量が多すぎます。また、パケットに高い優先順位を与えるコマンドを与えることができない場合、これらの中間ノードに送信するトラフィックを減らすことで、これらの中間ノードの負荷を減らすことができます。

したがって、 低遅延ストリーミングの抽象的なアプリケーションには、2つの主な目標があります。

500ミリ秒未満の遅延
特定の遅延に対して可能な限り最高の品質

そして、これらの目標は次の方法で達成されます。

目標
500ミリ秒未満の遅延	可能な限り最高の品質
UDPを使用するネットワーク問題の動的検出動的CPU負荷検出動的ビットレート削減ダイナミックFPSドロップ動的解像度の削減	部分的なパッケージ発送動的ビットレート増加ダイナミックFPSブースト動的解像度の増加

左側の列には、待ち時間を短縮する方法がリストされ、右側の列には、ビデオの品質を改善できるものがリストされています。

したがって、低レイテンシが必要であり、品質が静的で一定ではなく、適切なタイミングでパケット送信を要求し、現在のネットワークの状態に応じてビットレートを低下または増加させる、ネットワークの変化に柔軟に対応する必要があるビデオストリーム。

よくある質問の1つは、「500ミリ秒の遅延で720pライブビデオをストリーミングできますか」です。一般的な場合、この質問は意味がありません。 2 Mbpsのビットレートと0.5 Mbpsのビットレートでの解像度は1280x720pです。これらは完全に異なる2つの画像です。どちらも解像度が720pで、一方は鮮明で、他方はマクロブロックで非常に希釈されます。

正しい質問は、「500ミリ秒未満の遅延と2 Mbpsのビットレートで高品質720pビデオをストリーミングできますか」です。あなたとあなたがこれを行うことができる宛先との間に実際の2 Mbps帯域（プロバイダーが示す帯域ではない）がある場合、答えはイエスです。そのような保証された帯域がない場合、指定された遅延に収まるように、既存の帯域に対する2番目の調整ごとに、ビットレートと画質が変動します。

ご覧のとおり、笑顔は微笑んでいますが、「私は幸せですか？」という質問を自問自答しています。実際、浮動ビットレート、帯域幅の解像度の適応、およびパケットの部分送信は、ほぼゼロの遅延と任意のネットワークで真のフルHD品質を同時に達成できない妥協点です。しかし、このアプローチにより、あらゆる瞬間において品質を最大に近づけ、遅延を制御し、低レベルに保つことができます。

WebRTC

多くの場合、湿気と冗長性のためにWebRTCテクノロジーがoldられています。ただし、実装機能をさらに深く掘り下げると、この技術は非常に適切であり、その仕事はうまくいくことがわかります。低遅延を維持しながら、リアルタイムのオーディオおよびビデオ配信を提供します。

ネットワークの不均一性のため、低遅延を維持するために、ビットレート、FPS、解像度などのフローパラメータを絶えず調整する必要があることを上記で書きました。このすべての作業は、通常のChromeブラウザーのchrome：// webrtc-internalsタブにはっきりと表示されます。

それはすべてウェブカメラで始まります。カメラが良好で、安定して30 FPSのビデオを生成するとします。同時に、これは実際のビデオストリームで起こり得ることです。

グラフからわかるように、カメラが30 FPSを生成するという事実にもかかわらず、およそ25-31 FPSの範囲で送信し、極小値で送信すると実際のフレームレートが21-22 FPSに達することがあります。

FPSと同時に、ビットレートが低下します。実際、エンコードされるビデオが少ないほど、ネットワークに送信されるフレーム/パケットが少なくなり、ビデオストリームの全体的な速度が低下します。

ヘルパーメトリックには、RTT、NACK、およびPLIが含まれます。これらは、ブラウザーの動作（WebRTC）と、結果のビットレートおよびストリーム品質に影響します。

RTTは往復時間であり、受信者への「ping」を意味します。

NACKは、ストリームの受信者がこのストリームの送信者に送信するパケット損失メッセージです。

PLIは、失われたキーフレームに関するメッセージと、それを送信する要求です。

失われたパケット、送信、RTTの数に基づいて、各瞬間のネットワークの品質について結論を導き出し、ビデオストリームのパワーを動的に調整して、特定の各ネットワークの容量の制限を超えず、チャネルを詰まらせないようにすることができます。 WebRTCでは、これはすでに実装され、機能しています。

720p WebRTCビデオストリームのテスト

まず、1280x720（720p）の解像度でWebRTCビデオストリームの変換をテストし、遅延を測定します。 WebRTCメディアサーバーWeb Call Server 5を介してブロードキャストをテストします。テストサーバーは、フランクフルトデータセンターのDigitaloceanサイトにあります。サーバーへのPingは90ミリ秒です。インターネットサービスプロバイダーの速度は50 Mbpsです。

テストパラメータ：

サーバー	Web Call Server 5、DO、フランクフルトDC、ping 90ms、2コア、2Gb RAM
ストリーム解像度	1280x720
システム	Windows 8.1、Chrome 58
テスト	1つのブラウザーウィンドウでサーバーにビデオを送信し、別のブラウザーウィンドウで受信するエコーテスト

テストのために、このリンクにある標準の例media_devices.htmlを使用しました。例のソースコードはこちらです。

ストリーム解像度を720pに設定するには、カメラを選択し、サイズ設定で1280x720を設定します。また、トランスコーディングを使用しないように、再生/ビデオ/品質は0に設定されます。

したがって、ビデオストリームをリモート720pサーバーに送信し、右側のウィンドウで再生します。このページには、PUBLISHINGの確認ステータスが表示されます。

次に、仮想カメラからのミリ秒でタイマーを開始し、実際の遅延を測定するためにいくつかのスクリーンショットを撮ります。

画面1

画面2

画面3

画面4

画面5

画面6

画面7

画面8

画面9

画面10

テスト結果と遅延

その結果、ミリ秒単位の測定結果を含む次の表が得られます。

	キャプチャー	表示された	待ち時間
1	09599	09277	322
2	13376	12992	384
3	16256	15866	390
4	19198	18751	447
5	22394	22022	372
6	25661	25211	450
7	32511	32126	385
8	36166	35839	327
9	40318	39935	383
10	45310	44987	323

分のテストで、720pストリームの遅延のグラフを取得します。

720pの変換テストでは、300〜450ミリ秒の視覚的遅延でかなり良い結果が示されました。

WebRTCビットレートチャート

WebRTCレベルのビデオストリームで、この瞬間に何が起こるか見てみましょう。これを行うには、タイマーの代わりに、高解像度で漫画を実行して、WebRTCが高ビットレートを管理する方法を確認します。

以下は、このWebRTCブロードキャストのグラフです

グラフは、ストリームのビットレートが1〜2 Mbpsの範囲で動的に変化することを示しています。これは、サーバーがチャネル不足を自動的に検出し、Chromeにビットレートを時々下げるように要求するためです。ビットレートバーは動的に変化し、グラフ上でgoogAvailableSendBandwidthによって赤で示されます。緑は、実際に送信されたビットレートgoogTransmitBitrateを示します。

これが、サーバー側での輻輳制御の仕組みです。ネットワークの混雑とパケット損失を回避するために、サーバーは常にビットレートを調整し、ブラウザーはサーバーのコマンドに従ってビットレートを調整します。

同時に、すべてが幅と高さのグラフで安定しています。送信幅は1280、高さは720pです。つまり送信される解像度は変更されず、ビデオエンコードのビットレートを下げることで、解像度を変更せずにビットレートが制御されます。

CPU輻輳制御

解像度が変わらないようにするために、テスト中にGoogle ChromeブラウザーのCPUディテクター （googCpuOveruseDetection）の使用を無効にしました。

CPUディテクターはCPU負荷を監視し、しきい値に達すると、Chromeブラウザーによる解像度のリセットにつながるイベントをトリガーします。この機能を無効にすることで、プロセッサのオーバーランを許可し、解像度を修正しました。

mediaConnectionConstraints: {"mandatory": {googCpuOveruseDetection: false}}

CPUディテクターを使用すると、グラフィックはより滑らかに見えますが、ビデオストリームの解像度は絶えず上下に切り替わります。

適応をテストするために、より弱い車を選択します。これは、コアi5 1.7 GhzとChrome 58を搭載した2011 Mac Miniになります。テストと同じ漫画を使用します。

ストリーミングの最初に、ビデオ解像度が540x480に低下したことに注意してください。

その結果、次のグラフが作成されます。

グラフでは、画像の幅と高さがどのように変化するか、つまりビデオ解像度：

そして、これらのグラフでは、幅と高さが減少および増加した変化を背景に、それが示されています。

googAdaptationChangesパラメーターは、Chromeがストリーミングプロセス中にトリガーしたイベント（適応）の数を示します。より多くの適応が行われると、ビデオストリーミング中にビデオ解像度とビットレートが頻繁に変化します。

ビットレートに関しては、サーバーが上のバーを過小評価していないという事実にもかかわらず、スケジュールはより鋸歯状であることが判明しました。

ビットレートのこのような積極的な変更は、次の2つのことに関連しています。

Google Chromeブラウザ側でgoogAdaptationChanges適応を有効にします。これは、CPU負荷の増加が原因です。
VP8とは異なる方法でエンコードし、シーンの内容に応じてエンコードビットレートを大幅にリセットできるH.264コーデックを使用します。

おわりに

その結果、次のことを行いました。

リモートサーバーを介したWebRTC変換の遅延を測定し、その平均値を決定しました。
CPU適応が無効になっている場合、VP8コーデックの720pビデオストリームビットレートがどのように動作し、ビットレートがネットワーク条件にどのように適応するかを示しました。
サーバーによって動的に設定されるビットレートバーを見ました。
CPUとH.264コーデックに適応した、それほど強力でないクライアントマシンでWebRTC変換をテストし、ビデオストリームのアクセス許可の動的な調整を見ました。
彼らは、解像度の変更と適応の数に影響するCPUメトリックを示しました。

したがって、記事の冒頭で暗示されたいくつかの質問に答えることができます。

質問：最小限の遅延でWebRTCブロードキャストを行うには何をする必要がありますか？

回答：ただ放送してください。ストリームの解像度とビットレートは、最小遅延を提供する値に自動的に調整されます。たとえば、1280x720を設定すると、ビットレートは1 Mbpsに低下し、解像度は950x540になります。

質問：720pの安定した解像度で最小遅延でWebRTCブロードキャストを行うには、何をする必要がありますか？

回答：このためには、ユーザーチャンネルは実際に少なくとも1 Mbpsを提供する必要があり、CPU適応は無効にする必要があります。この場合、解像度は低下せず、ビットレートが原因でのみチューニングが行われます。

質問：200 kbps帯域の720pビデオストリームはどうなりますか？

回答：マクロブロックと低い（約10）FPSによってぼやけた画像があります。同時に、遅延は低くなりますが、ビデオの品質は視覚的に非常に悪くなります。

参照資料

メディアデバイスは、レイテンシをテストするために使用されたWebRTC変換のテスト例です。

ソース -サンプルのテスト翻訳のソースコード。

Web Call Server -WebRTCサーバー

chrome：// webrtc-internals-WebRTCチャート

Webcam Live Delay、Heartless You Bitch

遅延