この記事は CyberAgent Developers Advent Calendar 2024 24 日目の記事です。

CyberAgent Developer Experts 動画技術担当の五藤 佑典（ @ygoto3_ ）です。本記事では、株式会社 AbemaTV で開発している動画再生品質管理システムについて書きます。

視聴体験の品質

株式会社 AbemaTV では、新しい未来のテレビ『ABEMA』を提供しています。動画サービスのユーザーは当然ながら動画コンテンツを視聴するために、それらサービスが提供するスマートフォン・アプリや Web サイトに訪ずれます。ここでしか見ることができないコンテンツがあることや、見たいと思えるコンテンツがあっと言う間に見つけられるなど、市場競争力を支える動画サービスの要素はさまざまですが、動画プラットフォームとしては最終的には動画コンテンツを見るときの体験品質が市場競争力です。

インターネットで提供する動画コンテンツの場合、その品質は下記 3 点の要素に分解することができます。

1. アセット品質
2. 伝送・配信品質
3. 再生品質

です。

1 つ目のアセット品質は、映像や音声データなどのエンコード後の品質です。ここにはどんなコーデックでどの程度のビットレートを割り当ててエンコードするかで品質が変わります。インターネット動画配信では、CDN などを利用したスケーラビリティに優位な配信を行うために、HLS や MPEG-DASH などの HTTP ベースでアダプティブ・ビットレートに対応したストリーミング・プロトコルを使って配信することが多いですが、その場合はどのような階調でビットレートを割り当てるかもこのアセット品質の要素です。

次は、伝送・配信品質です。これは再生クライアントから要求された動画ファイルなどのアセットをいかにスムーズに配信できるかが影響します。生配信であればカメラから撮影された動画データをリアルタイムで受け取り、配信に適した形にエンコード、パッケージし、広告など収益に関わるデータの挿入する速度がポイントです。また、配信する動画データは多くの人が同じものを視聴するので、CDN などキャッシュを効率的に再利用することで品質を高めることもできます。生配信の例を出しましたが、VOD（ビデオ・オン・デマンド）やファイル・ベースのリニア配信であってもストレージに保存された動画コンテンツのアセット・データを効率的に配信するためのパッケージング処理やコンテンツ保護処理などに品質は影響されます。

最後の品質要素が本投稿のテーマである再生品質です。

再生品質はどんな要素で構成されているか

再生品質はユーザーの手元でいかに自然に動画を再生できるかです。ABEMA の場合は、マルチプラットフォーム・サービスなので、市場に広く普及している多種多様なデバイス上で ABEMA の動画コンテンツを最適な解像度で、止まったり乱れたりすることなく再生させられることが期待値です。世の中にはハイエンドのものからローエンド・スペックまでさまざまなデバイスがあります。アセット・レベルでどんなに美しい映像を用意していたとしても、いま視聴しているデバイスの性でまともに再生できなければその美しさに価値はありません。

映像はとても情報量が多いコンテンツ媒体です。そのため、基本的に符号化・圧縮（エンコード）して伝送・配信します。デバイスで再生する際には、それをデコードして再生しますが、一般的にエンコードが高効率であればある程デコード時の処理負荷は高いため、デコードするデバイス側にも高いスペックが求められます。

ABEMA の場合はテレビ局同様プロコンテンツを流しているので、コンテンツが不当に流出することがないように動画データ自体を暗号化して保護していますが、適切な手順で復号できなければ再生されません。セキュリティ・レベルを上げれば上げる程再生できる条件が厳しくなるため、これを適切に制御できることも再生品質に影響します。これは特定のデバイスが搭載する DRM の CDM（コンテンツ・ディクリプション・モジュール）のセキュリティ・レベルが低かったためコンテンツが再生できないみたいな正当な条件の制御だけでなく、例えばデバイスの作りが特殊でデバイスにはめ込まれているディスプレイが内部で外部ディスプレイのように接続されていて、結果的に設定した HDCP に対して出力違反で引っかかるようなこともセキュリティ・レベルを上げると誘発される確率が上がります。

