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

This presentation describes how ABEMA's new video playback client contributes to the service's evolution as an online video platform . As a video-tech-focused complicated subsystem team, we design architecture to proceed the development of the video playback client by trial and error apart from the stream-aligned development teams and closer to the video streaming platform team in order to make critical decisions related to video quality of experience with great ease.

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

2. 五藤 佑典 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 事業部
3. in Video Technology and Product Design
4. 1. 動画再生クライアント 2. Streaming Client チームのミッションとチームトポロジー 3. X-as-a-Service としての動画再生サブシステムの設計 4. X-as-a-Service からの動画再生サブシステムの進化 CONTENTS
5. 01
動画再生クライアント

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

25. Streaming Client チームが生まれた経緯
 1. ABEMA 開局当初、動画再生機能はモバイルアプリ／Web アプリ開発チームなど の各々のクライアントエンジニアチームが開発
 2. 動画再生技術は高い専門性が必要なため、各クライアントエンジニアチーム内で 実装できるメンバーが固定化
 3. 動画は ABEMA のコアドメインなので、関連する機能開発の頻度も高く、チームご とに知見がサイロ化
 4. サイロ化を防ぐために、各クライアントエンジニアチームから動画技術を得意とする メンバーを集めてギルドを結成
 Streaming Client チームのミッションとチームトポロジー
 02

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

69. 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

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

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

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

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

74. 同一エンコードのマニフェスト違い
 （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

75. 同一エンコードのプレイリスト違い
 （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

76. 同一映像ソースのプレイリスト違い
 （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

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

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

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

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

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

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

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

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

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

86. 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

87. PlaybackResource
 同一映像ソースから出力した
 複数の再生用リソースの情報
 • 視聴ユースケース
 • DRM
 • エンコーディング・パターン
 • 広告挿入方式
 • CDN バランシング手段
 この情報の組み合わせから
 Fluffy が自身の環境に
 最適な動画マニフェストを判断する
 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

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

89. PlaybackResource から動画マニフェストの決定
 Fluffy は次のように複数のマニフェストから再生するものを決定する
 1. 再生可能な動画ストリームの選択
 2. 収益性、セキュリティ、冗長化の観点で動画マニフェストの選択
 3. フェールオーバーするマニフェストチェーンの構築
 X-as-a-Service としての動画再生サブシステムの設計
 03

90. PlaybackResource から動画マニフェストの決定
 Fluffy は次のように複数のマニフェストから再生するものを決定する
 1. 再生可能な動画ストリームの選択
 2. 収益性、セキュリティ、冗長化の観点で動画マニフェストの選択
 3. フェールオーバーするマニフェストチェーンの構築
 X-as-a-Service としての動画再生サブシステムの設計
 03

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

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

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

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

95. PlaybackResource から動画マニフェストの決定
 Fluffy は次のように複数のマニフェストから再生するものを決定する
 1. 再生可能な動画ストリームの選択
 2. 収益性、セキュリティ、冗長化の観点で動画マニフェストの選択
 3. フェールオーバーするマニフェストチェーンの構築
 X-as-a-Service としての動画再生サブシステムの設計
 03

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

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

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

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

100. PlaybackResource から動画マニフェストの決定
 Fluffy は次のように複数のマニフェストから再生するものを決定する
 1. 再生可能な動画ストリームの選択
 2. 収益性、セキュリティ、負荷分散の観点で動画マニフェストの選択
 3. フェールオーバーするマニフェストチェーンの構築
 X-as-a-Service としての動画再生サブシステムの設計
 03

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

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

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

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

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

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

107. 動画エンジニアのアサインを容易にする
 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

108. 動画エンジニアのアサインを容易にする
 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 は
 まだまだサポートデバイスを増やしていく

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

124. マルチ CDN 制御
 マルチ CDN は大規模生配信において特に重要な負荷制御機構
 動画配信の CDN 切り替えロジックは Stream-aligned チームにとって 無関心であるべき領域 マルチ CDN 制御によって 再生に至るまでの手順に 大きな変更を要する プロダクトの変更と分離して
 X-as-a-Service が
 柔軟に切り替えることができる必要がある
 X-as-a-Service からの動画再生サブシステムの進化
 04

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

