本記事では、動画配信の低遅延化を実現する技術であるLow Latency HLS (LL-HLS)について解説し、AWSを用いた実装方法と検証結果を共有します。
私は2024年にエンジニアとして新卒入社し、2025年1月から動画配信システムの開発に携わっています。業務でLL-LHSを導入できないかとプライベートで調査を行ったものをまとめたものです。
動画配信技術は書籍等での情報が限られており、体系的な資料も少ないため、基礎知識から実装、検証結果まで包括的に解説します。
そもそも動画配信技術とは？
動画配信技術は用途や要件に応じて複数の規格が存在します。現在広く使用されている主要な技術を紹介します。
RTMP（Real Time Message Protocol）
- 2002年にAdobeが開発
- Adobe Flash Playerとの高い互換性を持つ
- 現在は新しい技術への移行が進んでいる
HLS（HTTP Live Streaming）
- 2009年にAppleが開発
- HTTP通信を利用した配信方式
- YouTube、Twitchなどの大規模配信サービスで採用
- オンデマンド配信とライブ配信の両方に対応
WebRTC（Web Real Time Communication）
- 2011年にGoogleが主導して開発
- ブラウザ間の直接通信を実現
- Zoom、Google Meetなどのビデオ会議システムで採用
引用元：https://qiita.com/khayama/items/fe10e2068b53584cfbd6
HLSの仕組み
HLS(HTTP Live Streaming)は、動画ファイルを一定の長さのセグメントに分割し、HTTP通信でクライアントに配信する技術です。クライアント側のプレイヤーは、セグメントの再生順序や時間情報が記載されたマニフェストファイルを参照して、連続的な再生を実現します。
HLSはAppleが開発した技術なので、英語ですがAppleの公式のドキュメントがわかりやすく参考になります。
引用元：https://developer.apple.com/documentation/http-live-streaming
LL-HLSの概要
LL-HLS（Low Latency HTTP Live Streaming）は、2019年にAppleが発表したHLSの拡張規格です。従来のHLSで発生する10〜30秒の遅延を、2〜5秒程度まで短縮することを目的としています。
-
主な特徴
- 従来のセグメント（2〜6秒）をさらに細かいパーシャルセグメント（0.1〜0.5秒）に分割
- 従来のHLSとの後方互換性を維持
- LL-HLSに対応していないクライアントでもHLSとして再生することが可能
-
対応環境
- iOS 15.0以上
- Android 2.16.1以上
- 主要な動画プレイヤーライブラリ（hls.jsなど）
LL-LHSはHLSで分割した動画ファイル（セグメント）をさらに細かくしたパーシャルセグメントを作ります。
従来のHLSよりもより細かく・頻繁に更新されることで遅延を短縮します。さらに、更新されたデータもCDNのキャッシュを効率よく使用できるように設計されています。
これにより、HLS（左）よりもLL-LHS（右）は単純に比較しただけで10秒程度遅延を短くすることができます。（他にも動画遅延が起こる原因は多々あるので、この議論はあくまでも単純化したものです。）
詳しい仕様は、Apple WWD 19の動画の動画で詳しく解説されています。
現在の業務システムでは、AWS MediaLive 及び、AWS MediaPackageを使用してHLS形式でライブ配信を行っています。月間アクティブユーザーが50万人を超えるサービスで、1回の配信で数千人から数万人規模の視聴があります。
現状では数十秒程度の遅延が発生しており、以下の課題があります：
- 視聴者とのコメントによる円滑なインタラクティブなコミュニケーションが困難
- 番組開始時の待機映像（ふた映像）が長くなり、視聴者の離脱につながる可能性がある
本検証では、LL-HLSの導入による遅延時間の短縮効果を確認し、実際の業務で使う際の課題を明らかにすることを目的としています。
本検証ではローカル環境でNTP時計の時間を表示させ、実際にリアルタイムに配信されているHLS配信・LL-HLS配信の時間を比較し、どれくらい遅延があるかを検証しました。
NTP時計はNTP時計（ミリ秒）を使用しました。
また、配信切り替えソフト（OBS）で画面を切り替えた際にHLS配信・LL-HLS配信の画面でどれくらい切り替えのラグが発生するかを実際のスタジオからの配信を模擬する形で検証しました。
- 検証①：NPT時計を用いた遅延時間の比較
- 検証②：画面切り替え時のラグ
遅延時間の比較
| 設定 | HLS | LL-HLS |
|---|---|---|
| 初期設定 | 30.2秒 | 25.7秒 |
| 最適化後 | 26.3秒 | 7.0秒 |
画面切り替え時のラグ
OBSでのシーン切り替え（フェード効果300ms）を行った際の遅延
- HLS：26秒
- LL-HLS：7秒
システム構成
業務に近い形での配信環境を模擬するために、スタジオからのライブ配信を仮定し、配信はCDNも含めた以下の構成で検証します。
また、LL-HLS配信を導入するにあたり、いきなりLL-HLS配信に全切り替えすることは現実的ではないです。そのため、同じ映像入力をHLS配信、LL-LHS配信の２つの異なるエンドポイントで出力するように設計しました。
検証環境は以下のコンポーネントで構成されています。
- AWS Elemental MediaLive：エンコーディングサービス
- AWS Elemental MediaPackage：パッケージングサービス
- Amazon CloudFront：コンテンツ配信ネットワーク（CDN）
- OBS Studio：配信ソフトウェア
HLS配信システムの構築
AWS Elemental MediaPackageのv1で、ll-hls-testというチャンネルを作成しました。オリジンエンドポイントに対応するCloudFrontも作成しました。
次に、AWS Elemental MediaLiveの設定を行います。こちらも同様にチャンネルを新規で作成します。この際に、出力グループを先ほど作成した、Media Packageのチャンネルll-hls-test に設定しておきます。
MediaPackage v1を使用しているので、送信先を”HLS出力を使用します”の方にしておく必要があります。
今回は簡単のために、出力を1080pのみに設定しました。
このチャンネルにデフォルトのMediaLiveAccessRoleを付与する必要があるので注意してください。
入力アタッチメントはRTMP（プッシュ）形式で設定しました。
詳しくは、【初心者】AWS Elemental MediaLive + MediaPackage を使ってみる（PCからのライブ配信）を参照してください。
ここでは入力として、 hls-test-input-obs を作成しました。このエンドポイントに向けて、OBSの映像を出力させます。
OBS側の設定を行います。OBSにはオープンソースのOBS Studioを使用しました。hls-test-input-obs のエンドポイントを配信情報に設定します。
LL-HLS配信システムの追加
AWS Elemental MediaPackageのライブ v2にチャンネルグループ、チャンネルを新設します。今回はll-hls-test-2グループ内に、ll-hls-test-channelを作りました。
2023年からライブ v2が新たにできて、LL-HLS配信はv2のみの対応になっています。
v2では、マニフェストファイルごとにオリジンエンドポイントを作成するようになっています。今回はll-hls-indexというマニフェストを作成して、これに対応するCloudFrontを作成しました。
デフォルトではMediaPackageのエンドポイントポリシーが「ポリシーをアタッチしない」になっているので、パブリックに向けて公開したい場合は「パブリックポリシーをアタッチする」に変更してください。
次に、MediaLiveの設定ですが、先ほど作成したlhs-testチャンネルの出力グループにLL-HLS用のMediaPackageのグループを追加します。
MediaPackage v2を使用しているので、送信先を”CMAFインジェスと出力をします”の方を選択するように注意してください。
CMAF出力の場合は映像と音声を別々の出力に設定しなければいけません。デフォルトの設定では1出力に対して、映像と音声が設定されている状態になり、画像のようなエラーが出ます。今回は簡単のために、映像のみを出力の設定にしました。
検証①（初期設定）
初期設定の場合は、以下のような結果になりました。
画像の右上がLL-HLS、右下がHLS、左側がOBSの画面です。
LL-HLS配信では3-5秒程度の遅延に抑えられるとのことでしたが、初期設定ではHLS配信よりも5秒程度早くなる結果しか得られませんでした。
| HLS | LL-HLS | |
|---|---|---|
| 遅延秒数（初期設定） | 30.2秒 | 25.7秒 |
検証①（最適化後）
LL-HLS配信設定のパラメータを調整して、さらに低遅延になるように調整します。
前述の通り、LL-HLS配信はHLS配信よりも動画ファイルのセグメントを小さくすることで、遅延を短くしています。
そこでMediaPackageのセグメント期間を10秒→1秒に変更します。
また、セグメント長を短くするために、MediaLiveの出力設定の「GOPの構造」のGOPサイズ単位をFRAMES、GOPサイズを1, Bフレーム数を0に変更しました。（MediaLiveの出力にMediaPackageを選択していると、セグメント長などを細かく設定することができません。）
最適化後の結果が以下の通りです。
最適化の結果、LL-HLS配信の遅延が7.0秒に抑えられました。HLS配信の遅延よりも19秒程度早くなりました。
HLS配信の方も26.3秒とチューニング前よりも約4秒下がる結果になりました。ネットワークの回線状況によるものだと考えられます。
| HLS | LL-HLS | |
|---|---|---|
| 遅延秒数（最適化後） | 26.3秒 | 7.0秒 |
検証②（最適化後）
ストップウォッチが6秒時点で、OBSのシーンを変更した時に、HLS配信、LL-HLS配信でどれだけ切り替えに時間がかかるか検証しました。
結果は以下の通りです。
| HLS | LL-HLS | |
|---|---|---|
| 切り替えのラグ（最適化後） | 26秒 | 7秒 |
先ほどと同様に、画像の右上がLL-HLS、右下がHLS、左側がOBSの画面です。
13秒時点でLL-HLSの画面が切り替わり、32秒時点でHLSの画面が切り替わりました。
コスト考察
最後に導入にあたってのコストについて議論します。
- MediaPackage v2の利用自体に追加コストは発生しない
- 検証期間中は既存のHLS配信と並行して運用するため、一時的に配信コストが2倍になる
- セグメント長の短縮によりCloudFrontへのアクセス頻度が増加し、CDNコストが上昇する可能性がある
既存のHLS配信をLL-LHS配信に切り替えるにあたって、MediaPackage v2を使用するのに追加のコストはかかりません。そのため、検証期間のみHLS配信の2倍の配信費用がかかると考えれば良いと思います。
ただし、LL-LHS配信に切り替えることで、動画のセグメントが短くなるため、CloudFrontへのアクセス頻度が増えることでCloudFrontの費用が増加する可能性があります。
今回の検証では短時間の配信かつ、アクセス数が1なので費用が増大することは確認できませんでしたが、大規模なサービスで使用する場合はこのあたりのコストの増加を考慮する必要があるかもしれません。
本検証により、LL-HLSの導入で遅延時間を約7秒まで短縮できることを確認しました。これは従来のHLS配信と比較して約19秒の改善となります。
- 今後の課題と展望
- CMAFインジェストグループの詳細な設定によるさらなる遅延短縮の可能性検討
- 大規模配信時のCDNコストの詳細な試算
- 実際の業務システムに組み込んだ時の遅延の評価
- クライアント側の再生環境の互換性検証
Views: 0
