皆さん、こんにちは。Stop Refactoring チャンネルへようこそ。
この号では、 HTTP-FLV、HLS、RTMP、Web-RTC、RTSP など、ライブ ブロードキャストに関連するプロトコルについて詳しく説明します。
これらのプロトコルの仕組み、適用シナリオ、遅延の理由について詳しく紹介します。
この順序で説明します
1、RTMP、HTTP-FLV
2、HLS
3、Web-RTC
4、RTSP
RTMP、HTTP-FLVプロトコル
RTMP と HTTP-FLV はどちらも FLV カプセル化に基づいています。
RTMPは通常、ライブストリーミングに使用され、HTTP-FLVは通常、ライブ表示に使用されます。
まず RTMP について説明します。RTMPプロトコルは、ストリームのプッシュとプルの両方ができるプロトコルです。
RTMP アドレスは rtmp:// で始まり、ストリーミング アドレスは再生アドレスと同じです。
ただし、ブラウザーが Flash プレーヤーを放棄しており、高同時実行下では不安定な問題が発生する可能性があると言われているため、 RTMP は通常、ライブ ソースからのストリーミングやライブ CDN へのストリーミングなどのシナリオでのみ使用されます。
RTMP プロトコルには、 SRS、RTMP プラグインを備えた Nginx などの特定のストリーミング サービス ソフトウェアが必要です。
過去のライブ ブロードキャストの動作原理で説明したように、この種のストリーミング メディア サービス ソフトウェアは、実際にはオーディオおよびビデオ データの転送ステーションであり、通常、データはメモリ内で周期的に上書きされるだけで、ディスクには書き込まれません。 。
RTMP プロトコルの遅延は比較的短く、約 1 ～ 3 秒です。
RTMP 通信は、TCP ロング接続チャネル上で確立され、オーディオおよびビデオ データをカプセル化するときに、スライスによって各データ パケットのサイズが強制的に制限されます。
必須のスライスにより、リアルタイムのパフォーマンスもある程度保証されます。各データ パケットが大きすぎないため、データ パケットの検証に失敗した場合の再送信のコストがそれほど大きくないため、脆弱なネットワークに耐える一定の能力があります。また、データ パケットのマージによって CPU 負荷が増加するため、したがって、一定のパフォーマンスの消費が発生します。
RTMP プロトコルには、RTMPT、RTMPS などのいくつかのバリエーションもありますが、ここでは説明しません。
HTTP-FLV プロトコルについてもう一度説明しましょう。
アドレスは http:// で始まり、HTTP プロトコルに基づいており、HTTP-FLV は単純に RTMP の HTTP プロトコル バージョンとして理解できます。機能や動作原理は同様で、前述のRTMPスライスデータ機能HTTP-FLVも利用可能です。
ただし、HTTP-FLV プロトコルは通常、ストリーミング表示にのみ使用できます。
HTTP-FLV プロトコルの遅延も比較的低く、約 1 ～ 3 秒ですが、実際の経験では、HTTP-FLV の遅延は RTMP の遅延よりわずかに高いことが示されていますが、HTTP-FLV は RTMP よりもシナリオの再生に適しています。 RTMP。
HTTP-FLV ライブ ストリームは通常、プラグインを追加して再生する必要があります。たとえば、ブラウザで再生できるようにするには、Web ページで flv.js をインポートする必要があります。HTTP-FLV ライブ ストリーミング。ここでは、ブラウザーでの HTTP-FLV の普及を促進するステーション B のオープンソース flv.js に感謝する必要があります。
HTTP-FLV プロトコルには、 HTTP-FLV プラグインを備えた Nginx などの特定のストリーミング サービス ソフトウェアが必要です。
Nginx の HTTP-FLV プラグインには RTMP 機能が含まれているため、一般的な HTTP-FLV ストリーミング メディア サービスでは、プッシュ ストリームは RTMP プロトコルを使用し、プル ストリームは HTTP-FLV プロトコルを使用します。
現在、より一般的なソリューションは、ライブ ブロードキャスト ソースが RTMP プロトコルを使用してストリームをプッシュし、ライブ ストリーミング ストリーミング ウォッチが HTTP-FLV プロトコルを使用するというものです。
HLSプロトコル
HLS プロトコルは一般にストリーミング視聴のみに使用されますが、厳密に言えば、HLS プロトコルはストリーミング プロトコルではありません。
HTTP プロトコル経由で静的ファイルをダウンロードするだけで機能します。
違いは、HLS プロトコルのファイルが 2 つの部分で構成されていることです。1 つは数秒の長さしかない複数の.ts 断片化されたビデオ ファイルであり、もう 1 つはこれらのビデオ ファイルのアドレスを記録する.m3u8 インデックス ファイルです。これらの静的ファイルはディスクに直接書き込まれます。
具体的には、HLS 表示アドレスは http:// で始まり .m3u8 で終わります。実際、このアドレスはインデックス ファイルのアドレスです。クライアントはインデックス ファイルを取得した後、対応する断片化されたビデオ ファイルをダウンロードして開始できます。それを再生しています。
HLS プロトコルは実際には HTTP プロトコルを通じてファイルを要求し、HLS 関連のファイルはディスクに直接書き込まれるため、特別なストリーミング サービス ソフトウェアは必要なく Nginx などの HTTP サービスで十分です。
HLS プロトコルは、オンデマンドおよびライブ表示に使用できます。さまざまな再生シナリオに適応します。通常、プラグインを追加することで再生できます。たとえば、Web ページは HLS js を追加することで再生できますプラグイン。Apple デバイスは、HLS プロトコルをネイティブにサポートします。
オンデマンド シナリオ、つまり通常のオンライン ビデオ視聴のシナリオ。
.m3u8 インデックス ファイルには、断片化されたすべてのビデオ ファイルのアドレスが記録されます。HLS には、オンデマンドシナリオでの明らかな利点があります。
HLS の関連ファイルはステートレスな静的ファイルであり、各ファイルのサイズが制限されているため、負荷分散と CDN 高速化の効果がより顕著になります。
HLS プロトコルのオンデマンド ビデオは、.mp4 および .flv ビデオよりも速く再生され、読み込み中のビデオ ジャンプがよりスムーズになります。
ライブ ブロードキャスト シナリオでは、トランスコーディング ソフトウェアは HLS 関連ファイルをディスクに直接生成でき、クライアントは HTTP サービスを通じてファイルをダウンロードできます。
さらに、RTMP プラグインを Nginx に追加することもでき、トランスコーディング ソフトウェアが RTMP プロトコルを通じてストリームを Nginx にプッシュし、Nginx が HLS 関連ファイルを生成します。
このうち、後者のソリューションは、初期段階の研究開発とドッキング後のライブ CDN の移行がよりスムーズであるため、より推奨されます。
さらに、ライブ ブロードキャスト シーンの HLS 関連ファイルは、オンデマンドのファイルとは多少異なります。
ビデオ ストリーム データは、数秒ごとに .ts というサフィックスが付いた断片化されたビデオ ファイルにパッケージ化され、.m3u8インデックス ファイルは、新しいビデオ ファイルが生成されるたびに同期して更新されます。
また、断片化されたビデオ ファイルの数には上限があり、上限に達すると、デフォルトで最も古いビデオ ファイルが削除され、.m3u8 インデックス ファイルが更新されます。
したがって、ライブ ブロードキャスト シナリオでは、クライアントは .m3u8 インデックス ファイルを定期的に再取得する必要もあります。
HLS プロトコルには、ライブ ブロードキャストのシナリオでは利点がありません。
HLS プロトコルのライブ ストリームも多くの再生シナリオに適応できますが、静的ファイルを生成する必要があるため、ライブ ブロードキャストの遅延は非常に大きくなり、約 5 ～ 30 秒になります。ライブ CDN を使用する場合は、エッジ ノードが原因で、同期やその他の問題により、ライブブロードキャストの遅延が 1 分程度発生する可能性があります。
もちろん、HLS プロトコルには利点もあります。ライブ ブロードキャストのタイム シフト (ライブ ブロードキャストからオンデマンドへのブロードキャスト)、または録画ブロードキャスト (オンデマンドからライブ ブロードキャストへのブロードキャスト) では、理論的にはインデックス ファイルを変更するだけで済みます。
さらに、HLS プロトコルの .m3u8 インデックス ファイルは、セカンダリインデックス作成。つまり、高解像度、標準解像度、スムーズなどの複数の表示アドレスを 1 つのインデックス ファイルに統合できます。プレーヤーは、現在の帯域幅に応じて異なる表示アドレスを自動的に切り替えることができ、ほとんどの Web プレーヤーの「自動」もこれによるものです。
ここでは、HLS プロトコルに関する小さな知識ポイントを示します。
HLS プロトコルのビデオ ファイルとインデックス ファイルはディスクに直接書き込まれるため、複数のライブ ストリームを同時に長時間処理すると、ディスクに過剰な書き込み圧力が発生し、機械ディスクが損傷する可能性があります。そしてソリッドステートドライブの寿命は劣化を加速します。
この場合、過剰なディスク書き込み圧力が発生しないように、メモリ空間のセクションを HLS 関連ファイルの書き込み場所としてマウントすることが最善です。
補足しますと、HLS プロトコルは Apple が導入した規格です。HLS プロトコルと同様に、MPEG-DASH プロトコルもあります。HLS と MPEG-DASH の動作原理は似ていますが、一部の規格が異なるため、私が勝ちましたここを拡張しないでください。
WebRTCプロトコル
WebRTC プロトコルは、実際にはライブ ブロードキャスト シナリオ向けに設計されたものではなく、ポイントツーポイントのビデオ/音声通話プロトコルです。
WebRTC は UDP をベースとしているため、通信確立後はストリームでデータが送信され続けるため、RTMP よりも遅延が少なくなります。
グッズなどを使ったライブブロードキャストなど、インタラクティブ性の高い一部のライブブロードキャストシナリオでは、ストリーミングおよび視聴プロトコルとして WebRTC が使用されますが、WebRTC の遅延は理論上 1 秒以内に達します。
WebRTC プロトコルはプッシュ ストリームとプル ストリームをサポートしており、アドレスは通常 webrtc:// で始まり、プッシュ ストリーム アドレスとプル ストリーム アドレスは通常同じです。
WebRTC はポイントツーポイントのプロトコルですが、ライブブロードキャストのシーンに適用する場合、ストリーミングサービスとして WebRTC サーバーを構築する必要があり、ストリーミングサービスソフトウェアは SRS を使用できます。
ちなみに、SRSは中国で開発された比較的ポピュラーなオープンソースのストリーミングメディアサービスソフトウェアで、現在4.0にはRTMP、HLS、WebRTC、HTTP-FLVといった主流のプロトコルが含まれている。
RTSPプロトコル
RTSP は通常、ライブ ブロードキャスト シナリオには使用されません。RTSP は通常、カメラや監視などのハードウェア デバイスのリアルタイム ビデオ ストリームの表示とプッシュに使用されます。
RTSP プロトコルはプッシュ/プル ストリームもサポートし、TCP、UDP スイッチング、その他多くの利点をサポートします。
しかし、汎用性が不十分であり、特に現在のブラウザは RTSP 再生をサポートしていません。
要約する
上記は一般的に使用されるライブ ブロードキャスト プロトコルの紹介です。ここで述べた遅延は純粋な通信遅延です。ライブ ブロードキャスト プロセス全体を見たい場合、遅延はさらに増幅されます。
ライブ ブロードキャストの遅延には、プッシュ遅延、トランスコーディング遅延、プル遅延が含まれるため、プッシュおよびプル プロトコルとして WebRTC が使用されている場合でも、最終的な遅延は数秒になります。
生放送の遅延の問題に関しては、上記の合意が重要な役割を果たしていますが、絶対的な役割を果たしていないことがよくあります。
生放送の遅延を減らすには多くの問題が伴います。たとえば、B フレームの禁止、GPU ハードウェア アクセラレーション、ストリーミング メディア サービスでの I フレームのキャッシュ、ビット レート制限などの詳細な問題については、後で詳しく説明します。