ABEMA の視聴体験を進化させ続ける新しい動画再生クライアント設計

ABEMAの視聴体験を進化させ続ける  新しい動画再生クライアント設計  株式会社AbemaTV 五藤佑典 

五藤佑典 YUSUKE GOTO https://ygoto3.com/ @ygoto3_ • California State University,
San Bernardino グラフィックデザイン専攻 Career History 1. Graphic / Web Designer 2. Marketer 3. Web Engineer 4. Video Engineer 5. Technical Product Manager • CyberAgent Developer Expert @（株）サイバーエージェント • Technical Product Manager @（株）AbemaTV CTV 事業部

in Video Technology and Product Design

1. 動画再生クライアント 2. Streaming Client チームのミッションとチームトポロジー 3. X-as-a-Service としての動画再生サブシステムの設計 4.
X-as-a-Service からの動画再生サブシステムの進化 CONTENTS

01 動画再生クライアント 

動画再生クライアント  動画再生クライアント = 動画プレイヤー  01  ? 

動画再生クライアント  動画再生クライアント  特定の動画視聴システムに対応した再生機能を持つ  クライアントアプリケーション  01 

動画再生クライアント  動画再生クライアント  特定の動画視聴システムに対応した再生機能を持つ  クライアントアプリケーション  • 主な機能  ◦ 動画プレイヤー  ◦ … 
01  動画プレイヤー機能はもちろん必須 

動画再生クライアント  動画プレイヤー  01  動画配信で主流な HTTP ベースのストリーミングプロトコルは複雑な仕様だが  再生ライブラリのバリエーションは充実  M3U8  Apple HLS 
MPD  MPEG-DASH  https://datatracker.ietf.org/doc/html/rfc8216 

動画再生クライアント  動画プレイヤー  01  動画配信で主流な HTTP ベースのストリーミングプロトコルは複雑な仕様だが  再生ライブラリのバリエーションは充実  単純な再生だけならそれ程難しくはない  M3U8  Apple
HLS  MPD  MPEG-DASH  https://datatracker.ietf.org/doc/html/rfc8216 

動画ストリーミングを商用サービスとして成立させる  01  動画再生クライアント 

動画ストリーミングを商用サービスとして成立させる  01  現在の動画サービスに一般的に必要な要素は意外と多い  動画再生クライアント 

商用サービスとしての動画再生クライアント  • 主な機能  ◦ 動画プレイヤー  ◦ 広告挿入  ◦ 視聴ログ  ◦
DRM  01  マネタイズ、プロダクトグロース、  コンテンツ保護など商用サービスを  成立させるための機能が増える   動画再生クライアント 

市場競争力を持った動画ストリーミングを成立させる  01  動画再生クライアント 

市場競争力を持った動画ストリーミングを成立させる  01  動画再生クライアントに求める機能はより複雑化する  動画再生クライアント 

商用サービスとしての動画再生クライアント  • 主な機能  ◦ 動画プレイヤー  ◦ 広告挿入  ◦ 視聴ログ  ◦
DRM  ◦ 広告パーソナライズ制御  ◦ 映像に同期した UI 制御  ◦ 複数エンコードによる動画ストリーム  01  視聴体験やビジネスモデルの向上には  より複雑な機能が必須  動画再生クライアント 

モダンな動画再生クライアントに求められる役割が複雑化  01  動画再生クライアント 

モダンな動画再生クライアントに求められる役割が複雑化  01  複雑な動画再生ドメインを専門に扱うチームが必要  動画再生クライアント 

モダンな動画再生クライアントに求められる役割が複雑化  01  複雑な動画再生ドメインを専門に扱うチームが必要  動画再生ドメインを専門に扱うチーム  ABEMA『Streaming Client チーム』設立  動画再生クライアント 

02 Streaming Client チームの  ミッションとチームトポロジー 

Streaming Client チームのミッションとチームトポロジー  Streaming Client チームが生まれた経緯  02 

Streaming Client チームが生まれた経緯  1. ABEMA 開局当初、動画再生機能はモバイルアプリ／Web アプリ開発チームなどの各々のクライアントエンジニアチームが開発  Streaming Client
チームのミッションとチームトポロジー  02 

Streaming Client チームが生まれた経緯  1. ABEMA 開局当初、動画再生機能はモバイルアプリ／Web アプリ開発チームなどの各々のクライアントエンジニアチームが開発  2. 動画再生技術は高い専門性が必要なため、各クライアントエンジニアチーム内で
実装できるメンバーが固定化  Streaming Client チームのミッションとチームトポロジー  02 

実装できるメンバーが固定化  3. 動画は ABEMA のコアドメインなので、関連する機能開発の頻度も高く、チームごとに知見がサイロ化  Streaming Client チームのミッションとチームトポロジー  02 

実装できるメンバーが固定化  3. 動画は ABEMA のコアドメインなので、関連する機能開発の頻度も高く、チームごとに知見がサイロ化  4. サイロ化を防ぐために、各クライアントエンジニアチームから動画技術を得意とするメンバーを集めてギルドを結成  Streaming Client チームのミッションとチームトポロジー  02 

実装できるメンバーが固定化  3. 動画は ABEMA のコアドメインなので、関連する機能開発の頻度も高く、チームごとに知見がサイロ化  4. サイロ化を防ぐために、各クライアントエンジニアチームから動画技術を得意とするメンバーを集めてギルドを結成  5. チームでの機能開発とギルドの動画機能開発が兼務ではリソースが回らないため、専任で動画再生技術を担当するチームを切り出し  Streaming Client チームのミッションとチームトポロジー  02 

Streaming Client チームのミッション  ABEMA の動画視聴の再生品質とその UX エンジニアリングに  責任を持ち、そのための最適な戦略と戦術についての決定を行う  Streaming Client
チームのミッションとチームトポロジー  02 

Streaming Client チームのミッションと役割を  チームトポロジーという考え方で説明する  Streaming Client チームのミッションとチームトポロジー  02 

チームトポロジーとは何か？  • 時間軸を持った生産性を  チームファーストで最適化する考え方  • 抽象化された 4 つのチームの役割と  3 つのチーム間インタラクションのモードで 
組み合わせた組織設計  Streaming Client チームのミッションとチームトポロジー  02  https://teamtopologies.com/book  Matthew Skelton 氏と  Manuel Pais 氏の著書 

4 つのチームの役割  • Stream-aligned チーム  ◦ 組織の根幹となるチーム  • Enabling チーム 
◦ Stream-aligned チームに足りない特定の  技術領域の能力ギャップを埋めるチーム  • Complicated Subsystem チーム  ◦ システムの中で  専門性が必要なパーツを開発する  • Platform チーム  ◦ Stream-aligned チームが  自律的に成果を作ることができる  内部サービスを提供する   https://teamtopologies.com/key-concepts  Streaming Client チームのミッションとチームトポロジー  02 

3 つのチーム間インタラクションモード    • コラボレーション  ◦ チーム間での密接な協業   • X-as-a-Service 
◦ 最小限の協業。一方のチームが他方に必要なものを提供   • ファシリテーション  ◦ 障害を取り除くために  一方のチームが他方を支援   https://teamtopologies.com/key-concepts  Streaming Client チームのミッションとチームトポロジー  02 

Streaming Client チームのチームトポロジー  Stream-aligned なプロダクト開発チームで扱うには  認知負荷が高すぎる動画再生領域を  サブシステムとして切り出して専門に扱う  Streaming Client チームのミッションとチームトポロジー 
02 

Streaming Client チームのチームトポロジー  Stream-aligned なプロダクト開発チームで扱うには  認知負荷が高すぎる動画再生領域を  サブシステムとして切り出して専門に扱う  動画再生領域の Complicated subsystem
チーム  Streaming Client チームのミッションとチームトポロジー  02 

Streaming Client チームのチームトポロジー  モバイルアプリ開発チーム  Web ブラウザアプリ開発チーム  CTV アプリ開発チーム  ゲームコンソールアプリ開発チーム  Streaming 
Client  チーム  Streaming Client チームのミッションとチームトポロジー  02 

Complicated subsystem チームとしての課題  Streaming Client チームは  Complicated subsystem チームならではの課題を抱えている  Streaming
Client チームのミッションとチームトポロジー  02 

Complicated subsystem チームとしての課題  Streaming Client チームは  Complicated subsystem チームならではの課題を抱えている  1.
動画再生機能が各 Stream-aligned チームで開発された経緯から、プロダクトの他の機能のコードと密結合している  Streaming Client チームのミッションとチームトポロジー  02 

動画再生機能が各 Stream-aligned チームで開発された経緯から、プロダクトの他の機能のコードと密結合している  2. 動画再生機能に変更を加える場合に、常に Stream-aligned チームとの密接で同期的なコラボレーションが必要とする  Streaming Client チームのミッションとチームトポロジー  02 

