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

by Yusuke Goto

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

五藤佑典 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 事業部

Slide 3

Slide 3 text

in Video Technology and Product Design

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

01 動画再生クライアント 

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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 

Slide 69

Slide 69 text

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 

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

同一エンコードのマニフェスト違い  （DASH）で Use case を表す  ライブ視聴の場合    …          …      …        …    …    追っかけ視聴の場合  見逃し視聴    …        …    …    X-as-a-Service としての動画再生サブシステムの設計  03 

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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 

Slide 87

Slide 87 text

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 

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

Slide 103

Slide 103 text

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

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

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

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

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

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

Slide 113

Slide 113 text

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

Slide 114

Slide 114 text

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

Slide 115

Slide 115 text

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

Slide 116

Slide 116 text

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

Slide 117

Slide 117 text

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

Slide 118

Slide 118 text

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

Slide 119

Slide 119 text

Slide 120

Slide 120 text

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

Slide 121

Slide 121 text

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

Slide 122

Slide 122 text

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

Slide 123

Slide 123 text

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

Slide 124

Slide 124 text

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

Slide 125

Slide 125 text

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

Slide 126

Slide 126 text

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

Slide 127

Slide 127 text

Slide 128

Slide 128 text

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

Slide 129

Slide 129 text

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

Slide 130

Slide 130 text

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

Slide 131

Slide 131 text

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

Slide 132

Slide 132 text

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

Slide 133

Slide 133 text

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

Slide 134

Slide 134 text

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

Slide 135

Slide 135 text

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

Slide 136

Slide 136 text

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

Slide 137

Slide 137 text

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

Slide 138

Slide 138 text

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

Slide 139

Slide 139 text

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

Slide 140

Slide 140 text

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

Slide 141

Slide 141 text

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

Slide 142

Slide 142 text

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

Slide 143

Slide 143 text

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

Slide 144

Slide 144 text

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

Slide 145

Slide 145 text

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

Slide 146

Slide 146 text

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

Slide 147

Slide 147 text

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

Slide 148

Slide 148 text

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

Slide 149

Slide 149 text

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

Slide 150

Slide 150 text

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

Slide 151

Slide 151 text

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

Slide 152

Slide 152 text

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

Slide 153

Slide 153 text

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

Slide 154

Slide 154 text

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

Slide 155

Slide 155 text

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

Slide 156

Slide 156 text

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

Slide 157

Slide 157 text

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

Slide 158

Slide 158 text

『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 

Slide 159

Slide 159 text

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

Slide 160

Slide 160 text

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

Slide 161

Slide 161 text

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

Slide 162

Slide 162 text

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

Slide 163

Slide 163 text

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

Slide 164

Slide 164 text

Slide 165

Slide 165 text

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

Slide 166

Slide 166 text

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

Slide 167

Slide 167 text

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

Slide 168

Slide 168 text

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

Slide 169

Slide 169 text

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

Slide 170

Slide 170 text

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

Slide 171

Slide 171 text

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

Slide 172

Slide 172 text

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

Slide 173

Slide 173 text

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

Slide 174

Slide 174 text

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

Slide 175

Slide 175 text

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

Slide 176

Slide 176 text

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

Slide 177

Slide 177 text

動画広告を扱う規格  動画広告を扱う規格も 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 

Slide 178

Slide 178 text

Slide 179

Slide 179 text

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

Slide 180

Slide 180 text

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

Slide 181

Slide 181 text

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

Slide 182

Slide 182 text

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

Slide 183

Slide 183 text

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

Slide 184

Slide 184 text

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

Slide 185

Slide 185 text

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

Slide 186

Slide 186 text

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

Slide 187

Slide 187 text

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

Slide 188

Slide 188 text

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

Slide 189

Slide 189 text

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

Slide 190

Slide 190 text

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

Slide 191

Slide 191 text

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

Slide 192

Slide 192 text

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

Slide 193

Slide 193 text

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

Slide 194

Slide 194 text

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

Slide 195

Slide 195 text

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

Slide 196

Slide 196 text

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

Slide 197

Slide 197 text

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 

Slide 198

Slide 198 text

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

Slide 199

Slide 199 text

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

Slide 200

Slide 200 text

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

Slide 201

Slide 201 text

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

Slide 202

Slide 202 text

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

Slide 203

Slide 203 text

Slide 204

Slide 204 text

Slide 205

Slide 205 text

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

Slide 206

Slide 206 text

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

Slide 207

Slide 207 text

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

Slide 208

Slide 208 text

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

Slide 209

Slide 209 text

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