CMAF と CMAFを使用した低遅延 LIVE 配信の実現

こんにちは。Akamai Solutions Engineer の Yuhki です。

今回は、最近だんだんと耳にするようになってきた HTTPストリーンミングの規格である CMAF (Common Media Application Format) について、簡単ではありますが、ご説明させて頂きます。

CMAF(Common Media Application Format)とは

2018年時点の HTTP Streaming の世界では、2017年に IETFでRFCとして承認されたApple が主導するHLS (HTTP Live Streaming) と、ISO国際標準規格である MPEG-DASH(Dynamic Adaptive Streaming over HTTP)という2つのメディアコンテナファイルのフォーマットが主に使われるようになっています。

より多くのユーザーにリーチしたいコンテンツの提供者は、それぞれの規格用にエンコードを行い、それぞれをストレージに保管する必要があります。複数のフォーマットに対応しなければいけないという事は、ファイルの変換コストと変換をしたメディアコンテナファイルを保管するコストを必要とするため、ストリーミング配信の複雑さと高コスト化の大きな要因となっています。

これらのメディアコンテナファイルのフォーマットの複雑さを解決するために、Apple と Microsoft は、CMAF(Common Media Application Format) と呼ばれる共通の規格の策定をMPEGに提出し、2018年1月にISO/IEC 23000-19:2018として正式に発行されました[1]。

CMAF では、マニフェストファイル自体は定義しておらず、普段目にしている mpd (MPEG-DASH) や m3u8  (HLS)と言ったマニフェストファイルが無くなるわけではありません。CMAF では、暗号化や、複数 Bitrate配信のためのリファレンスモデルが定義されており、ISO BMFF(ISO Base Media File Format) をメディアコンテナファイルのフォーマットとして使用する事が定義されています。ISO BMFFの現実の実装としては fragmented MP4 (fMP4)が広く使われています。

MPEG-DASHが抱合する規格の範囲はとても広く、正確に言うと MEPG2-TS もサポートしていますが、実際に使われているのは ISO BMFF (fragmented MP4) です。そのため、fragmented MP4が MPEG-DASHで用いられるほぼ唯一のフォーマットになっています。一方でHLSは、もともと MPEG2-TS と呼ばれるフォーマットをそのメディアコンテナファイルとして使用しており、現在でも主流は MPEG2-TSです。残念ながら MPEG2-TS は、CMAFで定義されているものではありません。

元々CMAF は、AppleとMicrosoft が提出した規格でもあり、Apple も 2016年6月のWWDC(Worldwide Developers Conference)で、HLS においてもfragmented MP4 をサポートする事を発表しました[2]。これにより、iOS10, macOS, tvOS では fragmented MP4が使用できるようになりました。

HLSがfragmented MP4に対応した事で、fragmented MP4という共通のメディアコンテナファイルに対して、HLS用とDASH用のマニフェストをファイルをそれぞれに作成する事で、両方のストリーミング型式を配信できるようになります。

また、HLS でサポートされているMPEG2-TSは、H.264やAACを格納する事が前提になっていますが、fragmented MP4ではH.264よりも圧縮効率の高いHEVC/H.265をサポートしています。こう言った背景もあり、今後、HLSでも新規の案件では TSファイルよりも fragmented MP4の使用が増えていくと考えられます。また、MPEG2-TS が新規に HEVC/H.265をサポートするとは考えにくく、実際、HLSでのH.265/HEVC 対応は、framgenented MP4 のみとされています[3]。

DASHとHLSのメディアコンテナファイルを共通化する事によって、コンテンツ事業者には以下のようなメリットがあります。

• Encoding のためのコストの半減
• メディアを保管するストレージコストの半減
• CDNのキャッシュ効率化

CENC (Common Encryption: 共通暗号化)

 DRMの規格には、Widevine (Google)、FairPlay(Apple)、PlayReady(Microsoft) 等の複数な規格が存在しています。

