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


動画

配信基盤

DMM Player v2を成し遂げるCMAF

facebook

twitter

DMM TV

DMMブックス

DMM pictures

DMM GAMES

DMMオンクレ

DMMスクラッチ

DMMくじ

DMMオンラインサロン

DMMいろいろレンタル

DMM DVD／CDレンタル

DMM通販

DMMオンラインクリニック

デジタルコミック事業

DMMチャットブースト

DMM英会話

DMMかりゆし水族館

ベルリング

ハッシャダイソーシャル

ヤンキーインターン

シント=トロイデンVV

DMM地方創生

DMM.make AKIBA

DMM.make 3Dプリント

Seamoon Protcol by DM2C Studio

ONE DAY DESIGN

DMM WEBCAMP

DMMぱちタウン

DMM競輪

Algoage

DMM EV CHARGE

DMMポイントクラブ

社会課題

エンターテインメント

電子書籍

アニメ

ゲーム

アプリゲーム

コミュニティ

オンラインサロン

PCゲーム

オンラインイベント

ビジネスソリューション

教育

英会話

水族館

救急車両

消防車両

モノづくり施設

サッカー

スポーツ

地方創生

Web3

研究開発

アプリ

ブロックチェーン

プラットフォーム

横断開発

インフラ

アミューズメント

同人

サーバサイド

バックエンド

フロントエンド

ネットワーク

セキュリティ

ペイメント

Android

データベース

ビッグデータ

フルスタック

データ分析

機械学習

プロトタイピング

グラフィックデザイン

3DCG

モーショングラフィック

プロダクトデザイン

コピーライティング

サービスデザイン

コンテンツ管理・制作

ブランディング

マーケティング

企画

編集

営業

プロモーション

DMM Player v2を成し遂げるCMAF

シェア

関連する記事

関連する求人