動画サービスはユーザーの手元にない動画データを、再生クライアントからのリクエストですぐ再生できるように配信します。そのためにストリーム配信という手法を使っていますが、ストリームは受信する方で再生速度を一定に保つためにバッファ処理を行います。バッファ処理に失敗すれば、再生は途切れてしまいます。バッファしすぎても、解像度の変更などが必要な際に切り替えが遅くなったり、無駄になることもあります。デバイスのスペックによってはバッファ可能な容量を超えてしまい、エラーになることもあります。

また、リクエストしたコンテンツの動画データを転送するインターネット経路の帯域も再生品質に影響します。帯域が狭ければ本当は HD で映像を見たいユーザーに SD のデータしか届けられないかもしれません。再生クライアントのアダプティブ・ビットレートの計算が適切で想定より解像度が低くても再生が継続していればまだ良いですが、ジッターが大きければ最適なビットレートの計算が狂って、バッファが枯渇して途中で再生が停止することもあります。

• デコード負荷の制御
• コンテンツ保護制御
• バッファリング制御
• アセットデータ取得帯域幅制御

これらの要素の制御はデバイス側のソフトウェアを変えるだけでは制御することができません。例えば、デコード負荷の制御は、デコード負荷を考慮してエンコード時のパラメータ制御をする必要があります。

コンテンツ保護制御は一般的には、DRM（デジタル・ライツ・マネジメント）など動画アセットの暗号化と認可処理で制御します。セキュリティを十分に高めた条件で復号処理を行うためには、デバイスが搭載する OS やハードウェアに合わせたキー・システムで保護した動画アセットを用意する必要があります。デバイスが復号できない条件で保護されている場合はデバイス側のソフトウェアで何をしても再生できないので、DRM パッケージング・サーバーやライセンス・サーバーに変更を加える必要があるかもしれません。DRM はその名前の通り権利を管理しているので、不適切なライセンス・チャレンジの場合は再生できないことが正ですが、デバイスの脆弱性の発覚などでデバイス・リボケーション（剥奪）されている場合もあります。その場合は、少し解像度など品質が落ちたとしても、セキュリティ要件が軽い条件で再生できるように処理を変更するなどの代替案が検討できます。

また、バッファリング制御はどの程度の尺の動画データが何バイトくらいで用意されているかデバイス側では分からないので、再生クライアントは基本的にメディア・アセットの再生手順を記述したマニフェストに指示された値を基準にバッファする容量を決めます。なので、バッファリングを制御するためにはマニフェストを生成する側のロジックに変更を加える必要があります。

このように再生品質は再生するデバイス側の挙動だけではなく、動画アセットの生成や配信サーバーの挙動にも大きく影響を受けます。再生品質を高めるためには、動画視聴システム全体をチューニングする必要があります。チューニングには、改善したことを判断するための指標が必要です。ABEMA では再生デバイスから見た QoE 指標を定義して日々チューニングを実施しています。私は過去数回の登壇で ABEMA がどのように視聴品質改善に取り組んでいるか話しているので、ぜひ参照してみてください。

• ABEMA の視聴品質向上戦術
• Streaming Reliability Engineering
• RUM と STM で実現する動画視聴における信頼性エンジニアリング

動画アセットを配信するサーバーに対して、そのアセットをリクエストして再生するデバイス上のソフトウェアを再生クライアントと呼びます。再生プレイヤーという概念とは別に、そのサービスで動画再生を行う特有の条件を処理する機能を持ち合わせているものを再生クライアントと呼んでいるので、ここからは「再生クライアント」という言葉で ABEMA が開発している動画再生品質管理システムを説明していきます。

再生クライアント・コア・モジュール（コードネーム『Fluffy』）

ABEMA は多機能な動画サービスです。24 時間 365 日流れ続けているチャンネルが数十とあり、オン・デマンドのコンテンツもあります。課金してサブスクリプションに入ると通常視聴できないコンテンツも見ることができたり、ライブで流れているものを最初から見るなど視聴するためのオプションも増えます。そのため、アプリケーションの UI も毎週のように開発され変化します。

しかし、そんな ABEMA も最初はチャンネルが 30 程だけ視聴できるサービスとして開局し、今と比べると機能が少ない動画サービスだったので、UI 実装と動画再生実装をあまり区別することなく実装していました。今だから言えますが、動画がコアバリューのサービスでは決して UI 実装と動画再生実装を密結合させてはいけません。動画再生処理は再生映像フレームを描画するビューと密接した実装が必要になるため、両者を近い関心として扱いたくなるような衝動に駆られ、UI 実装の近くに再生処理実装を管理することが適切なように思えますが、競争が激しい動画サービス市場で生き残るためには、コンテンツ・マッチング精度（に強く関わる UI 実装）と動画再生品質を分離してそれぞれ集中して改善できるようにすべきです。

