SRT・RTMP・WebRTC・HLSの違い|配信プロトコルを遅延で選ぶ

同じ「ライブ配信」という言葉で、まったく違うものが呼ばれています。開演前に数十秒の遅れがあっても誰も困らない配信と、視聴者のコメントに司会が返す配信では、許される遅れの桁が違います。

そして遅れの許容量が変わると、選ぶプロトコルが変わります。ここを決めないまま構成を組むと、後から「もっと速くしたい」と言われて基盤ごと作り直すことになります。

SRT、RTMP、WebRTC、HLS。名前は並べて語られますが、この4つは同じ土俵にいません。まずそこから整理します。

4つは、受け持つ区間が違う

配信の経路は、大きく2つの区間に分かれます。カメラや副調整室から配信基盤へ映像を届ける区間と、配信基盤から視聴者へ配る区間です。

前者は送り手が両端を把握できます。回線もエンコーダも自分たちの管理下にあり、必要なら設定を詰められます。後者はそうはいきません。相手の回線も端末も分からないまま、同時に何万人へも届けないといけない。

SRTとRTMPは前者の区間、つまり伝送のためのものです。HLSは後者の視聴者配信のためのもの。WebRTCだけが両方にまたがります。

この区分を押さえておくと、「SRTとHLSはどちらがいいか」という問いが成立しないことが分かります。役割が違うので、たいていの構成では両方使います。

早見表

遅延の数字は構成で動きます。特にHLSは、セグメントの長さと再生側のバッファ設定で大きく変わります。低遅延化の拡張を使えば数秒台まで詰められますが、それでもWebRTCの水準には届きません。

表で目を引くのは、たぶん右端の列です。遅延が短い順に並べると、多人数配信の適性はきれいに逆順になります。偶然ではなく、速く届けるための工夫がそのまま複製のしにくさになっているからです。この対角線が、プロトコル選定の実態をほぼ言い切っています。

WebRTCが速いのは、待たない設計だから

WebRTCはブラウザ同士がプラグイン無しで音声や映像をやり取りするために作られた仕組みです。ビデオ会議の裏側で動いているものと同じで、W3CとIETFで標準化されています。呼び方としてはプロトコルというより、映像や音声を運ぶための規格をひとまとめにしたAPIに近い。ブラウザに実装が入っているので、視聴者側に何かを入れてもらう必要がありません。

出す側から見ると、この「入れてもらわなくていい」が効きます。専用のプレーヤーを配る、視聴用のアプリを審査に出す、といった工程が丸ごと消える。少人数の双方向配信で採用されるのは、遅延だけが理由ではありません。

速さの理由は単純で、届かなかったデータを待たないからです。TCPを使う配信は、順番どおりに全部揃うまで次へ進めません。1つの欠損が後続を止める構造になっています。WebRTCはUDPの上に載っていて、欠けたフレームは欠けたまま先へ進みます。音が一瞬ざらつくかわりに、会話が成立する。

そのかわり、配る側の負担が重くなります。HTTPで配るHLSは、途中のCDNがそのまま複製して届けてくれます。WebRTCは接続ごとに個別のセッションを張るため、視聴者が増えれば専用の配信サーバを何段も重ねる必要が出てきます。数百人までなら現実的でも、同時に数万人へ配るとなると設計もコストも変わります。

「速いほうが良いに決まっている」と考えたくなりますが、速さは規模と引き換えです。

伝送区間はSRTかRTMPか

現場から基盤へ映像を上げる区間では、長らくRTMPが使われてきました。対応機材が多く、主要な配信サービスの受け口もこれで揃っています。決め手は速度ではなく、どこでも受けてもらえることです。

SRTは、その区間を不安定な回線でも成立させるために設計されました。UDPで送りつつ、欠けたパケットだけを再送し、受信側でバッファを持って並べ直します。中継車から局へ、あるいは海外の拠点から国内の基盤へ、専用線を引かずに送る構成で選ばれます。暗号化が仕様に組み込まれている点も、素材を通す経路としては効きます。

RTMPとSRTの細かい違いはSRTプロトコルの解説で扱っているので、ここでは判断だけ書きます。回線が自分たちの管理下にあって安定しているならRTMPで足ります。回線が読めない、あるいは長距離を通すならSRTを検討する。それだけです。

クラウド側で受ける場合も、AWSのメディアサービスをはじめ主要な基盤はSRTの受け口を持つようになっています。選択肢としては、もう特殊なものではありません。

ひとつ補足しておくと、字幕ファイルの拡張子に使われるSRTとは無関係です。同じ略称が別のものを指しているだけで、現場でも混同が起きます。伝送の話をしているのか字幕の話をしているのか、会話の頭で確かめたほうが早いことがあります。

視聴者配信はHLSが基準線になる

視聴者へ配る区間では、HLSが事実上の基準です。理由は技術的な優位というより、届く先の広さにあります。ブラウザもスマートフォンもテレビも受けられて、CDNをそのまま使える。

HLSとMPEG-DASHの違いはありますが、どちらもセグメントに切って配る点は同じです。この「切って配る」構造が、そのまま遅延の下限を作っています。セグメントを作り終えてから配るので、セグメントの長さより速くはなりません。

低遅延の拡張はここに手を入れて、完成前の断片を先に配ります。そのぶん構成は複雑になり、CDN側の対応も要ります。QUICによる低遅延化も同じ方向の取り組みで、待ち時間をどこから削るかという問いへの別の答えです。

実際の構成は、組み合わせになる

だから設計は「どれを選ぶか」ではなく、区間ごとに何を使うかの割り当てになります。

会場から基盤まではSRT、基盤から一般の視聴者へはHLS、出演者どうしの掛け合いだけWebRTC。ひとつのイベントでも3つが同居します。局内がIPベースに移行している現場なら、さらに構内の伝送規格が加わります。

こう並べると分かるのは、遅延はどこか1か所で決まるものではないことです。伝送で0.5秒、基盤の処理で1秒、視聴側のバッファで3秒。合計が視聴者の体感になります。速いプロトコルを1か所に入れても、他が長ければ効きません。

決めるのは、どこで遅延を許容するか

すべての区間を最速にする構成は作れます。ただ、そのぶん配信サーバの台数も監視の手間も増えます。

現実的な設計は逆から始まります。この配信で遅れが致命的になるのはどこか。視聴者のコメントに反応するのか、それとも視聴体験が途切れないことのほうが大事か。そこを決めれば、どの区間に金と手間をかけるかが決まります。

秒単位の遅れが問題にならない配信で、WebRTCの多段構成を組む必要はありません。逆に、遅れが競技の結果を先に知らせてしまうような配信では、HLSのバッファは短くする以外にありません。

自分たちの配信で、視聴者は何秒遅れていることに気づくのでしょうか。その答えを持たないまま選ぶプロトコルは、たいてい多すぎるか足りないかのどちらかになります。

NAXAの取り組み

NAXAは放送局・制作会社向けのシステム開発を手がけており、伝送と配信の構成設計もその範囲に入ります。既存の設備と回線の条件を前提に、どの区間にどのプロトコルを割り当てるかから相談を受けています。