動画再生機能が各 Stream-aligned チームで開発された経緯から、プロダクトの他の機能のコードと密結合している  2. 動画再生機能に変更を加える場合に、常に Stream-aligned チームとの密接で同期的なコラボレーションが必要とする  3. 密接で同期的なコラボレーションは再生品質を最適化する（ミッション）ための戦略と戦術の実施に時間がかかる  Streaming Client チームのミッションとチームトポロジー  02 

動画再生機能が各 Stream-aligned チームで開発された経緯から、プロダクトの他の機能のコードと密結合している  2. 動画再生機能に変更を加える場合に、常に Stream-aligned チームとの密接で同期的なコラボレーションが必要とする  3. 密接で同期的なコラボレーションは再生品質を最適化する（ミッション）ための戦略と戦術の実施に時間がかかる  4. 自律的に進化するサブシステムの必要性  Streaming Client チームのミッションとチームトポロジー  02 

03 X-as-a-Service としての  動画再生サブシステムの設計 

X-as-a-Service としての動画再生サブシステムの設計  再生サブシステムが  X-as-a-Service として  生まれ変わるプロジェクト  03 

X-as-a-Service としての動画再生サブシステムの設計  再生サブシステムが  X-as-a-Service として  生まれ変わるプロジェクト  03  『Fluﬀy』プロジェクト 

X-as-a-Service としての動画再生サブシステムの設計  ここからの便宜上の呼称  • プロダクト  ◦ Stream-aligned なクライアント機能開発チームが責務を持つソフトウェア  • Fluﬀy 
◦ Complicated subsystem な Streaming Client チームが責務を持つ  動画再生サブシステムのソフトウェア  03 

X-as-a-Service としての動画再生サブシステムの設計  X-as-a-Service としての動画再生サブシステム  • 動画再生クライアントとしての変化は、必ずしもエンドユーザーに対して直接の変化として見える形で現れるわけではない  ◦ ユーザーに対する Stream
とは異なる Stream に対して変更を適用する  • 近年の動画視聴システムは動画再生クライアントの進化なしでは  視聴体験／ビジネスモデルの市場競争力は得られない  ◦ 動画視聴システムとしての Stream に対して最適化するフェーズに来ている  03 

X-as-a-Service としての動画再生サブシステムの設計  X-as-a-Service としての動画再生サブシステム  • 動画再生クライアントとしての変化は、必ずしもエンドユーザーに対して直接の変化として見える形で現れるわけではない  ◦ ユーザーに対する Stream
とは異なる Stream に対して変更を適用する  • 近年の動画視聴システムは動画再生クライアントの進化なしでは  視聴体験／ビジネスモデルの市場競争力は得られない  ◦ 動画視聴システムとしての Stream に対して最適化するフェーズに来ている  03  Stream-aligned チームにとっての X-as-a-Service として  より動画視聴システムとの変更に同期して進化することを優先 

X-as-a-Service としての動画再生サブシステムの設計  Fluﬀy のゴール  開発する動画再生サブシステムが  • プロダクトから独立して動画視聴品質を改善し続けられること  • マルチプラットフォームに対応したソフトウェア設計であること  03 

Fluﬀy のゴール  開発する動画再生サブシステムが  • プロダクトから独立して動画視聴品質を改善し続けられること  • マルチプラットフォームに対応したソフトウェア設計であること  X-as-a-Service としての動画再生サブシステムの設計  03 

プロダクトから独立して動画視聴品質を改善し続けられること  X-as-a-Service としての動画再生サブシステムの設計  03 

プロダクトから独立して動画視聴品質を改善し続けられること  組織のチームトポロジーを明確に定義した  サブシステムとして開発する  X-as-a-Service としての動画再生サブシステムの設計  03 

動画視聴システム周辺のチームトポロジー  プロダクト開発チーム  <Stream-aligned チーム>  Streaming Client  チーム  <Complicated Subsystem チーム> 
動画配信基盤開発チーム／コンテンツ管理基盤開発チーム  <Platform チーム>  X-as-a-Service としての動画再生サブシステムの設計  03 

動画配信基盤開発チーム／コンテンツ管理基盤開発チーム  <Platform チーム>  動画配信基盤開発チームと Streaming Client チームで  視聴品質に関わる意思決定が完結する  X-as-a-Service としての動画再生サブシステムの設計  03 

動画配信基盤開発チーム／コンテンツ管理基盤開発チーム  <Platform チーム>  プロダクトと Fluﬀy の責務をどう分離するか  X-as-a-Service としての動画再生サブシステムの設計  03 

プロダクトと Fluﬀy の関心の分離  プロダクトの関心  • ユーザーが視聴する  コンテンツ  • ユーザーが  どのように視聴するか 
Fluﬀy の関心  • 再生の安定性  • 動画の解像度  • インストリーム広告の  挿入手段  • コンテンツ保護手段  X-as-a-Service としての動画再生サブシステムの設計  03 

Fluﬀy の関心  • 再生の安定性  • 動画の解像度  • インストリーム広告の  挿入手段  • コンテンツ保護手段  Content  X-as-a-Service としての動画再生サブシステムの設計  03 

Fluﬀy の関心  • 再生の安定性  • 動画の解像度  • インストリーム広告の  挿入手段  • コンテンツ保護手段  Content  UseCase  X-as-a-Service としての動画再生サブシステムの設計  03 

Fluffy による隠蔽  プロダクトと Fluffy の関心の分離  プロダクトの関心  • ユーザーが視聴する  コンテンツ  •
ユーザーが  どのように視聴するか  Fluffy の関心  • 再生の安定性  • 動画の解像度  • インストリーム広告の  挿入手段  • コンテンツ保護手段  Content  UseCase  Content  Session  X-as-a-Service としての動画再生サブシステムの設計  03 

Fluﬀy 責務分離のキーコンセプト  Fluﬀy の核となるコンセプトは Content Session という概念  • ユーザーが視聴するコンテンツ単位でのセッション  X-as-a-Service
としての動画再生サブシステムの設計  03 

Fluﬀy 責務分離のキーコンセプト  Fluﬀy の核となるコンセプトは Content Session という概念  • ユーザーが視聴するコンテンツ単位でのセッション  以前と何が変わったのか 
• 従来の再生モジュールはプロダクトから見える再生セッションを  マニフェスト（プレイリスト）単位で扱っていた  X-as-a-Service としての動画再生サブシステムの設計  03 

マニフェスト単位セッションの問題  • マニフェストはストリーミングプロトコルに依存して形式が決定する  ◦ プロダクトからマニフェストを指定すると、再生モジュールは使用するストリーミングプロトコルやプレイヤーライブラリの選択肢を制限される  • 1 つのコンテンツが複数のマニフェストを提供するためには、マニフェストを変更しなければならないため、セッションが変わってしまう 
X-as-a-Service としての動画再生サブシステムの設計  03 

マニフェスト単位セッションの問題  • マニフェストはストリーミングプロトコルに依存して形式が決定する  ◦ プロダクトからマニフェストを指定すると、再生モジュールは使用するストリーミングプロトコルやプレイヤーライブラリの選択肢を制限される  • 1 つのコンテンツが複数のマニフェストを提供するためには、マニフェストを変更しなければならないため、セッションが変わってしまう 
多くの動画プレイヤーライブラリがマニフェスト単位で1 つの再生のセッションを開始  → 自然とアプリの 1 再生の基本単位もマニフェストになる  X-as-a-Service としての動画再生サブシステムの設計  03 

Fluﬀy による隠蔽  Content と ContentSession  プロダクトの関心  • ユーザーが視聴する  コンテンツ  •
ユーザーが  どのように視聴するか  Fluﬀy の関心  • 再生の安定性  • 動画の解像度  • インストリーム広告の  挿入手段  • コンテンツ保護手段  Content  UseCase  Content  Session  X-as-a-Service としての動画再生サブシステムの設計  03 

Content と ContentSession  プロダクト  Fluffy  • プロダクトは Content を指定して Fluffy
に再生を依頼  • Fluffy は Content を視聴する ContentSession を返却  Content  Content Session  X-as-a-Service としての動画再生サブシステムの設計  03 

Content という概念  同一映像ソースからエンコードされた動画コンテンツ  M3U8  MPD  Web  RTC  HD エンコード  SD
エンコード  HFR エンコード  HLS パッケージ  DASH パッケージ  WebRTC 配信  映像ソース  X-as-a-Service としての動画再生サブシステムの設計  03 

Content という概念  同一映像ソースからエンコードされた動画コンテンツ  M3U8  MPD  Web  RTC  HD エンコード  SD
エンコード  HFR エンコード  HLS パッケージ  DASH パッケージ  WebRTC 配信  映像ソース  エンコードや  パッケージが違っても  同一 Content  X-as-a-Service としての動画再生サブシステムの設計  03 

