ネット配信の映像は、放送波のように1本のストリームが流れ込んでくるのだと思われがちです。実際には違います。プレーヤーが受け取っているのは、数秒ごとに切り分けられた小さな動画ファイルの連なりです。視聴者が「途切れずに見られている」その裏で、プレーヤーは数秒おきにファイルを取りに行き、つなぎ合わせ、次にどの画質のファイルを取るかを決め続けています。この仕組みの上に立つ配信プロトコルの代表が、HLSとMPEG-DASHです。
二つはよく似ています。どちらもHTTPで小分けのファイルを配る方式で、やっていることの骨格はほとんど同じです。それなのに現場では「iPhoneはHLS、Android TVはDASH」といった使い分けが当たり前に語られる。同じことをする規格が、なぜ二つ並んで生き残っているのでしょうか。
HLSとDASHの違いはどこにあるのか
先に生まれたのはHLS(HTTP Live Streaming)です。Appleが2009年、iPhoneでの動画配信のために設計しました。マニフェストはm3u8という拡張M3U形式のテキストで、セグメントは当初MPEG-TS、後にfMP4にも対応しています。Appleが自社デバイスに標準搭載したため、iPhoneやiPadのSafariは今もHLSをプレーヤーライブラリなしでそのまま再生できます。
MPEG-DASHは、この状況への応答として作られました。特定企業の仕様に配信の足場を委ねてよいのか、という問題意識のもとMPEGで標準化が進み、2012年にISO/IEC 23009-1として発行されています。マニフェストはMPD(Media Presentation Description)と呼ぶXMLで、設計上の特徴はコーデックにもコンテナにも依存しないことです。中身がH.264でもHEVCでもAV1でも、規格の側は関知しません。
実務を規定するのは、この思想の差よりも対応デバイスの非対称です。iPhoneのSafariはHLSをネイティブ再生できる一方、DASHの再生に必要なMSE(Media Source Extensions)を長く提供してきませんでした。iPhoneのブラウザで確実に動くのは、事実上HLSだけです。逆にPCのWebブラウザやAndroid TVの世界ではdash.jsやShaka Playerといったオープンソースプレーヤーが揃い、YouTubeやNetflixがDASHを採用していることも知られています。国内の放送同時配信・見逃し配信も、この地形の上で、デバイスごとにHLSとDASHを使い分ける構成を取ることが多くなります。
要するに、HLSはAppleのデバイスから出発した事実上の標準、DASHは最初から国際標準として設計された規格です。
セグメント配信とABR(アダプティブビットレート)の仕組み
では、小分けのファイルを配るとは具体的にどういうことか。配信サーバー側では、1本の映像を数秒単位のセグメントに切り、さらに同じ内容を複数の画質で並行して用意します。1080pで6Mbps、720pで3Mbps、480pで1.5Mbpsといった段階を並べたものはビットレートラダー(階段)と呼ばれます。マニフェストは、この階段のどこに何があるかを書いた目次にすぎません。
プレーヤーの仕事は、この目次を見ながら賭けを続けることです。直近のセグメントのダウンロードにかかった時間から回線の太さを推定し、バッファの残量と見比べて、次のセグメントをどの段から取るかを決める。回線が細れば下の段へ降り、余裕が出れば上の段へ戻る。視聴中に「画質がふっと変わった」と感じる瞬間は、プレーヤーが数秒先の帯域を読み違えないよう手を打った跡です。再生が止まるくらいなら画質を落とす。ABRの設計思想はこの一点に尽きます。
HTTPで運ぶことの利点は、配信のスケールに直結します。セグメントはただの静的ファイルなので、Webページと同じCDNのキャッシュに載ります。視聴者が10万人に増えても、オリジンサーバーは同じファイルを一度CDNに渡すだけでいい。専用のストリーミングサーバーが視聴者ごとにセッションを張っていた時代と比べ、規模の伸ばし方が根本から変わりました。
弱点は遅延でした。数秒のセグメントを数個貯めてから再生を始める設計のため、従来のHLSでは放送より数十秒遅れることが珍しくありません。ゴールの瞬間、映像より先にSNSの歓声が届いてしまう、あの現象です。ここに答えたのがCMAF(共通メディアフォーマット)と低遅延拡張です。CMAFはfMP4ベースのセグメント形式を共通化した規格で、HLSとDASHが同じセグメントファイルを共有できるようにしました。さらにセグメントをチャンクと呼ぶ細かい単位で書き出しながら順次転送することで、Low-Latency HLSやLow-Latency DASHでは遅延を数秒まで詰められます。
放送局が配信基盤を選ぶときの論点
配信基盤の選定では、規格の優劣よりも三つの現実が判断を左右します。一つめは、いま見た遅延です。同時配信で放送から数十秒遅れるのを許容するのか、LL-HLSやLL-DASHで数秒まで詰めるのか。低遅延化はバッファを削る営みなので、回線の揺れに対する耐性と引き換えになります。詰めるほど、視聴環境の悪い人から先に破綻していく。どこで折り合うかは、スポーツ中継なのかドラマの見逃し配信なのかという番組の性質次第です。
二つめはCDNのコストです。HLSとDASHを別々のセグメントで二本立てにすれば、ストレージもCDNのキャッシュも単純に二重になります。CMAFでセグメントを共通化できれば、この重複は大きく減らせます。ラダーの段数と最上段のビットレートは配信量に直結し、同じ画質でも H.264で組むかHEVCで組むかというコーデックの選択 で必要な帯域は変わります。画質設計は、そのまま帯域コストの設計です。
三つめがDRMです。有料配信や見逃し配信ではコンテンツ保護が前提になりますが、DRMの実装は事実上3社に集約されています。AppleのFairPlayはHLSでしか使えず、GoogleのWidevineとMicrosoftのPlayReadyは主にDASHと組み合わせて使われます。iPhoneからAndroid、スマートテレビまで全デバイスへ保護付きで届けようとすると、マルチDRM対応、つまりHLSとDASHの併用がほぼ避けられません。二つの規格が並存し続けている最大の理由は、技術の優劣ではなくこのDRMの勢力図にあります。
なお、ここまでの話はすべて視聴者へ届ける配信(ディストリビューション)の側です。中継先から局へ映像を集める伝送(コントリビューション)では SRTのような低遅延伝送プロトコル が別の論理で選ばれますし、局舎内の制作設備では SMPTE ST 2110のような非圧縮のIP伝送規格 が使われます。同じ「映像をIPで運ぶ」でも、求められる品質と遅延の桁がまるで違うのです。
結局のところ、HLSかDASHかという問いに技術だけで答えることはできません。視聴者がどのデバイスで見るのか。その内訳が分かった時点で、選択肢はおおかた決まっています。プロトコルの比較表を眺める前に、まず自社サービスの視聴ログでデバイス構成を確かめる。選定はそこから始まります。
NAXAの取り組み
NAXAはテレビ業界向けの独自技術として、日本語に特化した音声認識エンジンと、テロップ・字幕に対応した画像解析・OCRエンジンを保有し、放送・配信領域のシステム開発を手掛けています。HLSやDASHが整えたのは、放送番組を放送波の外へ届けるための経路です。その経路の上で字幕付与や映像解析といった処理をどこに組み込むかは、配信基盤の設計と切り離せません。配信パイプラインの構築や映像処理システムの開発に関心のある方は、お気軽にご相談ください。
