ストリーミング視聴解析の基本とその応用　IPv4・IPv6デュアルソース

1. ストリーミング視聴解析の
基本とその応用
IPv4・IPv6デュアルソース
鍋島 公章
2020年2月17日
Copyright (c) kosho.org 1

2. ◼ 第0部：ストリーミングのトレンド
• HTTPベース、プレイヤー主導
◼ 第1部：ストリーミング視聴解析の基本
• ストリーミングプレイヤー上でのイベント検知
◼ 第2部：バックエンド
• IoTビックデータ系
◼ 第3部：応用
• マルチソース再生
• マルチCDN、マルチスタック(IPv4、IPv6)
Copyright (c) kosho.org 2
もくじ

3. ◼ プロトコルのトレンド
• 昔：ストリーミング専用プロトコル
• 細切れのメディアファイルを特殊なプロトコルでダウンロード
• 今：HTTPベース
• 細切れのメディアファイルをHTTPでダウンロード
• 一般的なHTTP技術の利用が可能
◼ 視聴解析のトレンド
• プレイヤー上でイベント検知、解析サーバにビーコン送信
• 配信サーバの送信データは、ほぼ利用してない
Copyright (c) kosho.org 3
第0部：ストリーミングのトレンド

4. ◼ Web Browser (HTML5)
• 標準化が進む
◼ ストリーミング視聴解析に利用可能な標準
• HML5 video event
• 動画再生の各種イベント（再生開始等）
• Performance Timing API
• ファイルダウンロードのタイミング（ダウンロード時間）
• 非動画専用（HTTPを使うものすべてが対象）
• Media Source Extensions
• メディア再生の状況（チャンク落ち、チャンクエラー等）
Copyright (c) kosho.org 4
第1部：ストリーミング視聴解析の基本

5. Copyright (c) kosho.org 5
プレイヤー・イベント(html5 Video)
分類 イベント 概要 分類 イベント 概要
再生
状況
play 再生開始(キック)
準備
状況
emptied メディアバッファが空
waiting 再生可能を待つ resize 画面サイズ取得済
playing 再生開始(実効) durationchange コンテンツ長取得済
timeupdate 再生位置変更(再生中) loadedmetadata メタ情報取得済
seeking シーク中 loadstart 読み込みを開始
seeked シーク終了 progress メディアダウンロード中
pause 停止 suspend メディアダウンロードがアイドル
ended 再生終了 loadeddata 再生可能(次のフレーム)
ratechange 再生速度(倍速再生等)変更 canplay 再生可能(先送り可能)
volumechange 音量変更 canplaythrough 再生可能(バッファリングなし連続)
エ
ラー
abort ダウンロード失敗(取得中止)
stalled ダウンロードできない(取得継続)
error エラー発生

6. ◼ readyState
◼ networkState
Copyright (c) kosho.org 6
プレイヤー・ステイタス(html5 Video)
ステイタス 概要 関連イベント
HAVE_NOTHING 0
HAVE_METADATA 1 メタ情報読み込み済 loadmetadata
HAVE_CURRENT_DATA 2 メディアを読み込み済(早送り不可能) loadeddata
HAVE_FUTURE_DATA 3 メディアを読み込み済(早送り可能) canplay
HAVE_ENOUGH_DATA 4 メディアを読み込み済(バッファリングなし
に連続再生可能)
canplaythrough
ステイタス 概要 関連イベント
NETWORK_EMPTY 0
NETWORK_IDLE 1 アイドル suspend
NETWORK_LOADING 2 ダウンロード中 loadstart, progress
NETWORK_NO_SOURCE 3 読み込み失敗