Content クラス概要  Content • channelId: String（ARIN 形式） • title: String
• contentRole: ContentRole? • … 視聴対象のコンテンツを表す  • 対応する動画リソースへの  識別子  • タイトルやコンテンツが持つ役割などのメタデータ  ContentRole（列挙型） • ANGLE_MAIN • ANGLE_SUB ※ABEMA では任意アセットグループを  ARIN（ABEMA Resource Identiﬁer Name）という識別子で識別している  X-as-a-Service としての動画再生サブシステムの設計  03 

ContentSession クラス概要  コンテンツの視聴の開始から終了までの状態を制御  • ステートフル  • 視聴方法（Use case）の選択肢を与える 
• 再生やトリックプレイの制御  • タイムラインのサムネイルの提供  • 広告制御  ContentSession • content: Content • state: State • availableUseCases: UseCase[] • … • prepareToPlay(UseCase?) • play() • pause() • seek(toMs: Long) • getTimelineThumbnail(atMs: Long) • setAdInformation(AdInformation) • … X-as-a-Service としての動画再生サブシステムの設計  03 

Fluﬀy による隠蔽  UseCase と ContentSession  プロダクトの関心 • ユーザーが視聴するコンテンツ •
ユーザーがどのように視聴するか Fluffy の関心 • 再生の安定性 • 動画の解像度 • インストリーム広告の挿入手段 • コンテンツ保護手段 Content  UseCase  Content  Session  X-as-a-Service としての動画再生サブシステムの設計  03 

UseCase と ContentSession  プロダクト  Fluffy  • Fluffy はプロダクトに Use case（利用可能な視聴方法）を提示 
• プロダクトは Fluffy に ContentSession を介して Use case を指定  UseCase  Content  Session  available  UseCases  X-as-a-Service としての動画再生サブシステムの設計  03 

UseCase 列挙型概要  UseCase • LIVE • STARTOVER • CATCHUP •
LOW_LATENCY • … X-as-a-Service としての動画再生サブシステムの設計  03  1 つのコンテンツに対して  異なる視聴ユースケースを提供  • ライブ視聴（LIVE）  • 追っかけ視聴（STAROVER）  • 見逃し視聴（CATCHUP）  • 低遅延優先視聴（LOW_LATENCY）  • … 

UseCase 列挙型概要  1 つのコンテンツに対して  異なる視聴ユースケースを提供  • ライブ視聴（LIVE）  • 追っかけ視聴（STAROVER）  •
見逃し視聴（CATCHUP）  • 低遅延優先視聴（LOW_LATENCY）  • …  UseCase • LIVE • STARTOVER • CATCHUP • LOW_LATENCY • … 同じ映像ソースを  異なる方法で視聴しているだけ  X-as-a-Service としての動画再生サブシステムの設計  03 

同一エンコードのマニフェスト違い  （DASH）で Use case を表す  ライブ視聴の場合  <MPD … type=”dynamic” …> 
…  <SegmentTimeline>  <S t=”882000” d=”750000” r=”7” />  <S t=”882000” d=”558000” />  </SegmentTimeline>  …  </MPD>  <MPD … type=”dynamic” …>  …  <SegmentTimeline>  <S t=”0” d=”750000” />  <S d=”750000” />  …  </SegmentTimeline>  …  </MPD>  追っかけ視聴の場合  見逃し視聴  <MPD … type=”static” …>  …  <SegmentTimeline>  <S t=”0” d=”750000” />  <S d=”750000” />  …  </SegmentTimeline>  …  </MPD>  X-as-a-Service としての動画再生サブシステムの設計  03 

同一エンコードのプレイリスト違い  （HLS）で Use case を表す  ライブ視聴の場合  #EXTM3U  #EXT-X-VERSION:6  #EXT-X-TARGETDURATION:9  #EXT-X-MEDIA-SEQUENCE:2 
#EXT-X-MAP:URI="init.mp4"  #EXTINF:8.333,  segment_1632000.m4s  #EXTINF:8.333,  segment_2385000.m4s  #EXTM3U  #EXT-X-PLAYLIST-TYPE:EVENT  #EXT-X-VERSION:6  #EXT-X-TARGETDURATION:9  #EXT-X-MEDIA-SEQUENCE:0  #EXT-X-MAP:URI="init.mp4"  #EXTINF:8.333,  segment_132000.m4s  #EXTINF:8.333,  segment_882000m4s  …  追っかけ視聴の場合  見逃し視聴  #EXTM3U  #EXT-X-PLAYLIST-TYPE:VOD  #EXT-X-VERSION:6  #EXT-X-TARGETDURATION:9  #EXT-X-MEDIA-SEQUENCE:0  #EXT-X-MAP:URI="init.mp4"  #EXTINF:8.333,  segment_132000.m4s  #EXTINF:8.333,  segment_882000.m4s  …  #EXT-X-ENDLIST  X-as-a-Service としての動画再生サブシステムの設計  03 

同一映像ソースのプレイリスト違い  （HLS）で低遅延 Use case を表す    HLS ライブ視聴の場合  #EXTM3U  #EXT-X-VERSION:6 
#EXT-X-TARGETDURATION:9  #EXT-X-MEDIA-SEQUENCE:2  #EXT-X-MAP:URI="init.mp4"  #EXTINF:8.333,  segment_1632000.m4s  #EXTINF:8.333,  segment_2385000.m4s  #EXTM3U  #EXT-X-VERSION:6  #EXT-X-TARGETDURATION:9  #EXT-X-MEDIA-SEQUENCE:2  #EXT-X-MAP:URI="init.mp4"  #EXTINF:8.333,  segment_1632000.m4s  #EXT-X-PART:DURATION=1.02,URI=”2385000.mp 4”,BYTERANGE=20000@0  #EXT-X-PART:DURATION=1.02,URI=”2385000.mp 4”,BYTERANGE=23000@20000  …  LL-HLS ライブ視聴の場合  X-as-a-Service としての動画再生サブシステムの設計  03 

視聴ユースケースの技術的解釈  同一映像ソースに対する複数の視聴方法  従来の再生モジュールでは再生セッションを切り替える必要があった  異なるエンコードやマニフェストで表現される  （※ MPEG-DASH や HLS の場合）  X-as-a-Service

UseCase と ContentSession  プロダクト  Fluﬀy  Content  Session  ライブ・マニフェスト  追っかけ視聴マニフェスト  見逃し視聴マニフェスト 
低遅延視聴マニフェスト  UseCase  LIVE  1  1  X-as-a-Service としての動画再生サブシステムの設計  03  • Fluﬀy では UseCase の切り替えは 1 セッションです 

UseCase と ContentSession  プロダクト  Fluﬀy  UseCase  STARTOVER  Content  Session  ライブ・マニフェスト 
追っかけ視聴マニフェスト  見逃し視聴マニフェスト  低遅延視聴マニフェスト  UseCase  LIVE  1  2  1  2  X-as-a-Service としての動画再生サブシステムの設計  03  • Fluﬀy では UseCase の切り替えは 1 セッションです 

UseCase と ContentSession  • Fluﬀy では UseCase の切り替えは 1 セッションです 
プロダクト  Fluﬀy  UseCase  STARTOVER  Content  Session  ライブ・マニフェスト  追っかけ視聴マニフェスト  見逃し視聴マニフェスト  低遅延視聴マニフェスト  UseCase  LIVE  1  2  1  2  1セッション  X-as-a-Service としての動画再生サブシステムの設計  03 

UseCase と ContentSession  • Fluﬀy では UseCase の切り替えは 1 セッションです 
プロダクト  Fluﬀy  UseCase  STARTOVER  Content  Session  ライブ・マニフェスト  追っかけ視聴マニフェスト  見逃し視聴マニフェスト  低遅延視聴マニフェスト  UseCase  LIVE  1  2  1  2  1セッション  X-as-a-Service としての動画再生サブシステムの設計  03  セッションで共通なデータに  キャッシュを効かせるなど最適化の選択肢ができます  

最適な動画ストリームを選択するのは試行錯誤を要する  X-as-a-Service としての動画再生サブシステムの設計  03 

最適な動画ストリームを選択するのは試行錯誤を要する  ソフトウェアの変更影響が動画再生サブシステム内で  完結することによって試行錯誤が加速する  X-as-a-Service としての動画再生サブシステムの設計  03 

動画配信基盤開発チーム／コンテンツ管理基盤開発チーム  <Platform チーム>  動画配信基盤開発チームと Streaming Client チームで  視聴品質に関わる意思決定が完結する  X-as-a-Service としての動画再生サブシステムの設計  03 

