クライアントには、ビデオが蓄積され、リアルタイムに遅れることがある場所があります。
- 入力ネットワークバッファ。
- 内部トランスポート同期バッファー。
- ネットワーク速度の変動を補正するためのプロトコルバッファ。
- プレイヤーバッファ;
- デコーダーのバッファー（ビデオカード）;
- ハードウェアの遅延。
そして、これらは再びバッファ、バッファ、そして再びバッファです。 順番に行きましょう。
（チューブバッファー）
入力ネットワークバッファー
クライアントは、ネットワークソケットを介してデータを受信します。 IPソケットには、ユーザープログラムデータの受信が十分に速くないときにいっぱいになる可能性のあるバッファーがあります。
バッファが小さすぎる場合、ビデオブロードキャストは絶えず中断され、大きすぎる場合、ユーザーはデータ転送速度によって決定される必要な時間より長くバッファがいっぱいになるのを待つ必要があります。 最悪の場合、バッファがメガバイト未満の場合、最大4〜8秒のビデオをロードできます。
バッファーがいっぱいの場合、早送りするか、データの一部を破棄することにより、リアルタイムを復元できます。 実際、プレーヤーの開発者は将来のリリースでこの機能を先送りするため、これはほとんど起こりません。
リアルタイムに近いという観点からすると、大きなネットワークバッファは悪です。 TVチャンネルをスムーズに再生するという観点から見ると、これは非常に合理的なことです。なぜなら、カーネルは高速で十分にバッファを満杯にできるためです。
Linuxが存在する場合はssユーティリティを実行できるため、クライアントのバッファーの状態を確認することは困難です。 しかし、AndroidやWindowsでこの情報を見つけることはさらに困難です。
内部デマルチプレクサ同期バッファ
さまざまなプロトコルで、彼らはオーディオとビデオに向けてさまざまな方法で引き離すことを好みます。 たとえば、MPEG-TSでは、トラフィックを減らすために、3〜5個のオーディオフレームを連続して取得し、1つのパケットに入れるのが一般的です。 同時に、「VAVAAVAVAA」からのフレームストリームは「VVAAAAAVVAAAAVAAAVVVAAA」に変わります。
タイムスタンプは同時に混合され、それらをさらにソートする必要がある場合（たとえば、RTMPへのアップロードにとって重要です）、フレームを遅くするバッファーを開始する必要があります。 このようなバッファの特に素晴らしい動作は、オーディオが完全に消えるとき、または5つのチャネルの1つで発生するときに発生します。
一般的なケースでは、総損失と非常に大きな遅延を区別することは事実上不可能です。 したがって、開発プロセスでは、そこで起こったことを「感じる」必要があるコードを記述する必要があります。
ネットワーク速度補償バッファー
ここでは、HLSにあるバッファー、またはRTMPプレーヤーで制御されたバッファーについて説明します。
たとえば、HLSプレーヤーは次のように配置されます。
- プレーヤーは3つのセグメントをダウンロードします。
- 3番目をダウンロードした後、プレーヤーは最初からストリームの再生を開始します。
- 1つのプロセスが最も古いセグメントを個別に取得し、他のプロセスが最初のセグメントをスワップします。
理想的な場合、2〜3個のセグメントがバッファでサポートされますが、ネットワーク速度が低下し始めると消える可能性があります。
ネットワーク速度の変動を補正するためのバッファーは、すべてのプレーヤーに組み込まれています。 たとえば、RTMPではこのバッファーは理論的に0であり、HLSでは理論的には10秒です。RTSPプレーヤーでは通常0であり、SIPでは正確に0です。
境界パラメータには何も機能しないため、「理論的に」と言います。 たとえば、1秒のフラグメントのHLSプレーヤーは、非常に不安定になり始める可能性があります。 そして、これは、ミリ秒ではなく、秒単位でセグメントの継続時間を計算するなどの一般的なエラーが原因である可能性があります。
また、ゼロバッファー上のRTMPフラッシュプレーヤーは、単純に「楽しく」動作します。1分間に1秒の遅延が累積し始め、数時間後にはひどく苦しみます。
プレイヤーバッファー
再生メカニズムは、ほとんどの場合、プロトコルを使用してビデオをダウンロードするメカニズムから分離されています。 フレームは展開され、メタデータから分離され、プレーヤーに転送されます。 その後、「奇妙な」開始：FlashとMSEプレーヤーは、再生を開始するために複数のフレームを必要とする場合があります。
これが発生した場合、あなたは再び遅れて遅延し始めます。 ここで、番号は2〜5フレームのオーダーです。 最大200ミリ秒。
デコーダーバッファー
優れたリアルタイムデコーダーは、受信したストリームをすぐにデコードし、配布します。 アクセスブロックは連続的にバッファに入り、バッファの充填率はエンコードされたストリームの速度に比例します。 エンコードされた画像のデータ量は異なるため、アクセスブロックは異なる時間にバッファにロードされます。 データは、再生されたイメージのフレームレートに等しい等間隔でバッファからダウンロードされ、完全に瞬時にアンロードされます。 たとえば、新しいストリームの開始遅延が古いストリームの終了遅延よりもはるかに大きい場合、古いストリームの最後の画像が再生されてバッファからアンロードされた後、新しいストリームの最初の画像をデコードして再生するのに時間がかかります。 これにより、たとえば、古いストリームの最後の画像がフリーズし、接着が目立つようになります。 新しいストリームの速度が古いストリームの速度よりもはるかに速い場合、バッファがいっぱいでデータの一部が失われるため、接着がさらに顕著になります。
リアルタイムストリームのエンコードにbフレームを含めた場合、それ自体が素晴らしい仕事ですが、すぐに出力でN * Tの量に遅延が生じます。ここで、
- N-最大フレーム置換距離、通常約4
- T-フレーム期間。 25 fpsの場合、これは40ミリ秒です。
したがって、青から、少なくとも160ミリ秒の遅延が発生します。
実際には、デコーダーはまだフレームを1つか2つ遅くするか、単にフレームの準備状況をタイムリーに通知するための適切なイベントAPIを持っていない場合があります。
ビデオ配信の最後のメーターのハードウェア遅延
巨大なデコードされたフレームを表示する必要があります。 ビデオカードではなくプロセッサでデコードした場合、表示のためにビデオメモリにコピーする必要があり、これには時間がかかります。 ビデオカードもミリ秒を追加できますが、通常、ここでのすべては、以前のケースの数千ミリ秒に比べてそれほど怖いものではありません。
合計
ビデオの配信と受信におけるあらゆる種類の遅延に対処したら、それを測定し始めることができます。 次の記事では、これを行う方法について説明します。