低遅延 HLS とは？ そして CMAF との関連は？

パートナー記事 post
By Traci Ruether @ Wowza
カテゴリ:
パートナー:
タグ:
8分で読めます(目安)

この記事は、当社パートナーの Wowza Media Systems の記事 Update: What is Low-Latency HLS and How Does It Relate to CMAF の翻訳記事です。この記事では、Apple の低遅延 HLS (Low-Latency HLS) を詳しく説明します。

注意: このブログ記事の投稿の以降に、低遅延 HLS (Low-Latency HLS) 仕様は、包括的で重要となっている HLS 標準に組み込まれています。詳細については、仕様のアップデートに関するブログ記事 をご覧ください。

昨年の (訳注: 2019年の) Worldwide Developer Conference (WWDC) で、Roger Pantos は HTTP ライブ ストリーミング (HLS) プロトコルのまったく新しい拡張のための仕様を発表 しました。それが 低遅延 HLS (Low-Latency HLS) です。この仕様では、大規模の配信で 2 秒未満の遅延を実現することが約束される一方で、既存のクライアントとの下位互換性も提供も約束されました。

業界ではいくつかの理由で注目を集めました。 HLS の拡張として、低遅延 HLS (Low-Latency HLS) の普及が想定されました。それは、HLS が結局のところ現在最も一般的に使用されているプロトコルだからです (2019 年のビデオ ストリーミング レイテンシ レポート では、コンテンツ配信者の 45% 以上が HLS を採用しています)。

しかし、ベンダーが低遅延 HLS (Low-Latency HLS) のサポートをどれくらい早く実装できるかは不明のまま残りました。 その 1 つには、Apple の発表により、CMAF のチャンク転送エンコーディングによって遅延を削減するという業界全体の取り組みが中断された点です。また、低遅延 HLS (Low-Latency HLS) が、多くのコンテンツ配信ネットワーク (CDN) がまだ提供できていない HTTP/2 PUSH を必要とするという点でした。

そして、騒動はそれだけではありませんでした。この拡張機能が大規模配信で(適切に)機能するかどうか疑問を持っている人もいました 。さらに、この技術を実際に実装する前に、Apple には解決すべきいくつかの問題があるという明確な意見の一致がありました。

低遅延 HLS の最新の更新

訳注: この記事は 2020年の記事になります

低遅延 HLS (または LL-HLS) は、当初からすでに大幅に進化しています。 HLS メーリング リストで通知されたように、Apple は数週間前に HTTP/2 PUSH 要件を削除しました。その代わりに、この拡張機能は短いメディア チャンクと #EXT-X-PRELOAD-HINT という新しいタグを使用するようになりました。この変更は、仕様がまだどれだけ流動的であるかを反映しています。

THEOplayer の私たちの友人たちは次のように説明しています :

低遅延 HLS ストリームを公開するサーバーは、このタグを使用して利用可能になる次のメディア データの最も可能性の高い場所を通知する必要があります。これにより、プレーヤー クライアントはセグメントの次の部分のリクエストを実行できるようになり、その結果、セグメントの次の部分が利用可能になるとすぐにデータをプレイヤーのバッファに入れることができるようになります。そして、このプロセスを繰り返すことで、新しいメディア データをロードする際に追加の往復時間を削減することができます (元々、この往復時間の削減が HTTP/2 PUSH を使用する主な理由でした)。

Apple が最初に低遅延 HLS を発表したときのもう 1 つの大きな懸念は、MPEG-DASH の低遅延 CMAF との相互運用性の欠如でした。この更新によって、LL-HLS がチャンク転送のアプローチを模倣できるようになり、いくつかの障害が取り除かれました。 低遅延 HLS とMPEG-DASH の低遅延 CMAF の間の互換性の向上は、複雑さを解消し、CDN のキャッシュ効率を向上させるのに役立つはずです。

この開発のインパクトをさらに明らかにするために、低遅延 HLS について最初から振り返ってみましょう。

CMAF と低遅延への競争

かつて Apple と Microsoft の両方のデバイスを利用するユーザーに配信したいコンテンツ配信者は、同じコンテンツのオーディオ データとビデオ データを 2 回エンコードしてストレージに保存する必要がありました。これは、Apple の HTTP ライブ ストリーミング (HLS) プロトコルが .ts 形式の使用するのに対して、HTTP の動的アダプティブ ストリーミング (DASH) は、たいていの場合 .mp4 コンテナーを使用するためです。

これは、電話やコンピューターの充電器のようなものだと考えてください。 Android と iPhone は同じ充電器を使用していないため、すでにコードだらけの世界の中で必要以上の充電コードが必要になります。 Apple は独自のポートに独自のケーブルを使用しているため、ユーザーは充電器を紛失するたびに Apple Store に行くことになります。 HLS プロトコルは、Apple の仕様をサポートするデバイスにストリーミングするための独自の充電器のようなものでした。一方、MPEG-DASH は、他のデバイスへの配信にも機能しました。

奇跡的に、Microsoft と Apple は、Common Media Application Format (CMAF) と呼ばれる新しい標準を発表することで、すべてを単純化することができました。この仕様では、HLS と MPEG-DASH の両方で参照できる断片化された .mp4 コンテナーを使用します。