ABEMA では、分離した改善ができるように再生クライアント機能の『X as a Service』化を行いました。『X as a Service』化によって何が起こったかは過去のいくつかのイベント登壇機会に説明している資料があるので、下記を参照してもらえればと思います。

• マルチデバイスx大規模xライブで快適な視聴体験を提供する再生品質制御
• ABEMAの視聴体験を進化させ続ける新しい動画再生クライアント設計
• Designing a Playback Client for Large-Scale Live Sports Events

参照いただいた資料で説明している内容で一番大事なことは、動画再生処理に関わる詳細なプロトコルを再生クライアント機能を持つサブシステムである『Fluffy』の中に隠すことができたことです。これにより、実験的なコーデックやストリーミング・プロトコルなどを試験的に導入して評価するようなことが可能になりました。特にプロトコルは日本語で言うと「手順」のことなので、サブシステム外に見える状態でこれを変えようとするとかなりの既存処理シーケンスに変更が走ります。そのため、動画再生処理以外の UI レイヤーなどの実装にも影響することが過去にはよく発生しましたが、現在は少なくなりました。

上記資料にも説明がありますが、『Fluffy』はマルチ・プラットフォームをサポートする再生クライアント・コア・モジュールで、ABEMA がサポートする全てのデバイスで同じインターフェースを搭載しています。これにより、プラットフォームを跨いだ開発も容易になりました。現在も『Fluffy』は拡張開発し続けていますが、1 – 2 名の動画エンジニアがマルチ・プラットフォームで共通する 1 つの要件に対して基本的には全てのプラットフォーム（iOS、Android、Web、Unity など）に実装しています。

『Fluffy』という ABEMA における動画再生クライアント機能のサブシステムができたことにより、再生品質改善をよりダイナミックに実施するための土台が整いました。ここからは、コア・モジュールである『Fluffy』を中心に、より進化した再生品質管理を実現するためのシステムを構成するコンポーネントを 3 点紹介します。

1. 再生品質サンドボックス・テスティング・システム（コードネーム『Golem』）
2. 再生不体裁検知システム（コードネーム『Sphinx』）
3. 再生品質動的制御システム（コードネーム『Zeus』）

余談ですが、今から紹介するこれらのコンポーネントも『Fluffy』同様マルチ・プラットフォーム・サポートです。同じく 1 – 2 名の動画エンジニアが 1 つのタスクに対して全てのプラットフォームを実装する体制で開発しています。

これは動画再生品質管理システムを拡張していく上でとても大事な体制です。なぜかというと、動画再生品質管理システムのコンポーネント 1 個 1 個がとても複雑かつ深い技術的知見を要するので、プラットフォームごとに専門性が分かれることで 1 つ 1 つのコンポーネントが要求する専門性が薄くなることを防げるからです。

再生品質サンドボックス・テスティング・システム（コードネーム『Golem』）

動画再生クライアント機能をサブシステム化する上で大事なのが、システムとしての品質管理が完結していることです。この品質管理を実現するためにコードネーム『Golem』という再生品質サンドボックス・テスティング・システムを開発しました（ドラゴンクエストＩでまさにサンドボックス状態のメルキドの町を守っているゴーレムを思い浮かべて 3 秒くらいでコードネームを付けました）。

『Golem』は再生クライアント上で計測可能なソフトウェア品質をサンドボックス・テストするためのシステムで、『Fluffy』が持つ機能を効率的にテストすることに特化して開発しています。上述した通り ABEMA がサポートする全てのデバイス・プラットフォームの『Fluffy』をサポートしています。

従来、ABEMA では動画再生処理の機能テストの多くを ABEMA アプリケーションに組み込んでから QA に入っていました。ABEMA のように複雑な動画再生機能を持つアプリケーションで、このデリバリー・フローだと動画視聴画面で期待値と異なる振舞いが発見されると原因の切り分けにとても時間がかかります。動画再生はとてもステートフルなので一度発生した事象に対して同じ手順で再現を試みても、動画の再生位置や再生し始めた場所、同じ位置に来るまでに再生していた時間などによっても再現条件が変わり、意図的に再現させられないことが多いからです。