動画配信基盤開発チーム／コンテンツ管理基盤開発チーム  <Platform チーム>  PlaybackResource インターフェースで情報を交換  X-as-a-Service としての動画再生サブシステムの設計  03 

PlaybackResource  同一映像ソースから出力した  複数の再生用リソースの情報  • 視聴ユースケース  • DRM  • エンコーディング・パターン  •
広告挿入方式  • CDN バランシング手段  message PlaybackResource {    message Manifest {  string arin = 1;  url = 2;  Manifest failover = 3;  AdInsertion adInsertion = 4;  CdnBalancing = 5;  …  }    message Stream {  Drm drm = 1;  UseCase useCase = 2;  FrameRate = frameRate = 3;  repeated Manifest manifests = 4;  …  }    string arin = 1;  repeated Stream streams = 2;  …    }  X-as-a-Service としての動画再生サブシステムの設計  03 

PlaybackResource  同一映像ソースから出力した  複数の再生用リソースの情報  • 視聴ユースケース  • DRM  • エンコーディング・パターン  •
広告挿入方式  • CDN バランシング手段  この情報の組み合わせから  Fluﬀy が自身の環境に  最適な動画マニフェストを判断する  message PlaybackResource {    message Manifest {  string arin = 1;  url = 2;  Manifest failover = 3;  AdInsertion adInsertion = 4;  CdnBalancing = 5;  …  }    message Stream {  Drm drm = 1;  UseCase useCase = 2;  FrameRate = frameRate = 3;  repeated Manifest manifests = 4;  …  }    string arin = 1;  repeated Stream streams = 2;  …    }  X-as-a-Service としての動画再生サブシステムの設計  03 

PlaybackResource から動画マニフェストの決定  Fluﬀy  プロダクト  配信基盤  Content  Usecase  ARIN  Playback  Resource 
動画マニフェスト選択  X-as-a-Service としての動画再生サブシステムの設計  03 

PlaybackResource から動画マニフェストの決定  Fluﬀy は次のように複数のマニフェストから再生するものを決定する  1. 再生可能な動画ストリームの選択  2. 収益性、セキュリティ、冗長化の観点で動画マニフェストの選択  3. フェールオーバーするマニフェストチェーンの構築 

PlaybackResource から動画マニフェストの決定  再生可能な動画ストリームの選択  X-as-a-Service としての動画再生サブシステムの設計  03 

PlaybackResource から動画マニフェストの決定  再生可能な動画ストリームの選択  • CDM（Content Decryption Module）が対応している DRM  X-as-a-Service としての動画再生サブシステムの設計 
03 

PlaybackResource から動画マニフェストの決定  再生可能な動画ストリームの選択  • CDM（Content Decryption Module）が対応している DRM  • デバイスのデコード性能に見合うエンコーディング・パターン 

PlaybackResource から動画マニフェストの決定  再生可能な動画ストリームの選択  • CDM（Content Decryption Module）が対応している DRM  • デバイスのデコード性能に見合うエンコーディング・パターン 
• ContentSession に指定された視聴ユースケース  X-as-a-Service としての動画再生サブシステムの設計  03 

PlaybackResource から動画マニフェストの決定  Fluﬀy は次のように複数のマニフェストから再生するものを決定する  1. 再生可能な動画ストリームの選択  2. 収益性、セキュリティ、冗長化の観点で動画マニフェストの選択  3. フェールオーバーするマニフェストチェーンの構築 

PlaybackResource から動画マニフェストの決定  収益性、セキュリティ、負荷分散の観点で動画マニフェストの選択  X-as-a-Service としての動画再生サブシステムの設計  03 

PlaybackResource から動画マニフェストの決定  収益性の観点で動画マニフェストの選択  • 最も収益率が高く、安定している広告挿入方式を選択  ◦ 収益率は、パーソナライズド広告＞クラスタリング広告＞オール配信広告の順に高い  ◦ 安定性はその逆になる  X-as-a-Service

PlaybackResource から動画マニフェストの決定  セキュリティの観点で動画マニフェストの選択  • 自身の環境で最も強固なセキュリティの DRM を選択  ◦ 複数の DRM
キーシステムをサポートしている場合、  TEE（Truested Execution Environment）と見なされる環境で  処理可能なシステムを最優先  ▪ 例：Android で TEE 処理の Widevine L1、ソフトウェア処理の PlayReady SL2000 をサポートしている場合、可能な限り Widevine を選択  X-as-a-Service としての動画再生サブシステムの設計  03 

PlaybackResource から動画マニフェストの決定  冗長化の観点で動画マニフェストの選択  • 最も冗長化された通信経路／オリジンの選択肢がある  マニフェストを選択する  ◦ マルチ CDN で通信が冗長化されている場合はより柔軟な負荷分散制御が可能になる 
◦ マルチリージョンでオリジンが冗長化されている場合は障害時によりシームレスなフォールバックが可能になる  X-as-a-Service としての動画再生サブシステムの設計  03 

PlaybackResource から動画マニフェストの決定  Fluﬀy は次のように複数のマニフェストから再生するものを決定する  1. 再生可能な動画ストリームの選択  2. 収益性、セキュリティ、負荷分散の観点で動画マニフェストの選択  3. フェールオーバーするマニフェストチェーンの構築 

PlaybackResource から動画マニフェストの決定  フェールオーバーするマニフェストチェーンの構築  • 絶対に止めることが許されない配信は多重にフェールオーバー先を用意する  • 広い帯域を確保している経路順、キャパシティに余裕がある経路順、コールドスタンバイしている経路順などを通過するマニフェストをチェーンに並べる 
◦ Fluﬀy は最初に選択したマニフェストで再生が失敗したり不安定になった場合、構築したマニフェストチェーン順にフェールオーバーを繰り返す機構を持つ  X-as-a-Service としての動画再生サブシステムの設計  03 

Fluﬀy のゴール  開発する動画再生サブシステムが  • プロダクトから独立して動画視聴品質を改善し続けられること  • マルチプラットフォームに対応したソフトウェア設計であること  X-as-a-Service としての動画再生サブシステムの設計  03 

マルチプラットフォームに対応したソフトウェア設計であること  X-as-a-Service としての動画再生サブシステムの設計  03 

マルチプラットフォームに対応したソフトウェア設計であること  プラットフォームごとの独自のお約束がない統一されたアーキテクチャ  X-as-a-Service としての動画再生サブシステムの設計  03 

マルチプラットフォームに対応したソフトウェア設計であること  動画エンジニアのアサインを容易にする  プラットフォームごとの独自のお約束がない統一されたアーキテクチャ  X-as-a-Service としての動画再生サブシステムの設計  03 

動画エンジニアのアサインを容易にする  ABEMA がサポートするデバイスは 20 種類以上  • iPhone  • iPad  •
Apple TV  • Android Smartphone  • Android Tablet  • Android TV  • Fire Tablet  • Amazon Fire TV  • Google Chrome  • Mozilla Firefox  • Internet Explorer  • Microsoft Edge  • Apple Safari  • Google Chromecast  • SONY BRAVIA  • Panasonic VIERA  • Panasonic DIGA  • TOSHIBA REGZA  • FUNAI  • LEOPALACE21 Life Stick  • Aladdin X  • ...  X-as-a-Service としての動画再生サブシステムの設計  03 

動画エンジニアのアサインを容易にする  ABEMA がサポートするデバイスは 20 種類以上  • iPhone  • iPad  •
Apple TV  • Android Smartphone  • Android Tablet  • Android TV  • Fire Tablet  • Amazon Fire TV  • Google Chrome  • Mozilla Firefox  • Internet Explorer  • Microsoft Edge  • Apple Safari  • Google Chromecast  • SONY BRAVIA  • Panasonic VIERA  • Panasonic DIGA  • TOSHIBA REGZA  • FUNAI  • LEOPALACE21 Life Stick  • Aladdin X  • ...  X-as-a-Service としての動画再生サブシステムの設計  03  “いつでも、どこでも” 楽しめることをミッションに掲げる ABEMA は  まだまだサポートデバイスを増やしていく 

歴史的経緯があるプラットフォームごとの設計  • もともと複数の Stream-aligned チームの一部のメンバーが扱っていたドメイン  ◦ iOS の AVPlayer
を拡張した動画プレイヤー  ◦ Android の ExoPlayer を拡張した動画プレイヤー  ◦ Web Browser の Flashls、THEOplayer、dash.js  • プラットフォームごとに設計はバラバラ  ◦ 動画再生の Complicated subsystem チームはプラットフォームごとの  独自マナーを先に修得しなければならない  X-as-a-Service としての動画再生サブシステムの設計  03 

再生クライアントエンジニア・リソースのサイロ化  再生課題に取り組む前に  プラットフォームの設計に詳しいことがアサイン可能な人材の前提条件  X-as-a-Service としての動画再生サブシステムの設計  03 