7. ◼ イベント発生
• 実装により異なる
◼ 今回のサンプル
• Chrome (2018年ごろのやつ）
◼ フロー
• 基本再生
• 異常処理
• バッファリング
• エラー
Copyright (c) kosho.org 7
イベントのサンプルフロー

8. ◼ 外部イベント：ブラウザにURL投入
1, loadstart 読み込み開始
2, suspend メディアダウンロードがアイドル
◼ 外部イベント：再生ボタン押下
1, play 再生開始(キック)
2, waiting 再生可能を待つ
3, progress メディアダウンロード中
4, suspend メディアダウンロードがアイドル
5, durationchange コンテンツ長取得済
6, resize 画面サイズ取得済
7, loadedmetadata メタ情報取得済
8, progress メディアダウンロード中
9, suspend メディアダウンロードがアイドル
10, loadeddata 再生可能(次のフレーム)
Copyright (c) kosho.org 8
サンプル：基本フロー

9. ◼ 外部イベント：再生ボタン押下（続き）
11, canplay 再生可能(先送り可能)
12, playing 再生開始(実効)
13, canplaythrough 再生可能(バッファリングなし連続)
◼ 再生中イベント
1, timeupdate 再生位置変更(複数回、1/4秒単位)
2, progress メディアダウンロード中
3, suspend メディアダウンロードがアイドル
～上記の繰り返し～
◼ 終了時イベント(メディア終端での自動停止)
1, pause 停止
2, ended 再生終了
Copyright (c) kosho.org 9
サンプル：基本フロー(続き)

10. ◼ バッファリング（内部停止）
1. timeupdate
2. waiting
3. progress
4. canplay
5. playing
6. canplaythrough
7. timeupdate
Copyright (c) kosho.org 10
サンプル：異常系フロー

11. ◼ バッファリング（再生停止）
1. timeupdate
2. waiting
3. stalled
4. progress
5. progress
6. seeking
7. waiting
8. timeupdate
9. seeked
10.canplay
11.playing
12.canplaythrough
13.Timeupdate
Copyright (c) kosho.org 11
サンプル：異常系フロー
stalledとseekが発生

12. ◼ ネットワークエラー
1. timeupdate
2. waiting
3. stalled
<NETWORK_LOADINGのままダウンロード継続>
◼ 処理エラー
1. timeupdate
2. waiting
3. stalled
4. error
5. timeupdate
6. Pause
Copyright (c) kosho.org 12
サンプル：異常系

13. ◼ W3C Web Performance Timing API
• ブラウザのパフォーマンス計測用API
• W3C Web Performance Working Groupが策定
• APIs
Copyright (c) kosho.org 13
Performance Timing API
API 概要
User Timing API ブラウザ表示に関する時間取得
Resource Timing API リソースのロードに関する時間取得
Frame Timing API フレーム表示に関する時間取得
Server Timing API サーバが送信するヒント情報の取得
High Resolution Time API マイクロ秒単位のタイムスタンプ

14. ◼ 計測単位
• ブラウザが読み込むリソース毎にタイミングを計測
• リソース例
• HTMLファイル、CSS、画像、動画チャンク等
◼ サンプルコード
• timingList = window.performance.getEntriesByType("resource");
• ダウンロードしたリソースすべてが含まれる配列
• 動画の場合、チャンク数＋α(html、CSS等分)の配列となる
Copyright (c) kosho.org 14
Resource Timing API

15. ◼ ブラウザコンソール (F12)
Copyright (c) kosho.org 15
取得例 手入力
配列が返る

16. ◼ 取得可能な情報
Copyright (c) kosho.org 16
Resource Timing API
値 概要 例
name URL https://example.jp/a.png
entryType タイプ resouece(固定)
duration
ダウンロード時間
(responseEnd-startTime)
5345.0000000011641
transferTime ダウンロード量(HTTPヘッダ含む) 93315
encodedBodySize コンテンツ長(エンコード後) 92990
decodedBodySize コンテンツ長(本体) 92990
nextHopPrototol プロトコル http/1.1, h2, http/2+quic/39
initiatorType 取得タイプ(HTMLタグ名) link, img, script, css, iframe,
xmlhttprequest

17. ◼ 取得可能な情報(続き、タイミング)
Copyright (c) kosho.org 17
Resource Timing API
値 概要 例
startTime ダウンロード処理開始 613.7000000016997
redirectStar httpリダイレクト開始 0
redirectEnd httpリダイレクト処理終了 0
fetchStart 実処理開始 613.7000000016997
domainLookupStart DNSルックアップ開始 796.4000000065425
domainLookupEnd DNSルックアップ終了 913.7000000046100
connectStart TCP接続開始 913.7000000046100
secureConnectionStart SSL開始 916.4000000018859
connectEnd TCP接続完了 943.7000000034459
requestStart クエスト送信 945.2000000019325
responseStart レスポンス受信開始 957.8000000037719
responseEnd レスポンス受信完了 5958.7000000028638

18. ◼ Media Source Extensions (MSE)
• ブラウザ用HTTPベース・メディアストリーミング
• ソースハンドリングAPI
• 実装的な意味合い
• 各種実装(hls.js等)はチャンクをMSE経由でブラウザに渡す
• ブラウザは受け取ったチャンクを順次再生処理
Copyright (c) kosho.org 18
Media Source Extensions
00.ts 01.ts 02.ts
ブラウザ内部
MSE API
hls.js等

19. ◼ インターフェイス
• VideoPlaybackQuality
Copyright (c) kosho.org 19
Media Source Extensions
インターフェイス 概要
MediaSource 再生ソース
SouceBuffer チャンクバッファ
SouceBufferList チャンクバッファのリスト
VideoPlaybackQuality 再生品質
TrackDefault トラック情報
TrackDefaultList トラック情報のリスト
値 概要
creationTime 経過時間
totalVideoFrames 総フレーム数
droppedVideoFrames ドロップしたフレーム数
corruptedVideoFrames 壊れたフレームの数
totalFrameDelay フレーム表示の遅れ

20. ◼ 呼び出し方
• var video = document.getElementById('myVideo’);
• videoPlaybackQuality = video.getVideoPlaybackQuality();
◼ 注意点：実装状況
• Chrome：サポートせず
• Firefox: サポートするが、まともに実装できているか不明
• creationTime、totalVideoFramesは動くが、それ以外は不明
Copyright (c) kosho.org 20
Media Source Extensions

21. ◼ ビーコン
• JSONをそのまま送信
◼ プレイヤーからのビーコン送信
• REST：一般的な実装
• MQTT：動く！、しかしストリーミング用としては未開
◼ 解析
• 独自システム：一般的
• ビックデータ系：徐々に使われ始める
Copyright (c) kosho.org 21
第2部：バックエンド

22. ◼ ありがちな実装
• 送信内容
• タイムスタンプ、ユーザID、セッションID、各種イベント等
• 形式
• JSON
◼ 標準化
• なし、各社独自の実装
Copyright (c) kosho.org 22
ビーコン

23. ◼ プロトコル
• REST: REpresentational State Transfer
• MQTT: Message Queueing Telemetry Transport
• 動画における双方向性(サーバ⇒プレイヤー)の必要性
• チャット、緊急通知、プレイリスト変更
Copyright (c) kosho.org 23
ビーコン送信
REST MQTT
概要 HTTPでAPIをたたく 専用プロトコル(IoT系)
ストリーミング解析での状況 広く使われる 実装は可能だが、普及していない
プロトコルの重さ 重い 軽い
双方向性 なし あり

24. ◼ Azureでの実装例
Copyright (c) kosho.org 24
バックエンド
HTML5
Video
Player
IoT Hub
Streaming
Analytics
Job
Device
Explorer
SQL
Server
Power
BI
Storage
ブローカー
リアルタイム
処理 (SAQL)
生データ保存
簡易グラフ
ビジネス
インテリジェンス
データベース
Time
Series
Insight
簡易
管理ツール

25. ◼ 簡易管理ツール
• 操作
• Configuration：IoT Hubへの接続管理
• Management：デバイス追加
• Data：データのモニタ
• Message To Device
• Call Method on Device
Copyright (c) kosho.org 25
Device Explorer

26. ◼ 簡易グラフ
Copyright (c) kosho.org 26
Time Series Insight
例：イベント毎の発生
回数をグラフ化

27. ◼ リアルタイム解析
• SAQL
Copyright (c) kosho.org 27
Stream Analytics Job
SAQL

28. ◼ SQLに時間論理を追加
Copyright (c) kosho.org 28
SAQL (Stream Analytics Query Language)
タイムスタンプ
(TimeStamp by)
EventEnqueuedUtcTime イベントがキューに入った
EventProcessedUtcTime イベントが処理された
期間指定(ウィンド
ウ)
TumblingWindow ウィンドウ固定、かぶりなし
HoppingWindow ウィンドウが指定時間(例：5秒）で移動、か
ぶりあり
SlidingWindow ウィンドウがデータの発生消滅に合わせて移
動、かぶりあり
時間関数 ISFIRST 最初かどうか
LAG 前回の値
LAST 最後の値
TopOne トップ1件
CollectTop トップX件

29. ◼ アルゴリズム
• 単位時間(1分間)内に発生した”timeupdate”をUID別に数え上げる
◼ SAQL
SELECT count(distinct uid) as u_count, System.Timestamp as time
INTO [kosho-output4]
FROM [kosho-input2] timestamp by EventEnqueuedUtcTime
WHERE eventName = ‘timeupdate’
GROUP BY TumblingWindow(minute,1)
◼ 出力
{"u_count":1,"time":"2018-01-25T02:19:00.0000000Z"}
{"u_count":3,"time":"2018-01-25T02:20:00.0000000Z”}
{“u_count”:6,”time”:”2018-01-25T02:21:00.0000000Z"}
Copyright (c) kosho.org 29
SAQLサンプル：同時視聴数

30. ◼ 行動解析
• timeupdate：同時視聴数(視聴しているユーザ数)
• play：再生を開始したユーザ数
• pause:ポーズしたユーザ数(再生終了を含む)
• ended：再生を終了したユーザ数
◼ QoE解析
• waiting：帯域がぎりぎりのユーザ数(再生開始時のwaitingを含む）
• stalled：バッファリングが発生したユーザ数
• error：プレイヤーエラーのユーザ数
Copyright (c) kosho.org 30
イベントの意味合い

31. ◼ ビジネス・インテリジェンス
• 集計、グラフ化
• REST APIもあり
• 直接投入可能
Copyright (c) kosho.org 31
Power BI
青：再生回避
黄：再生中
ピンク：再生終了

32. ◼ マルチソース再生
• 複数のソースを計測し、複数のソースを上手く使う技術
• ソース例
• マルチCDN
• マルチサーバ
• マルチスタック(IPv4、IPv6)
Copyright (c) kosho.org 32
第3部：応用

33. ◼ アプローチ
• サーバサイド・マルチソース
• マルチソース・管理サーバ
• 計測結果を集計
• プレイヤーに判定指示
• プレイヤーサイド・マルチソース
• プレイヤー単体で計測、判定
Copyright (c) kosho.org 33
マルチソース再生

34. ◼ 概要
• マルチソース管理サーバがデータ集計、ソース判定
Copyright (c) kosho.org 34
サーバサイド・マルチソース再生
マルチソース
管理サーバ
CDN-a
object
CDN-b
object
CDN-c
object
ソース計測
計測結果報告最適ソース指示
データ集計
最適ソース判定

35. ◼ 概要
• プレイヤー単体でソース計測、判定
• 類似技術
• アダプティブ・ストリーミング受信
Copyright (c) kosho.org 35
プレイヤーサイド・マルチソース再生
CDN-a
object
CDN-b
object
CDN-c
object
ソース計測
最適ソース判定

36. Copyright (c) kosho.org 36
比較(サーバサイド、プレイヤーサイド）
サーバサイド プレイヤーサイド
用途 Web、ストリーミング ストリーミング
概要
プレイヤーでデータ計測、
サーバ側で計測データの収集、
ソース判定を実施
プレイヤーだけで、データ計測、
ソース判定を実施
状況 一般的に使用されている 実験レベル
実装規模
大規模(集計サーバ、統計サー
バ等が必要）
小規模(プレイヤー改良のみ）
リアルタイム判断 × 〇
無駄な計測トラフィック × 〇
4K、8Kコンテンツの計測 × 〇
継続的なソース計測 〇 ×
ソース切り離し後の処理 〇 ×

37. ◼ 全体切替と視聴中切替
Copyright (c) kosho.org 37
プレイヤーサイド・マルチソース
全体切替 視聴中切替
計測タイミング 1回(視聴開始時) 全チャンクの速度
切替 1回 複数回
再生ソース シングルソース マルチソース
実装 容易 難しい

38. ◼ 基本アプローチ
• 視聴開始時に1回計測
• 両CDNのレイテンシ計測
• http headリクエストで代用
• CDN選択
• 最初に1回のみ
• 視聴中のコンディション変化には対応しない
• 実装
• 比較的容易
• 商用実装あり(Hola Spark)
Copyright (c) kosho.org 38
全体切替アプローチ

39. ◼ 基本アプローチ
• 複数のCDNからチャンクをダウンロード
• それぞれの速度を計測
• CDN選択
• 早いCDNを多く使う
• 4:1、9:1等
• 実装
• そこそこ困難
• 商用実装なし
Copyright (c) kosho.org 39
視聴中切替アプローチ

40. ◼ 遅いソースの順番(1:4 or 4:1)
◼ アダプティブ・ストリーミング
Copyright (c) kosho.org 40
視聴中切替：アルゴリズムチューニング
遅いソース 補足
VoD 後(4:1) 遅いソースを先読み(両ソースを同時にダウンロード開始)
ライブ 先(1:4) バッファリング分の時間猶予
速度
両ソース>視聴ビットレート そのまま
片ソース<視聴ビットレート 両ソースを合わせた平均速度とバッファリング許容時間から判断
遅いソースの切り離し
両ソース<視聴ビットレート 視聴ビットレートを落とす

41. ◼ 切り離し
• 接続エラー
• あまりに遅い
• 例：アダプティブ・ストリーミング
◼ 再接続
• 網構成が変わった
• 例：モバイル網⇔Wi-Fi網
• 定期的
• 例：ゴールデンタイム、深夜帯
Copyright (c) kosho.org 41
視聴中切替：ソースの切り離しと再接続

42. ◼ Netflix
• 米国成立(2015)、日本なし
• 概要
• 共通バッファの割り振り方法
• 早いCDNに多くのダウンロードバッファを割振る
◼ J-Stream
• 日本成立(2019)、米国申請中
• 概要
• チャンクダウンロードの速度をベースにチャンク割当を変える
• 早いCDNに多くのチャンクを割振る
Copyright (c) kosho.org 42
特許

43. ◼ マーケットニーズ
• ユーザ側デュアルスタックの一般化
• 米国：50%程度
• 日本：20～30%程度
• IPv4とIPv6で速度が違うことが多い
• 家庭：IPv4 (PPPoE)は詰まり気味
• 企業：IPv6は詰まり気味(Youtubeの影響？)
• 早いスタックを使い分ける技術が求められている
◼ 実装
• 一般的なマルチCDN実装と同じ
Copyright (c) kosho.org 43
IPv6・IPv4マルチソース

44. http://ipv6.jpcdn.jp/ (IPv6のみアクセス可能)
• Media Source Extensions (MSE)を利用した簡易プレイヤー
• 定期的にチャンクをMSEに投げ込む
• 10秒分のチャンクが溜まるようにダウンロード(timeupdateに
引っ掛ける)
• チャンクソース
• ipv6.jstream.jp：IPv4、IPv6のデュアルスタック
• ipv4.jstream.jp：IPv4のみ
• 制限事項
• IPv4とIPv6でサーバが異なる(経路が異なる)
• IPv6.jstream.jp(デュアルスタック)に対してIPv4でアクセスしてい
る可能性がある
Copyright (c) kosho.org 44
サンプルサイト

45. http://ipv6.jpcdn.jp/
• 速度比較(IPv4とIPv6を交互にアクセス)
• http://ipv6.jpcdn.jp/4k-comp.html (25Mbps)
• http://ipv6.jpcdn.jp/2k-comp.html (6Mbps)
• http://ipv6.jpcdn.jp/1m-comp.html (1.2Mbps)
• マルチソース(早い方を4倍使う)
• http://ipv6.jpcdn.jp/4k-psmcdn.html (25Mbps)
• http://ipv6.jpcdn.jp/2k-psmcdn.html (6Mbps)
• http://ipv6.jpcdn.jp/1m-psmcdn.html (1.2Mbps)
Copyright (c) kosho.org 45
サンプルサイト

46. 2019年11月21日 – 2019年12月16日
• 集計データ
• セッション数: 149
• クライアント数: 134
• 生データとフィルタ
• 生セッション数: 413
• フィルタ
• フィルタ1：データが取れている (IPv4チャンク> 9、IPv6チャン
ク> 9)セッションのみ利用
• フィルタ2：同一ユーザのセッションは最後のものだけ利用
Copyright (c) kosho.org 46
計測結果

47. ◼ 平均速度
IPv4: 7.81MB/s
IPv6: 6.79MB/s
Copyright (c) kosho.org 47
Analysis

48. ◼ カウント別
Copyright (c) kosho.org 48
分析
サンプル数
IPv6早い (> 4) 5 3.36%
IPv6早い (4 ~ 2) 7 4.70%
IPv6早い (2 ~ 1.2) 24 16.11%
ほとんど同じ(~ 1.2) 63 42.28%
IPv4早い (2 ~ 1.2) 31 20.81%
IPv4早い (4 ~ 2) 11 7.38%
IPv4早い (> 4) 8 5.37%

49. ◼ 時間別
Copyright (c) kosho.org 49
分析
0.01
0.1
1
10
100
0 4 8 12 16 20 24
IPv6 / IPv4 Speed Rate (log)
Hour Session# IPv6/IPv4
0 7 2.02
1 8 1.04
2 1 1.14
3 1 1.58
4
5
6 2 0.85
7
8 6 1.16
9 2 1.20
10 9 0.84
11 9 0.82
12 9 0.85
13 6 1.03
14 11 1.04
15 15 1.11
16 14 1.25
17 9 0.91
18 2 1.25
19 11 0.80
20 4 1.63
21 4 1.29
22 9 6.30
23 9 1.89
IPv6/IPv4 (log)

50. ◼ トレンド
• IPv4とIPv6の速度は同じではない
• 2割程度は速度が倍以上異なる
• 時間帯により速度が変わる
• 昼間: IPv4 > IPv6
• 夜間: IPv6 > IPv4
◼ 理由？
• PPPoE vs IPoE
• 家庭 vs 企業ネットワーク
• モバイル vs 固定
Copyright (c) kosho.org 50
IPv4 IPv6速度比較：議論

51. ◼ 詳細解析
• クライアントの分析
• AS (IPv4 IPv6)、オフィス・家庭、固定・モバイル
◼ 単一サーバ(非CDN) での計測
• CDNでは複数の拠点を使用
• データがぶれる場合がある
◼ データ獲得
• テストサイトの露出強化、外部との協力
◼ ビッグデータ分析環境
• 基本実装は終了、課題は予算
Copyright (c) kosho.org 51
IPv4・IPv6 今後の予定

52. ◼ ストリーミングの視聴解析
• 取っつきにくいが、理解すれば難しくない
◼ ビックデータ解析
• ストリーミングプレイヤーからRESTやMQTTで直接データ投入可能
◼ マルチソース再生
• 有効な技術
• プレイヤーの工夫だけでパフォーマンス向上が可能
• きちんと作りこめば流行る技術
• スタディされてない
• 論文はあまり出ていない
• 特許は出ている
Copyright (c) kosho.org 52
おわりに

53. ◼ 研究
• やるべきこと
• 精度の高いデータ収集、もっと多くのデータ収集
• ソース選択アルゴリズムの改良
• いっぱい論文書けます
◼ 開発
• やるべきこと
• hls.js、video.jsのプラグイン作成
• 有効な技術、特許化済み
Copyright (c) kosho.org 53
協力者募集