より高品質なメディアサービスを目指す ABEMA の技術進化
•
2 recomendaciones•2,034 vistas
The presentation describes how ABEMA uses video streaming technologies to improve its quality as a public media service. It also discusses technological challenges in the COVID-19 pandemic.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a より高品質なメディアサービスを目指す ABEMA の技術進化
Similar a より高品質なメディアサービスを目指す ABEMA の技術進化 (20)
Más de Yusuke Goto
Más de Yusuke Goto (20)
より高品質なメディアサービスを目指す ABEMA の技術進化
- 1. より高品質なメディアサービスを目指す ABEMAの技術進化 - 2020年映像情報メディア学会創立70周年記念大会 記念講演 - 株式会社サイバーエージェント五藤 佑典
- 2. 五藤 佑典 YUSUKE GOTO https://ygoto3.com/ @ygoto3_ ● California State University, San Bernardino グラフィックデザイン専攻 ● ソフトウェアエンジニア @ サイバーエージェント ● ABEMA 開発本部 ○ New Device チーム あらゆるデバイスにAbemaTV を展開するための技術を提供するチーム ○ Streaming Client チーム AbemaTV の再生品質を軸にUX エンジニアリングにコミットするチーム ○ 動画技術エバンジェリスト 世界各国に足を運び動画技術に関する情報をキャッチアップし、 社内外の動画サービスの発展に貢献するロール ○ DesignOps 推進バックエンド 大規模組織でスケールできるプロダクトデザイン開発組織を構築する活動
- 3. in Video Technology and Product Design
- 6. すべて無料 オリジナル番組をはじめ、アニメやドラマ、音 楽、スポーツなど、すべて無料で提供してい ます。 100% プロコンテンツ サイバーエージェントとテレビ朝日のそれぞ れの強みを活 かした制作体制で高品質のコ ンテンツを拡充しています。 完全編成型 24 時間 365 日配信で、いつでもテレビを見る ような感覚で楽しむことができます。 多彩なラインナップ オリジナルの生放送や、ドラマ、ニュース、ア ニメ、スポーツなど約 20 チャンネルを取り揃 えています。
- 9. ABEMA プレミアム ベーシック ABEMA プレミアム 無料コンテンツ 無料コンテンツ 有料コンテンツ 有料コンテンツ 追っかけ再生 追っかけ再生 動画ダウンロード 動画ダウンロード 見逃しコメント 見逃しコメント
- 12. コロナ禍における変化
- 16. 2020.04 2020.06 開発決定 リリース ABEMA PPV ONLINE LIVE LDH グループ 様 ももいろクローバー Z 様 浜崎あゆみ 様 サザンオールスターズ 様 など多数実績
- 17. Go To イベントキャンペーン 「ABEMAPPV ONLINE LIVE」がオンライン ライブ事業として初めて「Go Toイベント キャンペーン」の対象に 新型コロナウイルス感染症の感染拡大によって甚大な影響を受 けている文化芸術やスポーツに関するイベントの需要喚起 https://times.abema.tv/news-article/8634858 LDH JAPAN（以下、LDH）の『LIVE×ONLINE（ライブオンライ ン）』（※1）全6公演のチケット（※2）を販売額の20％割引き （※3）で購入できる。
- 20. アジェンダ 1. オンラインライブプラットフォームとしての品質 2. オンラインライブならではの演出品質 3. リモートワークでも品質を落とさないフルクラウドオペレーション 4. 報道品質 5. 愛される広告を届ける品質 6. 品質向上のためのクライアントデータ
- 21. オンラインライブプラットフォーム としての品質 Photo by Danny Howe on Unsplash
- 22. 生配信で高解像度の映像を届ける価値 ABEMA はこれまで FAST (Free Ad Supported TV) とサブスクリプションの ハイブリッドサービスだった ● 安定性重視のビットレート戦略 ○ 明滅／動きが激しい映像に対してビットレートが低すぎる ○ 音楽ライブを表現するには無理がある構成 Photo by Desi Mendoza on Unsplash
- 24. 生配信で高解像度の映像を届ける価値 安定性重視 → 音楽ライブに適したビットレート 8Mbps 4Mbps 8Mbps 4Mbps プロファイルの調整、 HD への最適化により 2 倍のビットレート ... ... ユーザーがより柔軟に 解像度設定できる設計
- 25. より高いオンラインライブ品質を検討する ● HEVC + Zixi による打ち上げ ○ 4K 4:2:2 10bit を安定的に ● 次世代コーデックによるデリバリー ○ 4K 品質での映像提供が可能に ● 低遅延配信 ● （ラウドネス調整）
- 29. コーデックに依存しないコーデック強化 n 世代コーデックの符号効率を n+1 世代と同等に強化 n 世代コーデックと同等の複雑性を保ちながら ソフトウェア実装可能でバッテリー消費が少ない強化コーデック Low-Complexity Enhancement Video Coding
- 30. LCEVC
- 31. LCEVC 既存コーデック - AVC / HEVC / VVC / EVC - に更にコーデックを 付け足すイメージ ● 既存コーデックで基本サイズの絵を符号化 ● より大きいサイズの絵を LCEVC で符号化
- 32. LCEVC 既存コーデック - AVC / HEVC / VVC / EVC - に更にコーデックを 付け足すイメージ ● 既存コーデックで基本サイズの絵を符号化 ● より大きいサイズの絵を LCEVC で符号化 AVC を搭載している 既存のプラットフォームに対して プラスα の画質を提供することができる
- 36. バーチャル撮影システム リアルタイムに人物と 3DCG 空間を 合成・撮影 ● 現在日本国内に数台しかないシステム ● 2018 年国内初導入以後 2 年調査・調整
- 37. Zero Density Reality Engine x stYpe RedSpy Reality Engine ● リアルタイムノードベース合成ソフトウェア ● Unreal Engine ネイティブプラットフォーム ○ 高品質なリアルタイム CG 生成 https://docs.zerodensity.tv/reality29/reality-walkthrough/reality-node-graph
- 38. Zero Density Reality Engine x stYpe RedSpy stYpe RedSpy ● デジタルトラッキングシステム ● 独自のトラッキングプロトコルによる カメラ・レンズ情報との連動 ○ レンズの FOV、ディストーション、DoF などの情報と背景 CG の連動 https://www.nacinc.jp/creative/virtual-products/redspy/
- 40. Da-iCE ONLINE LIVE TOUR 2020
- 41. リモートワークでも品質を落とさない フルクラウドオペレーション Photo by Paul Hanaoka on Unsplash
- 42. フルクラウドでの編集ソリューション ● Grabyo ● Vimond IO ● Tellyo ● Blackbird ● Amazon WorkSpaces 2019
- 43. フルクラウド編集における要件 ● ストレスがない操作性 ● MXF／ProRes ファイルを扱えること ● Adobe Premiere に依存したワークフロー
- 44. Blackbird ● Web ブラウザベース ● GCP / AWS / Azure サポート ● Live ○ インジェスト ■ RTMP / HLS / SDI ● File-based ○ 4K サポート ○ ProRes / MXF サポート ● 独自インターフェース ● EDL を利用した Proxy 更新 ○ ストレスがない操作性
- 47. Blackbird ● Web ブラウザベース ● GCP / AWS / Azure サポート ● Live ○ インジェスト ■ RTMP / HLS / SDI ● File-based ○ 4K サポート ○ ProRes / MXF サポート ● 独自インターフェース ● EDL を利用した Proxy 更新 ○ ストレスがない操作性
- 48. Amazon WorkSpaces ● マネージドの Desktop-as-a-Service (DaaS) ソリューション ● Adobe Premiere などのデスクトップアプリケーション環境 ● PCoIP を利用したゼロクライアント思想 ○ 手元の PC は非力なスペックで問題ない
- 51. 報道品質 Photo by ThisisEngineering RAEng on Unsplash
- 54. HTTP ストリーミングの遅延 Shoot Encode Frames Segment Playback Buffer
- 55. 一般的な HTTP ストリーミングの低遅延化手法 ● セグメント長短縮 ● B フレーム不使用 ● バッファー長短縮
- 57. B フレーム不使用 I P P P I P P P I P P P I P P P I P P P Shoot Encode Frames Segment Playback Buffer
- 59. ABEMA NEWS の遅延要因
- 60. ABEMA NEWS の遅延量
- 61. ABEMA News の低遅延化のアプローチ ● セグメント長の短縮 ○ 5 秒セグメント → 1 秒セグメント ● インジェスト方式の変更 ○ Pull 型インジェスト → Push 型インジェスト ● まずは HLS から ○ 対応パッケージングを両方に実装するのは大変
- 62. ABEMA News の低遅延化のアプローチ ● セグメント長の短縮 ○ 4 秒セグメント → 1 秒セグメント ● インジェスト方式の変更 ○ Pull 型インジェスト → Push 型インジェスト ● まずは HLS から ○ 対応パッケージングを両方に実装するのは大変 約 15 〜 23 秒 → 約 8 秒 まで 遅延短縮
- 67. 低遅延ストリームのカナリアリリース ● Feature Toggle - Bucketeer ● Real User Monitoring - YOUBORA
- 68. 低遅延ストリームのフォールバック ユーザーがアプリケーション使用中に x 秒内に ● リバッファリング ● 再生エラー が y 回発生したら自動フォールバック 致命的な視聴体験の低下を回避しながらリリース
- 72. 低遅延ストリームのモニタリング オリジナルストリームからの通常の偏差を見て 著しく低下している場合は 視聴体験を悪化させている判断 監視メトリクス ● リバッファー率 ● 再生時エラー率 トグルオフ
- 73. より低遅延な配信技術を検討する
- 75. HESP High Efficiency Streaming Protocol ● THEO Technologies 開発 ● HTTP ベースで Ultra-Low Latency を実現するストリーミングプロトコル ● オーバーヘッドが少ない再生開始手順 ○ 再生開始にマニフェストは必須ではない ● HTTP 1.1 ベース ○ 標準的なデリバリーインフラで利用可能 ○ オプションで HTTP/2 も使用可能 ● フレーム精度の任意の位置から再生可能 ○ 2 種類の補完的なストリームを組み合わせる独特なプロトコル
- 76. HESP 2 種類のストリーム ● Initialization stream ○ 全てキーフレーム ○ 再生継続するのは高コスト ● Continuation stream ○ Initialization stream の後に 来るストリーム ○ 1 つ前のフレームだけ参照す る https://www.youtube.com/watch?v=KOTI-swmH_0
- 77. HESP ABEMA Web 版は THEOplayer を使用 use 文脈的にも検討の価値があるが プロトコルの独自性と低遅延への高い最適化が ABEMA にとっては今後の技術的拡張に対するリスクも
- 81. CMAF-CTE CMAF Chunked Transfer Encoding を使った低遅延ストリーミング
- 83. CMAF-CTE mdatmoof mdatmoof mdatmoof mdatmoofmdatmoof moof mdat 同じサンプルを複数の CMAF チャンクに CMAF チャンク CMAF チャンク CMAF チャンク CMAF チャンク CMAF チャンク
- 84. CMAF-CTE mdatmoof mdatmoof mdatmoof mdatmoofmdatmoof moof mdat 同じサンプルを複数の CMAF チャンクに Encode flush Encode flush Encode flush Encode flush
- 85. ABEMA のセグメントファイルフォーマット ● CMAF に対応するためには、エンコーダーからプレイヤーまで対応が必要 ● 既存コンテンツの再パッケージングも必要 ※ABEMA Playout の仕組み上の制約 ts m4s
- 86. ABEMA のセグメントファイルフォーマット ● CMAF に対応するためには、エンコーダーからプレイヤーまで対応が必要 ● 既存コンテンツの再パッケージングも必要 ※ABEMA Playout の仕組み上の制約 ts m4s Playout の仕組みから見直し中
- 87. LL-HLS HTTP Live Streaming v2 に含まれる低遅延ストリーミング向けプロトコル
- 88. LL-HLS 2019.06 2020.04 2019 Worldwide Developer Conference にて最初の仕様発表 ● HTTP/2 Push 要件が CMAF-CTE による低遅延要件と衝突 HTTP Live Streaming (HLS) 2nd Edition 発表 ● HTTP/2 Push 必須要件削除 ● #EXT-X-PRELOAD-HINT タグ追加
- 90. LL-HLS vs LL-DASH LL-HLS LL-DASH Parts ● 独立してアドレス可能 ● 新しい part を取得するために Manifest 更新が必要 ● IDR フレームのマーク ○ デコード開始可能な位置 Chunks / Fragments ● Chunks は Segment の一部 ● 新しい fragment の取得に Manifest 更新は必要ない 諸々の違いはあるが、LL-HLS と LL-DASH 両者で 同じセグメントファイルを再利用することは可能
- 91. HTTP ベース低遅延配信の限界 HTTP デリバリー = ベストエフォート ● 動画プレイヤーの ABR (Adaptive Bitrate) ロジックは 最悪の条件に合わせる必要がある
- 92. 2019
- 93. DVB-I DVB-I DVB-DASH LL-DASH mABR DVB AV Codecs Signaling / Metadata Service Discovery https://www.slideshare.net/foerderverein/new-media-services-from-a-mobile-chipset-vendor-and-standardization-perspective
- 94. DVB-I DVB-I DVB-DASH LL-DASH mABR DVB AV Codecs Signaling / Metadata Service Discovery https://www.slideshare.net/foerderverein/new-media-services-from-a-mobile-chipset-vendor-and-standardization-perspective
- 96. DVB-I mABR ● Multicast Adaptive Bitrate ● 放送局と通信事業者が協業して IP ベース配信の最適化 ● OTT とケーブル／DTH の良いとこ取り ○ Multicast ○ Managed network ○ High Scalability ○ Multi-screens ○ ABR ○ DRM ● アイデアのオリジナルは castLabs が米国で実装した例から ○ Broadpeak の nanoCDN multicast ABR を利用
- 98. mABR による安定したトラフィック https://broadpeak.tv/blog/why-multicast-abr-is-not-about-saving-bandwidth 想定すべき最悪の条件が改善され よりアグレッシブな ABR ロジックを 組むことを可能にする
- 99. Origin Transcaster Unicast to Multicast ISP’s Agent Multicast to Unicast A’s network B’s network Public network Gateway’s Agent Multicast to Unicast Multicast Unicast
- 100. Origin Transcaster Unicast to Multicast ISP’s Agent Multicast to Unicast A’s network B’s network Public network Gateway’s Agent Multicast to Unicast Multicast Unicast Nest step: より安定した低遅延配信へ
- 101. mABR ● CMAF-CTE との組み合わせを念頭に置かれている ○ HTTP ベースの短いバッファリングでの再生安定性を保証する ● コンテンツの人気度に応じて Multicast / Unicast の経路を 使い分けることが可能 ○ 配信システムとして失うものがない ● パーソナライズド配信などに課題 ○ Multicast to Unicast 変換以降で Manifest Manipulation することで 個別の組み合わせを作ることは可能
- 102. 愛される広告を届ける品質 Photo by Joshua Earle on Unsplash
- 103. ABEMA の広告の特徴 さまざまなターゲティングオプション ● デモグラフィック ● OS ● キャリア ● エリア ● 時間 ● チャンネル ● カスタムオーディエンス
- 104. ABEMA 広告ターゲティングの進化 2016.04 2018.02 2018.07 2020.06 Linear Server-Side Ad Insertion VOD Client-Side Ad Insertion 広告クラスター配信 リニアパーソナライズド広告
- 105. Server-Side Ad Insertion (SSAI) サーバーサイドで広告を挿入する技術 Pros ● 番組と広告の切り替え処理がない ● 全デバイスで広告配信ができる ● 広告ブロックに強い Cons ● パーソナライズド処理の 難易度が高い ● トリックプレイに対する 広告制御の難易度が高い
- 106. Client-Side Ad Insertion (CSAI) クライアントサイドで広告を挿入する技術 Pros ● ターゲティング広告挿入が容易 ● トリックプレイに対する 広告制御が容易 Cons ● 番組と広告の切り替えに 処理が発生する ● デバイスによって実装難易度が 異なる ● 広告ブロックに弱い
- 107. リニアインストリーム広告 SSAI を採用 テレビと同等の品質の広告を配信する ● 広告切り替え時にタイムラグがない ● 全てのデバイスで広告配信
- 108. VOD インストリーム広告 CSAI を採用 トリックプレイに柔軟に対応した広告を配信する ● シークなどのトリックプレイも考慮したフリークエンシー制御が可能 ● ターゲティング広告挿入が容易
- 111. リニアにおけるターゲティング広告の難しさ 番組表に沿ってリアルタイムで番組が配信され、 同じ番組の視聴者は広告ブレークのタイミングが同時 本編 広告 本編 広告 広告ブレークのタイミングに負荷が集中
- 113. 広告クラスター配信 CM チャンスの度に視聴者を特定のクラスターに分類し、 各々に適した広告を配信 本編 広告 A 本編 クラスター 1 本編 広告 B 本編 クラスター 2 本編 広告 C 本編 クラスター 3
- 115. 広告クラスター配信 Playout CDN Devices Manifest Request w/ Cluster ID Ad Cluster Request Manifest Request Ad Cluster API
- 116. 広告クラスター配信 Playout CDN Devices Manifest Request w/ Cluster ID Ad Cluster Request Manifest Request Ad Cluster API 広告クラスター決定のタイミングは非同期
- 117. 広告クラスター配信 Playout CDN Devices Manifest Request w/ Cluster ID Ad Cluster Request Manifest Request Ad Cluster API クラスターごとにストリームキャッシュ ↓ クラスター分のみオリジン流量増加 z
- 118. 更なる精度のターゲティングへ クラスターでは表現しきれない変数を組み合わせたターゲティング ● 番組という変数でのターゲティング ● 時間という変数でのターゲティング ● ユーザーという変数でのターゲティング ● デモグラという変数でのターゲティング
- 120. リニアパーソナライズド広告 ● ユーザーに最適化した広告を 本編 広告 本編 A B C D A E
- 122. リニアパーソナライズド広告 ● 課題は広告ブレークのタイミングに広告決定の負荷が集中すること 本編 広告 本編 A B C D A E 広告決定のタイミングを分散する
- 123. プリフェッチによる分散 広告ブレーク A 広告ブレーク B IN OUT OUTIN 時間 https://www.akamai.com/us/en/multimedia/documents/white-paper/go-live-white-paper.pdf
- 124. プリフェッチによる分散 広告ブレーク A 広告ブレーク B IN OUT OUTIN 時間 広告ブレーク B プリフェッチ （ペーシング） 広告ブレーク C プリフェッチ （ペーシング） https://www.akamai.com/us/en/multimedia/documents/white-paper/go-live-white-paper.pdf
- 125. プリフェッチによる分散 広告ブレーク A 広告ブレーク B IN OUT OUTIN 時間 広告ブレーク B プリフェッチ （ペーシング） 広告ブレーク C プリフェッチ （ペーシング） https://www.akamai.com/us/en/multimedia/documents/white-paper/go-live-white-paper.pdf 新規ユーザーのプリフェッチの期間 （既存ユーザーのプリフェッチは完了済）
- 126. プリフェッチによる分散 広告ブレーク A 広告ブレーク B IN OUT OUTIN 時間 https://www.akamai.com/us/en/multimedia/documents/white-paper/go-live-white-paper.pdf
- 127. Akamai Adaptive Media Delivery の導入 プリフェッチだけでは負荷分散しきれない ストリーム再生開始時のロードバランシングで分散 動画再生開始までの時間が長くなる
- 129. Akamai Adaptive Media Delivery の導入の効果 パーソナライズド処理なしの ストリームと同等の再生開始速度 にまで底上げ w/ Adaptive Media Delivery w/o Adaptive Media Delivery
- 131. Server-Guided Ad Insertion (SGAI) Hulu が実践している Ad Insertion ソリューション サーバーがユーザーの状態を持つのではなく クライアントが自身の状態に応じて 広告をスティッチ
- 132. Server-Guided Ad Insertion (SGAI) Hulu が実践している Ad Insertion ソリューション サーバーがユーザーの状態を持つのではなく クライアントが自身の状態に応じて 広告をスティッチ クライアントサイドでの Manifest Manipulation
- 133. Origin Transcaster Unicast to Multicast ISP’s Agent Multicast to Unicast A’s network B’s network Public network Gateway’s Agent Multicast to Unicast Multicast Unicast mABR などによる 配信でも柔軟性確保
- 134. Server-Guided Ad Insertion (SGAI) MPEG-DASH Patch Update ● サーバーはスティッチングしない ○ 更新情報をどこに取りに行くかガイドするだけ ○ コンテンツと広告が分離される ● スケーラビリティが高くなる ○ ただし、適切な時間管理を必要とする Nest step: より高可用なパーソナライズド広告へ
- 135. 品質向上のためのクライアントデータ Photo by Kelly Sikkema on Unsplash
- 136. サーバー側で検知できない不具合 ● 正常なレスポンスだが再生に失敗 ● 特定のバージョンでのみ発生 ● 特定の環境でのみ発生 ● 特定のデバイスでのみ発生 ● サーバーがリクエストを受け取る前にクラッシュ ● 出力マニフェストの変更によりリバッファリングの頻度増加 ● エンコーディングパラメータの変更によりデコード失敗 ● コンテンツ特性である区間だけ高ビットレート
- 139. RUM QoE - Quality of Experience Real User Measurement Quality of Experience ● ユーザーの環境で視聴体験に品質を計測
- 140. どんな品質メトリクスが必要か？ ● 致命的な再生障害発生率を計測するメトリクス ● 再生の快適さを計測するメトリクス ● ユーザーエンゲージメントを計測するメトリクス
- 141. 致命的な再生障害発生率を計測するメトリクス ● Startup failure % ● In-Stream failure %
- 146. 再生の快適さを計測するメトリクス ● Join time ● Buffering ratio ● Buffering event % ● Average bitrate
- 149. Buffering ratio １視聴全体の時間におけるユーザーが経験した バッファリング時間の比率（Join Time は省く）。 バッファリング比率
- 150. Joining Playing プレイヤーの状態遷移 Buffering 1 Buffering BufferingPlayingPlaying Buffering 2+ Ended
- 155. ユーザーエンゲージメントを計測するメトリクス 動画サービスのエンゲージメントは視聴時間と視聴コンテンツ数に現れる ● Playtime = 視聴時間 ● Plays = 視聴回数 ≒ 視聴コンテンツ数
- 156. ユーザーエンゲージメントを計測するメトリクス Playtime / Plays との相関／因果がある品質メトリクスを分析する ● Playtime ● Plays ● Join time ● Buffering ratio ● Buffering event %
- 157. 例：スムーズな再生体験に最適化する
- 158. Join time 初回ターゲット通信帯域幅（Bandwidth）の最適化 Mobile w/o WiFi Mobile w/ WiFi TV w/ WiFi 中解像度開始 高解像度開始 低解像度開始
- 159. Join time / Buffering / Bitrate A/B テストで複数メトリクスのバランスを見ながらアルゴリズムを検証 Flag A: 33.3% Flag B: 33.3% Flag C: 33.3%
- 160. Join time / Buffering / Bitrate A/B テストで複数メトリクスのバランスを見ながらアルゴリズムを検証 Flag A: 33.3% Flag B: 33.3% Flag C: 33.3% セグメントによってはバッファリングを抑えながら 消費ビットレートを上げる結果に
- 162. おわりに ● オンラインライブプラットフォームとしての品質 ○ より高画質なライブ配信 ● オンラインライブならではの演出品質 ○ リアルタイムのバーチャル撮影システムによるオンラインならではの演出 ● リモートワークでも品質を落とさないフルクラウドオペレーション ○ 社会の様相の変化に振り回されない動画オペレーション体制の構築
- 163. おわりに ● 報道品質 ○ より高い速報性 ● 愛される広告を届ける品質 ○ より高可用なパーソナライズド広告 ● 品質向上のためのクライアントデータ ○ 計測ありきの改善でより確実な品質向上