ああ、遅れている

彼らはしばしばこのような問題を抱えて私たちのところに来ますが、すぐに明確にしなければなりません。これらは通常男性であり、私たちはビデオ配信に携わっています。



私たちは何について話しているのですか？ カメラの前で何かが起こってから視聴者に届くまでの遅延を減らすことです。 量子物理学の講義の放送がコメディクラブよりも長く続くことは明らかですが、技術的な詳細はまだ行っています。



遅延（レイテンシー、遅延とも呼ばれます）の議論に進む前に、非常に重要な質問に答える必要があります。なぜそれらを減らすべきなのでしょうか？ 私はほとんど常に遅延を減らしたいが、 それは必ずしも必要ではない。



したがって、たとえば、激しい政治的トークショーを伴うライブブロードキャストは、ディスカッションの急激な進展に迅速に対応できるように、ライブブロードキャストを3分間停止する必要がありますが、ドローンのウェビナーまたはリモートコントロールは、人々がお互いを簡単に中断できるように最小限の遅延を必要とします、および負荷はターゲットで正確に低下しました。



先に進む前に、重要な事実を修正しましょう：ビデオとオーディオのブロードキャストの遅延を減らすことは高価であり、非線形に高価なので、ある時点で必要な遅延で停止する必要がありますが、このために戻って理解する必要があります：なぜそれが必要なのか削減する。



このような紹介は単なるものではありません。 お客様にアンケートを実施した結果、対立する要望がありました。TVチャンネルを放送する人は、低遅延のストリーミングを望んでいます。 なぜ-誰も説明しなかった、私はちょうどしたい。

遅延形成

ビデオ送信の遅延がどのように形成されるかを見てみましょう。 ビデオ信号配信スキーム（ビデオパススキーム）の例は次のとおりです。

1. ビデオメモリ内の画像はカメラセンサーから取得されます
2. ビデオエンコーダーは生の画像をコーディングバッファーに入れます
3. ビデオ圧縮アルゴリズムは、バッファ内の複数のビデオフレームを圧縮する最適な方法を見つけます。
4. 圧縮されたビデオフレームはサーバーのビデオ配信バッファー（存在する場合）に送信されます
5. ビデオフレームはUDPを介して送信されるか、送信のためにTCPカーネルバッファーにコピーされます。
6. バイトがクライアントに到達し、ネットワークデータを受信するためにカーネルバッファーに追加されます
7. クライアントに届く
8. フレームソートバッファにスタックされている可能性があります
9. そこから、必要に応じて、ネットワーク速度の変動が補正バッファーに追加されます
10. それからデコーダに送信され、デコーダはbフレームのバッファを蓄積します
11. デコーダーはフレームをデコードし、描画するために送信します

これはおおよそのスキームであり、場合によっては一部の詳細が破棄されたり、バッファが追加されたりします。 しかし、一般的に、バッファ、バッファ、バッファバッファ、バッファバッファが再び表示されます。



なんで？ はい。バッファリングはコストを削減し、全体的なスループットを向上させる一般的な方法だからです。 もう1つ重要な点があります。バッファは変動を滑らかにするのに役立ちます。 ネットワーク上の伝送速度は変動します。問題ではありません。開始時により多くのバイト/フレームをアップロードし、インターネットが回復している間に、バッファーにあるものを再生します。



すなわち かなり単純化された論文に注意してください。 データのバッチ処理による最適化 と、ビデオパスの特性の変動を補正するために、バッファが必要です。



起こっていることと視聴者が見ることとの間の遅延を減らすために、各段階で体系的に作業する必要があります。

詳細

センサーの取り外し

些細なことのように思えますが、古き良きアナログテレビでは、撮影が完了する前にテレビでラインを再生し始めることができます（ところで、ここで私は誇張していますが、それが実際にどのようになっているかを知るのは興味深いでしょう）。



しかし、見てみると、今日のセンサーは最小2メガピクセル、またはそれ以上であることを理解できます。 Intel Xeonはまったく接続されていませんでしたが、データをコピーするだけで時間を浪費する最小限の対処力の鉄です。



私の知る限り、現在、ピクセルストリーミングモードで生のビデオを操作できるようにする広範なビデオ伝送技術はありません。 すなわち フレーム全体がセンサーから取り外されるまで、何もできません。



ここで遅延の正確な推定値を提供する準備ができていません。

コーディングバッファ

エンコーダは非常にリソースを消費するタスクに従事しており、メモリとプロセッサの間のデータバスをひどくロードします。 彼は、ビデオ圧縮オプションのさまざまな組み合わせをソートし、隣接するフレーム間の違いを見つけ、複雑な数学的計算を行う必要があります。 毎秒25フレームのFullHDビデオは毎秒約ギガビット（100メガバイト）であるため、負荷は膨大です。 ただし、古典的な間違いをしないでください。また、プロセッサの負荷と遅延を混同しないでください。 フレームの圧縮にかかる時間はまだ1 / fps未満です（そうしないと、けいれんできず、とにかく成功しません）、エンコーダーははるかに長い遅延を作成します。



