オンライン動画はどう再生されるのか？クリックからフレームまでの全工程

YouTubeの再生ボタンを押した瞬間、1秒以内には画面に何かが映っています。その1秒の間に何が起きたのでしょうか。動画はそもそもあなたのデバイス上には存在せず、視聴しているファイルはどこにも単一のファイルとして存在しておらず、画面を点灯させているバイトはYouTubeのサーバーから来たものですらない、という事実を考えれば、そこには本当に大変な量の処理が走っています。バイトは、自宅と同じ都市圏のどこかにあるキャッシュから届きました。あなた、あるいは1,000人の別の視聴者がまさにその映画のまさにそのスライスを要求するかもしれないので、念のため作っておかれたコピーです。

順番はこうです。ブラウザはサーバーと通信し、動画を記述した小さなテキストファイルを受け取ります。プレーヤーはそのファイルを読み、いくつかの画質オプションから1つを選び、CDNに音声と映像の短いチャンク（通常2〜6秒）を要求し始めます。チャンクは、普通のウェブページを配信するのと同じHTTPSコネクション上で届きます。プレーヤーはあなたのスマートフォンやノートパソコンに既に搭載されているハードウェアでそれをデコードし、フレームを画面に描画します。最初のチャンクを再生している間に、プレーヤーは次の3つを取りにいっています。Wi-Fiが揺らげば、再生が止まらないように次のチャンクをそっと低画質バージョンに切り替えます。このループ全体（マニフェスト取得→セグメント取得→デコード→描画→計測→適応）が、ウェブ上のNetflix・YouTube・Twitch・Disney+・TikTokのすべての動画の裏側で見えないところで走っています。

これは当社のストリーミングシリーズのピラー記事です。一方の端のカメラから、もう一方の端の画面に映るフレームまで、パイプライン全体を平易な日本語で歩いていきます。技術レイヤーは精確さを保てる程度の深さでカバーしつつ、専門用語に溺れることなく、どのサービスがこれらのレイヤーをどう組み合わせて使っているかを見て、最後に多くの読者をここに連れてきた実用的な疑問、すなわち「視聴した動画のコピーを手元に残せるか？」に答えます。

動画ストリーミングとは、HTTPS上で取得される短く連番のファイルセグメントの連続として動画をデバイスに配信し、小さなマニフェストファイルに従って動的にデコードし、次のセグメントが流れ込むと同時に破棄していく仕組みのことです。