再生クライアントエンジニア・リソースのサイロ化  再生課題に取り組む前に  プラットフォームの設計に詳しいことがアサイン可能な人材の前提条件  プラットフォーム間の設計の差異がリソースのサイロ化  X-as-a-Service としての動画再生サブシステムの設計  03 

再生クライアントエンジニア・リソースのサイロ化  再生課題に取り組む前に  プラットフォームの設計に詳しいことがアサイン可能な人材の前提条件  プラットフォーム間の設計の差異がリソースのサイロ化  再生クライアントエンジニアの流動性が低いため  柔軟な開発ライン数確保のボトルネックに  X-as-a-Service としての動画再生サブシステムの設計  03 

一意の UML によるインターフェース統一  言語（プラットフォーム）間の設計を統一する  • Swift  • Kotlin  • TypeScript 
• C#  X-as-a-Service としての動画再生サブシステムの設計  03 

一意の UML によるインターフェース統一  言語（プラットフォーム）間の設計を統一する  • Swift  • Kotlin  • TypeScript 
• C#  言語に最適化されたマナーよりも優先してインターフェースを  統一することで、後に共通ロジックを WebAssemblyや Kotlin MPP など  のマルチプラットフォームコードで段階的に差し替えることを目指す  Wasm  Kotlin  MPP  X-as-a-Service としての動画再生サブシステムの設計  03 

04 X-as-a-Service からの  動画再生サブシステムの進化 

X-as-a-Service からの動画再生サブシステムの進化  ここからは X-as-a-Service の Fluﬀy が  どのように動画視聴システムの進化を容易にするかを  実例を交えてお話します  04 

Fluﬀy は『FIFA ワールドカップカタール 2022』（2022 年 11 月）から導入  https://times.abema.tv/ﬁfaworldcup/articles/-/10053448  X-as-a-Service
からの動画再生サブシステムの進化  04 

Fluﬀy は『FIFA ワールドカップカタール 2022』（2022 年 11 月）から導入  https://times.abema.tv/ﬁfaworldcup/articles/-/10053448  ABEMA
にとっては未踏の規模と品質を提供する  動画視聴システムのために開発  X-as-a-Service からの動画再生サブシステムの進化  04 

マルチ CDN 制御  X-as-a-Service からの動画再生サブシステムの進化  04 

マルチ CDN 制御  マルチ CDN は大規模生配信において特に重要な負荷制御機構  X-as-a-Service からの動画再生サブシステムの進化  04 

マルチ CDN 制御  マルチ CDN は大規模生配信において特に重要な負荷制御機構  動画配信の CDN 切り替えロジックは Stream-aligned
チームにとって無関心であるべき領域 X-as-a-Service からの動画再生サブシステムの進化  04 

チームにとって無関心であるべき領域マルチ CDN 制御によって再生に至るまでの手順に大きな変更を要する X-as-a-Service からの動画再生サブシステムの進化  04 

チームにとって無関心であるべき領域マルチ CDN 制御によって再生に至るまでの手順に大きな変更を要するプロダクトの変更と分離して  X-as-a-Service が  柔軟に切り替えることができる必要がある  X-as-a-Service からの動画再生サブシステムの進化  04 

マルチ CDN 制御選択のフロー  プロダクト  Fluﬀy  動画配信システム  ARIN  Content ARIN CDN
制御選択肢一覧  PlaybackResource マルチ CDN 制御手段を動的に切り替える機能を搭載  • プロダクトは ARIN でコンテンツを指定するのみ  • PlaybackResource で複数の CDN 制御選択肢の提供を制御  • 選択肢に従い Fluﬀy 内部で CDN を複数使うか、  どう CDN を切り替えるかを決定する  X-as-a-Service からの動画再生サブシステムの進化  04 

PlaybackResource で制御するマルチ CDN  PlaybackResource から指定しうる選択肢のパターン  • ストリームのマルチ CDN の制御方法を直接指定する  •
ストリームで使用可能なマルチ CDN ソリューションを指定する  • ストリームで使用可能な CDN の選択肢のみを提供する  X-as-a-Service からの動画再生サブシステムの進化  04 

『FIFA ワールドカップカタール 2022』  大規模なライブイベントを安定して配信するためにマルチ CDN を活用  Tokyo Origin Fluffy
Akamai Seoul Origin CloudFront X-as-a-Service からの動画再生サブシステムの進化  04 

提供を検討したマルチ CDN バランシング・パターン  • マニフェスト単位のバランシング  • セグメント単位のバランシング  X-as-a-Service からの動画再生サブシステムの進化  04 

提供を検討したマルチ CDN バランシング・パターン  マニフェスト単位のバランシング  • 再生開始時に CDN 選択サーバーに問い合わせ、  選択された CDN
からマニフェスト更新とセグメントを  取得し続ける  クライアントサイド制御の一般的なバランシング・パターン  ロジックで単純だが、負荷分散の柔軟性は高くない   X-as-a-Service からの動画再生サブシステムの進化  04 

提供を検討したマルチ CDN バランシング・パターン  セグメント単位のバランシング  • 再生開始時に CDN 選択サーバーに問い合わせ、最初に 1 つの
CDN を選択。以降もマニフェストの更新やセグメントごとに CDN を切り替える  バランシング・ロジックは複雑だが、  再生中でも CDN の状態によって負荷調整可能  X-as-a-Service からの動画再生サブシステムの進化  04 

NPAW によるマルチ CDN ソリューション  NPAW CDN Balancing を利用した 2 種類のバランシング機能 
• NPAW CDN Selector → マニフェスト単位のバランシング  • NPAW CDN Active Switching w/ NPAW CDN Selector  → セグメント単位のバランシング  X-as-a-Service からの動画再生サブシステムの進化  04 

Active Switching の検証  NPAW CDN Active Switching  • 専用の SDK
を使用  • スタンドアローンで CDN のヘルスチェック実施  • マニフェストマニピュレーションでセグメント単位で  CDN をバランシング  X-as-a-Service からの動画再生サブシステムの進化  04 

Active Switching の検証  NPAW CDN Active Switching  • 専用の SDK
を使用  • スタンドアローンで CDN のヘルスチェック実施  • マニフェストマニピュレーションでセグメント単位で  CDN をバランシング  マニピュレーション後マニフェストが  ABEMA では想定していない変更  X-as-a-Service からの動画再生サブシステムの進化  04 

Active Switching の検証  CDN 制御の変更は Fluﬀy と動画配信システムで完結するため  イベント開催ギリギリまで SDK を検証することができた 
プロダクト  Fluﬀy  動画配信システム  ARIN  Content ARIN CDN 制御選択肢一覧  PlaybackResource X-as-a-Service からの動画再生サブシステムの進化  04 

Active Switching の検証  CDN 制御の変更は Fluﬀy と動画配信システムで完結するため  イベント開催ギリギリまで SDK を検証することができた 
プロダクト  Fluﬀy  動画配信システム  ARIN  Content ARIN CDN 制御選択肢一覧  PlaybackResource 最終的に Active Switching は見送り  NPAW CDN Selector と独自の CDN バランシングアルゴリズムを採用し、本番を向かえた  X-as-a-Service からの動画再生サブシステムの進化  04 

NPAW CDN Selector で利用したバランシング機能  • 重み付きラウンドロビン  ◦ CDN ごとの帯域状態、価格帯などに合わせた制御  •
視聴形態によって異なるルールの適用  ◦ ライブ再生  ◦ 追っかけ再生  ◦ オンデマンド再生  • アングルによって異なるルールの適用  ◦ メインアングルとサブアングルでは求められる冗長性や品質観点が異なる  X-as-a-Service からの動画再生サブシステムの進化  04 

視聴形態によって異なるルールの適用  ◦ ライブ再生  ◦ 追っかけ再生  ◦ オンデマンド再生  • アングルによって異なるルールの適用  ◦ メインアングルとサブアングルでは求められる冗長性や品質観点が異なる  NPAW は  再生品質計測ソリューションも提供  再生品質を重み係数に反映可能  X-as-a-Service からの動画再生サブシステムの進化  04 

視聴形態によって異なるルールの適用  ◦ ライブ再生  ◦ 追っかけ再生  ◦ オンデマンド再生  • アングルによって異なるルールの適用  ◦ メインアングルとサブアングルでは求められる冗長性や品質観点が異なる  CDN 決定に異なるロジックが必要  • ライブは一時的な負荷が高い  ◦ 性能＞料金  • オンデマンドは負荷に時間差がある  ◦ 料金＞性能  X-as-a-Service からの動画再生サブシステムの進化  04 