実際には、エンコーダーは、可能な限り最高の品質で可能な限り低いビットレートを生成するために、バッファーにいくつかの連続した生フレームを蓄積します。 ここでバッファが作成されるタスクは次のとおりです。

• ストリームのビットレートの中央値を維持します。 1つのフレームで品質を本当に向上させたい場合は、残りのフレームで、くすくしようとする必要があります。
• 参照できる最適なフレームの選択。 前のフレームではなく、次のフレームを参照する価値がある場合があります。 したがって、フレームの順列と最大15〜20％のトラフィックの節約があります。

この遅延で遊ぶことができますが、まず第一にビットレートの増加につながります。 このサイトには、低遅延コーディングに関するlibx264の作者からの良い投稿があります。 これだ。



合計で、ここでは1-2フレーム（それぞれ40ミリ秒）を管理できます。または、最大3-5秒を費やすことができますが、ビットレートを節約できます。



覚えておいて、私はあなたが低遅延のために支払う必要があると最初に言った？ これで、ビットレートで支払いを開始できます。

サーバー上のバッファ

おそらく、私たちにとって最もよくある質問は、遅延についてです。「サーバーのバッファを削除する必要があるHLSを介してブロードキャストする場合、非常に大きな遅延があります」。



実際、サーバーバッファリングは非常に可能です。たとえば、mpegtsをパックするとき、オーディオフレームの送信を待って、1つのPESパケットに複数のフレームを入れたいと思っています。 または、HLSやDASHなどのプロトコルをパックする場合、通常は数秒待つ必要があります。



ここで重要な点：たとえば、mpegsは複数のオーディオフレームを1つのPESフレームにパックすることを好みます。 理論的には、PESパケットを開き、そこにあるものの書き込みを開始してネットワークに送信し、ビデオフレームを送信してから、別のビデオフレームを続行できます。 しかし、通常の問題があります。PESオーディオフレームでは長さが長くなるため、オーディオを蓄積する必要があります。 蓄積することは、バッファを意味し、遅延の増加を意味します。



一部のサーバーは、CPU使用率を削減するためにRTMPなどのフレームごとのプロトコルを使用している場合でも、100キロバイトを1回送信すると50倍のコストよりも安くなるため、フレームをバッファリングします。



すなわち それはすべてプロトコルに依存します。HLSまたはDASHサーバーがある場合、少なくとも1セグメント（1〜10秒）のバッファリングは避けられません。 フレームごとのプロトコルが不要な場合、フレームを一度にすべてのクライアントに安全に送信できますが、これを行うことはほとんどありません。



たとえば、RTP（RTSP / RTPカメラから）などのどこかから取得した場合、理論的には、RTPパケットを受信するとすぐにクライアントに配信できます。 これにより、1フレーム未満の遅延が発生しなくなります。 実際には、このアプローチはプログラミングの巨大な複雑さを作成し、ソフトウェアの使用のばらつきを劇的に減らすため、めったに実装されません。 ほとんどの場合、ビデオストリーミングサーバーは、コンテナとプロトコルがクリアされたフレームで動作します。



ここに小さな詳細があります： CMAF低レイテンシイニシアチブがあります。 アイデアの本質は、参照フレーム（キーフレームとも呼ばれる）が到着すると、サーバーがすべてのクライアントに新しいセグメントを通知することです。 すべてのクライアントが緊急にダウンロードを開始します。ここでは、HTTPプログレッシブダウンロードによってフレームごとに取得します。



したがって、中間CDNでのキャッシュを使用したファイルの転送、およびバッファリングなしでこれを配布する方法を知っているサーバーに接続したときに遅延なくフレームを受信する機能がわかります。



これはまだ開発のイニシアチブですが、興味深いことがあります。



合計：HLSを使用しない場合、サーバー上のフレームバッファーを基本的に拒否できますが、HLSを使用している場合でも、特別な条件下では何かを考えることができます。

ネットワーク送信バッファ

私たちはパルプ自体に行きました、つまずきのブロックとビデオ配信の無限のスロー：UDPまたはTCP？ 損失または予測不可能な遅延？ それとも組み合わせる？



理論的には、 失敗したルーターがない理想的な世界では、UDPはping速度で通過するか失われ、TCPは送信を遅くする可能性があります。



