HLSとは何か、プロトコルと動作原理

HLSとは？

HTTP Live Streaming (HLS) は、2009年にAppleによって開発され、iOS 3.0とSafariで初めて導入されたメディアストリーミングプロトコルです。2017年には、RFC 8216を通じてインターネット標準として提案され、あらゆるプラットフォームで実装可能なオープン仕様としての地位が確認されました。

HLSの主なアイデアは、連続したメディアストリームを2〜10秒の短いセグメントに分割することです。各セグメントは独立したファイルであり、通常のHTTPリクエストでダウンロードできます。ストリーム管理は、セグメントへの参照と正しい再生のためのメタデータを含むM3U8形式のテキストプレイリストを通じて行われます。

適応性 はHLSの重要な利点です。サーバーは、弱い接続向けの200 Kbpsから4Kビデオ向けの20+ Mbpsまで、異なるビットレートで同じコンテンツの複数のバージョンを準備します。クライアントは現在のチャネル帯域幅に基づいて適切なビットレートを自動的に選択します。Appleの調査（WWDC 2024）によると、LL-HLSはビットレート間の切り替え時間を500ミリ秒に短縮し、目立った一時停止なしでスムーズな品質変更を保証します。

HLSの開発の歴史

最初のバージョン のHLS（2009年）は、AACオーディオコーデックとH.264ビデオコーデックを備えたMPEG-2 TSセグメントのみをサポートしていました。iOS 8（2014年）でfMP4（fragmented MP4）セグメントのサポートが追加され、HEVC（H.265）を含むより現代的なコーデックでのHLSの使用が可能になりました。iOS 11（2017年）でHDR10とDolby Visionのサポートが導入されました。iOS 13（2019年）でLow-Latency HLSが導入され、従来の6〜30秒から2〜6秒にレイテンシが短縮されました。

2023年、AppleはHLSを拡張し、AV1およびEVC（Essential Video Coding）コーデックのサポートを追加するとともに、コンテンツステアリング（最適な負荷分散のためにCDNサーバー間でクライアントを動的にリダイレクトするメカニズム）を導入しました。コンテンツステアリングにより、サーバーは再生を中断することなく、クライアントを最寄りまたは最も負荷の少ないCDNノードにリダイレクトしながら、セグメントURLをリアルタイムで変更できます。

HLSの仕組み

HLS のアーキテクチャは、サーバー側（オリジンサーバー＋エンコーダー）、配信ネットワーク（CDN）、クライアント側（HLS対応プレーヤー）の3つの主要コンポーネントで構成されています。ビデオキャプチャからユーザーのデバイスでの再生までの全プロセスには、複数の順次的な段階が含まれ、それぞれがストリーミング品質にとって重要です。

エンコードとセグメント化

ソースビデオは最初に、異なるビットレートと解像度の複数のバリアントにエンコードされます。FFmpegやAWS Elemental MediaConvertなどのプロフェッショナルエンコーダーは、一度に4〜12のストリームバリアントを作成します（240p（400 Kbps）から4K（40 Mbps）まで）。各バリアントは等しい長さのセグメントに分割され、通常LL-HLSの場合は2〜6秒、従来のHLSの場合は6〜10秒です。

各バリアントに対して、すべてのセグメントのURLとその長さを含むバリアントプレイリストが作成されます。さらに、すべてのバリアントを結合し、それぞれの解像度、ビットレート、コーデック、オーディオトラックに関する情報を含むマスタープレイリストが作成されます。クライアントは最初にマスタープレイリストをロードし、接続速度の分析に基づいて適切なバリアントを選択します。

CDNによる配信

セグメント とプレイリストは、ユーザーの地理的に近い場所にあるCDNサーバーにキャッシュされます。配信に標準のHTTPプロトコルを使用することで、HLSは重要な利点を得ています。HTTPをサポートするあらゆるCDN、ロードバランサー、プロキシサーバーが追加設定なしでHLSと連携できます。これにより、HLSは専用サーバーを必要とするRTMPやWebRTCなどのリアルタイムプロトコルとは一線を画しています。

import subprocess

subprocess.run([
    "ffmpeg",
    "-i", "input.mp4",
    "-codec:v", "libx264",
    "-codec:a", "aac",
    "-hls_time", "6",
    "-hls_list_size", "0",
    "-var_stream_map", "v:0,a:0 v:1,a:1",
    "-map", "v:0", "-b:v:0", "5000k",
    "-map", "v:1", "-b:v:1", "1000k",
    "-f", "hls",
    "stream/output.m3u8"
])

クライアント側は適応ビットレートアルゴリズム（ABR）を使用します。HLSプレーヤーはマスタープレイリストをロードし、利用可能なバリアントを分析して、最も適切なビットレートで再生を開始します。再生中、プレーヤーは常にセグメントのダウンロード速度とバッファの充填レベルを監視し、より高いまたは低いビットレートに切り替えるかを判断します。最新のABRアルゴリズムは、ネットワーク速度だけでなく、バッファサイズ、コンテンツタイプ、さらにはデバイスの消費電力も考慮します。

HLSストリームの構造：プレイリストとセグメント

エンコード、配信を正しく設定し、再生の問題をデバッグするには、HLSストリームの構造を理解する必要があります。各HLSストリームは、2レベルのプレイリストと、厳格な階層で編成された多数のメディアセグメントで構成されています。

マスタープレイリスト