視聴形態によって異なるルールの適用  ◦ ライブ再生  ◦ 追っかけ再生  ◦ オンデマンド再生  • アングルによって異なるルールの適用  ◦ メインアングルとサブアングルでは求められる冗長性や品質観点が異なる  • 通常メインアングルが  同時視聴数が一番多い  • メインアングルの映像品質だけが  サブより高いことがある  ◦ 1 セッションあたりの  トラフィック量増加  X-as-a-Service からの動画再生サブシステムの進化  04 

マルチリージョン制御  X-as-a-Service からの動画再生サブシステムの進化  04 

マルチリージョン制御  ABEMA では動画配信システムのオリジンに  パブリッククラウド（『FIFA ワールドカップカタール 2022』では AWS）を利用  リージョンの多重化で 
リージョン障害起因の視聴障害を回避  X-as-a-Service からの動画再生サブシステムの進化  04 

パブリッククラウドの SLA  https://aws.amazon.com/medialive/sla/  X-as-a-Service からの動画再生サブシステムの進化  04 

リージョン切り替え制御  リージョンの障害時に  別リージョンの動画配信システムにリクエストを切り替える方法を検討  • PlaybackResource から使用するリージョンを指示  • 配信経路障害を確認するための API をポーリング 
• CDN バランシング機能にリージョン・バランシング機能を追加  X-as-a-Service からの動画再生サブシステムの進化  04 

リージョン切り替え制御  リージョンの障害時に  別リージョンの動画配信システムにリクエストを切り替える方法を検討  • PlaybackResource から使用するリージョンを指示  • 配信経路障害を確認するための API をポーリング 
• CDN バランシング機能にリージョン・バランシング機能を追加  『FIFA ワールドカップカタール 2022』では  残りの開発時間を考慮してこの手段を選択  X-as-a-Service からの動画再生サブシステムの進化  04 

マルチリージョンのバランシング機能  ある CDN で再生が失敗した場合、  CDN に起因した障害かリージョンに起因した障害か判定する術がない  → 次に選択する経路は別リージョンに繋げている同一 CDN を選択する 
CDN Group A CDN A for Region 1 CDN A for Region 2 CDN Group B CDN B for Region 1 CDN B for Region 2 Failure Failure Failure Failure • リージョン切り替えを優先した CDN バランシング  X-as-a-Service からの動画再生サブシステムの進化  04 

マルチリージョン制御の詳細を隠蔽  リージョンの変更は 1 ContentSession の中で扱う  Stream-aligned のプロダクトはリージョンの切り替わりを意識しない   プロダクト  Fluﬀy 
動画配信システム  ARIN  Content ARIN リージョン制御選択肢一覧  PlaybackResource エラーハンドルによるリージョン切替  Content  Session X-as-a-Service からの動画再生サブシステムの進化  04 

デバイスに最適化したエンコーディング・パッケージ  X-as-a-Service からの動画再生サブシステムの進化  04 

デバイスごとのエンコーディング・パッケージ選択  ABEMA（当時 AbemaTV）が開局した 2016 年より  美しい映像素材を届けることができる技術的下地が整ってきている  X-as-a-Service からの動画再生サブシステムの進化  04 

デバイスごとのエンコーディング・パッケージ選択  ABEMA（当時 AbemaTV）が開局した 2016 年より  美しい映像素材を届けることができる技術的下地が整ってきている  • 4K、HFR（High Frame Rate）、HDR（High
Dynamic Range）など従来より高品質な映像素材を届けることができる時代  X-as-a-Service からの動画再生サブシステムの進化  04 

デバイスごとのエンコーディング・パッケージ選択  ABEMA（当時 AbemaTV）が開局した 2016 年より  美しい映像素材を届けることができる技術的下地が整ってきている  • 4K、HFR（High Frame Rate）、HDR（High
Dynamic Range）など従来より高品質な映像素材を届けることができる時代  映像の解像度（画素数、フレームレート、輝度）が  高くなればデバイスカバレッジとの間にトレードオフが生まれる  X-as-a-Service からの動画再生サブシステムの進化  04 

視聴者のデバイスにとって最高の映像品質を届ける  X-as-a-Service からの動画再生サブシステムの進化  04 

視聴者のデバイスにとって最高の映像品質を届ける  デバイス自身が快適に再生可能な  エンコーディング・パッケージを選択すればいい  X-as-a-Service からの動画再生サブシステムの進化  04 

エンコーディング・パターン  動画のエンコーディングのユースケースを大きく 3 パターンに分け、  デバイスのユースケースと性能に最適なエンコーディングを提供する  X-as-a-Service からの動画再生サブシステムの進化  04 

エンコーディング・パターン  動画のエンコーディングのユースケースを大きく 3 パターンに分け、  デバイスのユースケースと性能に最適なエンコーディングを提供する  • Defender  ◦ どんなデバイスでも再生可能な動画ストリームを提供する  ◦
社会インフラを支える動画ストリームを提供する  X-as-a-Service からの動画再生サブシステムの進化  04 

社会インフラを支える動画ストリームを提供する  • Midﬁelder  ◦ 時流に準拠した標準的なデバイスに最適な動画品質を提供する  X-as-a-Service からの動画再生サブシステムの進化  04 

社会インフラを支える動画ストリームを提供する  • Midﬁelder  ◦ 時流に準拠した標準的なデバイスに最適な動画品質を提供する  • Striker  ◦ スポーツの種類や音楽ライブなどのコンテンツ特性を最大限に活かし、その時代の最高のエンターテイメントを提供する  ▪ 例：HFR、Immersive Audio  X-as-a-Service からの動画再生サブシステムの進化  04 

『FIFA ワールドカップカタール 2022』では  サッカーの映像特性を最大限に活かすために HFR の Striker を用意  Striker
- コンテンツ最適化品質 Defender - カバレッジ優先品質構成 FPS 59.94 29.97 Rate Control Mode V:QVBR/A:VBR V/A:CBR Proﬁle/Level [email protected]/以下Main/4.2 Main/4固定 1080p V:QVBR Max12M（Buf:24M） A:VBR 256k Stereo V:CBR 8M(Buf:自動) A:128k Stereo 720p V:QVBR Max8M(Buf:16M) A:VBR 256k Stereo V:;CBR 4M(Buf:自動) A:128k Stereo 480p V:QVBR Max4M(Buf:8M) A:VBR 256k Stereo V:CBR 2M(Buf:自動) A:128k Stereo 360p V:QVBR Maxim (Buf:4M) A:VBR 256k Stereo V:CBR 1M(Buf:自動) A:128k Stereo 240p V:CBR 0.5M(Buf:自動) A:128k Stereo V:CBR 0.5M(Buf:自動) A:128k Stereo X-as-a-Service からの動画再生サブシステムの進化  04 

デバイスごとのエンコーディング・パッケージ選択  Fluﬀy は PlaybackResource の情報と自デバイスのデコード性能から  どのエンコーディングパッケージを再生するかを動的に選択する  • iOS／tvOS  ◦ 全機種においてメディア処理性能が高いため、Striker
を再生  • Android mobile / Android TV / Fire TV  ◦ MediaCodecInfo.VideoCapabilities の情報を必要条件  ◦ 再生エージングテストを通過したものを  各エンコーディングのエンコーディング・パッケージ許可リストに追加  • Web Browser / HTML5-based TV  ◦ Media Capabilities API の情報を必要条件 … にできると良いのだが、  適切に判定できる基準値を得ることは難しいため Defender にマッピング  X-as-a-Service からの動画再生サブシステムの進化  04 

デバイスごとのエンコーディング・パッケージ選択  エンコーディング・パッケージの決定も  Fluﬀy と動画配信システムの間で完結  プロダクト  Fluﬀy  動画配信システム  ARIN  Content ARIN
パッケージ一覧  PlaybackResource X-as-a-Service からの動画再生サブシステムの進化  04 

デバイスごとのエンコーディング・パッケージ選択  エンコーディング・パッケージの決定も  Fluﬀy と動画配信システムの間で完結  プロダクト  Fluﬀy  動画配信システム  ARIN  Content ARIN
パッケージ一覧  PlaybackResource 現在も、Stream-aligned のプロダクトと独立して  パッケージのバリエーションを追加中  X-as-a-Service からの動画再生サブシステムの進化  04 

低遅延優先視聴ユースケース  X-as-a-Service からの動画再生サブシステムの進化  04 

低遅延優先視聴ユースケース  • 生配信映像の場合は遅延なく視聴できることに付加価値がある  • 低遅延性の実現にはトレードオフが発生する  • トレードオフの内容は低遅延向けプロトコルの詳細に依存  X-as-a-Service からの動画再生サブシステムの進化  04 

低遅延用プロトコル  • 動画の低遅延用プロトコルは  複数ある  • 各プロトコルには  メリット／デメリットがある  ◦ トライアンドエラーが必要  •
特定のプロトコルに限定せずに低遅延視聴ユースケースを提供したい  https://www.theoplayer.com/blog/hesp-delivering-subsecond-lantency  X-as-a-Service からの動画再生サブシステムの進化  04 

