動画ストリーミングの仕組み — 少しずつ届く動画をどう再生する？

ひよこ

長い動画なのに、すぐ見始められるのはなぜ？

ペンギン先生

届いた部分から再生し、次の部分を先に受け取っておくからだよ。HLSなどでは動画を短い片に分け、その一覧を使って順に取得する。全部受け取ってから再生する以外の方法があるんだ。

ひよこ

ストリーミングなら、ダウンロードしていないの？

ペンギン先生

再生に必要なデータは受信しているよ。全部を保存して後で見ることと、受信しながら見ることを分けよう。1つの動画ファイルを受け取りながら再生するプログレッシブダウンロードもあり、すべてが同じ片分け方式ではないんだ。

ひよこ

読み込み中で止まるのは、次が来ないから？

ペンギン先生

再生用にためたバッファーが足りない場合はそうだね。通信、サーバー、端末の処理なども影響する。たくさんためると途切れにくくなる一方、ライブでは見る時刻が遅れることもあるよ。

ひよこ

m3u8というファイルは動画なの？

ペンギン先生

HLSのプレイリストで、テキストの一覧だよ。動画片の場所や長さを示す一覧と、複数の画質などから選ぶための一覧がある。下の例では3つの片をどの順に読むか見てみよう。

ひよこ

通信が遅くなると、画質を落とすの？

ペンギン先生

プレーヤーは通信状況やバッファー、端末の条件等を見て、用意された別のビットレートの流れへ切り替えることがあるよ。ABRと呼ぶ。画質、解像度、ビットレートは関係するけれど、同じ意味ではないんだ。

ひよこ

CDNは、一番近いサーバーから必ず届く？

ペンギン先生

配信を分散して負担や距離の影響を減らす助けになるよ。でも地図上で最寄りの場所になる保証ではなく、経路やキャッシュ、サービスの仕組みで違う。エンコードする役割とも分けよう。

ひよこ

ライブなら、本当に同じ瞬間を見られる？

ペンギン先生

撮影、エンコード、転送、バッファーなどで遅れが出るよ。低遅延HLSやWebRTCなどは目的に合わせて選ぶ方式で、いつでも何秒という保証ではない。遅れと途切れにくさの両方を考えるんだ。

ひよこ

新しい圧縮形式を使えば、全部解決する？

ペンギン先生

同じ見た目の品質に必要なデータ量を減らせる場合はあるけれど、機器の対応や計算の負担も見るよ。コーデック、動画を入れる形式、配信の方式は別の役割。まず片の一覧と再生待ちを分けられれば十分だよ。

まずは、動画片の「目次」を読む

動画を少しずつ受け取りながら見る仕組みを、HLSのプレイリストで見てみましょう。次は理解用の短い例です。動画そのものではなく、再生する片の場所と長さを並べたテキストです。

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXTINF:4.0,
part0.ts
#EXTINF:4.0,
part1.ts
#EXTINF:2.0,
part2.ts
#EXT-X-ENDLIST

part0.tsを4秒、part1.tsを4秒、part2.tsを2秒、順に再生する一覧です。合計は10秒です。EXT-X-ENDLISTは、これ以上の片が追加されないことを示します。この一覧だけでは再生できず、実際の動画片と対応した配信環境が必要です。

ここでは4秒を例にしていますが、片の長さが常に4秒という決まりではありません。EXT-X-TARGETDURATIONは片の長さを扱う上限の指定で、RFCでは各EXTINFを整数に丸めた値がこれを超えない条件があります。

再生中にも、次の片を受け取る

プレーヤーは届いた片を再生しながら、次のデータを先に受け取ってバッファーへためます。受信が再生に追いつかずバッファーが足りなくなると、待ち時間が出ることがあります。

長くためればいつでも良いわけではありません。とくにライブでは、ためる量を増やすと実際の出来事から遅れて見ることにつながります。図の片やためる数は理解用の例です。

画質を変える一覧は、別にある

上の例は1つの流れのメディアプレイリストです。別のビットレートや音声などを選ぶための一覧は、複数の流れを案内するプレイリストです。プレーヤーは用意された候補と通信状況、バッファー、端末等を考えて選びます。

• ビットレート：一定時間のデータ量に関わります。
• 解像度：画像の縦横の画素数です。
• 見た目の品質：元映像やコーデック、設定なども影響します。同じ解像度でも同じ品質とは限りません。

もう少し詳しく：ライブ・CDN・形式の役割

ライブのプレイリストは新しい片の追加に合わせて更新されます。録画配信のVODと、古い片を残すイベント配信、見られる範囲が進むライブ配信は、一覧の扱いが違います。

CDNは配信の分散やキャッシュを担当し、コーデックは映像・音声を符号化します。MPEG-TSやfMP4などの形式はデータの入れ物、HLSなどは配信の扱いです。CMAFを使うことだけで低遅延が保証されるわけではありません。

低遅延HLSは片の一部を扱う仕組み等も使います。WebRTC等との選択では、やり取りの目的、規模、遅延、実装条件を見ます。「HLSは必ず30秒」「WebRTCは必ず1秒未満」といった固定値で決めないようにしましょう。

🐧 ペンギン先生のまとめ：「ストリーミング」って出てきたら「届くデータをためながら、順に再生していく仕組み」と思えばだいたいOK！

配信経路はCDNの仕組み、通信の始まりはTCPハンドシェイクで続けて見られます。

参考資料

• RFC 8216：HTTP Live Streaming — プレイリスト・片・長さ・終了タグと配信条件
• Apple：About HTTP Live Streaming — 複数の流れ・ライブと録画の一覧・画質切り替え
• Apple：Enabling Low-Latency HLS — 部分セグメントと配信側の対応条件