CMAF とは?
この記事は、当社パートナーの Wowza Media Systems の記事 What Is CMAF? (Update) の翻訳記事です。この記事では、HLS ストリーミングプロトコルを詳しく説明します。
質の高い視聴体験を維持しながらビデオ配信の遅延を減らすという戦いは、適切に名付けられた Common Media Application Format (CMAF) の広範囲な採用につながってきました。 このプロトコルは、業界全体で効率化を進め、配信の遅延を短縮するための協調的な努力の成果です。 Apple の最近の提案がこの取り組みを覆す恐れがあるにもかかわらず、CMAF は、ストリーミング プロセスの単純化と高速化を求めるすべての人々にとって、依然として多くの可能性を秘めています。
訳注: 「Apple の最近の提案がこの取り組みを覆す恐れがあるにもかかわらず」は、低遅延 HLS の提案を意味すると考えられますが。低遅延という仕組みについては、この CMAF が想定しているものとは別のアプローチになりますが、Apple は HLS の CMAFフォーマット をサポートしています。
では、CMAF とは正確にはどのようなものであり、ストリーミングの改善にどのように役立つのでしょうか?
CMAFとは?
Common Media Application Format (CMAF) は、様々な形式の HTTP ベースのメディアをパッケージ化して配信するためのフォーマット規格で、比較的新しい仕様です。 この規格は、HLS プロトコルと MPEG-DASH プロトコルの両方でデータを統一されたトランスポート コンテナー ファイルにパッケージ化することにより、再生デバイスへのメディアの配信を単純化します。 また、チャンク エンコーディングとチャンク転送エンコーディングを使って遅延を低くします。 これにより、必要なストレージが削減され、ビデオの遅延によるビジネス損失のリスクが軽減されるため、ほとんどの企業でコストが削減されます。
CMAF 自体はプロトコルではなく、HLS や MPEG-DASH などのプロトコルで動作する単一のアプローチでビデオ ストリーミングを実現するコンテナであり、一連の標準規格である、ということに注目してください。 このように、CMAF ストリーミングの最大の成果は、ストリーミング市場全体を改善するための業界全体の取り組みを表すという点で、技術的というよりも政治的なものと言えるでしょう。
CMAFスナップショット
目的 | ビデオ ストリームに共通のメディア形式を使用することで、コスト、複雑さ、遅延を削減します |
目標 |
|
タイムライン |
|
CMAFが必要な理由
競合するコーデック、プロトコル、メディア形式、および、デバイスにより、すでに複雑となっているライブ ストリーミングの世界はますます複雑になっています。さらに頭痛の種になることは、様々なメディア形式を使用するとストリーミングの遅延とコストが増加することです。
ストリームのそれぞれのレンディションに対して単一のフォーマットで実現できることであるのに、代わりに同じコンテンツの複数のコピーを作成することをコンテンツ配信者に必要とさせているのです。言い換えれば、ストリーミング業界は、ビデオ配信を不必要に高価で遅延を増やしていると言えます。
.ts, .mp4, .wma, .mpeg, .mov などの様々なコンテナー ファイルの数だけでも膨大です。しかし、競合するテクノロジー プロバイダーがすべての再生プラットフォームで標準のストリーミング フォーマットで合意ができたらどうでしょうか? それが Common Media Application Format (CMAF) です。
CMAF は、単一アプローチのエンコーディング、パッケージング、および、ストレージの理想的な世界に私たちを近づけることができます。さらに、エンド・ツー・エンドの配信時間の遅延を 30 ~ 45 秒から 3 秒未満に短縮できるることが約束されています。
なぜ、どのように、どのくらい、CMAF によってこれらの利点が実現可能となるのでしょうか?
以下に詳細を説明しますので、引き続き、読み進めてください。
CMAF に至るまで
当時に戻ると、RTMP (Real-Time-Messaging Protocol) は、インターネット経由でビデオをストリーミングするための主要な方法でした。この独自プロトコルにより、ストリーミング ビデオ配信が可能になりましたが、ファイアウォールを経由して配信する場合に問題が発生しました。
多くのブラウザーが Flash のサポートを段階的に廃止し始めたため、業界はアダプティブ ビットレート ストリーミングを使った HTTP ベース (Hypertext Transfer Protocol) ベースの技術に移行しました。 Apple は、Apple HLS (HTTP Live Streaming) というアダプティブ ビットレート ストリーミングの形をとりました。一方、MPEG-DASH (Dynamic Adaptive Streaming over HTTP) は、アダプティブ ビットレート ストリーミングの国際標準として確立しました。
しかし、ストリーミングのプロトコルが異なれば、ファイル コンテナーも異なります。 HLS は .ts 形式の使用を指定しますが、MPEG-DASH は ISOBMFF 仕様に基づく .mp4 コンテナーをほぼ一様に使用します。
訳注: ISOBMFF = ISO Base Media File Format: MPEG-4 Part 12 (ISO/IEC 14496-12) で規定されている仕様
多くの略語があり (混乱するかもしれませんが)、ここで重要なのは、テクノロジー プロバイダーがそれぞれのストリーミングのために個別のコンテナーをサポートしていることです。これは、現在利用されている無数のデバイスでの再生に影響を与えます。
具体的にどんな問題でしょうか? Apple デバイスと Microsoft デバイスの両方のエンドユーザーに配信したいコンテンツ配信者は、同じオーディオ データとビデオ データを 2 回エンコードして保存する必要があります。実際に、ユーザーは iPhone, スマート TV, Xbox、PC のストリームにアクセスしているため、この問題は明らかでした。
Akamai の言葉 を借りれば:
これらの重複するファイルは、同じコンテンツを表しているにもかかわらず、パッケージ化に 2 倍のコストがかかり、オリジンのストレージに保存するのに 2 倍のコストがかかり、Akamai エッジ キャッシュでキャッシングスペースをめぐって互いに競合するため、(本来) 効率的に配信可能であるコンテンツの配信効率を低下させます (以下注)
(注): 重複するストレージとエンコードのコストの解決手段として Streaming Media がWowza を推奨している ことに注目してください:
Wowza Streaming Engine のような製品 […] を使用して、コンテンツを MP4 ファイルから DASH, HLS, Smooth Streaming 形式に動的にパッケージ化することで、ストレージとエンコードのコストの増加を回避できます
CMAFの登場
CMAFは企業間のコラボレーションから生まれました。 2016 年 2 月、Apple と Microsoft は、Moving Pictures Expert Group (MPEG) に提案を持ちかけました。 Common Media Application Format (CMAF) と呼ばれる新しい標準を確立することで、彼ら 2 つの組織が協力してビデオをオンラインで配信する際の複雑さを軽減するであろうことを意味しました。
この活動のプレイヤーとなる企業は、素早い対応で動きました。 Apple は、2016 年 6 月 15 日に、断片化された MP4 のサポートを HLS に追加すると発表しました。これは、Apple がビデオ ストリームに .mp4 配信を使用できるようにすることを意味しました。これは、Microsoft が既に使用しているまさにそのコンテナーです。
2017 年 7 月までに、共同開発者は CMAF の仕様を最終決定し、そして、2018 年 1 月に標準が公開されました。
ビデオ配信のための単一のコンテナーでエンコード、パッケージ化、および、キャッシングすることの利点は言うまでもありません。しかし、CMAF は複雑さを軽減するだけではありません。何年も前に RTMP から手を引いた後でも、HTTP ベースのビデオ配信には、視聴者が要求するリアルタイム配信オプションがまだありません。
CMAF も配信遅延をも改善できるのでしょうか? チャンク エンコーディングとチャンク転送エンコーディングにより、新しい仕様はまさに遅延の削減を行うように設計されました。
CMAFの仕組み
単一フォーマット:
CMAF 仕様が確立する以前は、Apple の HLS プロトコルは MPEG トランスポート ストリーム コンテナ フォーマット、つまり .ts (MPEG-TS) を使用していました。 MPEG-DASH などの他の HTTP ベースのプロトコルは、断片化された MP4 形式、つまり .mp4 (fMP4) を使用していました。
Microsoft と Apple は、現在、標準化されたトランスポート コンテナー (断片化された MP4 の形式の ISOBMFF) を使用して、HLS および MPEG-DASH プロトコル全体で視聴者に配信することで合意しています。理論的には、これは、コンテンツ配信者が .mp4 コンテナーのみを使用してコンテンツを配信できることを意味します。
チャンク エンコーディング:
CMAF ストリーミングとは、チャンク エンコーディングとチャンク転送エンコーディングを使用して遅延を短縮するために、業界全体で相互に調整された取り組みを表します。このプロセスでは、ビデオをある設定された長さの小さなチャンクに分割し、エンコードが完了するとすぐに公開できるようにします。そうすれば、後のチャンクがまだエンコード処理されている間でも (その前にエンコード済みの) チャンクの配信を行うことができます。一度にすべてが来るのではなく、コースで食事をするようなものだと考えてください。すべての食事のプレートが “バッファリング” されるまで (訳注: 準備されるまで) 空腹で待つのではなく、キッチンで次のコースを準備している間、おいしい前菜を楽しむことができます。
ファイルの暗号化とデジタル著作権管理:
CMAF が対処しようとしていた様々なメディア形式の問題と同様に、業界全体に別の非互換性が存在します。それは、デジタル著作権管理 (DRM) とファイル暗号化です。複数の DRM (FairPlay、PlayReady、および Widevine) をサポートすることは、非互換の暗号化モードもサポートすることを意味します。
業界の関係者は、現在、共通暗号化 (CENC) と呼ばれるこの分野の標準を CMAF に適用することに合意していますが、標準化は一夜にして実現できるものではないことにも注意する必要があります。
CMAFとHLS
CMAF と HLS ストリーミングの違いを探る前に、まず HLS と低遅延 HLS について説明する必要があります。低遅延 HLS は CMAF の出現後に Apple によって開発されたものであり、CMAF が業界全体の標準になるという仮定に異議を唱えているようです。
訳注: Apple がフォーマットとしての CMAF には異議を唱えているようには見えませんが、CMAF フォーマットが想定する低遅延ストリーミングの方式には異議を唱えているように見えます。
HLS (HTTP ライブ ストリーミング) は Apple ベースのプロトコルであり、歴史的に遅延の問題よりもストリームの信頼性を優先しており、約 5 ~ 20 秒の遅延で配信することができます。 これは、iPhone のライブ ストリーミング再生の問題に対する Apple の答えであり、最小限のバッファリングで視聴者のエクスペリエンスを改善することに成功しました。 CMAF は “cbcs” または “cenc” で暗号化されたプレゼンテーション プロファイルの HLS と連携できます。暗号化されていない 3 番目のプレゼンテーション プロファイルはサポートされていません。
低遅延 HLS (Low-Latency HLS) は、遅延を大幅に削減する HLS のプロトコル拡張であり、CMAF と同じニーズの多くに対応します。(HLS が)遅延を削減するための取り組みとして CMAF フォーマットを既に対応していたのに、なぜ Apple が HLS ストリーミング プロトコルを拡張する必要性を感じたのかは少し謎であり、Apple が CMAF の標準化の取り組みにどれだけコミットしているか疑問に思う人もいるでしょう。
これらすべてを念頭に置いて、HLS を使用する場合のオプションは 3 つあります:
- 高い信頼性と遅延を兼ね備えた従来の HLS
- 遅延を改善するための低遅延 HLS (Low-Latency HLS) プロトコル拡張を使用した HLS
- 遅延を改善しコンテナー ファイルを標準化する CMAF 形式の HLS
どれくらいの遅延の違いがあるのでしょうか?
低遅延 HLS と CMAF の範囲は少し異なります。 通常、低遅延 HLS は約 2 ~ 8 秒の遅延で配信が実行されます。 CMAF は約 2 ~ 5 秒の遅延で配信が実行されると言われています。 いずれにせよ、これらはかなり互角です。ただし、CMAF には、標準化されたコンテナー ファイル (.fmp4) という追加の利点があり、これが広く採用されることで、すべてのストレージ コストが削減されます。
CMAFとRTMP
RTMP (Real-Time Messaging Protocol) は、もともと Adobe の Flash プレーヤーと連携するために Macromedia によって開発され、ストリーミング テクノロジの最前線に位置付けられていました。しかし、その後、HTTP ベースの技術が支持され、脇に追いやられました。
確かに、RTMP は引き続き使用できますが、ビデオの入力取り込みとしてのみ機能し、実際にビデオの再生のためのオプションではなくなりました。また、より高品質の視聴体験のためにスケーラブルにする最新の技術の最適化も不足しています。
とはいえ、約 5 秒のレイテンシーで、様々な企業がこのプロトコルを利用して、迅速かつ確実にストリーミングを実現してきました。
CMAF と WebRTC
では、CMAF とは反対側にある最先端の WebRTC (Web Real-Time Communications) プロトコルを見てみましょう。 これは利用可能なオプションの中の最速のライブ ストリーミング オプションであり、簡単に使うことができます。 CMAF ストリーミングを低遅延と呼ぶ場合、WebRTC は 1 秒未満のレイテンシーの超低遅延 (ULL = Ultra Low Layency) と呼ぶことができます。また、WebRTC は、様々なネットワーク要件に簡単に適応でき、フリーで使うことができます。
では、WebRTC の利点をどのように達成するのでしょうか? WebRTC は、プラグインを必要とせずに、ブラウザーとデバイス間のリアルタイムの音声、テキスト、ビデオによる通信を追加することができます。 とはいえ、WebRTC は、ビデオ会議用に特別に設計されているため、簡単に大規模な視聴者に向けた配信のために拡張することはできません。 ここで、Wowza のようなストリーミング プラットフォームが役に立ちます。 Wowza の大規模向けのリアルタイム ストリーミング ソリューションは、機能的には、スケーリングをサポートするワークフローを備えた WebRTC です。
CMAF まとめ
配信の遅延と複数のメディア ファイル タイプのストレージに関連するコストを削減する最も簡単な方法の 1 つは、ビデオ配信を単純化することです。 CMAF の目標は 3 つでした。
- コスト削減
- ワークフローの複雑さを最小化
- 遅延を短縮
これらは達成されるでしょうか? おそらくそうでしょう。
CMAF は、ほとんどのエンドポイントにサービスを提供するためのサーバー効率を最適化するでしょう。また、最近のデモでは、この新しい代替手段によって 3 秒未満の遅延を実現することができています。
とはいえ、アップグレードされていない従来のデバイスとブラウザーでは、再生のために独自のコンテナー ファイルが引き続き必要になります。別の言い方をすれば、可能な限り視聴者に配信し続けるには、CMAF がさかのぼって対処できないことに対する追加の調整 (およびコスト) が必要となります。
そこで Wowza の出番です。Wowza Streaming Engine は、MPEG-TS, Apple HLS, Adobe FTMP など、様々なフォーマットでのビデオ配信をサポートしています。CMAF 準拠デバイスの普及が拡大し続けているので、これによりビデオのスケーラビリティが保証されます。さらに、Wowza Streaming Engine は CMAF ストリーミングをサポートするようになり、ロードマップでは低遅延の最適化が行われる予定です。
また、簡単に利用できる CMS へのアクセスを含む、最適化されたソリューションをお探しの場合は、新しく改善された Wowza ビデオ ストリーミング プラットフォームをお試しください。