日本語
再生を押すと、映画の大部分がまだ別の場所にあっても映像が始まる。動画ストリーミングは、見続けるのに十分なデータを届け、再生中に続きを取りに行くことで動く。端末はデータをダウンロードしている。ただ、通常は映画全体がそろうまで待たなくてよいのだ。
構成要素は、略語が与える印象ほど難しくない。圧縮した動画、利用できる版のメニュー、バッファーという小さな蓄え、そして次の部分を届けるサーバーだ。それらがどう組み合わさり、なぜ回転する待機マークが望まないカメオ出演をするのかを見ていこう。
目次
ストリーミングの流れ
符号化、配信用の準備、配信
サービスは元の動画を再生可能な版へ圧縮する。多くの場合、複数の解像度とビットレートを用意する。その後、配信できる形にまとめる。一般的なHTTPストリーミングでは、プレーヤーは前の部分を再生しながら、短いセグメントを要求する。Appleの2020年の断片化された動画についての説明は、録画とライブの両方でこの流れを示している。
各セグメントが別々のファイルである必要はなく、大きなリソース内の一部分でもよい。大事なのは、再生と配信が重なることだ。食べ始める前に、厨房が宴会の料理すべてを出す必要はない。
マニフェスト：プレーヤーのメニュー
マニフェストやプレイリストは、利用できるメディアと取得方法を記述する。HLSはM3U8プレイリスト、DASHはMedia Presentation Description、略してMPDを使う。プレーヤーはその情報をたどり、必要な部分を取得する。
メニューが一つとは限らない。HLSでは、上位のプレイリストから別の版を指し、それぞれがメディア用のプレイリストを持てる。2017年公開のRFC 8216はこの構造を説明している。最初の小さなテキストファイルに、映画の全フレームの住所が一つずつ書かれているとは限らない。
解像度とビットレートは別のもの
解像度は画像の寸法を表す。720pや1080pなどは、通常、画像の縦方向のピクセル数を指す。ビットレートは1秒あたりに使うデータ量だ。ピクセルが多ければデータも多く必要になり得るが、すべての1080p動画に一つの決まったビットレートがあるわけではない。
圧縮、フレームレート、映っている素材も関わる。静かな会話と細かなものが激しく動く画面では、エンコーダーに求めるものが違い得る。画質表示は便利な略記であり、レシピ全体ではない。
動画が読み込み待ちになる理由
バッファーは、すでに受信したが、まだ再生していないメディアの蓄えだ。配信の短い途切れを補う。次の再生可能なデータが来る前に蓄えがなくなれば、再生は待たなければならない。
どこでも共通の10秒や30秒のバッファーがあるわけではない。プレーヤーは、特に開始の速さと途切れへの強さを釣り合わせながら、異なる量を選ぶ。ライブ配信では、ためすぎない理由もある。余分に保持する1秒ごとに、実際の出来事から遅れていくからだ。
IETFの2022年のストリーミング運用の概説は、配信能力、利用可能なメディア、再生側の必要量のすべてが重要な理由を説明している。高速な回線契約でも、特定のサービスまでの経路の全区間が良好だとは保証できない。
実際に問題を切り分ける順序
- 別の作品やサービスを試す。一つの動画だけが失敗するなら、その項目や配信元に固有の問題かもしれない。
- 使っている端末で接続を確認する。ルーターの横の速度テストでは、テレビの裏のWi-Fiの電波状況はわからない。
- 競合する転送を減らす。大きなダウンロードやバックアップを止めて、再生が改善するかを見る。
- 有線接続にするか、ルーターに近づく。Wi-Fiが弱点かどうかを試す助けになる。
- 再生画質を下げる。必要なデータが少なければ、不安定な接続にも余裕ができる。
これらは診断の手順であり、必ず直る方法ではない。複数の端末で複数のサービスが失敗するなら接続を調べ、一つのアプリだけがおかしいなら、そのアプリの対処ガイドから始めよう。最初の当て推量で新しいルーターを買うのは、かなり高くつく。
アダプティブビットレート：画質が変わる理由
ビットレート適応の研究は、画質と中断の間のトレードオフを説明している。アダプティブビットレート配信、ABRでは、状況の変化に応じてプレーヤーが用意された版から選ぶ。次に何を要求するか決める際、最近のダウンロード状況、バッファー、端末の能力などを使える。
MDNの適応型ソースのガイドは、それを可能にする複数の符号化版と参照情報を説明する。互換性のある代替版をサービスが用意しなければならない。存在しない高画質版をプレーヤーが魔法で出すことはできない。
最初はぼんやりしていて、少し後に鮮明になる動画は、プレーヤーが慎重な開始点を選んだ結果かもしれない。配信が悪化すれば、低いビットレートを要求できる。適切に準備した切り替えなら時間軸を途切れさせずに進められるが、画質の変化自体は見える場合がある。
目的は中断を減らすことであり、読み込み待ちゼロという絶対の約束ではない。適切な版のうち最も軽いものさえ間に合わないなら、プレーヤーの外交力にも限界がある。
HLSとDASH：二つの配信方式
HLSはHTTP Live Streamingの略だ。Appleが開発し、プレイリストはライブとオンデマンドの両方を記述できる。MPEG-2トランスポートストリームはセグメント形式の一つだが、断片化MP4にも対応する。単に「M3U8とTSファイル」ではない。
DASHはDynamic Adaptive Streaming over HTTPの略で、MPDを使ってメディアの構成を記述する。MDNのDASHガイドは、ブラウザーのプレーヤーがJavaScriptライブラリーで扱う方法を説明している。
HLSはAppleの環境で重要だが、「Apple端末はHLSしか再生しない」は誤りだ。対応する動画ファイルや再生技術には、ほかの方法もある。あるストリームが動くかどうかは、ブラウザーやアプリ、OS、コーデック、ときにはコンテンツ保護にも依存し、端末のロゴだけでは決まらない。
CDNの役割
コンテンツ配信ネットワークは、分散したインフラにメディアのコピーを配置し、全視聴者が一つの配信元からすべてを取得する必要を減らす。「近い」は地理だけでなくネットワーク上の配信の話でもある。経路、容量、コンテンツがすでに保存されているかどうかが選択に関わる。
Netflixの2021年のOpen Connectの説明資料は、キャッシュとインターネット接続事業者との連携によって、視聴者の近くへコンテンツを届ける方法を紹介する。考え方の具体例であり、すべてのサービスが同じネットワークを使うという規則ではない。
キャッシュは仕事の分担を助ける。ただし、すべての作品がすべての町に永久保存されるわけでも、物理的に最も近いサーバーが必ず答えるわけでもない。CDNは便利なインフラであり、瞬間移動の呪文ではない。
ライブ動画が違う理由
録画された映画は、すでに存在している。ライブは次の瞬間が起きるのを待って、収録し、符号化し、届け、再生しなければならない。現場に近い時間で視聴してもらうほど、遅れを吸収する時間は少なくなる。
Low-Latency HLSのような技術は、より小さな部分を早く利用可能にする。遅延を減らすが、処理の流れ自体をなくすわけではない。だから、画面のゴールより先に、隣人の歓声が届くことはまだある。
ストリーミングとダウンロードは反対語ではない
ストリーミングでもデータは端末へ転送される。主な違いは配信と視聴の組み合わせ方だ。ストリーミングは続きが届く間に消費を始め、オフライン用ダウンロードは後で使うために保存する。
プログレッシブダウンロードも、ファイル全体が届く前に再生を始められる。ファイル、プレーヤー、サーバーによっては、途中へ移動する際に、それ以前の全バイトを待たず、別の部分を要求できる。
また、定額制アプリからダウンロードしても、永久に保管できる無制限のファイルを得られるとは限らない。たとえばNetflixはダウンロードした作品に期限があると説明している。端末内への保存と映画の所有は、別の問題だ。
よくある質問
どのくらいの回線速度が必要？
希望する画質について、サービスの推奨値を確認し、ほかの利用者や転送の分も余裕を持たせよう。「4Kには常に正確に25 Mbps必要」という普遍的な規則はない。符号化や配信元の条件は異なる。
速度テストが速ければ、接続の問題はない？
いいえ。特定の時刻に、特定のテストサーバーまでの接続を測っているだけだ。動画の配信元への経路、Wi-Fiの安定性、競合する通信は、再生中には違うかもしれない。
自動画質なら、すべての停止を防げる？
いいえ。状況の変化に対応する助けにはなるが、障害、エラー、配信能力の不足によって、ストリームはなお中断し得る。
映画全体を受け取る前に見られる？
見られる。受信と視聴が重なることこそ、中心となる便利さだ。プレーヤーに必要なのは、視聴位置より少し先に十分な再生可能なデータがあることで、必ずしもエンドクレジットまで全部そろうことではない。
ネットの娯楽を支える技術が好きなら、私たちのスピードランのガイド（英語）では、特に緊張感のある視聴体験を生み出す人たちを紹介している。ゲームのプレーヤーは時計に勝とうとし、動画のプレーヤーは別の時計に先行しようとしている。
2026-05-15公開の英語版の記事を日本語に翻訳しました。翻訳日：2026年10月30日。翻訳にはAIを使用し、記事内の時点は原文に合わせています。