これに加え、実際のアプリケーションでは、アプリケーション自体も状態を持ち、ステートフルです。動画再生処理の状態に比べると、こちらは意図的に状態を再現すること自体は可能ですが、複雑な条件が重なれば一定の手順で作業する必要があるので時間がかかります。ユーザーが使う前提の UI に組み込まれるとテストの前提条件を整えるために、場合によってはこのテスト実行作業自体よりもこの事前作業の方が時間がかかるテスト項目もあります。『Golem』では、このような前提条件を簡単に揃えることができるようにテスト専用の UI を搭載しています。

動画再生エンジニアリングが一般的なソフトウェアエンジニアリングに比べて大変なところは、再生処理自体が OS 、ドライバ、SoC に依存しており、ソフトウェアとハードウェアが組み合わさって初めて動作条件が揃う部分が多いことにあります。『Golem』は実際にユーザーに使われているハードウェアとソフトウェア上で動画再生処理の単体テストを実施するためのシステムと言えます。

『Golem』自体は DUT（デバイス・アンダー・テスト）、Controller、Logger という 3 種類のコンポーネントで構成されたシステムです。

DUT はデバイス・アンダー・テストと言われるものですが、その名前の通りテストされるデバイスのことです。このデバイス上で実際に動画が再生されて、その結果が評価されます。Controller は DUT を制御するサーバーです。DUT からのリクエストで Controller と WebSocket で接続し、Controller から DUT に対してテスト・シナリオの実行と結果ログの収集を実行します。

また、DUT は Controller と接続しなくても使用することができます。その場合は、ABEMA のリファレンス・プレイヤーのような役割をします。配信サーバーの実装やエンコーダーの設定などに変更を加えたときに、リファレンス・プレイヤーで確認すれば変更に対する純粋な影響を確認することができます。

アプリケーションはリリースの直前まで QA を実施していることが多々あるので、再生機能を ABEMA アプリケーションに組み込んでから QA に入っていたときと比べると、『Golem』によってサンドボックスで事前に徹底的にテストしてから『Fluffy』を提供することができることで、かなり余裕を持って品質保証ができるようになりました。

再生不体裁検知システム（コードネーム『Sphinx』）

『Golem』は再生クライアント上で計測可能なメトリクスを基準に品質を測定しますが、残念なことに再生品質に影響する要素はソフトウェアで検出可能なものだけではありません。ソフトウェア側では正常に再生できているように認識していても、映像の乱れなどの映像不体裁と呼ばれるような品質劣化も存在するからです。ABEMA はこれまではこのような見た目の品質を人の眼で確認することで担保するようにしてきました。しかし、動画を確認するという作業は一瞬見ればいいというわけではなく、2 時間のコンテンツであればそれを目を話さずずっと見ている必要があります。録画をしておいて、後から少々早送りして確認するというような方法も取ることができますが、それでも拘束時間が長い作業です。ABEMA はマルチ・プラットフォーム・サポートの動画サービスなので、この作業を数十種類のデバイスに対して実施することになります。

これらの QA 内容はエイジング・テストと同時に行なっています。エイジング・テストは一般的には長時間製品を稼働させて動作に問題がないか耐久性などをテストするものですが、動画再生の場合も 30 分以上再生されて初めて再現するような現象もあるため、重要なテスト手法です。再生中にメモリ・リークが発生して次第に動作が不安定になるようなプログラミングの実装具体に起因するような内容もなくはありませんが、ここで検知される多くの問題は、再生開始したタイミングによって再現有無が変わるような不具合です。

HLS と MPEG-DASH は、長い動画を細かいファイルに分割して、それを再生プレイヤーが指定された順番で取得しながら再生し続けるプロトコルです。エンコードの仕方に依存しますが、分割された動画ファイルのサイズは大きかったり小さかったりします。指定された速度で再生するため取得した動画ファイルはバッファ領域に一時的に貯められてから再生されます。この領域に一時的に貯められる容量以上に動画データをバッファしてしまうと、いわゆるバッファ・オーバーフローしてしまいます。このケースの場合、ある再生位置で不具合を検知して、その再現を試みようと不具合が発生した再生位置までシークしたりしてもオーバーフローする程のバッファが溜まり切っていないので、再現しません。再生位置までに選択してきた帯域幅でも再現は変わります。

