HLS (HTTP ライブ ストリーミング) とは？

この記事は、当社パートナーの Wowza Media Systems の記事 What Is HLS (HTTP Live Streaming)? [Update] の翻訳記事です。

Adobe Flash は 2020 年に最終的に廃止されました。そのため、Apple の HTTP ライブ ストリーミング (HLS) プロトコルがストリーミング ビデオをユーザーに配信するための推奨される方法になりました。 HTTP ライブ ストリーミング (HLS) とは？ どのように機能するか？ 少し長い記事になりますが、これから HTTP ライブ ストリーミング (HLS) プロトコルの詳細について説明します。

HLSとは？

HLS (HTTP Live Streaming) は、ビデオおよびオーディオ データをメディア サーバーから視聴者の画面に転送するためのアダプティブ HTTP ベースのストリーミング形式です。スマートフォンのアプリでライブ ストリームを視聴している場合でも、スマート TV でオンデマンド コンテンツを視聴している場合でも、HLS ストリーミングを使用している可能性があります。特に、Apple デバイスを使用している場合に HLS ストリーミングが使われている可能性があります。

HLS を使用すると、ビデオとオーディオのコンテンツが一連のチャンク (断片) に分割され、圧縮されて配信され、HTTP 経由でエンドユーザーのデバイスに送信されます。視聴者は、バックグラウンドですべてが進行しているにもかかわらず、スムースなストリームの再生を享受することができます. MPEG-DASH 等の技術は、HLS と同様の方法でストリームを配信しますが、あまり広範囲で使用されていません。

Wowza の 2021 年のビデオ ストリーミング レイテンシ レポート では、レポートの回答者の 70% 以上がコンテンツ配信に HLS プロトコルを使用していると回答しています。 その他の代替プロトコルに対する HLS の人気は、プレイヤーでの再生の互換性とエクスペリエンス品質のおかげです。これは、すべての Mac、Android、Microsoft、および Linux デバイスが、HLS を使用して配信されたストリームを再生できるためです。

HLS を使用すると、コンテンツ ディストリビューターは、グローバルな配信のためにコンテンツ配信ネットワーク (CDN) に依存しつつ、幅広いデバイスで優れた視聴体験を保証することができます。 従来では、スケールと品質を保つことによって迅速な配信を犠牲にしてきましたが、Apple が Low-Latency HLS (低遅延 HLS) をリリースしたことで、すべてが変わりました。

HLS は Apple 独自の技術ですが、技術仕様は Internet Engineering Task Force (IETF) を通じて公開 されています。 Apple は定期的に技術仕様を更新し、パッケージャーとクライアントが互換性を維持できるようにしています。

訳注: HLS (HTTP Live Streaming) は、2017年 8月に正式な RFC (Request For Comment) 8216 として採択されています。また、Apple は、最新仕様である第2版を ドラフト仕様 として公開し、定期的に更新しています。

Apple HLS スナップショット

HLS (HTTP Live Streaming) の歴史

• 2009 年 5 月: HLS プロトコルの初期リリース
• 2015 年 1 月: Microsoft が Windows 10 での HLS のネイティブ サポートを発表
• 2016 年 6 月: Apple が fMP4 形式のサポートを発表
• 2019 年 6 月: Apple が Low-Latency HLS 拡張機能の仕様を発表
• 2019 年 11 月: Wowza は、Wowza Streaming Engine 4.7.8 リリースで Apple Low-Latency HLS のサポートを発表
• 2020 年 5 月: Low-Latency HLS (低遅延 HLS) 仕様が包括的な HLS 標準に組み込まれた

訳注: HLS (HTTP Live Streaming) は、2017年 8月に正式な RFC (Request For Comment) 8216 として採択されています。また、Apple は、最新仕様である第2版を ドラフト仕様 として公開し、定期的に更新しています。

HLS ストリーミングはどのように機能するか？

訳注: この例では、カメラのライブ映像の入力をエンコーダーで RTMP エンコードを行い、Wowza Streaming Engine などのメディアサーバーを使って、RTMP 方式で入力されたストリームを HLS にパッケージ化し (プロトコルの形式の変換を行い)、エンドユーザーに向けて、HLS ストリーミング方式で配信しています。

