はじめに
動画配信事業部・配信基盤チーム所属の丸山です。
「進化する動画配信基盤」についての連載第２回目となるこの記事では、 DMM Player v2 を成し遂げるための CMAF について記載します。
目次記事はこちらです。https://inside.dmm-corp.com/articles/02/04/evolving_content_delivery_platform_00
CMAF とは
ISO/IEC 23000-19 Common Media Application Format
動画配信の数あるデファクトスタンダードの最大公約数的な仕様を共通規格として括ったもので、
- コンテナ
- コーデック
- エンコードプロファイル
- 暗号化方式
- DRM ベンダー固有情報の格納方法
- アダプティブビットレートがスムーズに切り替わるための仕様
これらの既存の ISO 規格のサブセットを定義しています。新しく追加された仕様はほぼありません。
これまでの配信技術 (～2016)
再生環境 (デバイス、OS、プレイヤー) や配信形態によって規格が異なるため、
1 つの作品を複数の形式にエンコード・パッケージングする必要がありました。
| コーデック | コンテナ | 暗号化方式 | 配信形態 | 再生環境 |
|---|---|---|---|---|
| VC-1, WMA | ASF (wmv) | Cocktail, AES-CTR | ダウンロード | PC |
| H.264, AAC | PIFF (ismv) | AES-CTR | ストリーミング | PC, TV |
| H.264, AAC | MPEG-2 TS | AES-CBC | ストリーミング | スマートフォン, PC |
| H.264, AAC | ISOBMFF (mp4) | WebStream DRM | ダウンロード | スマートフォン |
これでは各形式ごとにエンコード・ストレージ・配信サーバーコストがかかり、非効率的です。
また、それぞれのコーデックやコンテナなどの規格で定義されている仕様にはかなり幅があるため、現実の再生環境では規格に準拠していても再生できないファイルが時々見つかることもあり、開発・検証コストも予測しにくい形で嵩んでしまいます。
消えゆくもの
WMV の終焉
2021 年秋、Silverlight のサポート終了によって Windows 10 以外のデバイスで WMV を再生する手段を失ってしまうため、MP4 などの広くサポートされているフォーマットに置き換える必要がありました。
しかし、いわゆる MP4 と呼ばれているコンテナは単一の規格ではなく、仕様が複雑で多岐に渡るためより多くの環境に対応させるにはトライ＆エラーしかなく、2016 ～ 2018 年は試行錯誤の連続でした。
業界の動向を追う
暗号化仕様の規格化
ISO/IEC 23001-7 Common Encryption (CENC)
調査を進めるなか、DRM の中核となる暗号化処理については ISO 規格として定義されました。
ファイル暗号化には標準規格の AES が採用され、復号化のための鍵のやり取りを各 DRM ベンダーが担うこととなり、マルチ DRM が実現できるようベンダー固有情報の複数格納が可能になりました。
しかし、選択できる暗号化方式は複数あり、まだファイル形式の完全統一には至りませんでした。
| 暗号化方式 | 対応環境 |
|---|---|
| AES-CTR | Windows, Android, Xbox, PlayStation, etc |
| AES-CBC | macOS, iOS |
また、フルセットの MP4 コンテナや多様なコーデックの複雑さに関する問題は依然として残りました。
PlayReady Training Event in Shenzhen
その当時、ちょうど PlayReady のイベントに参加する機会を得られたので、パスポートを取得して中国の深圳へ。
主に Windows 10 向けの新機能などの説明だったのですが、それとは別に気になるキーワードが:
- CMAF
Microsoft と Apple が協力して仕様を策定⁉ 配信規格統一の夢は実現するか⁉
CMAF が目指したもの (理想)
ひとつのファイル形式ですべての環境をカバーしよう！ という理想を掲げて規格の草案が出されました。
| コーデック & コンテナ & 暗号化方式 | 配信形態 | 再生環境 |
|---|---|---|
| CMAF (H.264/AAC + AES-CTR) | ストリーミング & ダウンロード | スマートフォン, PC, TV |
が、統一までの道のりは険しく…
AES-CTR vs AES-CBC
草案の段階では AES-CTR 方式に統一されるかに見えたのですが、AES-CBC 勢が歩み寄ることはなく、逆に AES-CTR 勢が AES-CBC もサポートするという方向にシフトしました。
ただし古いデバイスは対象外となるため、そこをカバーするためには両方の形式を用意せざるを得ません。
CMAF で達成されたもの (現実)
| コーデック & コンテナ | 暗号化方式 | 配信形態 | 再生環境 |
|---|---|---|---|
| CMAF | AES-CBC | ストリーミング & ダウンロード | macOS, iOS, iPadOS |
| CMAF | AES-CTR | ストリーミング & ダウンロード | その他全般 |
遠い未来には AES-CBC に統合される予定ではありますが、それまで当面の間は両方に対応する必要があるため、従来どおり MP4 から動的にパッケージングするアプリケーションを利用する方針になりました。
それでも WMV を置き換えるという最低限の目的は果たせるため、着実に進歩はしています。
閑話: DRM とプレイヤー技術選定の話
CMAF 化でコーデックやコンテナの問題は解決できるとして、あとは macOS 対応の DRM とプレイヤーをどうするかという課題がありました。CMAF はマルチ DRM 対応の設計になっていますが、現実問題として macOS 対応かつオフライン再生可能なプレイヤーの情報はほとんどありませんでした。候補としては
- Widevine (Electron)
- DivX (専用プレイヤー)
が挙がりましたが、CWIP Training のために Google Kirkland へ訪れた際に Electron が公式にサポートされるという話を聞き、将来性の高そうな Electron (この段階ではまだオフライン再生には対応していなかった) に比重を置いて調査を進めました。
(Electron ベースのプレイヤーについての詳しい話は 連載第 1 回 をご覧ください。)
ダウンロード用のファイル形態をどうするか
ストリーミングは CMAF に落ち着きましたが、ダウンロードしてオフライン再生するにはひと工夫が必要です。
| ファイルの形態 | ダウンロード方法 | ファイル移動 (外付け HDD 利用) |
|---|---|---|
| 細切れ (ストリーミング用そのまま) | 専用アプリケーション | 不可 |
| 単一ファイルに結合 | ブラウザ | 可 |
既に他社で多く採用されている前者の方法では、ファイルを移動させたいというニーズに応えられなかったり、各プラットフォームごとに専用アプリケーション内にダウンロード機能も追加実装する必要があったりと、デメリットが大きかったため、サーバーサイドでファイルを結合する後者が採用されました。
ファイル結合をどのタイミングで行うか
当初はストリーミング配信される前の MP4 ファイルを直接ダウンロード用に変換してから配信する想定で変換ツールを検討しました。対象となるファイル数が膨大 (数ペタバイト) なため、処理速度を追及した結果、入力から出力までを 1-pass で一気に変換できるツールを自社開発しました。
改良を重ねてスループット 150MB/s 以上になりましたが、それでも数か月～年単位で時間がかかります。
本当のデッドライン
Silverlight 廃止は 2021 年のため、それまでに延々とバッチ処理を回せば間に合うはずだったのですが、そこへ思いがけないニュースが飛び込んできました。
macOS Catalina では 32bit アプリケーションが動作しない
Silverlight は古い技術のため 32bit 版しか提供されておらず、アップデートされることもないため、2019 年秋以降は macOS で WMV を再生できなくなります。
このニュースを受けて突如、デッドラインが 2 年も前倒しになりました。
オンザフライでファイル結合
ファイルの変換処理が終わるまですべての macOS ユーザーに延々と待ってもらうわけにもいかないので、ストリーミングサーバーが動的に生成した細切れのファイルをさらに動的に結合するアプリケーションを開発することとなりました。時間があれば nginx module で書きたかったのですが、開発効率優先のため .NET Core を採用し、C++ で書かれた前述の CMAF 変換ツールを C# に移植する形で間に合わせました。
HTTP Range リクエストの課題
オンザフライで生成すると Content-Length が不明なためブラウザでダウンロード時間の予測が出なかったり、途中で切れた場合に Range リクエストで再開できず最初からやり直しになったりといった問題があります。
HTTP の仕様上、初回ダウンロード時は致し方ないとして、キャッシュが溜まっている 2 回目以降には通常のファイルダウンロードと同様に Content-Length や Range リクエストに対応してほしいところですが標準の nginx はサポートしていません。module 開発によって対応できないか、今後の課題となっています。
おまけ
CMAF 変換ツール開発の副産物として自社開発ライブラリを利用した MP4 解析ツールも作ってみたのですが、これが思いがけず大活躍で、研究開発だけではなく、プロダクション環境で正常に再生できなかった際の原因調査などに役に立っています。
あとがき
基礎研究の時期も含めるとおよそ 3 年、度重なる部署移動や組織変更で頓挫しそうになりながらも情報を蓄積し、ようやく目に見える成果が出たことで、これまでの研究が無駄ではなかったことを証明できたかなと思います。
スケジュール上の都合もあって本記事との同時公開は断念しましたが、MP4 解析ツールを OSS 化する話もあるので、今回の配信基盤の連載を最後までウォッチしていただけたら幸いです。
