動画ストリーミングの仕組み ― 再生ボタンの裏側で何が起きている？

いい質問だね。ダウンロードは「ファイル全体を保存してから再生」だけど、ストリーミングは「数秒ぶんのデータを受け取りながら同時に再生」するんだ。水道の蛇口をイメージするとわかりやすいよ。バケツに水を全部溜めてから使うのがダウンロード、蛇口から流れてくる水をそのまま使うのがストリーミングだね。

まず動画はH.264やH.265、最近だとAV1といったコーデックで圧縮されるよ。そのうえで、2〜10秒くらいの「セグメント」に分割されるんだ。プレイヤーはこのセグメントを1つずつ順番にリクエストして、つなぎ合わせて再生しているんだよ。

そこで登場するのがHLS（HTTP Live Streaming）やDASH（Dynamic Adaptive Streaming over HTTP）というプロトコルだよ。HLSなら.m3u8、DASHなら.mpdという「マニフェストファイル」があって、全セグメントのURLや再生順、利用可能な画質の一覧が書かれているんだ。プレイヤーはまずこのマニフェストを取得して、そこに従ってセグメントを順番にダウンロードしていくんだよ。

そのとおり！これがアダプティブビットレートストリーミング（ABR）の仕組みだよ。同じ動画を360p、720p、1080p、4Kといった複数の画質でエンコードしておいて、プレイヤーが通信速度を監視しながら最適な画質のセグメントを自動で選ぶんだ。電車でトンネルに入って回線が遅くなると画質が下がるのは、まさにABRが働いているからだね。

そこで活躍するのがCDN（コンテンツデリバリネットワーク）だよ。世界中にエッジサーバーを配置して、ユーザーに一番近いサーバーからセグメントを配信するんだ。東京のユーザーがアメリカの元サーバーまで取りに行く必要がなくなるから、遅延が大幅に減るし、元サーバーへの負荷も分散されるよ。

あれが「バッファリング」だね。プレイヤーは再生位置より先のセグメントを事前にダウンロードして「バッファ」に溜めているんだけど、通信速度が落ちてバッファが空になると再生が追いつかなくて止まるんだ。最近のプレイヤーは賢くて、バッファ残量に応じて画質を下げたり、先読み量を調整したりして、なるべく止まらないように工夫しているよ。

大きく違うよ。録画済み動画（VOD）はすべてのセグメントが事前に用意されているから、先読みバッファをたっぷり持てる。でもライブ配信はセグメントがリアルタイムに生成されるから、遅延を小さくする必要があるんだ。従来のHLSだと20〜30秒の遅延が出ていたけど、LL-HLS（Low-Latency HLS）やCMAF（Common Media Application Format）を使うと2〜5秒まで縮められるよ。

鋭いね！超低遅延が必要な場合はWebRTCという技術が使われるよ。これはもともとビデオ通話用に作られたプロトコルで、1秒未満の遅延を実現できるんだ。ただしWebRTCは大規模配信には向かないから、数千〜数万人が同時視聴するような配信ではHLSやDASHが主流のままだよ。

NetflixはOpen Connectという自前CDNを運用していて、ISP（インターネットプロバイダ）のデータセンター内に専用サーバーを設置しているんだ。ユーザーのすぐ近くにコンテンツがあるから超高速で配信できる。YouTubeはコーデック戦略が特徴的で、自社開発のVP9を広く採用し、さらに次世代のAV1への移行を進めているよ。AV1はH.265と同等の画質をより少ないデータ量で実現できるから、通信コストの削減に大きく貢献しているんだ。

そうなんだよ。コーデックで圧縮、セグメントに分割、マニフェストで管理、ABRで画質調整、CDNで高速配信、バッファで途切れ防止……これだけの技術が連携して初めて「ボタンを押したら即再生」が成り立っているんだ。次に動画を観るとき、ちょっとだけ裏側の仕組みを想像してみると面白いかもしれないね。