一般的な RTMP から HLS へのワークフロー

HLS ビデオ ストリームは、情報の連続した流れとして配信されるのではなく、データのセグメント (チャンクまたはパケットとも呼ばれます) に分割されます。従来のストリーム配信方法からの脱却により、高品質のストリームをより多くの視聴者に届けることができるようになりました。とはいえ、HLS ストリーミングの方式では遅延も大きくなるため、ほとんどのコンテンツ ディストリビューターは RTMP (リアルタイム メッセージング プロトコル) を使用して入力されたストリーミング コンテンツをエンコードし、メディア サーバーに到達したら HLS 配信用にパッケージ化します。

アダプティブ ビットレート ストリーミングのトランスコーディング

小さな画面のデバイスの視聴者やネットワーク接続状態の悪い視聴者を含め、視聴しているすべての人に対して可能な限り最高品質のストリームを配信するために、HLS ストリーミングは解像度を各個人の状況に動的に適応させます。アダプティブ ビットレート ストリーミングと呼ばれるこの機能により、(ストリームの) ブロードキャスターは、優れたネットワーク帯域幅と処理能力を備えたユーザーに高品質のストリームを配信できると同時に、ネットワーク帯域幅と処理能力が欠けているユーザーにも対応することができます。

1 つのビットレート (訳注: 1 つのビットレートと解像度) で 1 つのライブ ストリームを作成するのではなく、トランスコーダー (通常はメディア サーバーに配置) を使用して、異なるビットレートと解像度で複数のストリームを生成します。次に、サーバーは、視聴者の画面と接続速度に応じて可能な限り最高の (訳注: ビットレートと) 解像度のストリームを送信します。

1 つのストリームの複数のレンディションを作成すると、(訳注: プレイヤーで再生中の) バッファリングやストリームの再生中断を防ぐことができます。さらに、視聴者の信号強度が 2 本のバーから 3 本のバーに変わると、再生ストリームは動的に調整され、サーバーはより優れたレンディションを提供します。

訳注: 「レンディション」とは、同じストリームの異なる解像度と異なるビットレートの組み合わせのバリアントを意味します

配信とスケーリング

Flash Player と組み合わせて使用​​される RTMP プロトコルとは異なり、HLS は、通常の Web サーバーを使用して、グローバルなコンテンツ配信ネットワーク (CDN) を経由することで、簡単に配信をスケールすることができます。 HTTP サーバーのネットワークをまたいでワークロードを共有することにより、CDN は拡散された視聴者数の急増と予想を超えるライブ視聴者数に対応することができます。 CDN は、オーディオとビデオのセグメントをキャッシュすることで、視聴者のエクスペリエンスの向上にも役立ちます。

HLS と比較すると、RTMP は専用のストリーミング サーバーを使用する必要があるため、(訳注: スケールした配信のためには)　展開するリソースが多くなります。

HTTP ライブ ストリーミング ツールとサービス

HLS ストリーミング サーバー

前述のように、ほとんどのコンテンツ ディストリビューターはストリーミング サーバーを使用して、RTMP、WebRTC、または SRT などのストリーミングプロトコルで入力されたコンテンツを取り込み、ストリーミング サーバーに到達したら HLS 形式を使用してビデオ (ストリーム) をパッケージ化します。ビデオ (ストリーム) をその他の形式 (MPEG-DASH など) で追加で配信して、さまざまなデバイスの視聴者がコンテンツを確実に視聴できるようにすることも賢明です。 Wowza Video のようなクラウドベースのサービスや、Wowza Streaming Engine のようなストリーミング サーバー ソフトウェアは、このパッケージ化の変換プロセスやアダプティブ ビットレート配信のためのストリームのトランスコーディングの実現には不可欠です。

コンテンツ配信ネットワーク (CDN)