低遅延視聴の手段の詳細を隠蔽する  プロダクト  Fluﬀy  Stream-aligned のプロダクトは再生に  どの低遅延向けプロトコルを選択するかは知らない  UseCase  LOW_  LATENCY  Content 
Session  CMAF-CTE  LL-HLS  HESP  WebRTC  Available UseCases  X-as-a-Service からの動画再生サブシステムの進化  04 

低遅延動画配信プロトコル - LL-HLS  #EXTINF:4.00008,  fileSequence269.mp4  #EXTINF:4.00008,  fileSequence270.mp4  #EXT-X-PART:DURATION=0.33334,URI="filePart271.0.mp4"  #EXT-X-PART:DURATION=0.33334,URI="filePart271.1.mp4"  #EXT-X-PART:DURATION=0.33334,URI="filePart271.2.mp4" 
#EXT-X-PART:DURATION=0.33334,URI="filePart271.3.mp4"  #EXT-X-PART:DURATION=0.33334,URI="filePart271.4.mp4",INDEPENDENT=YES  #EXT-X-PART:DURATION=0.33334,URI="filePart271.5.mp4"  #EXT-X-PART:DURATION=0.33334,URI="filePart271.6.mp4"  #EXT-X-PART:DURATION=0.33334,URI="filePart271.7.mp4"  #EXT-X-PART:DURATION=0.33334,URI="filePart271.8.mp4",INDEPENDENT=YES  #EXT-X-PART:DURATION=0.33334,URI="filePart271.9.mp4"  #EXT-X-PART:DURATION=0.33334,URI="filePart271.10.mp4"  #EXT-X-PART:DURATION=0.33334,URI="filePart271.11.mp4"  …  #EXT-X-PART:DURATION=0.33334,URI="filePart273.1.mp4"  #EXT-X-PART:DURATION=0.33334,URI="filePart273.2.mp4"  #EXT-X-PART:DURATION=0.33334,URI="filePart273.3.mp4"  #EXT-X-PRELOAD-HINT:TYPE=PART,URI="filePart273.4.mp4"  Parts によるメディア取得  • 独立してアドレス可能  • 新しい part を取得するために要 Manifest 更新  • IDR フレームのマーク  ◦ デコード開始可能な位置  X-as-a-Service からの動画再生サブシステムの進化  04 

低遅延動画配信プロトコル - CMAF-CTE  mdat moof mdat moof mdat moof mdat
moof mdat moof moof mdat 同じサンプルを複数の CMAF チャンクに Encode flush Encode flush Encode flush Encode flush X-as-a-Service からの動画再生サブシステムの進化  04 

X-as-a-Service からの動画再生サブシステムの進化  低遅延動画配信プロトコル - HESP  04  2 種類のストリームで構成  • Initialization
stream  ◦ 全てキーフレーム  ◦ 再生継続するのは高コスト  • Continuation stream  ◦ Initialization stream の後に  来るストリーム  ◦ 1 つ前のフレームだけ参照する 

低遅延動画配信プロトコル  X-as-a-Service からの動画再生サブシステムの進化  04 

低遅延動画配信プロトコル  プロトコルの差分が特に大きい  X-as-a-Service からの動画再生サブシステムの進化  04 

低遅延動画配信プロトコル  プロトコルの差分が特に大きい  Fluﬀy により低遅延動画配信プロトコルに対する検証容易性が上がり  最適化に対して拡張性を開くことができた  X-as-a-Service からの動画再生サブシステムの進化  04 

低遅延視聴機能提供の決断を直前まで遅らせる  提供可能なユースケースの決定も Fluﬀy と動画配信システムの間で完結  プロダクト  Fluﬀy  動画配信システム  ARIN  Content ARIN
ストリーム一覧  PlaybackResource • CMAF-CTE と LL-HLS による低遅延配信の提供をイベント開催直前まで検討  • DRM や CM 挿入手段の条件に見合わず提供を見送り  Available  UseCases X-as-a-Service からの動画再生サブシステムの進化  04 

インストリーム動画広告の進化  X-as-a-Service からの動画再生サブシステムの進化  04 

インストリーム動画広告  無料で動画コンテンツを提供するために番組の途中で挟む  インストリーム動画広告は大事なマネタイズ手段  インストリーム動画広告の挿入方法は Stream-aligned チームにとって無関心であるべき領域 X-as-a-Service からの動画再生サブシステムの進化 
04 

インストリーム動画広告  無料で動画コンテンツを提供するために番組の途中で挟む  インストリーム動画広告は大事なマネタイズ手段  インストリーム動画広告の挿入方法は Stream-aligned チームにとって無関心であるべき領域インストリーム動画広告はそれ単体で認知負荷が高い領域
X-as-a-Service からの動画再生サブシステムの進化  04 

動画広告を扱う規格  動画広告を扱う規格も 1 つ 1 つ大きい  IAB Tech Lab が標準化する代表的な規格 
• VAST - Video Ad Serving Template  ◦ 広告配信サーバーと動画プレイヤー間のデータの受け渡し方法を記述する規格  • VMAP - Digital Video Multiple Ad Playlist  ◦ 広告挿入位置を記述する規格  • VPAID - Video Player Ad Interface Deﬁnition  ◦ 動画広告と動画プレイヤー間の相互通信の挙動を記述する規格  • SIMID - Secure Interactive Media Interface Deﬁnition  ◦ VPAID の後継規格  X-as-a-Service からの動画再生サブシステムの進化  04 

X-as-a-Service からの動画再生サブシステムの進化  04 

プロダクトや Fluﬀy の変更と分離して  X-as-a-Service が  柔軟に切り替えることができる必要がある  X-as-a-Service からの動画再生サブシステムの進化  04 

再掲：動画視聴システム周辺のチームトポロジー  プロダクト開発チーム  <Stream-aligned チーム>  Streaming Client  チーム  <Complicated Subsystem チーム> 
動画配信基盤開発チーム／コンテンツ管理基盤開発チーム  <Platform チーム>  動画配信基盤開発チームと Streaming Client チームで  視聴品質に関わる意思決定が完結する  X-as-a-Service からの動画再生サブシステムの進化  04 

動画広告を加えたチームトポロジー  プロダクト開発チーム  <Stream-aligned チーム>  Streaming Client  チーム  <Complicated Subsystem チーム> 
動画配信基盤開発チーム／コンテンツ管理基盤開発チーム  <Platform チーム>  次の X-as-a-Service の対象  動画広告システム  開発チーム  <Complicated Subsystem チーム>  X-as-a-Service からの動画再生サブシステムの進化  04 

動画広告の種類  • インストリーム動画広告  ◦ 動画コンテンツの合間に流れる広告  • アウトストリーム動画広告  ◦ 動画コンテンツ外の広告枠に配信される動画広告  ◦
インバナー、インリード、インフィード、インタースティシャルなど多種  X-as-a-Service からの動画再生サブシステムの進化  04 

動画広告の種類  • インストリーム動画広告  ◦ 動画コンテンツの合間に流れる広告  • アウトストリーム動画広告  ◦ 動画コンテンツ外の広告枠に配信される動画広告  ◦
インバナー、インリード、インフィード、インタースティシャルなど多種  Streaming Client チームの関心対象  X-as-a-Service からの動画再生サブシステムの進化  04 

Fluﬀy の関心  • 再生の安定性  • 動画の解像度  • インストリーム広告の  挿入手段  • コンテンツ保護手段  X-as-a-Service からの動画再生サブシステムの進化  04 

プロダクトと Fluﬀy と動画広告の関心の分離  プロダクトの関心  • ユーザーが視聴する  コンテンツ  • ユーザーが  どのように視聴するか 
Fluﬀy の関心  • 再生の安定性  • 動画の解像度  • インストリーム広告の  再生品質  • コンテンツ保護手段  動画広告の関心  • インストリーム広告の  挿入手段  • フリークエンシー制御  • トラッキング手法  • インタラクティビティ  X-as-a-Service からの動画再生サブシステムの進化  04 

インストリーム動画広告を扱うモジュール  Fluﬀy 内には複数の広告システムを扱うための AdSystemAdapter   という Interface だけ定義し、実装は別アダプタとして開発  プロダクト  Fluﬀy 
<<Interface>>  Ad System   Adapter  Google IMA  Adapter  Yospace  Adapter  Cluster  Adapter  Content  Session  AdDisplay Context  実装アダプタ  X-as-a-Service からの動画再生サブシステムの進化  04 