TCPを介してビデオの送信を開始するとすぐに、ストリームをフレームに分割することを可能にするプロトコルの選択だけでなく、カーネル内の出力バッファーのサイズについても疑問が生じます。 核バッファーが大きいほど、ソフトウェアの配布が容易になり、コンテキストの切り替えが少なくなります。 遅延の成長のために再び。



核バッファを増やすと、ダウンロード速度の制御がすぐに失われます。フレームの送信を制御することが難しくなり、サーバー上で不明瞭になります。クライアントがビデオをダウンロードしているかどうかです。



ヘルメットがUDP上にある場合、パケット損失をどうするかを決める必要があります。 UDPパケット（TCPの一種）を再転送するオプションがありますが、クライアントでのバッファリングが必要です（以下を参照）。 ネットワーク上にRAID-5のようなものを整理するオプションがあります。冗長性は各udpパケットに配置され、たとえば5から1つのパケットを復元できます（FEC、ファウンテンコードなどを参照）。 これには、このような冗長性を計算するためにサーバーのレイテンシーを増やす必要があり、ビットレートも10〜30％増加します。 冗長性はクライアントに追加のバッファーを必要としない、または少なくとも1〜2フレームであるが5秒（125フレーム）ではない、と考えられています。



より洗練されたオプションがあります：H264 SVCでビデオをエンコードします。 最悪のフレーム品質を復元するために1つのパケットにデータを入れ、品質を改善するために次のフレームにデータを入れます。 次に、これらのパッケージには異なるレベルの値が付けられ、途中でスマートで親切なルーターが確実に最も不要なフレームを推測して捨て始め、徐々に品質が低下します。



現実の世界に戻りましょう。



FECには、Googleからの 良い約束と現実の 両方があります。「XOR FECは機能しません 。 」 非常に長い間、明確で理解できない。 一方、FECは衛星配信で長い間使用されてきましたが、他のエラー制御はありません。



SVCを使用すると、離陸しないことを除いて、すべて問題ありません。 JPEG2000またはウェーブレットを思い出させる：誰もが良いが、世界を征服するために何かが欠けています。 実際、サーバーとクライアントが制御されているビデオ会議のクローズド実装で使用されていますが、すぐにこのメカニズムを使用することはできません。



R-UDPは実際には複雑で、TCPに置き換わり、めったに使用されず、30秒の遅延を持つHLSが適している場合に十分に適用できます。 TCPの実現に関与する危険性がありますが、これは実質的に不溶性のタスクと考えることができます。



UDPを使用したこのようなアプローチは、確認のために転送速度を落とさないため、巨大なRTTと損失のあるチャネルを介した転送に適していると考えられています。 重要な点は、ビデオストリーミングの場合、送信者を遅くする必要がないということです。トラフィックは必要な速度で正確に配信されます。 速度が低下し始めた場合、まったく送信できませんが、より低い品質を選択します。 一方、TCPは非常に一般的な配信プロトコルであり、ライブブロードキャストには不適切な仮定があります。

• データをすべて転送するか、接続を切断する必要があります。 ライブブロードキャストの場合、これはそうではありません。送信できなかったものを安全に捨てることができます。
• データの送信を遅くすることができますが、その後、送信が加速されます。 また、これはライブブロードキャストには関係ありません。チャネルの合計の厚さが送信に十分であるかどうかのどちらかです。 高速または低速のビデオストリームは流れません（トランスコーダを再構成しなければ）

この結果、パケットはすぐに送信されますが、長距離で大きなpingを実行するとTCPの速度が低下し始める可能性があります。 UDPはリアルタイムの速度でパケットを転送します。高速ではありませんが、遅くはなく、配信確認は必要ありません。

顧客への配送

サーバーからクライアントへの配信の遅延の増加は、パケット送信自体の遅延と損失の割合で構成されます。 損失が大きいと、TCPの場合のデータ転送により配信が禁止されます。 UDPの場合、リカバリメカニズムが頻繁にオンになるか、ビデオがより頻繁に散らばります。



いずれにせよ、ビデオをモスクワからタイに直接送信せず、シンガポールのアマゾンクラウドを介して送信しますが（個人的な経験）、強制的なルートの選択ですが、奇跡はありません。近いと言わない。



この部分は、10ミリ秒で収まり、300ミリ秒伸びることができます（このようなRTTでは、通常、適切な速度を達成することは困難です）。



まれに、CDNがそのような問題を解決しますが、実際にはそれを期待するべきではなく、確かに何かを約束する準備ができているマーケティング担当者を信頼するべきではありません。



面白いのは、主な問題がWi-Fiルーターからラップトップへの最後のメーターで発生する可能性があることです。 ラップトップにケーブルを差し込むだけで、インターネットがどれほど高速になるのかと疑問に思うこともあります。



継続する。 次の出版物では、クライアントで何が起こっているかを検討します。