これらのDRM規格では、Media ファイルは AES-128で暗号化される事が想定されていますが、AES-128のモードには、CTR(Counter) モードと、CBC(Cipher Block Chaining)モードがあり、同じAES-128でも異なるモードで暗号化した場合、別のファイルが生成される事になります。

CMAFでは、CENC(Common Encryption) [4] を使うように決められてはいますが、CENC の定義では、AES-CTR と AES-CBC のどちらも使う事ができます。
そのため、ISO BMFF(fragmented MP4)にフォーマットが統一される事で、メディアコンテナファイルに関しては統一が可能になったものの、DRM方式がバラバラのケースでは、暗号化した時点で別のファイルとして取り扱う必要があります。現時点では一般的なＯＳやデバイスをカバーした形でDRMコンテンツを配信するには、どうしても複数のDRMを使用する事が避けられない状況にあります。

 FairPlay では、AES-CBC モードしかサポートしておらず、DRM毎にサポートしている暗号化モードは、異なっていましたが、2017年9月に、Microsoft が PlayReady 4.0 から、AES-CBC をサポートする事が発表されました[5]。

現在の流れ的には、AES-128 CBC modeに暗号化を統一できそうな兆しが見えてきました。もちろん、現状でもDRMのバージョン等やサポートするデバイスの違いによる複雑さがあったり、そもそも メディアコンテナ内で使われているcodec に H.264 と H.265/HEVC の違いがあればファイルも別になります。ですが、より簡単なDRMへの一歩である事は間違いないでしょう。

CMAF を使った Live配信の低遅延化

HTTP ベースの ストリーミング配信技術である HDS, Smooth Streaming, HLS, MPEG-DASH 等のLive配信などでの遅延は、現在一般的に 10秒～60秒ほどの遅延で配信されているのが現状だと思います。

HTTPリクエストに対するレスポンスで動画データを返すという仕組み上、動画セグメントのダウンロードが完了してから動画の再生をする事になります。動画セグメントのサイズが10秒分の動画であれば、カメラからネットワークの間に何も遅延がなくても、10秒の遅れが生じます。また、通常、動画再生Player は幾つかの動画セグメントを、動画が途切れないように数個ため込んでから再生するようにするため、「(動画セグメント(s)) x (バッファーで貯めておく動画セグメント数)」だけ Live 配信に遅延が生じます。

そのため、遅延がクリティカルなLive動画の再生では、HLS や MPEG-DASH 等を使わずに、RTMP通信(Flash) をそのまま使い続けたり、最近では WebRTCを使用した低遅延配信なども行われてきています。

一方で、HTTP通信をベースにした動画の配信は、汎用的な Web Server が使用でき、データはファイルベースで処理されます。生成された動画ファイルをCDNの様な負荷分散用のサーバーにキャッシュし、そこから配信する事で規模を拡張する事が容易であり、大規模配信に本質的に向いている技術です。そのため、既存のHTTP Streaming 技術を改良して低遅延を実現しようという動きも進んできています。

HTTP Streaming におけるLive配信の遅延はセグメントのサイズから来ているため、基本的にセグメントのサイズを小さくする事と再生するPlayer側に持たせるバッファーサイズを小さくする事で遅延を減らす事ができます。(動画 Player のバッファーサイズを減らす事により、ネットワーク帯域の不安定さの影響を受けやすくなるので、この点に関してはトレードオフになります)

一方で単純に小さなファイルのリクエストをHTTPレベルで行うと、細かなファイルサイズになる事で、Live配信のワークフローの各部分における負荷が増える事になります。例えば各動画セグメントは何らかの形でCDN等のディスクにキャッシュされますので、セグメントサイズが小さくなる事でディスクのI/Oが増大する事が予想されます。また、一つのHTTPヘッダーに対するデータのペイロードのサイズも小さくなりますので、転送効率の点から言っても望ましい方向性ではありません。

CMAFでは低遅延 Live を実現するために、"chunk" という概念が導入されています。CMAF を使用した低遅延 Live 配信では、大きく2つの技術を同時に使う事が想定されています。

