ABEMA の視聴品質向上戦術
•
0 recomendaciones•1,851 vistas
The presentation describes how ABEMA, a Japanese Internet TV station, uses Real User Measurement methods to improve video QoE of their own contents.
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 の 視聴品質向上戦術 株式会社 AbemaTV 五藤 佑典 - 2020.08.28 ライムライト・ネットワークス・ジャパン株式会社主催ウェビナー -
- 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
- 4. Internet media ● Blogging platform ● Music streaming ● Game ● Curation ● Ad product Development ● Ad agency Broadcasting ● News ● Documentary ● Drama ● Anime ● Sports ● Music ● Movies - Internet TV station -
- 6. イントロ
- 7. Video QoE に対する課題意識は SNS から寄せられる 「ABEMA が再生できない」という ありがたい声たちとともに 芽生えていきました
- 8. サーバー側で検知できない不具合 ● 正常なレスポンスだが再生に失敗 ● 特定のバージョンでのみ発生 ● 特定の環境でのみ発生 ● 特定のデバイスでのみ発生 ● サーバーがリクエストを受け取る前にクラッシュ ● 出力マニフェストの変更によりリバッファリングの頻度増加 ● エンコーディングパラメータの変更によりデコード失敗 ● コンテンツ特性である区間だけ高ビットレート
- 11. RUM Real User Measurement Real User Monitoring 実際のユーザー環境で計測する 実際のユーザー環境を監視する
- 12. 本日は ABEMA で実践してきた RUM QoE を用いた視聴品質向上戦術を フェーズに分けたご紹介します
- 13. ７つのフェーズ 1. 品質メトリクスの可視化 2. 致命的な品質メトリクスへのアプローチ 3. スムーズな視聴体験へのアプローチ 4. 動画新技術の評価 5. Streaming Reliability Engineering 6. 事業に連動したメトリクスへのアプローチ 7. SLI/SLO モニタリングシステムへの統合
- 16. どんな品質メトリクスが必要か？ ● 致命的な再生障害発生率を計測するメトリクス ● 再生の快適さを計測するメトリクス ● １視聴の総合満足度を計測するメトリクス ● ユーザーエンゲージメントを計測するメトリクス
- 17. 致命的な再生障害発生率を計測するメトリクス ● Startup failure % ● In-Stream failure %
- 22. 再生の快適さを計測するメトリクス ● Join time ● Buffering ratio ● Buffering event % ● Average bitrate
- 25. Buffering ratio １視聴全体の時間におけるユーザーが経験した バッファリング時間の比率（Join Time は省く）。 バッファリング比率
- 26. Joining Playing プレイヤーの状態遷移 Buffering 1 Buffering BufferingPlayingPlaying Buffering 2+ Ended
- 31. １視聴の総合満足度を計測するメトリクス Happiness Score YOUBORA 独自のアルゴリズムで算出される １視聴におけるユーザー満足度の総合指標 ● アルゴリズム不明 → 改善案が出しづらい ● ABEMA のチャンネルザッピングのようなユースケースにミスマッチ あくまで参考指標として使用
- 33. ユーザーエンゲージメントを計測するメトリクス 動画サービスのエンゲージメントは視聴時間と視聴コンテンツ数に現れる ● Playtime = 視聴時間 ● Plays = 視聴回数 ≒ 視聴コンテンツ数
- 34. ユーザーエンゲージメントを計測するメトリクス Playtime / Plays との相関／因果がある品質メトリクスを分析する ● Playtime ● Plays ● Join time ● Buffering ratio ● Buffering event %
- 36. 致命的な品質メトリクスへのアプローチ 対象のメトリクス ● Startup Error % ● In-Stream Error % 意図しないエラーにより再生が開始できない、再生途中にクラッシュする、などの 致命的な再生パターンを洗い出し、原因を解決する
- 37. Android mobile の再生不具合改善 iPhone ユーザーより多くの Android mobile ユーザーから 再生不具合の報告 2018
- 38. Android mobile の再生不具合改善 スマートフォンというユースケースは同一のはず iPhone ユーザーより多くの Android mobile ユーザーから 再生不具合の報告 2018
- 39. Android mobile の再生不具合改善 Android mobile の再生実態はどうなってる？ スマートフォンというユースケースは同一のはず iPhone ユーザーより多くの Android mobile ユーザーから 再生不具合の報告 2018
- 40. 頻度が高い不具合を探る Play failures / In-Stream failures 、Live セッション / VOD セッション を セグメントすることで、エラー原因の傾向に違いがあることが分かる
- 41. 頻度が高い不具合を探る Play failures / In-Stream failures 、Live セッション / VOD セッション を セグメントすることで、エラー原因の傾向に違いがあることが分かる 頻度が高いエラーから 実装を修正する
- 42. Live セッションのストリームで 一定時間が経過したために メディアセグメントが利用できなくなり発生 ExoPlayer の BehindLiveWindowException の例 帯域に余裕を持たせ、発生を抑制するよう調整
- 43. 1 ヶ月スプリントで 約 3 ポイント減少
- 50. スムーズではない再生体験 ユーザーにストレスを与えるプレイヤーの状態遷移 Joining Playing 長い Join Time 短かいが頻繁な バッファリングイベント EndedBuffering 1 回だけだが 長いバッファリング時間
- 51. スムーズな再生体験 理想的なプレイヤーの状態遷移 Joining Playing 短かい Join Time エラーもバッファリングもなく再生終了 Ended
- 52. スムーズな再生体験に関わるメトリクス改善 ● Join time ● Buffering ratio ● Rate of buffering events
- 53. Join time 初回ターゲット通信帯域幅（Bandwidth）の最適化 Mobile w/o WiFi Mobile w/ WiFi TV w/ WiFi 中解像度開始 高解像度開始 低解像度開始
- 54. Join time / Buffering / Bitrate A/B テストで複数メトリクスのバランスを見ながらアルゴリズムを検証 Flag A: 33.3% Flag B: 33.3% Flag C: 33.3%
- 55. Join time / Buffering / Bitrate A/B テストで複数メトリクスのバランスを見ながらアルゴリズムを検証 Flag A: 33.3% Flag B: 33.3% Flag C: 33.3% セグメントによってはバッファリングを抑えながら 消費ビットレートを上げる結果に
- 57. 特に Join time は配信サーバーやデリバリー経路も問題も大きい
- 58. 特に Join time は配信サーバーやデリバリー経路も問題も大きい RUM だけでは網羅できない
- 59. 特に Join time は配信サーバーやデリバリー経路も問題も大きい 合成監視と組み合わせる RUM だけでは網羅できない
- 60. 合成監視 curl 等による合成監視的手法での詳細な計測とも組み合わせる ● DNS 解決の時間 ● TCP 接続の時間 ● リダイレクトで追加される時間 ● ファーストバイトが送信される直前の時間 ● ファーストバイトを受け取るまでの時間 ● ...
- 61. フェーズ４ 新技術の評価
- 62. IPv6
- 65. IPv6/IPv4 比較 IPv6 の導入は本当にユーザーの通信を改善したのか？ ● Average Bitrate ○ Linear : 18％↑ ○ VOD : 5％↑ ● Exit Before Video Starts ○ Linear : 2.8％↓ ○ VOD : 3.4％↓ ● Play failure % ○ VOD : 90％↓ Happiness Score : 3.6%↑
- 67. リニアパーソナライズド広告
- 68. リニアパーソナライズド広告
- 71. より広い Reliability のためのモニタリング ● シビリティレベルがデザインされたアラート ○ False Positive の頻度も高い ○ アクション可能なものだけインシデントにしたい ● 主観品質評価への対応 ○ MOS ○ 不体裁などのユーザーが認知する品質 ● 地域特性 ○ RUM QoS
- 74. The Cedexis Methodology 参照 ● Availability ○ Availability also known as 'cold start probes' are intended to allow media organizations to warm the caching services from the provider. Although there is a measurement value associated with this probe, at a high level, the availability probe can be used by a media organization to determine whether the provider is available or not. ● RTT/Latency/TTFB ○ This is the time for a single packet to be returned in response to an HTTP request. (ResponseStart - RequestStart) using the Resource Timing API provides this metric. ● Throughput ○ The throughput is measured (kilobits per second) for an entire request and response based on a large-test object download. File size (kilobytes) * 8 / (responseEnd - requestStart) using the Resource Timing API. https://blogs.akamai.com/2019/10/akamai-outlook-optimizing-edge-delivery-performance-and-monitoring.html
- 75. クライアントサイドでの RTT 値の取得方法 ● 厳密な RTT 値は求めない ○ クライアントサイドアプリケーション上で計測するため、ある程度の不純物は許容 ■ サーバーサイドでの実行処理時間はクライアントサイドからは分からない ● 保守的で原始的な取得方法を選択 ○ AbemaTV がサポートしている／今後していくデバイスは多岐に渡るため、 ○ 全デバイスで取得可能な方法を選択 ■ DNS ルックアップの時間やキャッシュ有無は無視する ■ アプリケーション上でリクエストから実際のネットワーク・インターフェースまでの遅延は無視 する ■ TTFB は諦める ● ペイロードを全てパースしたタイミングで計測する ● ペイロードを限りなく小さくする - Small object の概念
- 76. Req created in app Client App Client Network IF Server Network IF Server App Req sent Req received Req received in app Backend process Res created in app Res sentRes received Res received in app
- 77. Req created in app Client App Client Network IF Server Network IF Server App Req sent Req received Req received in app Backend process Res created in app Res sentRes received Res received in app ○ Timestamp ○ Timestamp
- 78. 全デバイス共通で取得可能な RTT 値を考える ● セグメントファイルへの HTTP の HEAD リクエストのレスポンス時間 ○ Small object の概念 ○ 実際のセグメントファイルからペイロードを除く ● 計測タイミング ○ 再生開始に取得 ■ HLS：最初の ts リソースに HEAD リクエスト ■ MPEG-DASH：Initialization segment のリソースに HEAD リクエスト ○ 再生開始後は 5 分間隔で取得 ■ 取得タイミングで一番最後にリクエストしたリソースに HEAD リクエスト ■ 番組本編と広告などコンテンツの種類は区別しない
- 79. QoS メトリクス ● Throughput ● RTT 比較セグメント ● CDN ● ISP ● City RUM QoS に必要なメトリクス／セグメント RTT 以外は YOUBORA 上にデータがある
- 83. ユーザーエンゲージメントを計測するメトリクス Playtime / Plays との相関／因果がある品質メトリクスを分析する ● Playtime ● Plays ● Join time ● Buffering ratio ● Buffering event %
- 84. ユーザーエンゲージメントを計測するメトリクス Playtime / Plays との相関／因果がある品質メトリクスを分析する ● Playtime ● Plays ● Join time ● Buffering ratio ● Buffering event %組み合わせによっては 相関が薄い
- 85. Join time x Playtime Join Time は極端に下がらないと視聴単位の Playtime に大きく影響しない 一度視聴するというモチベーションを持てば よほど開始までの時間が長くない限りはキリが良いところまでは視る 仮説
- 86. Join time x Playtime ただし、Join time が低いと無意識に次のエピソードへの腰が重くなる Join time が下がるとユーザー単位の Playtime や Plays は下がる 仮説
- 88. エンゲージエントメトリクスの最適化 より ABEMA の現状に則したエンゲージメントメトリクスを定義する ● 視聴単位 ○ Play time x *** ● ユーザー単位 ○ User total playtime x *** ○ User total plays x ***
- 89. マルチプラットフォーム ● Mobile device ○ iPhone / Android mobile ● Smart TV ○ Bravia / VIERA / REGZA / REAL / HISENSE / FUNAI / Apple TV ● Computer ○ Windows / macOS
- 90. マルチプラットフォーム ● Mobile device ○ iPhone / Android mobile ● Smart TV ○ Bravia / VIERA / REGZA / REAL / HISENSE / FUNAI / Apple TV ● Computer ○ Windows / macOS 空いた時間に暇を潰したい
- 91. マルチプラットフォーム ● Mobile device ○ iPhone / Android mobile ● Smart TV ○ Bravia / VIERA / REGZA / REAL / HISENSE / FUNAI / Apple TV ● Computer ○ Windows / macOS 据え置き／リモコン操作
- 92. エンゲージエントメトリクスの最適化 より ABEMA の現状に則したエンゲージメントメトリクスを定義する ● 視聴単位 ○ Play time x *** ● ユーザー単位 ○ User total playtime x *** ○ User total plays x *** ● ユースケース単位 ○ Mobile device ○ Smart TV ○ Computer
- 93. 消費スタイル ● Linear ● Timeshift ● VOD ● Live event ● Downloaded
- 94. 消費スタイル ● Linear ● Timeshift ● VOD ● Live event ● Downloaded 素早いザッピング
- 95. 消費スタイル ● Linear ● Timeshift ● VOD ● Live event ● Downloaded 求められる高解像度
- 96. エンゲージエントメトリクスの最適化 より ABEMA の現状に則したエンゲージメントメトリクスを定義する ● 視聴単位 ○ Play time x *** ● ユーザー単位 ○ User total playtime x *** ○ User total plays x *** ● ユースケース単位 ○ Mobile device ○ Smart TV ○ Computer ● 消費スタイル ○ Linear ○ Timeshift ○ VOD ○ Live event ○ Downloaded
- 97. エンゲージエントメトリクスの最適化 より ABEMA の現状に則したエンゲージメントメトリクスを定義する ● 視聴単位 ○ Play time x *** ● ユーザー単位 ○ User total playtime x *** ○ User total plays x *** ● ユースケース単位 ○ Mobile device ○ Smart TV ○ Computer ● 消費スタイル ○ Linear ○ Timeshift ○ VOD ○ Live event ○ Downloaded
- 99. メトリクスから SLI/SLO へ Streaming Reliability Engineering 事業最適化視聴メトリクス プロダクト DevOps
- 100. メトリクスから SLI/SLO へ Streaming Reliability Engineering 事業最適化視聴メトリクス プロダクト DevOps SLI でリンク
- 101. メトリクスから SLI/SLO へ In Progress ...