インストリーム動画広告を扱うモジュール  AdDisplayContext で広告表示枠となるビューの参照、ビューアビリティ計測のための情報をプロダクトから AdSystemAdapter に共有  プロダクト  Fluﬀy  <<Interface>>  Ad
System   Adapter  Google IMA  Adapter  Yospace  Adapter  Cluster  Adapter  Content  Session  AdDisplay Context  実装アダプタ  X-as-a-Service からの動画再生サブシステムの進化  04 

インストリーム動画広告を扱うモジュール  プロダクト  Fluﬀy  <<Interface>>  Ad System   Adapter  Google IMA 
Adapter  Yospace  Adapter  Cluster  Adapter  Content  Session  AdDisplay Context  実装アダプタで動画広告の  • 挿入方式  • トラッキング手法  • ビューアビリティ計測  • インタラクション  の最適な実装を再生制御と切り離して  アドテクチームが変更可能に  実装アダプタ  X-as-a-Service からの動画再生サブシステムの進化  04 

広告挿入方式の変更  広告挿入方式によって再生するマニフェストが変わる  • CSAI - Client-Side Ad Insertion  • SSAI
- Server-Side Ad Insertion  • SGAI - Server-Guided Ad Insertion  X-as-a-Service からの動画再生サブシステムの進化  04 

- Server-Side Ad Insertion  ◦ デフォルト  ◦ ユーザークラスタリング型広告出し分け  ◦ ユーザーパーソナライジング型広告出し分け  ▪ Yospace / AWS Elemental MediaTailor  • SGAI - Server-Guided Ad Insertion  フリークエンシー制御の  柔軟性はトレードオフがある  • ◦ 収益性  • × 再生開始までの時間  • × 再生安定性  X-as-a-Service からの動画再生サブシステムの進化  04 

- Server-Side Ad Insertion  ◦ デフォルト  ◦ ユーザークラスタリング型広告出し分け  ◦ ユーザーパーソナライジング型広告出し分け  ▪ Yospace / AWS Elemental MediaTailor  • SGAI - Server-Guided Ad Insertion  X-as-a-Service からの動画再生サブシステムの進化  04 

生配信のユーザーパーソナライジング型広告  本編  広告  本編  A B C D A E
広告決定の負荷が広告ブレークのタイミングに一点集中 X-as-a-Service からの動画再生サブシステムの進化  04 

- Server-Side Ad Insertion  • SGAI - Server-Guided Ad Insertion  マニフェストの決定 =  Fluﬀy の関心 && 動画広告の関心  X-as-a-Service からの動画再生サブシステムの進化  04 

インストリーム動画広告を扱うモジュール  アドテクチームは広告に関する意思決定を担う AdManager を提供し、広告挿入方式の優先度を Fluﬀy に伝える  プロダクト  Fluﬀy  Ad
System   Adapter  Content  Session  AdDisplay Context  Ad Manager  広告挿入方式の  優先度  広告挿入の  具体実装  生成  X-as-a-Service からの動画再生サブシステムの進化  04 

インストリーム動画広告を扱うモジュール  Fluﬀy は広告挿入方式の優先度を加味して再生するマニフェストを決定  → 視聴品質を収益性より優先する意思決定フロー  プロダクト  Fluﬀy  Ad System  
Adapter  Content  Session  AdDisplay Context  Ad Manager  広告挿入方式の  優先度  広告挿入の  具体実装  生成  再生マニフェスト  の決定  X-as-a-Service からの動画再生サブシステムの進化  04 

視聴体験を最適化する再生リトライ  X-as-a-Service からの動画再生サブシステムの進化  04 

ContentSession 内の再生リトライ管理  1 ContentSession 内で複数のマニフェストで再生をリトライする  • 1 再生セッションで再生品質に問題がある場合は  より確実なマニフェストに切り替えて再生を継続する  ◦
MPEG-DASH x Fragmented MP4 → HLS x MPEG-2 TS  ◦ CDN A → CDN B  ◦ Striker → Defender  ◦ 低遅延ストリーム → 通常ストリーム  ◦ パーソナライズドインストリーム広告 → 通常インストリーム広告  X-as-a-Service からの動画再生サブシステムの進化  04 

ContentSession 内の再生リトライ・ロジック  マニフェストを切り替えて再生を継続するロジックを最適化  • ContentSession 内の再生リトライは x 分間に y 回のスタートアップ・エ
ラー／インストリーム・エラー／リバッファリングの発生で段階的により保守的なマニフェストに切り替える  • 規定の試行回数を超えたときに ContentSession は Stream-aligned のプロダクトにエラーを通知する  X-as-a-Service からの動画再生サブシステムの進化  04 

再生リトライ・ロジックの進化  視聴体験に最適化するための再生リトライ・ロジックを  Stream-aligned のプロダクトとは独立して進化させる  プロダクト  Fluﬀy  動画配信システム  Error ARIN ストリーム選択肢一覧 
PlaybackResource 再生リトライ／マニフェスト切替  Content  Session X-as-a-Service からの動画再生サブシステムの進化  04 

ワークアラウンドの選択肢  X-as-a-Service からの動画再生サブシステムの進化  04 

動画視聴システムを進化  動画視聴システムの進化の過程では  システムのコンポーネント変更が頻繁に発生する  • コンポーネントを変更すると想定外の不具合に出くわす  ◦ エンコーダーが出力した特定の解像度帯が特定のデバイスで  再生時ドロップフレームを起こす  ◦ パッケージャーが出力したマニフェストを特定の再生プレイヤーが解釈できない 
◦ パッケージャーが出力時に追加したメタデータを  特定の再生プレイヤーが解釈を間違える  X-as-a-Service からの動画再生サブシステムの進化  04 

動画視聴システムの進化に痛みが伴う  システム全体が前に進むために  一部にワークアラウンドを適用しながらも進むことも必要  X-as-a-Service からの動画再生サブシステムの進化  04 

動画視聴システムを進化  動画視聴システムの進化の過程では  システムのコンポーネント変更が頻繁に発生する  • コンポーネントを変更すると想定外の不具合に出くわす  ◦ エンコーダーが出力した特定の解像度帯が特定のデバイスで  再生時ドロップフレームを起こす  ◦ パッケージャーが出力したマニフェストを特定の再生プレイヤーが解釈できない 
◦ パッケージャーが出力時に追加したメタデータを  特定の再生プレイヤーが解釈を間違える  X-as-a-Service からの動画再生サブシステムの進化  04 

パッケージャーが追加したメタデータによる不具合  • 新しいパッケージャーで追加した emsg が既存の emsg の presentationTime の計算に影響を与えた  ◦
既存の動画ストリームには emsg v1 で視聴ログに必要なメタデータ  ◦ パッケージャーでは生配信の映像制御のために emsg v0 で scte35 のメタデータ  ◦ Android OS 向けに使用している ExoPlayer が emsg v1 と v0 の同時利用を想定していない  ▪ v0 は presentation_time_delta による計算、v1 は presentation_time による計算  ▪ v0 は前のメタデータの presentation_time_delta 依存で計算  • → v1 を挟むと計算がずれる  ▪ ExoPlayer 自体は emsg v0 / v1 それぞれ単体はサポート  X-as-a-Service からの動画再生サブシステムの進化  04 

ワークアラウンドの選択肢とその影響範囲  プロダクト  Fluﬀy  動画配信システム  ARIN  Content ARIN マニフェスト選択肢一覧  PlaybackResource ワークアラウンドの選択肢 
• パッケージャーの処理を変更する  • emsg のバージョンを変更する  • プレイヤーのパース処理を変更する  • ストリーミングプロトコルの種類を変更する  多くのワークアラウンドが Fluﬀy と動画配信システム間で完結  取り得る選択肢が増える  X-as-a-Service からの動画再生サブシステムの進化  04 

ワークアラウンドの選択肢とその影響範囲  プロダクト  Fluﬀy  動画配信システム  ARIN  Content ARIN マニフェスト選択肢一覧  PlaybackResource ワークアラウンドの選択肢 
• パッケージャーの処理を変更する  • emsg のバージョンを変更する  • プレイヤーのパース処理を変更する  • ストリーミングプロトコルの種類を変更する  余談：当時は、  プレイヤーのパース処理を変更  X-as-a-Service からの動画再生サブシステムの進化  04 

• 市場競争力を持った動画再生クライアントを開発するため  Complicated Subsystem チームとして Streaming Client が誕生  • 動画再生サブシステムを
X-as-a-Service として再設計する Fluffy プロジェクトが開始 • Fluffy のキーコンセプトは Content Session による責務分離 • Fluffy は今も動画視聴システムとの変更に同期して進化を続けているまとめ

ご視聴ありがとうございました 

ABEMA の視聴体験を進化させ続ける新しい動画再生クライアント設計

ABEMA の視聴体験を進化させ続ける新しい動画再生クライアント設計

More Decks by Yusuke Goto

Other Decks in Technology

Featured

Transcript