140. NPAW CDN Selector で利用したバランシング機能
 • 重み付きラウンドロビン
 ◦ CDN ごとの帯域状態、価格帯などに合わせた制御
 • 視聴形態によって異なるルールの適用
 ◦ ライブ再生
 ◦ 追っかけ再生
 ◦ オンデマンド再生
 • アングルによって異なるルールの適用
 ◦ メインアングルとサブアングルでは求められる冗長性や品質観点が異なる
 • 通常メインアングルが
 同時視聴数が一番多い
 • メインアングルの映像品質だけが
 サブより高いことがある
 ◦ 1 セッションあたりの
 トラフィック量増加
 X-as-a-Service からの動画再生サブシステムの進化
 04

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

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

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

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

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

146. マルチリージョンのバランシング機能
 ある 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

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

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

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

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

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

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

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

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

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

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

157. エンコーディング・パターン
 動画のエンコーディングのユースケースを大きく 3 パターンに分け、
 デバイスのユースケースと性能に最適なエンコーディングを提供する
 • Defender
 ◦ どんなデバイスでも再生可能な動画ストリームを提供する
 ◦ 社会インフラを支える動画ストリームを提供する
 • Midfielder
 ◦ 時流に準拠した標準的なデバイスに最適な動画品質を提供する
 • Striker
 ◦ スポーツの種類や音楽ライブなどのコンテンツ特性を最大限に活かし、その時代の最高 のエンターテイメントを提供する
 ▪ 例：HFR、Immersive Audio
 X-as-a-Service からの動画再生サブシステムの進化
 04

158. 『FIFA ワールドカップ カタール 2022』では
 サッカーの映像特性を最大限に活かすために HFR の Striker を用意
 Striker - コンテンツ最適化品質 Defender - カバレッジ優先品質構成 FPS 59.94 29.97 Rate Control Mode V:QVBR/A:VBR V/A:CBR Profile/Level 1080p@High4.2/以下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

159. デバイスごとのエンコーディング・パッケージ選択
 Fluffy は 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

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

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

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

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

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

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

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

167. 低遅延動画配信プロトコル - 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

168. 低遅延動画配信プロトコル - 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

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

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

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

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

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

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

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

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

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

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

179. インストリーム動画広告
 無料で動画コンテンツを提供するために番組の途中で挟む
 インストリーム動画広告は大事なマネタイズ手段
 インストリーム動画広告の 挿入方法は Stream-aligned チームにとって 無関心であるべき領域 インストリーム動画広告は それ単体で認知負荷が高い領域 プロダクトや Fluffy の変更と分離して
 X-as-a-Service が
 柔軟に切り替えることができる必要がある
 X-as-a-Service からの動画再生サブシステムの進化
 04

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

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

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

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

184. プロダクトと Fluffy の関心の分離
 プロダクトの関心
 • ユーザーが視聴する
 コンテンツ
 • ユーザーが
 どのように視聴するか
 Fluffy の関心
 • 再生の安定性
 • 動画の解像度
 • インストリーム広告の
 挿入手段
 • コンテンツ保護手段
 X-as-a-Service からの動画再生サブシステムの進化
 04

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

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

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

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

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

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

191. 広告挿入方式の変更
 広告挿入方式によって再生するマニフェストが変わる
 • CSAI - Client-Side Ad Insertion
 • SSAI - Server-Side Ad Insertion
 ◦ デフォルト
 ◦ ユーザークラスタリング型広告出し分け
 ◦ ユーザーパーソナライジング型広告出し分け
 ▪ Yospace / AWS Elemental MediaTailor
 • SGAI - Server-Guided Ad Insertion
 X-as-a-Service からの動画再生サブシステムの進化
 04

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

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

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

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

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

197. 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

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

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

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

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

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

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

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

205. パッケージャーが追加したメタデータによる不具合
 • 新しいパッケージャーで追加した 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

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

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

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