ストリーミング・プロトコルに依存した再生タイミングによって再現有無が変わる現象もあります。例えば、HLS では 2 つ以上の異なるエンコード処理がされた動画を #EXT-X-DISCONTINUITY タグを入れることで 1 つの連続する動画ストリームとして配信することができますが、（ABEMA は、広告を挿入したり、複数の番組を 1 つの枠で一挙配信したりするので、#EXT-X-DISCONTINUITY タグの登場回数はとても多いです）、このタグはライブ配信モード（HLS の Live Session）では、再生位置が進んでいくと古い動画セグメントデータとともに消えていきます。

#EXTM3U
#EXT-X-VERSION:5
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:1193
#EXT-X-DISCONTINUITY-SEQUENCE:3
#EXTINF:4.83817,
/program/2.ts
#EXT-X-DISCONTINUITY
#EXTINF:0.500,
/ad/1199.ts
#EXTINF:4.004,
/ad/1200.ts
#EXTINF:4.004,
/ad/1201.ts
#EXTINF:4.004,
/ad/1202.ts
#EXTINF:4.004,
/ad/1203.ts


上記にあるような HLS のプレイリストの #EXT-X-DISCONTINUITY が、再生クライアントが次に取得した下記では HLS のプレイリストでは先頭が広告に入ったので、消えています。

#EXTM3U
#EXT-X-VERSION:5
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:1194
#EXT-X-DISCONTINUITY-SEQUENCE:4
#EXTINF:0.500,
/ad/1199.ts
#EXTINF:4.004,
/ad/1200.ts
#EXTINF:4.004,
/ad/1201.ts
#EXTINF:4.004,
/ad/1202.ts
#EXTINF:4.004,
/ad/1203.ts
#EXTINF:4.004,
/ad/1204.ts


ちなみにこの消え方だと HLS プレイヤーの実装によっては再生が止まります。現在の HLS の仕様では、 #EXT-X-DISCONTINUITY はそれに続くメディアセグメントと一緒に消えることが正しいからです。それであれば、ただの HLS パッケージャーの実装ミスのようにも思えますが、初期の HLS では明示的に #EXT-X-DISCONTINUITY が消えるタイミングについて仕様が記述されていなかったので、そのように実装しているパッケージャーがあっても不思議なことではありません。これも再現を試みようとして同じ再生位置までシークしたとしても、プレイリストの更新タイミングによって再現したりしなかったりします。この場合は、再生時間が長くなることで再現するようなものでもないので、エイジング・テストをしたとしても検知できるかは運になってしまいますが、結果的にエイジング・テストによって発覚する例でもあります。

このセクションの冒頭で『Golem』では再生クライアント上のソフトウェアで検出できない不具合があるという話をしました。そのため、エイジング・テストは『Golem』と再生不体裁検知システムであるコードネーム『Sphinx』とで実施します。

『Sphinx』は、映像の見た目の異状を検知するシステムです。見た目の異状として最も一般的なものは、カクツキや停止です。『Sphinx』は再生デバイスの API に頼ることなく、実際にデバイスが再生した映像（の録画映像）から異状を検知します。例えばカクツキや停止の場合は、Netflix が映像の動きを評価するために開発した VMAF Motion Score を利用します。

VMAF Motion Score は数値が 0 に近いほど前フレームからの変化が小さいことを示すため、映像がカクついている場合は連続的に数値が上がったり下がったりを繰り返します。

瞬間的に 1 フレームだけ止まるような通常人が知覚できないようなカクツキも検知してしまうため、実際のエイジング・テストでは人が知覚できる程度の感度に調整しています。カクツキの頻度に応じて Sphinx Score という指標としてテスト結果を出力します。

Sphinx 記録 ID	Device	Sphinx Score	Sphinx 詳細	撮影ファイル
248	Pixel 7 Pro GFE4J	4.9008		aaa.mp4
249	Chromecast with Google TV4K	4.40482	00:34:58.1 カクツキ 00:06:01.9 カクツキ	bbb.mp4
250	iPhone 15	4.9008		ccc.mp4
251	macOS Safari	3.0815	00:00:40.0 カクツキ 00:00:54.2 カクツキ 00:01:30.7 カクツキ 00:01:59.4 カクツキ 00:03:25.1 カクツキ 00:03:51.7 カクツキ … 1時間あたり232.1回	ddd.mp4
…	…	…	…	…