コンテンツ配信ネットワーク (CDN) は、世界中のサーバーに接続することで、ビデオ ストリームを配信元からエンド ユーザーに配信するのにかかる時間を短縮するスーパーハイウェイ (超高速道路) を作り出します。CDN は、多数の視聴者または地理的に分散した地域に向けてストリーミングするすべての人にとって、信頼性の高いコンテンツ配信を実現するのに不可欠です。 Wowza Video プラットフォームには、ライブ ストリームの配信をスケーリングするための統合 CDN が含まれています。さらに、Wowza Streaming Engine サブスクリプションのアドオン ストリーム ターゲットとして Wowza CDN を提供しています。 Akamai, Fastly, Microsoft Azure が提供する CDN も HLS ストリーミングの CDN の優れたオプションです。これらはすべて、Wowza の製品ポートフォリオを使用してアドオン ストリーム ターゲットとして利用することができます。

HTML5 プレーヤー

最後に、視聴者には、互換性のあるデバイス、または、HTML5 プレーヤーが必要となります。 HLS は、Adobe Flash の衰退を受けてデファクト スタンダードになっています。つまり、ほとんどのデバイスとブラウザーには、既にこの HLS 再生の機能が組み込まれています。最高の HTML5 ビデオ プレーヤーのリストについては、このブログ記事 をご覧ください。

HLS ストリーミングの技術概要

HLS の仕組みの基本的な概要はわかりましたが、詳細はどうでしょうか。エンコーディング要件からセグメントのサイズまで、ここから掘り下げて見ていきましょう。

• サポートするオーディオ コーデック: AAC-LC, HE-AAC+ v1 & v2, xHE-AAC, Apple Lossless, FLAC
• サポートするビデオ コーデック: H.265, H.264
• 再生の互換性: 良好 (すべての Google Chrome ブラウザー、Android、Linux、Microsoft、および MacOS デバイス、いくつかのセットトップ ボックス、スマート TV、およびその他のプレーヤー)
• 利点: アダプティブ ビットレート、信頼性が高く、広範囲のデバイスでのサポート
• 欠点: 低遅延よりもエクスペリエンスの質を優先
• 遅延 (レイテンシー): HLS は従来 6 ～ 30 秒の遅延で配信を提供していましたが、現在、低遅延 HLS 拡張機能が HLS の機能セットとして組み込まれており、2 秒未満の遅延を提供することが約束されている

UDP 対 TCP

ほとんどすべての HTTP アプリケーションは、伝送制御プロトコル (TCP) の上で実行されます。TCP は、信頼性が高く慎重にデータ転送を行うよう設計されたトランスポート レベルのプロトコルです。HTTP ベースの HLS プロトコルも同様に TCP 上で実行されます。これにより、UDP ベースのワークフローよりも高い品質が保証されます。

正確な配信が優先されるため、TCP の欠点の 1 つは速度です。しかし、HLS は、以下で説明する Low-Latency HLS (低遅延 HLS) 拡張機能によってこれを克服します。

コンテナ形式

MPEG-4 Part 14 (MP4) コンテナー形式を使用するほとんどの HTTP ベースのプロトコルとは異なり、HLS は当初、MPEG-2 トランスポート ストリーム (TS) コンテナー形式の使用を指定していました。 これは、Apple がフラグメント化された MP4 (fMP4) 形式のサポートを発表した 2016 年に変更されました。 現在、fMP4 は (MPEG-DASH および Microsoft Smooth Streaming を含む) すべての HTTP ベースのストリーミングで推奨される形式です。 これらのビデオ ファイルには、通常、AVC/H.264 でエンコードされたビデオと AAC でエンコードされたオーディオが含まれます。

エンコード要件

Apple は、HLS でストリーミングする場合のビット レート バリアントの典型的なセットの例として、以下のエンコード ターゲットを提供しています。 HLS ストリームの構成方法の詳細については、Apple の推奨事項 を確認してください。

HLS エンコード ターゲットの例 :

.M3U8 マニフェスト ファイル

