ライブ配信の遅延は、どこで何秒生まれているのか

イベントの配信でいちばん多い相談は、突き詰めるとほぼ一つです。

「壇上で問いかけてから、視聴者の反応が返ってくるまでが遅すぎる」

汎用の配信プラットフォームを使うと、演者が話してから視聴者の画面に映るまでに数十秒かかることがあります。質問への回答が届く頃には、会場の話題はとっくに次へ進んでいます。挙手や投票のような「同時であること」が前提の演出は、そもそも成立しません。

では、その数十秒はどこで生まれているのか。カメラのレンズから視聴者の画面までを段階ごとに分解すると、削れる場所と削れない場所がはっきり分かれます。

遅延は7つの区間に分けられる

映像が視聴者に届くまでの経路は、おおまかに次の7区間です。

区間	何をしているか	目安
1. キャプチャ	カメラの撮像・映像処理、キャプチャデバイスでの取り込み	数ms〜数十ms
2. エンコード	H.264などへの圧縮	数十ms〜数百ms
3. アップリンク	会場から配信サーバへの送出	数十ms〜数百ms
4. サーバ処理	受信・トランスコード・画質別ストリームの生成	数百ms〜数秒
5. パッケージング	配信形式へのセグメント分割	0秒〜十数秒
6. CDN配信	エッジサーバから視聴者への配送	数十ms〜数百ms
7. プレイヤーバッファ	再生前に手元へ貯める時間	0.2秒〜十数秒

数値の幅を見ると分かるとおり、1〜4と6は合計してもせいぜい1〜2秒です。ミリ秒単位の世界であり、ここをいくら詰めても「数十秒の遅延」は説明できません。

犯人は5と7、つまり配信形式そのものの作りにあります。

数十秒の正体は「セグメント × バッファ本数」

HLSやMPEG-DASHといった一般的な配信方式は、映像を一定の長さのファイルに切り分けて配ります。この切れ端をセグメントと呼びます。

ここで2つのことが同時に起きます。

ひとつ目は、セグメントは完成するまで配れないということ。セグメント長が6秒なら、6秒ぶんの映像が録り終わるまでそのファイルは存在しません。この時点で最大6秒の遅れが確定します。

ふたつ目は、プレイヤーが再生を始める前に、通常は複数のセグメントを手元に貯めるということ。回線が一瞬詰まっても再生が止まらないようにするための保険です。3本貯める設定なら、それだけで18秒ぶんの映像を抱えてから再生が始まります。

つまり、

セグメント長 6秒 × バッファ 3本 = 18秒

これが「なぜか30秒近く遅れる」の主成分です。エンコーダの設定を詰めても、回線を太くしても、ここは1ミリも縮みません。設計としてそうなっているからです。

WebRTCが1秒を切れる理由

一方でWebRTCは、そもそもセグメントに切りません。

映像を細かいパケットに分けて、できた端から送ります。ファイルとして完成するのを待つ工程が存在しないため、5の区間がまるごと消えます。プレイヤー側も、届いた順序の乱れを吸収するための最小限のバッファ（ジッタバッファ）しか持ちません。7の区間も数百ミリ秒まで縮みます。

結果として、キャプチャから表示までを1秒以内に収められます。テレビ会議で自然に会話できるのは、この仕組みだからです。

ただし、速さには対価があります。

	HLS系	WebRTC
遅延	2〜30秒	1秒以内
大規模配信のコスト	視聴者が増えるほど1人あたりは安くなる	視聴者数にほぼ比例して増える
途中参加	巻き戻して冒頭から視聴できる	参加した時点から
回線が細い視聴者への強さ	バッファが厚く、耐性が高い	バッファが薄いぶん影響が出やすい

WebRTCは「速い代わりに、バッファという保険を捨てている」方式です。だから回線品質の影響を受けやすく、視聴者数が増えたときのコスト構造もHLS系とは異なります。速ければ常に良い、という話ではありません。

どこを削るべきか、の判断

遅延を縮めたいとき、手を付ける順番は明確です。いちばん大きい区間から削る。

たとえば「エンコーダのプリセットを最速にしたのに変わらない」というのは、200ミリ秒の区間を50ミリ秒に削ったところで、18秒の区間が残っているからです。効くのは配信方式の選択であり、それ以外の調整は誤差に近い。

そして、そのうえで問うべきは「何秒必要か」ではなく、「そのイベントで同時性が要るか」です。

• 演者と視聴者がその場でやり取りする（質疑応答、挙手、投票、じゃんけん）→ 1秒以内が要る
• 一方向に届ける（説明会の中継、講演のライブ配信）→ 数秒の遅延は誰も困らない

同時性が要らない配信に超低遅延を持ち込むと、コストと回線耐性を無駄に犠牲にすることになります。逆に、対話が成立することを期待している場に数十秒の遅延を持ち込むと、イベントそのものが破綻します。

まとめ

• 遅延の大半は、キャプチャやエンコードではなく配信形式のセグメント長とプレイヤーバッファで決まる
• 「6秒 × 3本 = 18秒」のような構造的な遅延は、機材や回線をいくら強化しても縮まらない
• WebRTCはセグメント化を行わないため1秒以内を実現できるが、大規模配信のコストと回線耐性がトレードオフになる
• 同時性が要るイベントかどうかで方式を選ぶ。要らない配信に超低遅延は不要

この選択には、もう一段掘り下げる価値があります。WebRTC / HLS / SRT / RTMP をそれぞれどの場面で選ぶのかは、別の記事で整理します。