HLSとDASH：アダプティブストリーミングの比較解説

アダプティブビットレートストリーミング（ABR）は、変化するネットワーク状況やデバイスに対してビデオをスムーズに配信するという根本的な問題を解決します。

処理の流れ：

1. エンコーディング：ソースビデオが複数の品質レベル（レンディション）にトランスコードされます
2. セグメント化：各レンディションが小さなチャンク（各2〜10秒）に分割されます
3. マニフェスト：プレイリストファイルに利用可能なすべてのレンディションとセグメントURLが列挙されます
4. 再生：プレイヤーが帯域幅とバッファを監視し、品質を自動的に切り替えます

帯域幅が低下すると、プレイヤーはバッファリングを防ぐために低品質のレンディションに切り替えます。帯域幅が回復すると、より高品質に切り替えます。これはストリーム途中でもシームレスに行われます。

Appleが開発したHLSは、iOSおよびSafariでのビデオ再生に必須のプロトコルです。最も広くサポートされているアダプティブストリーミング形式です。

HLSの仕組み：

• マスタープレイリスト（.m3u8）に利用可能なすべてのレンディションが列挙されます
• 各レンディションはセグメントを列挙した専用のメディアプレイリストを持ちます
• セグメントは従来.ts（MPEG-TS）形式を使用しますが、現在はfMP4が推奨されます
• デフォルトのセグメント時間は6秒ですが、低レイテンシのために2〜4秒が一般的です

HLSの利点：

• iOS/Safariでは代替手段がなく必須
• 成熟したツール群と広範なサポート
• FairPlayによる組み込みDRMサポート
• シンプルなプレイリスト形式（プレーンテキスト）

HLSの制限：

• 元々プロプライエタリ（現在はRFC 8216）
• デフォルト設定ではレイテンシが高い
• .tsセグメントはfMP4より効率が低い

DASHはISO規格（ISO/IEC 23009-1）であり、特定のベンダーに支配されていません。YouTube・Netflix（Apple以外のデバイス）・多くのAndroidアプリケーションでデフォルトとして採用されています。

DASHの仕組み：

• XML形式のMPD（メディアプレゼンテーション記述）マニフェスト
• セグメントには.m4s（フラグメント化MP4）形式を使用
• 高度な機能を持ちHLSより柔軟性が高い
• 複数のDRMシステムをサポート（Widevine・PlayReady）

DASHの利点：

• オープンな国際標準
• より効率的なfMP4セグメント
• 高度な機能（複数期間・トリックプレイ）
• 低レイテンシへのより優れたサポート

DASHの制限：

• iOS/Safariではネイティブサポートなし
• より複雑なマニフェスト形式
• 全体的にHLSほど普及していない

CMAF（Common Media Application Format）は、同一のフラグメント化MP4セグメントをHLSとDASHの両方に使用できます。異なるのはマニフェストのみです。

CMAFのメリット：

• ストレージ50%削減：1セットのセグメントで両プロトコルに対応
• エンコーディングの簡略化：1回のエンコードでどこでも配信可能
• キャッシュ効率の向上：CDNがすべての視聴者に対して1つのコピーを保存
• 低レイテンシ化：チャンク転送エンコーディングのサポート

CMAFの実装：

• CMAF対応設定でfMP4セグメントにエンコード
• .m3u8（HLS）と.mpd（DASH）両方のマニフェストを生成
• 両マニフェストが同じセグメントを参照
• 主要なCDNおよびプレイヤーがCMAFをサポート

新規プロジェクトには通常CMAFベースの配信を推奨しております。ストレージおよび運用上の節約効果は非常に大きいです。

HLSを選ぶべき場合：

• iOSおよびSafariのサポートが必要な場合（多くのケースで該当）
• 高度な機能よりもシンプルさを優先する場合
• CDNやエンコーディングサービスがHLSを推奨している場合

DASHを選ぶべき場合：

• iOS/Safariのサポートが不要な場合
• 高度なDRM（マルチキー・オフライン）が必要な場合
• Androidのみ、またはウェブのみ向けに開発している場合

CMAFで両方を使うべき場合：

• 最大限のデバイスカバレッジが必要な場合（推奨）
• ストレージと配信コストを最適化したい場合
• やや複雑なパイプラインに投資できる場合

多くのプロジェクトでは、HLSとDASHの両マニフェストを使用したCMAFをお勧めします。これにより、最適な効率と普遍的な互換性を両立できます。