･セグメントの中に "chunk" と呼ばれるより細かい単位を定義する (CMAF)
･HTTPの "Chunked Transfer Encoding" を使用して、セグメントのファイルが Encoder から全て Ingest される前に、セグメント内の chunk を Player 側で再生する (HTTP1.1）

 CMAF を使った Live 配信では、動画のセグメントのファイルとしてのサイズは一般的な HTTP Streaming 配信で使用されるようなサイズに保ちながら、内部に chunk という形でデータを区切ったものを定義します。
Encoder 側は、セグメントが書き終わる前に次々と Chunkデータを Ingest Server に送信し、一方でPlayer 側はセグメントの全体のダウンロードが完了する前に受け取ったデータを次々に再生していきます。この際、セグメントデータのやりとりは、"Chunked Transfer Encoding"を使用して行われます。この方式は、HTTP1.1で定義された、現在でも広く用いられている方式ですが、一度のHTTP リクエストで送信されるデータを「データ + 送信データサイズ」の型式で、受信側に通知しながら、少しづつデータを送信する方法です。

chunk のサイズに決まったものは無く、どこまでも小さくできるので、理論的には動画のセグメントファイルのサイズに縛られていた Live Latency をぎりぎりまで縮める事が可能です。

一方で、現時点ではCMAFを使用したLow Lalentcy を行うには、2つのハードルがあります。一つは CMAFに対応している Encoder が少ない事、もう一つは、Low Latencyの再生を実現できるPlayerが少ない事です[7]。Chunked Transfer Encoding 自体は、古くからある技術ですが、ダウンロード途中の chunk を再生させるには、セグメントのダウンロードが完了する前にChunked Transfer で受け取ったデータを Player の buffer に非同期に追加していく必要があります。現時点では fetch 関数[6]を使用して、HTTPリクエストが完了する前の Chunked Transfer Encoding を取得したデータを Player で再生していく事は技術的には可能ですが、そのような安定した Playerが出回るまで暫く時間が必要そうです。

 まとめ

CMAF や CMAF を使った Low Latency 技術により、フォーマットの統一による大幅なコスト削減と、これまで実現が難しかったCDNを使用した大規模な低遅延 Live が目前にまで迫ってきています。また、Low Latency な配信は同時に少ないバッファイサイズを意味し、動画の再生を不安定にしやすくなりますが、HTTP Streaming 技術の特徴であるABR(Adaptive Bit Rate) や、QUICを使った UDP配信[8][9]を組み合わせていく事で、品質の高い配信を実現できる可能性を秘めていると思われます。

参考リンク

[1] https://www.iso.org/standard/71975.html:ISO/IEC 23000-19:2018 Information technology -- Multimedia application format (MPEG-A) -- Part 19: Common media application format (CMAF) for segmented media
[2] https://developer.apple.com/videos/play/wwdc2016/504/:WWDC:2016 What's New in HTTP Live Streaming
[3] https://developer.apple.com/videos/play/wwdc2017/504/:WWDC:2017 Advances in HTTP Live Streaming
[4] https://www.iso.org/standard/68042.html : ISO/IEC 23001-7:2016 Information technology -- MPEG systems technologies -- Part 7: Common encryption in ISO base media file format files
[5] https://www.microsoft.com/playready/newsroom/ : Microsoft PlayReady News
[6] https://caniuse.com/#search=fetch  caniuse.com
[7] 記事作製時点で Akamai が行っている CMAF Ultra Low Latency のデモは、Encoderベンダーの試作品や、プロトタイプの Player 等を使用して行われています。
[8] https://blogs.akamai.com/jp/2017/05/udpquic---akamai-media-acceleration.html UDP/QUICを使用した高速化 - AKAMAI MEDIA ACCELERATION [9] https://blogs.akamai.com/jp/2017/12/quicakamai-media-acceleration.html  通信品質が悪い環境におけるQUIC（AKAMAI MEDIA ACCELERATION）の有用性について