Sphinx Score の値は、従来人の目によるエイジングテストしていたときの 0 – 4 段階の評価指標に連動するように設計しています。0 が「視聴できない」を表し、4 が「通常視聴に問題なし」を表します。間の 1 – 3 は映像の停止や映像の乱れの頻度に応じて評価します。

『Sphinx』のおかげで、エンコーディング・パラメータの調整や新しいコーデックを評価することが容易になりました。エンコードのパラメータは VMAF、SSIM、PSNR のようなエンコード前の映像を参照した指標を確認しながら調整します。それら指標ができる限り高く、ビットレートが低く抑えることが解像度が高い動画を多くの人に配信するポイントです。しかし、ABEMA のようにサポートするデバイスが多いサービスでは、調整したエンコード結果がある環境で確認したときは問題なくても、特定のデバイスでは期待通りデコードできないことは少なくありません。

これはスペックが低いデバイスと高効率なエンコーディングに対してだけを気にしていればいいわけではなく、ロースペックの Android スマートフォンでは問題なく再生できている動画ストリームであるにも関わらず、本来マルチメディア処理性能に優れている Apple 製品でだけ映像にノイズが入ってしまうようなこともあります。それは、既存で利用しているエンコーダーのソフトウェア・バージョンをアップデートするような場合であっても発生しうるので、テスト時のデバイスのパターン網羅性は重要です。

ABEMA がリファレンスとしてテスト対象に指定しているデバイスも数十種類あるため、エイジング・テストで愚直にデバイスを網羅しようと思うと、総再生時間で 1,000 時間以上かかります。

『Sphinx』は、実際にデバイス上で再生させた映像をカメラで録画し、その録画データを解析するシステムです。これにより、不体裁と呼ばれるような不具合もパターンさえ見つけることができれば検出することが可能になります。

再生品質動的制御システム（コードネーム『Zeus』）

『Golem』と『Sphinx』のおかげで、動画アセットや配信アセットに対するいわゆる静的な再生品質を管理するためのシステムが揃いました。しかし、再生品質に影響する要素には動的なものがあります。インターネット動画配信の場合は、ユーザーの通信環境やインターネット自体の混雑状況です。

ユーザーの通信環境は再生クライアント側で一度動画を再生し始めてから TTFB や動画データ転送時間全体のスループットなどを計測して、通信環境に合わせて調整していくことができます。これは HLS や MPEG-DASH などのストリーミング・プロトコルを使っている場合はアダプティブ・ビットレートの動画ストリームを配信できるので、プレイヤー・ライブラリを使って再生している場合は意識せずとも実践していることだと思います。

しかし、アダプティブ・ビットレート方式で制御できるのは 1 つの転送経路で利用可能な帯域内で再生が止まることなく一番効率的なデータ量を取得することです。その転送経路の帯域自体が狭かった場合はどれだけ再生クライアントでデータの取得量を制御しても物理的に転送される最大値は変えることができません。

ただし、転送経路がほかにもあれば転送経路を変更することによって、転送可能量の最大値を変えることができることができます。配信システムとして事前に用意さえしておけば転送経路を複数選択することはできます。

再生クライアントが個々の通信環境の状態に応じてより空いている転送経路を選ぶためには、再生前か再生中に自分の環境から見て空いている転送経路を知る必要があります。一番直接的な方法は選択肢となる全ての経路に定期的に軽量なリクエストを行い続け、レスポンス性能を計測しておくことです。現在再生するためのデータを取得している経路よりレスポンス性能が良い経路が確認できれば、その経路に変更することが理論的には常に転送可能量の最大値を利用することができます。

一方、インターネット自体の混雑状況の把握には統計的情報が必要になります。RUM（リアル・ユーザー監視）や CDN のログデータを集計し、統計的に分析されたデータで混雑させないように動画データの取得経路を分散できればより多くのユーザーが最適な再生品質で動画コンテンツを視聴することができます。