重要ポイント {#key-takeaways}

• ストリーミングは特別なプロトコルではなく、素のHTTPの上に組まれた巧妙なパターンにすぎない。 マニフェストもセグメントもCDN上の単なるファイル。
• 「視聴している」動画は1つのファイルとしては存在しない。 マニフェストと数百個の小さなセグメントから、プレーヤー内で再構築されている。
• エンコードは同じコンテンツを複数のビットレートバリアントとして生成する。 プレーヤーはリアルタイムの帯域計測に基づいてその中から1つを選ぶ。
• ほとんどのセグメントはオリジンサーバーではなく、近くのCDNエッジから来る。 ストリーミングが瞬時に感じられるのはエッジキャッシュのおかげ。
• アダプティブビットレートストリーミングが画質が再生中にこっそり変わる理由。 プレーヤーはバッファの健康を保つためにセグメント間でバリアントを切り替える。
• 3層の暗号化が独立に積み重なる。 トランスポートのHTTPS、セグメント内容のAES-128、ライセンスゲートされた商用ストリームのDRM。
• HLSとDASHが市場を支配している。 HLSはAppleの仕様（RFC 8216、.m3u8）、DASHはISO/IEC標準（23009-1、.mpd XML）。主要サービスはほとんど両方を配信する。
• ストリームを保存するとは、マニフェストを解析し、すべてのセグメントを取得し、暗号化を扱い、リマックスすること。 右クリック→名前を付けて保存ではない。

シンプルな説明

世界中の1億人の視聴者に長編映画を届ける立場になってみてください。映画は巨大です。2時間の1080p H.264動画は4〜8GB程度になります。視聴者の回線はギガビット光からモバイル4Gの揺れる電車内まで、あらゆる種類があります。同じ巨大ファイルを全員に送ることはできません。正しい1つのファイルを送ることすらできません。電車の視聴者には低ビットレート版が必要で、光の視聴者は高ビットレート版を望み、電車の視聴者が映画の途中でWi-Fiに切り替えたら、再起動なしで画質を上げてあげる必要があります。

業界が落ち着いた解決パターンは、聞いて拍子抜けするほどシンプルです。映画を数百本の短いクリップに切り、各クリップを複数の画質でエンコードし、すべてのクリップを世界中のサーバーに保存し、次にどのクリップを再生するかは視聴者のプレーヤーに任せる。 それだけです。「ストリーミング」と呼ばれているものは、根本的にはフォルダの中のファイルが特定の順序でウェブ越しに取得されているだけなのです。

ライフサイクルを端から端まで並べるとこうなります。

1. カメラまたはレンダリングエンジンが生のフレームをキャプチャする。 ライブなら実物のカメラ、VODならスタジオから受け取った完成マスターです。
2. エンコーダーが生フレームをコーデックで圧縮する。 動画はH.264・H.265・AV1、音声はAACまたはOpus。1つの入力から複数のビットレートで出力するのが普通です。
3. パッケージャーがエンコード済みストリームを短いセグメントに切り、マニフェストを書く。 各バリアントは独自のセグメントフォルダと自身のマニフェストを持ち、バリアント群はトップレベルのマスターマニフェストに列挙されます。
4. セグメントとマニフェストをオリジンにアップロードし、CDNに複製する。 Cloudflare、Akamai、Fastly、AWS CloudFrontなど、サービスが使うCDNが世界中のエッジノードにキャッシュします。
5. あなたが再生を押す。 プレーヤーがマニフェストをダウンロードし、バリアントを選び、最初のセグメントを近くのCDNエッジから取り、デコードを開始します。
6. プレーヤーは各セグメントをデコードしてフレームを画面に描画する。 視聴中の地点より数秒先のバッファを保ちます。
7. プレーヤーはセグメント到着のたびに帯域を計測し、 リアルタイムの回線にバリアントを合わせるためにセグメント間で調整します。

これがパイプライン全体です。それ以外には何も起きていません。特別なサーバーも、有線上の独自プロトコルも、魔法もありません。各ステップは、気長にやればスクリプトを書ける程度のツールと形式しか使っていません。巧妙さは設計にあります。各セグメントは間でバリアントを切り替えられる程度に短く、マニフェストは往復が速くなる程度に小さく、セグメントは他の静的ファイルと同じようにキャッシュされ、プレーヤーはすでにBlu-rayやFaceTimeのデコードに使われているのと同じハードウェア上で走ります。ストリーミングウェブ全体がHTTPSとファイルとタイミングだけで作られている。 これから扱うプロトコルとコーデックは、これらの部品が大規模に相互運用できるようにするための取り決めにすぎません。

ストリーミング動画は実際どう動いているのか

ここがピラー記事の技術的な核です。パイプライン全体を端から端まで歩きます。読み終えるころには、どのストリーミングサイトのネットワークタブを開いても、各リクエストがどの段階のものかを言い当てられるはずです。

Camera → Encoder → Packager → Origin → CDN edge → Player → Decoder → Screen

この図がパス全体です。以下で扱う概念（ビットレートラダー・マニフェスト・セグメント・ABR・暗号化）は、すべてこの矢印のどこかに収まります。

オリジンとエンコーディング

すべては生の動画から始まります。ライブ配信であればカメラ（ゲーム配信なら画面キャプチャ）が1920×1080・60fpsの非圧縮フレームを生成します。非圧縮では約3Gbpsにもなります。生の動画を公開インターネットで配信する人はいません。最初の仕事は圧縮です。

動画エンコーダーは、時間冗長性（ほとんどのピクセルは前フレームのピクセルに似ている）と空間冗長性（画像のほとんどの領域は近隣に似ている）を利用して、生フレームを圧縮ビットストリームに変換します。2026年現在の主流コーデックは次のとおりです。

• H.264 (AVC) — 2003年に標準化。古いものの、依然としてインターネット上で最も広くサポートされているコーデック。過去15年以内に作られたあらゆるデバイスがハードウェアデコードできる。
• H.265 (HEVC) — 同画質でH.264より約50%効率的。ロイヤリティの絡みでウェブ普及は遅れたが、スマートフォン・スマートテレビ・Appleプラットフォームでは事実上どこでも対応。
• AV1 — ロイヤリティフリーかつオープン。HEVCよりわずかに効率的。YouTube・Netflix・Vimeoが主要なAV1配信者。ハードウェアデコードのサポートも2025〜2026年でようやく行き渡った。
• AACとOpus — 音声コーデック。AACはHLSで必須、OpusはWebRTCで支配的でDASHでも増えている。

同じコンテンツはほぼ常に複数のビットレートバリアントにエンコードされます。典型的なエンコードラダーは次のような形です。

この表の各行は、同じソースからの別エンコードです。時間軸が揃えられているので、プレーヤーはデコーダーを再起動することなく、壁時計上の同じ瞬間でバリアントを切り替えられます。各バリアントの中身（コンテナとコーデックの違い）の詳細については、MP4などのコンテナとH.264などのコーデックをご覧ください。

パッケージング — セグメントとマニフェスト

エンコーディングのあとはパッケージングです。各バリアントのビットストリームをセグメントと呼ばれる短いチャンクに切り、それらを列挙するマニフェストを書きます。

セグメントは通常、音声と映像それぞれ2〜10秒です。プレーヤーが任意のセグメントの先頭からデコードを開始できるよう、キーフレーム境界（ビットストリーム上のIフレーム）で切られています。マニフェストがEXT-X-INDEPENDENT-SEGMENTS（HLS）またはDASHでの相当する宣言を持つ場合、すべてのセグメントは単独で再生可能であることが保証されます。そうした宣言がない場合は、一部のセグメントが先行セグメントの情報に依存します。

セグメントのコンテナ形式はさまざまです。

• MPEG-TS（.ts） — 旧来のHLS。もとは1990年代の衛星・ケーブル放送形式で、ビットエラーに強い。現役だが段階的に置き換えが進んでいる。
• Fragmented MP4（.m4s、ときに.mp4） — 現代のHLSとDASH全般。通常のMP4と同じコンテナだが、フラグメントに切られて各々がヘッダを持ち、独立して再生可能。
• CMAF — Common Media Application Format（ISO/IEC 23000-19）。.tsとfMP4の融合ではなく、フラグメント化MP4のプロファイル・パッケージング制約。同じfMP4ファイル群がHLSの.m3u8からもDASHの.mpdからも参照できるよう、fMP4セグメントの構造を厳密に規定しています。現代のサービスはプロトコルごとにバイトを二重化する代わりにCMAFを配信し、fMP4を扱えない古いHLSクライアント向けに旧来の.tsセグメントが併存しています。

マニフェスト自体も2系統あります。

• HLSのマニフェストは.m3u8テキストファイル。マスタープレイリストがバリアントと帯域を列挙し、各バリアントがセグメントURLと尺を持つメディアプレイリストを持ちます。全体の解剖についてはm3u8ファイルに実際に何が入っているかをご覧ください。
• DASHのマニフェストは.mpd XMLファイル。1つのファイルがプレゼンテーション全体（AdaptationSet・Representation・SegmentTimeline・BaseURL）をツリー構造で記述します。HLSとの比較についてはDASHとその.mpdマニフェストをご覧ください。

どちらの設計も同じ仕事をしています。どんなバリアントが存在し、各セグメントがどこにあり、それぞれの尺がいくつなのかをプレーヤーに伝える。それ以外はすべてプレーヤー任せです。

CDNによる配信

セグメントとマニフェストがファイルとして存在するようになると、ストリーミングサービスはオリジンサーバー（通常はS3やR2のようなオブジェクトストア）にアップロードし、コンテンツデリバリーネットワークに世界中のエッジノードへの複製を任せます。ネットワークリクエストで目にするCDNには、Akamai・Cloudflare・Fastly・AWS CloudFront・Googleのエッジ網、そしてNetflix（Open Connect）やYouTubeがISP内に展開しているプライベートCDNがあります。

CDNがストリーミングでこれほど重要なのは、キャッシュ可能性ゆえです。セグメントはURLが変わらない静的ファイル。ある地域の最初の視聴者がオリジンからセグメントを取り、エッジがキャッシュし、それから1〜2時間以内のその地域のすべての視聴者は数十ミリ秒の距離にあるサーバーから受け取ります。人気のYouTube動画では、大多数のセグメントリクエストはYouTubeのオリジンに一切到達しない——ISP内部にあるキャッシュ箱から配信されているのです。

これがストリーミングの優れたスケール性の理由でもあります。東京で同時視聴者が100万人増えても、カリフォルニアへの往復が100万本増えるわけではありません。すでにファイルを持っている東京のエッジノードへの負荷が増えるだけです。この計算上の余裕は、2010年以前のストリーミングプロトコルでは到底できなかったものです。

プレーヤーのワークフロー

ここでデバイス側に戻ってきます。ブラウザがページをロードし、ページがJavaScriptプレーヤー（通常はshaka-player・hls.js・video.jsか、ベンダー固有のビルド）を起動し、プレーヤーがページの<video>要素に再生開始を依頼します。そこからプレーヤーはタイトなループを回します。

1. マニフェストを取得する。 HTTPS GETを1回。レスポンスは数キロバイトのテキスト。
2. マニフェストを解析して初期バリアントを選ぶ。 過去履歴やデバイスのネットワーク情報からシードされた帯域推定、画面解像度、最初のセグメントが詰まらないための安全マージンに基づいてプレーヤーが選択。
3. 最初の数セグメントを取得する。 現代のプレーヤーは単一のHTTP/2またはHTTP/3コネクション上で並列にフェッチする。セグメントは同時に到着。
4. セグメントのバイトをブラウザのMedia Source Extensionsバッファに送る。 MSEはJavaScriptが<video>要素にプログラム的に動画データを供給できるW3C API。あとはブラウザ内蔵のデコーダーが引き受ける。
5. デコードして描画する。 過去10年以内のほぼすべてのデバイスでハードウェアアクセラレーションされているデコーダーが圧縮フレームを生のピクセルに変換し、GPUが動画のフレームレートで描画。
6. バッファを満たし続ける。 ユーザーがセグメントNを視聴している間、プレーヤーはN+1、N+2、N+3を取得している。
7. セグメントごとに再評価する。 ダウンロードのたびに回線速度に関する新しいデータが手に入る。それをもとに次のセグメントのバリアントを切り替えるかを決める。

プレーヤーコードの大半は記帳作業です。バッファの健康管理、失敗したセグメントのリトライ、シークと一時停止、広告セグメントの差し込み、音声トラックの切り替え、字幕のレンダリング。ストリーミングの部分は概念的に小さく（取得・デコード・繰り返し）、エンジニアリングの複雑さはそのまわりのエッジケースの集合に住んでいます。

アダプティブビットレート（ABR）

アダプティブビットレートは、この仕組み全体に価値を与えている機能です。ABRがなければ、プレーヤーは1つの画質を選んで固定し、回線がそれを維持できなくなった瞬間に再バッファに入ります。ABRがあれば、プレーヤーは各セグメントで帯域を測り、走りながらバリアントを切り替えます。

基本ループはこうです。各セグメントのダウンロード後、プレーヤーは実効帯域（セグメントサイズ÷ダウンロード時間）を計算し、最近の測定値の移動平均と比較します。帯域が下向きなら次のセグメントは下のバリアントへ、上向きでバッファに余裕があれば上に戻ります。判断はセグメント間で行われ、セグメントの途中で起きることはなく、切り替えはシームレスです。

実際のABR実装はもっと繊細です。バッファ占有率（健康なバッファなら上のバリアントへ挑戦できる、減りつつあるなら急ぎ下げる必要がある）、画面解像度（720pのノートパソコンに4Kを流す意味はない）、移動平均・ローパスフィルター・機械学習推定器を使った予測モデルでバリアント間の振動を避ける、といった要素を考慮します。2026年に主流の2つのABRアルゴリズムはBOLA（バッファベース）とMPC（モデル予測制御）で、どちらもオープンソースプレーヤーに登場します。詳細な内訳は現代のあらゆるプレーヤーに組み込まれているABRロジックをご覧ください。

ユーザーに見える結末はこうです。あなたは画質を選ばなくてよく、プレーヤーが秒ごとに選び、切り替えは普段は見えません。見えるとき（Netflixの画面が急に少しソフトになるのに気づいたとき）、それは再生を途切れさせないためにABRが下のバリアントを選んでいるのです。

暗号化：混同されがちな3つのレイヤー

ストリーミングにおける暗号化は人々が思うより多層で、独立した3層がしばしばごちゃまぜに語られます。これらは同じものではありません。

HTTPS = トランスポートのセキュリティ。 現代のストリームはすべてTLS上で配信されます。これはネットワーク上の盗聴者（ISP、Wi-Fi上の攻撃者、企業プロキシ）が流れていくバイトを読めないようにするものです。HTTPSは受信側ブラウザがバイトを読むのを止めません。あくまで有線上の話です。

AES-128セグメント暗号化 = コンテンツ層。 HLSもDASHも、セグメント自体をAES-128のCBCまたはCTRモードで暗号化することをサポートしています。マニフェストにキーURLが含まれ、プレーヤーはHTTPSでキーを取得して各セグメントをデコード前に復号します。これはコンテンツ層の保護で、バイトを取得されても無意味にしますが、キーURL自体がゲートです。キーURLに届く者は誰でもセグメントを復号できます。多くのライブ・クリエイタープラットフォームはAES-128セグメント暗号化を基本的な保護層として使っています。

DRM = ライセンスサーバーゲート・ハードウェアバック復号。 Widevine（Google）・FairPlay（Apple）・PlayReady（Microsoft）は、セグメント暗号化の上にポリシー層を被せます。セグメントは依然としてAES暗号化（MPEG Common Encryption、ISO/IEC 23001-7の下）ですが、コンテンツキーはあなたのデバイスの信頼済み実行環境のみが展開できるよう包まれています。ライセンスサーバーはライセンス発行前にサブスクリプション・デバイス信頼性・地域を確認します。復号はハードウェアバックのセキュアモジュール内で行われ、復号済みフレームはアプリケーションメモリを経由せず直接GPUに渡されます。これがNetflix・Disney+・Apple TV+・有料ストリーミングの大半を保護しているものです。詳細な解説はWidevineと FairPlayがプレミアムストリームをゲートする仕組みをご覧ください。

これらの層は積み重なります。プレミアムなNetflixストリームは、トランスポート用のHTTPS、CENCで暗号化されたCMAFセグメント、そしてライセンスゲートのキー配信のためのWidevineまたはFairPlayを使っています。Twitchのライブストリームは単にHTTPSのみ。有料の講座プラットフォームならHTTPSにAES-128セグメント暗号化を足してDRMはなし、ということもあります。どのレイヤーが効いているかを知ることは、バイトにアクセスする技術的なハードルが実際にどこにあるか、そして正当な利用の境界がどこに引かれているかを示してくれます。

暗号化されていないストリームを保存するだけでも、これらすべてのプロトコルを正しく順番に話し、プレーヤーが裏で黙々と処理しているエッジケースに対応する必要があります。VidMostはこれらの作業を裏側で行うために作られています。マニフェスト解析、セグメント取得、AES処理、組み込みWidevine L3経由のDRM、コンテナのリマックス。ユーザーから見えるステップは「URLを貼る、MP4が得られる」だけです。

実世界でこれをどこで目にするか

上記のパイプラインは、基本的に2026年のあらゆる商用ストリーミングサービスに当てはまります。違いは、どのプロトコル・コーデック・DRMをサービスが採用し、デバイスとどう交渉するかにあります。

• YouTube。 メインプロトコルはウェブとAndroidではMPEG-DASH、Safari・iOS・AirPlay・大半のスマートテレビにはHLSを配信。コンテンツのほぼ全部がCMAFで、1組のfMP4セグメントが両マニフェストに対応。コーデックは互換性のためのH.264、ほとんどの再生でVP9、対応デバイスでの高解像度ストリームにAV1。映画・TVレンタルにはWidevineとFairPlayのDRM、ユーザー投稿動画は非暗号化。
• Netflix・Disney+・Apple TV+・HBO Max・Prime Video。 クライアントに応じてHLSとDASHを使い分け、CMAFが共通のセグメント形式。DRMは必須で、デバイスがWidevine・FairPlay・PlayReadyのいずれかを選ぶ。コーデックはH.264・H.265・AV1、Dolby Vision/Atmosのオーバーレイを含む。ライセンスサーバーが再生のたびに地域・サブスクリプション・デバイス信頼性を強制。NetflixはOpen Connectという独自CDNを多くのISP内で運用。
• Twitch。 HLSのみ。.tsセグメントもCMAFと並んで現役。低遅延バリアントでは2〜5秒、標準では15〜30秒のレイテンシ。セグメントは非暗号化。Twitchの保護モデルはアイデンティティとアカウントレベルで、コンテンツ暗号化ではない。
• Bigo Live・OnlyFansライブ・Chaturbate・Fansly。 HLSベースのライブ配信で、低遅延のための非暗号化セグメントと短い（2秒の）チャンクが典型。ブラウザ側の再生はhls.jsまたはSafariのネイティブHLSサポート。
• Vimeo・Mux・Cloudflare Stream・JW Player。 ホスト型動画プラットフォーム。アップロードを自動的にHLSとDASHの両方にパッケージングし、独自CDNで配信。Cloudflare StreamはCMAFを配信、Muxはデフォルトでは HLS。DRMは有料プランでオプション。
• スポーツとニュース — ESPN・DAZN・BBC iPlayer・Sling TV。 HLSまたはDASHにDRM、しばしばWidevine + FairPlay + PlayReadyを一緒にパッケージングして、同じエンコード済みセグメントですべてのデバイスを賄う。低遅延HLS（LL-HLS）がトレンド。かつて放送より30秒遅れていたライブイベントが3秒未満のレイテンシで届く。
• TikTok・Instagram Reels・YouTube Shorts。 ショート動画は最小クリップにはMP4のプログレッシブダウンロード、1分以上のものにはHLSまたはDASH。長尺サービスと同じCDNとコーデックの選択肢。

異なる場所で、同じ機械。物語は変奏を伴う反復です。各サービスがマニフェスト形式、コーデックラダー、DRMの組み合わせを選び、同じ取得・デコード・描画ループを数十億の視聴者に対して走らせています。

動画を保存したい場合に意味すること

パイプラインを理解すると、ひとつの実用的な事実が明白になります。保存すべき単一のファイルなど存在しない、ということです。あなたが「視聴している」動画は、マニフェストと数百個の小さなセグメントから、プレーヤーがリアルタイムで取得し、走りながらデコードし、次のものが届いたら破棄しながら再構築しています。ブラウザの「名前を付けて保存」はマニフェスト（動画バイトが1つも入っていない小さなテキストファイル）を取得するだけです。

手動で再生可能なファイルにする道のりは長いです。マニフェスト（HLSの.m3u8またはDASHの.mpd）を取得して解析。正しいバリアント（通常、ストレージが受け入れられる最大帯域のもの）を選ぶ。すべてのセグメントURLを列挙する。署名URLが失効する前にすべて取得する（6秒セグメントで30分の動画なら300以上のリクエスト）。EXT-X-KEYがあればAES-128キーを取得して各セグメントを復号する。DRM保護されていれば、ライセンスを発行できるCDMがなければ何もできず、そのCDMがあっても復号されたバイトはセキュアモジュールから出てこない。素のセグメントが手に入ったら、音声と映像を1つのMP4またはMKVコンテナにリマックス。バリアント選択が正しかったことを願う。間違っていたら別バリアントで繰り返す。

正しいツールはこのパイプラインを1つのユーザー操作にたたみ込みます。VidMostはHLSとDASHのマニフェストを解析し、利用可能な最高画質のバリアントを選び、ブラウザが話していたのと同じCDNからセグメントを並列でダウンロードし、AES-128セグメント暗号化を自動で扱い、DRM保護ストリームに対してはL3再生が利用可能な範囲でWidevine L3をサポート（実際の品質はサービスとDRMレベルでキャップされる場合があり、プレミアムプラットフォームは通常L3を480p〜720pに制限）し、すべてを任意のメディアプレーヤーで再生できるクリーンなMP4にリマックスします。プロトコルレイヤーは消えます。URLを貼る、ファイルが得られる。

視聴する正当な権利を持つコンテンツ（受講済みの講義、アーカイブしたいライブ配信、自身の放送、自由にライセンスされた動画）について、これがワークフロー全体です。本記事が説明したパイプラインは、ツールがあなたに代わって航行するために作られたものです。

よくある落とし穴と誤解

ストリーミングに関するいくつかの思い込みは繰り返し登場します。訂正する価値があります。

• 「ストリーミングは特別なプロトコルを使う。」 使いません。現代のアダプティブストリーミングは素のHTTPS上で動きます。HTMLやJPEGを配信するのと同じプロトコルです。マニフェストとセグメントはCDN上の静的ファイル。HLSやDASHにおける「プロトコル」とは、それらのファイルに何が入っているかという取り決めにすぎません。
• 「視聴中にファイルがダウンロードされている。」 正確ではありません。セグメントは再生のためにジャストインタイムでダウンロードされ、次のものが流れ込んだら破棄されます。デバイスは動画全体を保持しません。これが「セッションを停止する」が有効に働く理由であり、バイトの到着が止まった瞬間にストリーミングセッションが壊れる理由でもあります。
• 「高い帯域は高画質を意味する。」 帯域が安定している場合に限ります。100Mbpsで10秒だけ2Mbpsに落ちる回線は、安定した8Mbpsの回線より体験が悪くなります。エンコードラダーもキャップになります。最高バリアントが5Mbpsなら、それ以上の帯域を持っていても画質は買えません。
• 「バッファリングはインターネットが遅いことを意味する。」 ときには。エンコードラダーが疎すぎる（現在の帯域にマッチするバリアントがない）、CDNエッジのキャッシュミス、ピアリングの輻輳、プレーヤーのABRが反応の遅さなど、同じくらい頻繁に他の原因があります。バッファリングはプレーヤーが補充の時間を求めているサインで、回線速度の確定判決ではありません。
• 「DRMと暗号化は同じ。」 いいえ。暗号化は数学的な操作で、キーが必要なスクランブルされたバイトです。DRMはその暗号化の周囲にあるポリシーシステムです。キーを誰に渡すかを制御するライセンスサーバー、そのキーを使う信頼済み実行環境、どのデバイスがどのコンテンツを再生できるかを決める契約執行レイヤーの組み合わせ。暗号化が錠前、DRMはアラームシステム・鍵配布・失効ポリシーをまとめたものです。
• 「MP4はストリーミング形式。」 いいえ。MP4は音声・映像・メタデータを包むコンテナ、つまりファイル形式です。HLSとDASHはストリーミングプロトコルであり、フラグメント化MP4セグメントを運ぶことができます。通常の.mp4ファイルはストリームされません。プログレッシブにダウンロードされます。HLSとDASHで目にするCMAFセグメントはMP4由来ですが、構造はだいぶ違います。

混乱の大半は、パイプラインを内面化すれば消えます。ストリーミングはファイルとタイミング。それ以外は細部です。

結びに

インターネットは動画を、他のものを配信するのと同じように、HTTP上のファイルとして配信し始めました。それから、どのファイルを、どの順序で、どの画質で、どのエッジキャッシュから、どのハードウェアでデコードして配信するかという点で巧妙さを発揮し始めました。その巧妙なパターン（マニフェスト+セグメント+アダプティブビットレート+CDNキャッシュ）こそが、ストリーミングが瞬時に感じられ、数十億の視聴者にスケールし、現実のネットワークの乱雑さに耐える理由のすべてです。秘密のプロトコルも、独自のサーバーも、特別な魔法もありません。ただファイルとタイミング、そしてスタック全体にわたる非常に良いエンジニアリングがあるだけです。

プロトコルレイヤーを完全に飛ばして単に動画を保存したい場合、VidMostはHLS・DASH・fMP4・AES-128・Widevine L3を裏側で処理します。マニフェスト解析、セグメント取得、暗号化処理、MP4書き出しまですべて。

関連する読み物

• HLSとM3U8とは？ — ストリーミングの大半が走るプレイリスト+セグメントの設計。
• MPEG-DASH vs HLS — 各プロトコルが勝つ場面と、なぜほとんどのサービスが両方を配信するか。
• アダプティブビットレートストリーミング解説 — 現代のあらゆるプレーヤーに組み込まれているABRロジック。
• 動画コンテナとコーデック — セグメントの中に実際に入っているもの。
• DRM保護コンテンツとは？ — Widevine・FairPlay・PlayReadyがプレミアムストリームをゲートする仕組み。