HLS ビデオ セグメントは、ビデオ プレーヤーが (ストリームの) データの編成方法を理解できるように、メディア プレイリストの中でインデックス化されます。 マスター .m3u8 プレイリスト ファイルも作成する必要があります (これをインデックスのインデックスと考えてください)。これは、プレイヤーにバリアント固有のプレイリスト間で切り替える方法を指示するためです。 これは、マニフェスト ファイルとも呼ばれます。 ストリームを配信するには、.m3u8 を参照する URL を Web ページに埋め込むか、.m3u8 ファイルをダウンロードするアプリケーションを作成することで、コンテンツを配信できます。

訳注: バリアントは、この記事内では、レンディションとも呼ばれています。ビデオプレイヤーを実行するクライアントデバイスの接続ネットワークの帯域幅や処理能力に応じてレンディション固有のプレイリストを切り替えることで、ビデオプレイヤーが再生するレンディション (解像度やビットレート) を切り替え、アダプティブストリーミングを実現します。

セグメントのサイズとレイテンシ

HLS ライブ ストリームの遅延 (レイテンシ) はセグメントのサイズと密接に関連しており、通常は 10 ～ 45 秒の範囲内になります。

具体的には、次のようになります: HLS 経由で配信されるビデオ ストリームは、メディア サーバーでチャンク (訳注: セグメント) に分割されます。視聴者が再生をクリックすると、ビデオの再生が開始される前にデバイスがこれらのチャンクを 3 つ読み込む必要があります。セグメント化された配信により、プレーヤーは利用可能なリソースに応じて異なるレンディション間を切り替えることができ、同時に再生時のバッファリングやその他の再生の中断を減らすこともできます。

2016 年まで、Apple は HLS に 10 秒のセグメントを使用することを推奨していました。また、HLS の仕様では、再生を開始する前に 3 つのセグメントをロードする必要があるとしていました。 10 秒の推奨事項に従うと、(エンコーディング、トランスコーディングなどによって引き起こされるラグも考慮しないとしても) 30 秒の遅延から開始することになります。 Apple は最終的にデフォルトのセグメント サイズを 6 秒に減らしましたが、それでも “ライブ” ストリームがほぼ 20 秒遅れる可能性があることを意味していました。

訳注: 再生の開始前に、(セグメントサイズ x 3) の秒分のコンテンツがクライアントデバイスに配信されるのを待つことになるため、10秒セグメントの場合は 30秒の遅延、6秒セグメントの場合は 18秒の遅延が少なくとも発生する (エンド・ツー・エンドのライブワークフローの中のその他の遅延を考慮しなくても)

この遅延を減らす一般的な方法は、セグメントのサイズを小さくすることです。これは、低遅延の “チューニングされた” HLS と呼ばれます。チャンク (訳注: セグメント) が短いほど、ダウンロード時間が短縮され、速度が向上します。しかし、それだけが HLS による高速ストリーミングへの道ではありません。 2019 年、Apple は Apple Low-Latency HLS (低遅延 HLS) と呼ばれる拡張機能の仕様を発表しました。最近では、この拡張機能が機能セットとして包括的な HLS 標準に組み込まれています。 Low-Latency HLS は 3 秒以下の遅延を約束します。

訳注: 単純に セグメントサイズを 1秒やそれ以下に構成変更したとても、同じ時間のストリームのセグメントのリクエスト数が増えたり、プレイリスト (マニフェスト) のサイズが大きくなったりしますので、単純な方法では解決するわけではありませんでした。これらの点が、2019年に Apple が低遅延のために Low-Latency HLS という新しいアプローチを考案した背景になります。

Apple 低遅延 HLS (Low-latency HLS)

Apple は Low-Latency HLS 拡張機能を設計して、レイテンシを大幅に削減しました。この新しい Low-Latency HLS のプロトコルはもともと HTTP/2 PUSH 配信に依存するよう設計されていましたが、この要件は削除されました。さらに、Internet Engineering Task Force (IETF) は、最近、Low-Latency HLS 拡張機能を機能セットとして従来の HLS に組み込みました。これには 2 つの重要性があります。新しい技術をさらに標準化されるという点、および、技術を提供する企業が (標準仕様として) サポートを追加できるようにするという点です。