RUM を実施するためには、ユーザー・デバイスのコンテンツ視聴時のパフォーマンス視聴指標などを取得する必要があり、複数プラットフォームの API でデータ精度に差分がないように取得処理を実装するのは難しく、運用コストもかかるため、専門のソリューション・プロバイダに頼ることがオススメです。RUM は NPAW Video Analytics、Conviva、Mux Data などのソリューションを利用して取得することができます。最近では、WAVE（Web Application Video Ecosystem – Consumer Technology Association a.k.a. CTA が主催するプロジェクト）が開発した CMCD（Common Media Client Data） が少しずつ普及し始めてきて、この仕様を利用して CDN やデータ・プラットフォームを跨いでも同じデータ形式で解析することもできるようになってきています。

転送経路を変える手段が CDN の切り替えであれば、これは CDN セレクターと変わりません。しかし、自分と類似した状況にある他の再生クライアントの再生品質をあらかじめ知ることで、より良いパフォーマンスの CDN に切り替える以外にも柔軟な再生制御ができます。

1 つは、再生開始時の通信帯域幅を動的に決定することです。アダプティブ・ビットレート・アルゴリズムの中で最初に取得する通信帯域幅を決めるのは悩ましい問題です。狭い通信帯域幅で低い解像度から再生を始めれば再生開始時間も短く、リバッファリングの可能性も低くなりますが、最初の映像が綺麗でないため、ユーザーが受けるファースト・インプレッションは悪くなります。最初から広い通信帯域幅で再生を始めると最初から映像は綺麗ですが、帯域が十分でない場合はリバッファリングのリスクや再生開始時間が長くなります。2020 年 8 月にライムライト・ネットワーク・ジャパン株式会社さん主催のイベントで ABEMA の視聴品質向上戦術について話した際にも触れましたが、ABEMA では、この問題に対して前回の再生セッションの最後の通信帯域幅／解像度を再生することで初期ターゲット通信帯域幅の最適化を図っています。

移動することが前提のモバイル・デバイスは、アプリケーションが機動している間だけ前回の再生セッションの解像度から再生を継続し、アプリケーションが一度閉じたらまた保守的に低い解像度から再生を始め、スループットに応じて解像度を高めていきます。コネクテッド・テレビのような据付型のデバイスでは、通信条件が同じである可能性が高いのでアプリケーション・セッションを跨いで前回の解像度を引き継ぎます。この方法も理に適ってはいますが、通信帯域幅の急な変化に対応することは難しいです。再生開始するタイミングで今の通信帯域幅の状態が分かっていれば、再生クライアントが再生開始前に今の通信帯域幅の状態が分かっていれば、動的に適切な決定することができます。

また、再生クライアントに再生前にネットワークが混雑していることを知らせることで、再生開始時に保守的なストリーミング・プロトコルをあえて選択することができ、ネットワークの状態が良いときだけ自動的に LL-HLS や LL-DASH のような低遅延向けプロトコルに切り替えることができれば、ユーザーに意識させることなくライブイベントの感動を最速で伝えることができます。

インターネットのリアルタイムな状況や自身以外の多くの再生クライアントから得られる統計的なデータを基に最適な再生手段を決めることができれば、より柔軟に再生品質を制御することができます。これを実現するために、再生品質動的制御システムを開発しています。これのコードネームは『Zeus』です。

『Zeus』では、直近の QoE（クオリティ・オブ・エクスペリエンス）に関するデータを基に、再生クライアントが選択すべき設定を再生前、再生中に Configuration Decider サーバーとクライアント SDK の間で決定します。CDN などのメディアデータの経路選択、帯域制御、低遅延などの積極的なストリーミング・プロトコルの切替などをインターネットの状況に応じて動的に調整することを目的としています。

動画再生品質管理システムの形

ここまで 3 つの異なる側面で再生品質管理を担うコンポーネントを説明してきました。これらはコア・モジュールである『Fluffy』と連動して統合的に再生品質を管理していきます。

これらのコンポーネントは 1 つ 1 つが独立したサブシステムです。必要最低限の機能を搭載したサブシステムから動画再生品質管理システムはスモールスタートし、徐々に成果が現れていますが、品質をより早く改善するために 1 つ 1 つのコンポーネントで必要となる機能がまだ多くあります。今後の ABEMA の視聴品質にご期待ください。