マスタープレイリスト は、HLSプレーヤーのエントリーポイントです。.m3u8拡張子のファイルには、すべてのストリームバリアントとその特性への参照が含まれています。プレーヤーは最初にこのファイルをロードし、ビットレートと解像度に関する情報に基づいて、どのバリアントを選択するかの初期決定を行います。マスタープレイリストには、代替オーディオトラック、字幕、高速シークのためのIフレームプレイリストへの参照も含めることができます。

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/video.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1000000,RESOLUTION=640x360
360p/video.m3u8

メディアプレイリスト

メディアプレイリスト には、1つのストリームバリアントの実際のセグメントリストが含まれています。各セグメントは、その長さとURIとともに指定されます。メディアプレイリストは、静的（VODの場合 — すべてのセグメントの完全なリスト）または動的に更新される（ライブ放送の場合 — 古いセグメントが削除され、新しいセグメントが追加される）場合があります。

#EXTM3U
#EXT-X-TARGETDURATION:6
#EXTINF:6.000,
segment001.ts
#EXTINF:6.000,
segment002.ts
#EXT-X-ENDLIST

セグメントフォーマット

HLSは2つの主要なメディアセグメントフォーマットをサポートしています：MPEG-2 Transport Stream (.ts) と Fragmented MP4 (.m4s または .mp4)。MPEG-2 TSは元のHLSフォーマットで、最大の互換性を提供します。fMP4はより現代的なフォーマットで、HDR、HEVC、より効率的な圧縮をサポートします。AppleはiOS 10およびmacOS Sierra以降のすべての新規プロジェクトでfMP4を推奨しています。

追加のHLSストリーム要素には、高速シークのためのIフレームプレイリスト、字幕と広告マーカーの同期のためのID3メタデータ、視聴情報を分析サーバーに送信するためのSession Dataが含まれます。これらの要素はすべてオプションですが、使用することでユーザーエクスペリエンスの品質が向上します。

HLSの利点と欠点

HLS は、いくつかのアーキテクチャ上の利点によりビデオストリーミング市場を支配していますが、特定のプロジェクトのためにプロトコルを選択する際に考慮すべき制限もあります。HLSを代替のビデオ配信プロトコルと比較してみましょう。

主な利点 は、内蔵のAVPlayerを通じてすべてのAppleデバイス（iPhone、iPad、Apple TV、Mac）でネイティブサポートされていることです。これにより、HLSはiOS/macOSアプリケーションの事実上の標準となっています。さらに、配信に標準HTTPを使用することで、追加設定なしで任意のCDNやプロキシサーバーでコンテンツをキャッシュでき、配信インフラを大幅に簡素化できます。

HLSの欠点には、ライブ放送におけるRTMPやWebRTCと比較した高いレイテンシが含まれます。LL-HLSでも最低レイテンシは2〜6秒であり、リアルタイムのインタラクティブシナリオには許容できません。また、HLSはサーバー上により多くのファイルを生成し（各セグメントが個別のファイル）、多数の同時ストリームがある場合にファイルシステムに負荷をかける可能性があります。

モバイルアプリケーションにおけるHLS

モバイルアプリケーションへのHLSの統合は、プラットフォームによって異なります。iOSおよびmacOSでは、HLSはAVFoundationとAVPlayerを通じてオペレーティングシステムレベルでサポートされており、ハードウェアアクセラレーションによるデコードと最小限の電力消費を実現します。Androidでは、HLSは内蔵のMediaPlayerではサポートされていませんが、Googleの公式メディアプレーヤーであるExoPlayerを通じて利用可能です。

AVPlayerを使用したiOSでのHLS

Appleプラットフォームでは、AVPlayer の内蔵サポートにより、HLS再生は可能な限りシンプルです。マスタープレイリストのURLを持つAVPlayerを作成するだけで、システムが自動的にアダプティブビットレート切り替え、オーディオトラックの選択、字幕処理を処理します。開発者はAVPlayerItemとAVAssetResourceLoaderを通じて再生を完全に制御することもできます。

import AVFoundation

let url = URL(string: "https://example.com/stream.m3u8")!
let player = AVPlayer(url: url)
let controller = AVPlayerViewController()
controller.player = player
present(controller, animated: true) {
    player.play()
}

ExoPlayerを使用したAndroidでのHLS

Android では、別の拡張モジュールを通じてHLSをサポートするExoPlayerが使用されます。ExoPlayerはHLSストリームをより細かく制御でき、ビットレート選択の管理、バッファリングの設定、セグメント読み込みエラーの個別処理が可能です。LL-HLSにはExoPlayerバージョン2.14.0以上が必要です。

val player = ExoPlayer.Builder(this).build()

val uri = Uri.parse("https://example.com/stream.m3u8")
val mediaItem = MediaItem.fromUri(uri)

player.setMediaItem(mediaItem)
player.prepare()
player.play()

モバイルネットワーク向けのHLS最適化

モバイルアプリケーションは、セルラーネットワークの不安定さとトラフィック制限のため、HLS設定に特別なアプローチが必要です。主な推奨事項には、ネットワークタイプ（Wi-Fiまたはセルラー）に基づいた初期ビットレートの設定、より迅速な適応のための短いセグメント長（2〜4秒）の使用、Wi-Fi切り替え時のバッファの事前読み込み、弱い信号時のオーディオトラックの優先が含まれます。

AppleのHLS Authoring Specification for Apple Devices（2024）では、モバイルデバイスでは最大6秒のセグメントサイズと少なくとも4つのビットレートバリアントを使用することを推奨しています。モバイルネットワークでのトラフィックを節約するため、サーバーはCache-Control HTTPヘッダー付きでセグメントを配信し、通信事業者の中間プロキシサーバーでコンテンツをキャッシュできるようにする必要があります。