• 再生の互換性: 低遅延 HLS 用に最適化されていないプレーヤーは、標準 (高レイテンシ) HLS 動作にフォールバックできる
• 利点: 低遅延が HTTP ベースのストリーミングに対応
• 欠点: 新しい仕様として ベンダーはまだサポートを実装中
• 遅延 (レイテンシ): 3 秒以下

Apple Low-Latency HLS を Periscope が作成したオープンソースの Low-Latency HLS ソリューション (LHLS) と混同しないよう注意してください。 両者の技術の主な違いは配信方法にあります。 Apple の拡張機能とは異なり、Periscope が提唱する仕様では Chunked Transfer Encoding (チャンク転送エンコーディング) を使用します。(LHLS の提唱に関わった) ビデオ開発者コミュニティは、Apple の標準仕様を支持して、このオープンソースの代替手段を放棄しました。

昨年末、Wowza Streaming Engine ソフトウェアに Low-Latency HLS のサポートを追加しました。Wowza は、アーリー アダプターとして、この新しいテクノロジに対応する開発を続けており、製品ポートフォリオ全体にこのサポートを拡張するために取り組んでいます。

訳注: 本記事は 2022年の記事になります。

HLS の代替手段

ラストマイル配信の主な代替となるストリーミングプロトコルは、MPEG-DASH と WebRTC です。 DASH は機能的には HLS と非常に似ていますが、Apple デバイス全体でのサポートが不足しています。一方で、WebRTC はリアルタイム配信に関してはまったく別物であり、(配信規模の) スケールを考慮して設計されていません。

HLS と MPEG-DASH の比較

• 独自仕様と国際仕様: HLS は Apple 独自のものですが、MPEG-DASH は MPEG によって定義されたオープン スタンダードの仕様です
• 再生の互換性: HLS は Apple が業界全体に与える多大な影響力により、MPEG-DASH よりも広くサポートされています
• コーデック要件: HLS は特定のビデオ コーデック (H.265、H.265) と特定のオーディオ コーデック (詳細はこちら ) の使用を指定しますが、MPEG-DASH はコーデックに依存しません: これにより、より高度なコーデックが利用される場合、より低いビットレートでより高品質のブロードキャストが可能になります
• コンテナー形式: HLS は従来 MPEG-2 トランスポート ストリーム コンテナー形式 (.ts (MPEG-TS)) を使用してきましたが、MPEG-DASH は MP4 形式 (.mp4) を使用していました
• 遅延: どちらのプロトコルも配信遅延の点で伝統的に遅れをとっていましたが、新しいアプローチはこれを変えようとしています: MPEG-DASH の場合、これは Common Media Application Format (CMAF) の形式をとることで実現できますが、Apple は現在 Low-Latency HLS 拡張機能を提供します

訳注: Low-Latency MPEG-DASH では CMAF 形式のセグメントと Chunked Transfer Encoding (チャック転送エンコーディング) を活用することで低遅延でセグメントを転送することができます

HLS と WebRTC の比較

• 遅延: WebRTC ストリームは、低遅延 HLS をはるかに凌ぐ 500 ミリ秒という猛烈な速度でインターネット上で転送されます
• プロプライエタリ vs. オープンソース: HLS は Apple の独自技術ですが、WebRTC はオープンソースの技術です
• 再生の互換性: WebRTC はほとんどのブラウザーで機能するために追加のプラグインやソフトウェアを必要としませんが、HLS は多くのモバイル デバイスでより広くサポートされています
• スケーラビリティ: 配信規模ためのスケーラビリティは HLS の特徴ですが、WebRTC については同じことは言えません: Wowza のようなストリーミング プラットフォームがなければ、WebRTC は小さなチャットベースの環境に限定されます
• 品質: WebRTC では品質よりもリアルタイム配信が優先されます

HLS と RTMP の比較