CMAFへの移行

これは素晴らしいニュースでした。 コンテンツ配信者は、同じデータを 2 回エンコードしてストレージに保存するという必要がなくなりました。 単一の形式は、コンテンツの配信者の費用を節約し、ビデオ配信を最適化することができます。

複雑さを解決するだけでなく、業界全体のベンダーが協力して、チャンク エンコーディングとチャンク転送エンコーディングを使用して HTTP ベースのストリーミングの遅延を短縮しはじめました。 この技術を活用することで、CMAF を使用して 3 秒未満のビデオ配信を可能にすることができるでしょう。

遅延を短縮するための業界全体の取り組み

Wowza では、低遅延 CMAF のサポートに取り組みました。 Akamai , THEOPlayer , Fastly やその他の企業で構成されたチームは、同じ目標に向かって真剣に取り組んでいました。この低遅延 CMAF が機能するためには、ストリーミング エコシステム全体の各ベンダーがそれぞれの製品を最適化する必要があったため、このことは重要でした。低遅延の CMAF への早期アクセスにサインアップするようお客様を招待し、チャンク転送エンコーディングを使用して Apple と Microsoft の両方のデバイスにストリームを配信できる可能性に興奮しました。

Apple はこの業界の取り組みに対してコミットしていませんでしたが、コミュニティは熱狂的になっていました。 Periscope は、この技術を使用して開発したオープンソースの Low-Latency HLS (LHLS) 標準に関する記事を投稿しました 。Akamai の Will Law は、チャンク エンコードおよびチャンク転送 CMAF に多くの時間を費やしました。私たち Wowza のエンジニアは彼と一緒に座って、それがストリーミング業界にどのような影響を与えるかについて話し合っていました。

その後、Apple は Low-Latency HLS を発表しました 。

低遅延 CMAF と Apple 低遅延 HLS の比較

WWDC19 まで、ストリーミング コミュニティは、チャンク転送エンコーディングを使用して低遅延の CMAF を推進していました。 WWDC19 の Apple の発表では、HLS のための異なる低遅延の技術をサポートするであろうことが明らかになりました。低遅延 CMAF と Apple 独自の仕様との主な違いの 1 つは、HTTP/2 PUSH の使用でした。

この Apple の動きを支援するために、Wowza は Apple によって定義された 低遅延 HLS (Low-Latency HLS) のサポートを追加することにしました。昨年 11 月までに、我々 Wowza のお客様は Wowza Streaming Engine 4.7.8 リリースを使用して、Apple 独自の低遅延 HLS ワークフローの構築を開始できるようになりました。

ただし、大規模で高速な (訳注: 低遅延の) ビデオ配信は、(Wowza ソリューションだけが) 孤立した状態では実現できません。ワークフロー全体をまたぐ様々なベンダーがこの仕様を機能させるためにサポートする必要がありました。そして、前述の通り、HTTP/2 PUSH 機能は、ほとんどの CDN にとって依然として課題となっていました。

HTTP/2 PUSH 要件の削除

Apple による低遅延 HLS 仕様の改訂には、実装の先頭でリードしている組織がこの変更に適応する必要があります。とはいえ、HTTP/2 PUSH の削除により、この仕様の採用は簡単になるはずです。

私たちは、CDN やプレーヤーとの統合を通じて、低遅延 HLS の大規模な展開をサポートすることに引き続き取り組んでいます。そして、進化する仕様に合わせて開発を続けます。

今後も進化するであろう仕様をキャッチアップし続けますが、現時点での低遅延 HLS のスナップショットを以下に示します。

Apple 低遅延 HLS: スナップショット

Apple は、この拡張機能を設計して、大規模な配信での遅延を削減しました。プロトコルはもともと HTTP/2 PUSH 配信機能に依存していましたが、この要件は削除されました。代わりにこの拡張機能は短いメディア チャンクと #EXT-X-PRELOAD-HINT という新しいタグを使用します。

  • 再生の互換性: 低遅延 HLS 用に最適化されていないプレーヤーは、(高い遅延の)標準 HLS 動作にフォールバックできます。 HLS 互換デバイスには、MacOS, Microsoft, Android, および Linux デバイスが含まれます、そして、すべての Google Chrome ブラウザー、いくつかのセットトップ ボックス、スマート TV、およびその他のプレーヤーが含まれます。
  • 利点: 大規模配信時の低遅延と下位互換性。
  • 欠点: 新しい仕様として、ベンダーはまだこの機能のサポートを実装しており、まだ仕様の要件は流動的なままです
  • レイテンシ: 2 秒以下

注意: このブログ記事の投稿の以降に、低遅延 HLS (Low-Latency HLS) 仕様は、包括的で重要となっている HLS 標準に組み込まれています。詳細については、仕様のアップデートに関するブログ記事 をご覧ください。

訳注: 2022年現在では、Apple の低遅延 HLS の仕様は以前よりも固まってきていますが、HLS RFC仕様の第2版はまだドラフト仕様のままです。