その結果、問題は解決され、チェーン全体の遅延を500ミリ秒に減らすことができました。 私たちのソフトウェアの助けを借りて、別のクライアントがAndroidからコンピューター画面にビデオをブロードキャストする時間を1〜2秒に短縮したケースを思い出しました。
私たちが適用した手法のいくつかは、私たちだけでなく興味深いものになると考えました。
そのため、ビデオ配信チェーンは、撮影、圧縮、エンコーダからメディアサーバーへのローカルエリアネットワーク経由の送信、インターネット経由の送信、ユーザーのデバイスでのデコードと表示の6段階に概略的に分けることができます。
各段階で何がコストを決定し、どのように削減できるかを見てみましょう。
1.ビデオを撮影する
ここではすべてが簡単です-それはすべて、撮影で使用されるカメラに依存します。 ここでの遅延は1ミリ秒未満であるため、デバイスを選択するときに、コーデックとプロトコル、画質、価格などの消費者の品質に集中できます。
2.圧縮（エンコード）
ビデオ圧縮（エンコード）は、送信データのサイズを縮小するための元のビデオの処理です。 目標は、タスクに適したコーデックでストリームをシェイクすることです。 現在、事実上の標準は、H.264のビデオとAACのオーディオです。
このステップの作業は、将来的にチェーン全体に影響を与えます。
次のように、ハードウェアソリューションを優先することをお勧めします。 ソフトウェアは、リソースの操作に必要な時間とオペレーティングシステムのオーバーヘッドを追加します。 適切に構成されたエンコーダーは顕著な遅延を追加しませんが、結果のストリームのビットレートとそのタイプを設定します。 可変ビットレート（VBR）と定数（固定ビットレート、CBR）があります。
VBRの主な利点は、画質と占有データ量の最適な比率でストリームを生成することです。 ただし、より多くの計算能力が必要です。 さらに、特定の時点でのビットレートがチャネル容量を超える場合、これはデコード段階でのバッファリングをさらに伴います。 したがって、低遅延のリアルタイムビデオ送信にはCBRを使用することをお勧めします。
ただし、CBRもそれほど単純ではありません。 実際、一定のビットレートは常に一定ではありません。なぜなら、 H.264ストリームには、さまざまなサイズのフレームが含まれています。 したがって、エンコーダーでは、データの量がブロードキャスト全体で同じになるように、個々の時間間隔でビットレートを平均化する制御があります。 もちろん、この平均化は品質を損なうために行われます。 平均化期間が短いほど、デコード段階でのバッファが小さくなり、送信されるビデオの品質が低下します。
産業グレードのエンコーダーは、CBRが品質に与える影響を最小限に抑えるように設計されたさまざまなビットレートコントロールを提供します。 それらの説明は、この記事の範囲を超えています;レート制御粒度、コンテンツ適応レート制御などのパラメーターのみに言及できます。
3.エンコーダーからメディアサーバーへの送信
このステップの遅延は、ほとんどの場合、エンコーダとメディアサーバー間のネットワーク操作によって決定されます。 ここで、圧縮バッファの設定と使用されるメディアプロトコルのオーバーヘッドが役割を果たします。 したがって、エンコーダバッファには、最小フレーム数を指定し、メディアサーバーのできるだけ近くに配置する必要があります。
データ転送プロトコルは、エンドユーザーにデータを配信するエンコーダーとメディアサーバーの機能に基づいて選択する必要があります。 リアルタイムのビデオ伝送には、RTSP、RTMP、またはMPEG2-TSが最適です。
4.インターネットを介したユーザーのデバイスへの送信
最も興味深いステップであり、ほとんどの場合に最大の遅延をもたらします。 ただし、効率的なメディアサーバー、適切なプロトコル、および信頼性の高いインターネット接続を使用すると、遅延が最小限に抑えられます。
このチェーンの最初の要因は、あるプロトコルから別のプロトコルにストリームをトランスマックス（再パッキング）するときにメディアサーバー内でバッファリングすることです。
2番目の要因は、各プロトコルの詳細に関連しています。
HLSやMPEG-DASHなどのHTTPベースのプロトコルを使用する場合は、レイテンシが大幅に増加することに備えてください。 ここでのポイントは、これらのプロトコルの動作のまさに原理です-それらは、連続的に発行されるセグメントまたはチャンクへのコンテンツの分割に基づいています。 セグメントのサイズはプロトコルと伝送パラメーターに依存しますが、 2秒未満の間は推奨されません 。 Appleは、10秒以内にチャンクマーキングを行うことを推奨しています。 したがって、HLSを使用する場合は、サイズを小さくするか、時間の損失に耐えなければなりません。
HLSまたはDASHで配信を構築し、セグメントのサイズを最小限に抑え、他のすべての時間損失を最小限に抑えることができると想定できます。 ほとんどの場合、これは機能します。 ただし、リアルタイム送信（この例ではオークション）では、RTMPまたはRTSPプロトコルを使用する必要があります。
さらに、低遅延のライブブロードキャストプロトコルSLDPをリリースしました 。 Webソケットを使用するため、最新のブラウザーのほとんどで機能します。 さらに、モバイルプラットフォーム用のSDKがあります。
最後の要因にほとんど影響を与えることはできません。それは、ポンピングの速度とインターネットの直接通信チャネルの遅れに関連しています。 転送レートは、全体の遅延に追加する必要があります。 デコーダーは、バッファリングによって遅延を再生します。
（ケーブルマップの完全版はこちら ）
ソースメディアサーバーとビューアの間に、いわゆるエッジ、つまり多数の同時接続があるシステムの負荷を軽減するための中間キャッシングメディアサーバーを配置することを決定する可能性があります。 その場合、エッジに対しても適切な遅延をスローすることを忘れないでください。 もちろん、最大限の最適化のためには、遅延が重要ではない通常の視聴者にのみエッジを設定しますが、これも覚えておく必要があります。
5.デコード
この手順は、伝送速度に大きく影響します。 送信中にデータが不足する可能性をなくすために（前の手順を思い出してください）、再生バッファーには、ネットワーク遅延を考慮した1つの完全な平均期間のデータを含める必要があります。 そのため、バッファーには、エンコーダーのパラメーターとネットワークの状態に応じて、いくつかのGOP（GOP =ピクチャグループ）からいくつかのフレームまでを含めることができます。 多くのプレーヤーは、再生バッファーの最小値を1秒に設定し、作業中に変更します。 たとえば、Raspberry Piに基づくハードウェアデコーダー（プレーヤー）を使用する場合、最小限のバッファーが実現されます。
6.ディスプレイ
ここでは、最初のステップと同様に、遅延時間はごくわずかです-すべてが鉄の能力でカバーされています。
クライアントの例に戻ると、配信チェーンは次の部分から構築されました。 ビデオはカメラで撮影され、Beneston VMI-EN001-HDハードウェアエンコーダーに送信されました。 さらに彼から、RTMPストリームは、最大のパフォーマンスが得られるように構成されたNimble Streamerに送られました。 マカオでは、データはRTMP経由でも送信されました。RTMPでは、賭け室にデコードして大型モニターで表示するためのRaspberry Piがあります。 オーストラリアからマカオへのPingは140ミリ秒でした。 Raspberry Pi RTMPプレーヤーでは、バッファは300ミリ秒に設定されていました。 その結果、1080p30ストリームの信号遅延は500〜600ミリ秒の間で変化し、顧客の要件を完全にカバーしました。 世界中の普通の視聴者は、3〜4秒遅れて写真を見ます。特に、モバイルデバイスでHLSを通して見ることを好むためです。 この場合、この値も受け入れられます。
一般に、ライブ放送はあらゆる意味で簡単なことではありません。 高性能インジケータを達成することは重大な作業であり、信号の通過時間を短縮するには、適切なコンポーネントを選択し、その骨の折れるチューニングを行う必要があります。