• ファーストマイル vs. ラストマイル: RTMP は、入力のための技術として最も一般的に使用され、ビデオ ストリームをエンコーダからメディア サーバーに転送する際に利用されます。一方、HLS はエンドユーザー デバイスへの配信と再生に使用されます。
• 再生の互換性: HLS はマルチデバイスで十分にサポートされていますが、RTMP は iOS、Android、ほとんどのブラウザー、およびほとんどの埋め込み可能なプレーヤーでは受け入れられなくなりました
• 仕様開発の廃止: RTMP は Adob​​e によって更新またはサポートされなくなりましたが、Apple は HLS の開発を続けています
• アダプティブ ビットレート: RTMP はアダプティブ ビットレート ストリーミング用に設計されていません。そのため、アダプティブ ビットレート ストリーミングが一般的になると、すぐに HLS がその役割を引き継ぎました
• スケーラビリティ: HLS のような HTTP ベースのストリーミング プロトコルは通常の古い Web サーバーを使用することができますが、RTMP では専用のストリーミング サーバーを使用する必要があります
• 遅延: RTMP は常に HLS よりもはるかに速いビデオ配信速度 (訳注: 低い遅延) で配信することができます。とはいえ、Low-Latency HLS 拡張機能は、この遅延のギャップを埋めようとしています

HLS プロトコルを使用しないユースケース

Web 会議、カメラやドローンのリアルタイム デバイス制御、状況認識など、1 秒未満の配信が必要なユース ケースでは、WebRTC (Web Real-Time Communications) のようなプロトコルが必要です。 Apple Low-Latency HLS でさえ、これらのシナリオでは受け入れられない固有の遅延が発生します。

HLS プロトコルを使用するユースケース

HLS は現在、メディア ストリーミングで最も広く使用されているプロトコルであるため、大部分のブロードキャストにとって安全な方法です。インターネットに接続された (様々な) デバイスにストリーミングする場合は、少なくともこのプロトコルを考慮する必要があります。特に、品質が重要なライブ イベントやスポーツを放送する場合はそうです。遅延は考慮する価値がありますが、Apple Low-Latency HLS 機能セットのサポートが実装されると、2 秒未満の配信がより一般的になるはずです。これにより、インタラクティブ ストリーミング、オンライン ギャンブル、e-ゲームなどに適したものになります。

訳注: ギャンブルやインタラクティブストリーミングであっても、1秒以下の遅延が確実に必要となるシナリオでは、HLS が適さないケースもあります。詳細について、ご相談がありましたら、LiveInstantly 当社までご連絡ください。

モバイル デバイスにストリーミングする場合、HLS は必須です。携帯電話の世界で Apple iPhone が果たす役割を考えてみてください。多くのスマート TV、セットトップ ボックス、および、様々なプレーヤーもデフォルトで HLS に対応しているため、リビング ルームのエンドユーザーに向けて配信しようとする放送局 (ストリームサービス提供者) も HLS を検討する必要があります。そして、最後に、Flash への配信にまだ RTMP を使用しているサービスは、切り替える時が来ています。

とはいえ、可能な限り多くの視聴者にリーチするには、追加のビデオ フォーマット (訳注: ストリーミングプロトコル) に対応することから始めます。ストリームをさまざまな形式にトランスコードすることで、デバイスに関係なくビデオ配信のスケーラビリティを確保できます。

Wowza Video を使用すると、フル マネージド サービスを介してストリームをトランスコードおよび配信できます。または、Wowza Streaming Engine は、ストリーミング インフラストラクチャを企業内 (訳注: 企業のオンプレミスや企業のクラウドサブスクリプション内) に維持したい場合に適している可能性があります。

Wowza による HLS ストリーミング

統合されたビデオ プラットフォームを使用して、遅延を削減した HLS ストリームのブロードキャストを検討していますか？

Wowza Video があなたをサポートします。

メディア サーバーを使用して単純な RTMP から HLS へのワークフローの構成を検討していますか？

そのためには、Wowza Streaming Engine が最適な手段です。

HLS ストリーミングのニーズが何であれ、私たちは必ずソリューションを提供します。 Wowza を使用した HLS ストリーミングの詳細については、記事内のチュートリアルをご覧ください。

訳注: チュートリアルについては、オリジナルの記事内 のチュートリアルビデオを参照ください。詳細についてご不明点がございましたら、サポートいたしますのでご連絡ください。