tencent cloud

ライブイベントブロードキャストは、超低遅延の再生シナリオでの標準ライブブロードキャストの拡張です。従来のライブブロードキャストプロトコルよりもディレーが低く、視聴者にミリ秒レベルの最高ライブブロードキャスト視聴体験を提供します。この製品は、eコマースのライブブロードキャストとeラーニングに加えて、スポーツイベントのライブブロードキャストやゲームのライブブロードキャストなど、リアルタイムのインタラクションを統合できるさまざまなライブブロードキャストシナリオも含む、より高いディレーパフォーマンスを必要とする特定のシナリオのニーズを満たすことができます。

プロトコルの比較

現時点では、標準ライブブロードキャストは通常、RTMP、FLV、HLSといった形式の再生プロトコルを使用します。また、これらの再生プロトコルには、いずれもTCPプロトコルに基づいているという共通点があります。TCPには、遅延確認とピギーバック応答があります。例えば、データが送られてくると直ちにそれぞれのデータに対してACKで応答するのではなく、データがある程度溜まってから応答するため、遅延が検知されます。脆弱なネットワーク環境では、TCPなどのメカニズムによってデータが滞留し、データの伝送中に閉塞が起こり、数秒から数十秒の遅延が発生することがあります。

ある調査によると、業界での低遅延ライブブロードキャストのプロトコルには、QUIC、SRT、WebRTCおよびORTCがあることが判明しました。比較すると、QUICにはストリーミングメディア機能がないため、遅延は比較的大きく、SRT、WebRTCおよびORTCにはストリーミングメディア機能があるため、遅延はすべてミリ秒レベルです。このうちSRTとORTCの使用量が少なく、WebRTCエコシステムがよく使われているため、ライブイベントブロードキャストではWebRTCを使用して超低遅延を実現し、WebRTCの基盤にはUDPプロトコルを使用しています。

遅延の比較

現在、標準ライブブロードキャストのFLVプロトコルの遅延は通常約2秒～10秒であり、その遅延要因は主に、GOPサイズとTCPの脆弱なネットワーク伝送による滞留です。HLSの遅延は更に大きく、通常数秒～数十秒で、その遅延要因は主に、GOPサイズとTSサイズです。HLSはファイル形式でインデックスおよびダウンロードされるため、1ファイルあたりのサイズによって遅延が制限され、多くのプレーヤーは再生するために3つのTSを待たなければなりません。3つのTSは数十秒かかる場合があるため、HLSは標準ライブブロードキャストの中でも最も遅延が大きくなります。

ライブイベントブロードキャストでWebRTCを使用して低遅延改良を行う場合に考慮すべき重要な事項です。ChromeやSafariなど人気のあるブラウザのほとんどは、WebRTC標準をサポートしています。また、成熟したオープンソースのWebRTC SDKでは、最適化とカスタマイズを簡単に行えます。これにより、ブラウザを通じて標準のWebRTCライブブロードキャスト機能を提供することに加えて、カスタマイズされたSDKを通じてアップグレードされパーフェクトな低遅延ライブブロードキャスト機能（ライブイベントブロードキャストの遅延は通常、300ms～1000ms）を提供することもできます。

ライブイベントブロードキャストの優位性

• グローバルな配信と広範なカバレッジを持つライブイベントブロードキャストのスーパーアクセラレーションノード（2100以上のノードをサポート、25か国をサポート）。

• 超広帯域幅の容量（100T以上の帯域幅をサポート）。

• 高品質、低コスト、パーフェクトな機能（30%のパケットロス防止）。

• 簡単にアクセス（SDKを再生するだけで改良が完了、パーフェクトな機能、スムーズな互換性）。

• インスタントブロードキャスティング、超低遅延、以下のテスト結果図から、現在のライブイベントブロードキャストで実現可能な遅延は通常約300ミリ秒であり、限界は43ミリ秒であることがわかります。