IPDC ライブストリーミング配信システムの低遅延化と

スタジアムでの実証実験への適用

鈴木 賢一郎† 熊倉 克成‡ 及川 晃樹†

†株式会社 NTT データ 〒135-8671 東京都江東区豊洲 3-3-9 豊洲センタービルアネックス

‡株式会社 NTT データ MSE 〒222-0033 神奈川県横浜市港北区新横浜 3-1-9 アリーナタワー

E-mail: †suzukiknd@nttdata.co.jp

あらまし IPDC ライブストリーミング配信システムでは IPDC 技術と MPEG-DASH 規格の組合せによりライブ

映像の一斉同報配信が可能である．本システムに対して我々は MPEG-DASH のセグメント長の短縮および配信・受

信処理の改善により，ライブ視聴を実現するために重要な要素である低遅延化を実現した．性能検証の結果，最短

で 2 秒以内の遅延時間でライブストリーミング配信が可能なことを確認した．また本システムを，一般ユーザを対

象にしたスタジアムでの大規模実証実験に適用したので，その模様も合わせて報告する．

キーワード IPDC，FLUTE，MPEG-DASH，ストリーミング，スマートスタジアム

Performance Improvement of IPDC Live Streaming Delivery System and

Apply for Experiment in the Stadium

Ken’ichirou SUZUKI† Katsunari KUMAKURA‡ and Koki OIKAWA†

†NTT DATA Corporation 3-3-9, Toyosu, Koto-ku, Tokyo, 135-8671 Japan

‡NTT DATA MSE Corporation 3-1-9, Shin-yokohama, Kohoku-ku, Yokohama, Kanagawa, 222-0033 Japan

E-mail: †suzukiknd@nttdata.co.jp

Abstract In this paper, we report the performance improvement result of IPDC live-streaming delivery system and apply

for demonstration experiment in the soccer stadium. This system provides a live streaming service by sending MPEG-DASH

segments with IPDC. We have achieved delay reduction for IPDC live streaming system by MPEG-DASH segment length

shortening and optimization of a process at delivery server and client application. And we applied this system to smart stadium

demonstration experiment and provide new experience to visitors.

Keyword IPDC，FLUTE，MPEG-DASH，Streaming，Smart Stadium

1. はじめに

IPDC ライブストリーミング配信システムは， IPDC

技術と MPEG-DASH 規格の組合せにより，ライブ映像

の一斉同報配信を実現するシステムである．我々は本

システムの開発を行い，送受信時間の測定結果からラ

イブ映像配信の実現が可能なことを報告した [1]．

本システムの典型的なユースケースとして，スタジ

アム等の競技場におけるスポーツのマルチアングル視

聴が考えられる．この場合，視聴する映像の元となる

競技が目の前で行われているため，ユーザ体験上，実

際の競技シーンと配信される映像の間にタイムラグが

小さいことが望まれる．

そこで今回，想定されるユースケースでの実用化に

向けて必要とされる低遅延化を実現したので，その概

要と性能検証結果を報告する．

また，本システムをスタジアムにて一般ユーザを対

象にした大規模実証実験に適用したので，その模様も

合わせて報告する．

2. IPDC ライブストリーミング方式の概要

IPDC ライブストリーミングのプロトコルスタック

と送受信処理の概要を図 1 に示す．

エンコーダ・セグメンタでは，入力されたライブ映

像を MPEG-DASH 形式のセグメントファイルへの分割

と H.264 による圧縮をした上で，IPDC ライブストリー

ミング配信サーバにセグメントファイルを送出する．

IPDC ラ イ ブ ス ト リ ー ミ ン グ 配 信 サ ー バ で は ，

MPEG-DASH セグメントファイルをソースシンボルに

分割した上で，誤り訂正用の FEC シンボルを生成し，

FLUTE ヘッダを付与して，UDP/IP パケットで送出す

る．ここで FEC シンボルの生成にはファイルサイズに

応じて LDPC-Staircase と Reed-Solomon のいずれかを

適用する．

2017年3月10日(金)　　　　　　　映像情報メディア学会技術報告　　　　　　ITE Technical Report Vol.41,No.11 BCT2017-45(Mar.2017)

Copyright © 2017 by ITE25

エンコーダ・セグメンタ

カメラIPDCライブストリーミング

配信サーバ

IPDCライブストリーミング受信クライアント

MPEG-DASH LDPC RS

FLUTE

IP

HTTPサーバ

プレイヤ

H.264

ライブ映像

セグメントファイル

ソース/FECシンボル

セグメントファイル取得・再生

セグメントファイル

ソース/FECシンボル

FLUTE

H.264放送波

／通信網

LDPC RS

MPEG-DASHUDP/IP

FLUTE / AL-FEC

放送波

MPEG-DASH

通信網 MPEG-2 TS

ULE

DASHDASHFLUTEFEC

プロトコルスタック

配信処理

受信処理

図 1：プロトコルスタックと送受信処理概要

送出された IP パケットは放送波と通信網のいずれ

でも伝送可能である．ここで放送波を利用する際は

ULE によりカプセル化した上で MPEG-2 TS パケット

に変換する必要がある．

受信クライアントでは，受信できたソースシンボル

と FEC シンボルから MPEG-DASH セグメントファイル

を復元した上で，MPEG-DASH プレイヤにて再生する．

この方式は，ARIB TR-B35 2.0 版エリア放送運用規

定 [2]のマルチメディア伝送方式や LTE におけるマル

チキャスト方式である LTE-eMBMS でも採用されてい

る [3]．また，米国のデジタル放送規格 ATSC3.0 でも，

トランスポート方式として FLUTE をリアルタイムデ

ー タ 伝 送 用 に 拡 張 し た ROUTE(Real-time Object

delivery over Unidirectional Transport)+MPEG-DASH 方

式が採用されており [4]，MPEG-DASH＋ IPDC 方式は広

く普及展開が見込まれる方式である．

3. IPDC ライブストリーミングの低遅延化

低遅延化に取り組むにあたり，Wi-Fi 環境での送受

信処理に要する時間を計測した．Nexus7 端末で受信し

た場合の結果を図 2 に示す．MPEG-DASH のセグメン

ト長が 1 秒の場合，最長で 5.8 秒程度の遅延であった．

処理時間の内訳からソース /FEC シンボル生成処理が

0.5～1 秒と幅があること，MPEG-DASH プレイヤ内で

は 2.5 秒程度を要していることが判明した．

遅延時間短縮の目標としてユーザニーズ等を踏ま

えて，最短で遅延時間「2 秒以内」を設定した．目標

達成のために以下に述べる 3 つの取組みを行った．

1 点目は MPEG-DASH のセグメント長の短縮である．

セグメント長を 1 秒未満に短縮することにより，セグ

メントのファイルサイズが小さくなれば，エンコー

ダ・セグメンタでの MPEG-DASH セグメントファイル

の生成処理や配信サーバにおける FEC シンボル生成

処理，受信クライアントでの FLUTE/FEC 受信処理と

いった本システム全体で処理時間の短縮が期待できる．

本取組みにおいてはエンコーダ・セグメンタのベンダ

と連携し，200ms の MPEG-DASH セグメントファイル

の生成を実現した．

2 点目は IPDC ライブストリーミング配信サーバに

おける処理の見直しである．ソース /FEC シンボル生成

蓄積クライアント MPEG-DASHプレイヤ

IPDCライブストリーミング配信サーバ

エンコーダ・セグメンタ

IPDCライブストリーミング受信クライアント

セグメンタ処理時間

1,000msec

ソース/FECシンボル生成処理時間

500msec～1000msec

FLUTE送出処理時間

730msec

ネットワーク伝送時間

70msec蓄積時間

730msecFLUTE/FEC受信処理時間

560msecプレイヤ処理時間

2,500msec

Wi-Fiルータカメラ

再生遅延時間

5,860msec

図 2：低遅延化前の送受信処理時間

処理時間が 0.5～1 秒と揺らいでいたが，これはエンコ

ーダ・セグメンタからの MPEG-DASH セグメントファ

イル入力タイミングと配信サーバにおけるセグメント

ファイル読込タイミングの周期ズレが原因と判明した．

これに対して配信サーバ内にセグメントファイル用の

バッファの新設，および，配信サーバの処理周期の短

縮を行うことで改善した．

3 点目は受信クライアントにおける MPEG-DASH プ

レイヤの処理の見直しである．改善前の測定では 2.5

秒程度を要していたため，詳細な動作をログ分析によ

り確認したところ，セグメントファイルが欠損した場

合に蓄積クライアントに対してセグメントファイル受

信のリトライ処理により時間が掛かっていることが判

明した．そこで，蓄積クライアントから MPEG-DASH

プ レ イ ヤ に セ グ メ ン ト デ ー タ 欠 損 発 生 を 伝 え ，

MPEG-DASH プレイヤの「リトライ処理時間」が短く

なるように改良した．さらに，プレイヤ内でバッファ

リングする MPEG-DASH セグメントファイルの数をチ

ューニングにより最小化することでプレイヤでの処理

時間の短縮を図った．

4. 性能検証実験

遅延時間短縮の取組みの効果を確認するために性

能検証実験を行った．機器構成を図 3 に示す．エンコ

ーダ・セグメンタは NTT エレクトロニクス社製の

HVX-500 で，MPEG-DASH のセグメント長を最小で

200ms での出力を可能にした試作版のファームウェア

を搭載している．視聴用端末には Android 端末を 3 機

種， iOS 端末を 4 機種の合計 7 機種で測定を行った．

実験では遅延時間が明確に分かるように入力映像

として 3 台のカメラともストップウオッチを撮影した．

入力映像を，セグメント長＝200ms の MPEG-DASH セ

グメントファイルに分割し，H.264 により画角＝960×

540，ビットレート＝800Kbps に圧縮して出力した．

IPDC ライブストリーミング配信サーバでは，AL-FEC

を Reed-Solomon 符号により冗長化率=70％で付与し，

IP 送出レート＝1.6Mbps で配信した．

各端末での 30 分間の測定における遅延時間の最頻

値と平均を表 1 に，遅延時間が最短となった Nexus7

26

IPDCライブストリーミング配信サーバ

Cisco Wi-FiControllerWLC2504

Cisco Wi-Fi APAIR-CAP3702I-Q-K9

Cisco Router 892J

MPEG-DASHエンコーダNTTエレクトロニクス

HVX-500

図 3：性能検証実験の機器構成

表 1：遅延時間の測定結果

OS 機種名 最頻値(秒) 平均(秒)

Android Xperia A 2.1 sec 2.5 sec

Android Xperia Z3 2.1 sec 2.2 sec

Android Nexus7 1.9 sec 2.0 sec

iOS iPhone SE 2.1 sec 2.8 sec

iOS iPhone 5 2.3 sec 3.0 sec

iOS iPhone 6 2.1 sec 2.3 sec

iOS iPhone 6 Plus 2.1 sec 2.4 sec

蓄積クライアント MPEG-DASHプレイヤ

IPDCライブストリーミング配信サーバ

エンコーダ・セグメンタ

IPDCライブストリーミング受信クライアント

セグメンタ処理時間

200msec 【-800ms】

FLUTE送出処理時間

150msec

ネットワーク伝送時間

70msec蓄積時間

150msec 【-580ms】FLUTE/FEC受信処理時間

100msec 【-460ms】プレイヤ処理時間

1300msec 【-1200ms】

Wi-Fiルータカメラ

再生遅延時間

1,920msec【-3940ms】

ソース/FECシンボル生成処理時間

100msec 【-900ms】

図 4：Nexus7 での処理時間の内訳

図 5：Nexus7 における遅延時間の推移

での処理時間の内訳を図 4 に，Nexus7 での遅延時間の

推移のグラフを図 5 にそれぞれ示す． Nexus7 では合

計で 3.9 秒の短縮により，最短 1.9 秒の遅延時間を達

成できた．また，30 分間の連続視聴でも安定して遅延

時間が 2 秒程度に収まっていることが確認できた．

図 2 と図 4 の比較から，第 3 章で述べた低遅延化の

個々の取組みの効果を分析する．まずセグメント長が

200ms になったこと で， セグメンタの処理時 間が

1000ms から 200ms で 800ms の短縮，受信クライアン

トの蓄積処理で 1290ms から 250ms で約 1 秒の短縮が

実現できたことが分かる．また，配信サーバにおいて

はセグメント長の短縮とサーバ内の処理の見直しによ

り，ソース /FEC シンボル生成処理時間が最大で 1000ms

であったのが 100ms に安定し，900ms の短縮が実現で

きた．さらに，MPEG-DASH プレイヤでも処理時間が

2500ms から 1300ms になり 1200ms の短縮が実現でき

たことが分かる．

表 1 から機種ごとに遅延時間のばらつきがあるが，

これは主に端末のハードウェア実装の違いに起因する．

また， iOS 端末が全般的に Android 端末よりも遅延時

間が長い傾向にあるのは，iOS は標準では MPEG-DASH

の再生に対応していないため，ソフトウェアで独自の

実装を行った影響である．

5. 実証実験への適用

開発したシステムをサッカーの J1 リーグ大宮アル

ディージャの本拠地である NACK5 スタジアム大宮に

おけるスマートスタジアム化の実証実験に適用した

[5]．本実験は 2016 年のセカンドステージを通じて行

われたもので，スタジアム内の Wi-Fi を通じて，来場

したファンにチーム情報の提供や映像配信に加えて，

所定の席へのフードデリバリやスタジアム周辺の店舗

で使えるクーポン配信なども行われた．

IPDC ライブストリーミング配信システムについて

は，9 月 25 日と 10 月 22 日，11 月 3 日に開催された 3

試合で「Wi-Fi マルチキャスト」のサービス名で 3 チ

ャンネルのライブ映像配信サービスを提供した．本シ

ステムによる 1.5 万人収容のスタジアム全体での映像

配信は国内初の試みである．実証実験における全体の

システム構成を図 6 に示す．来場者はスマートフォン

で大宮アルディージャの公式アプリの「LIVE 動画」を

タップすることで視聴できる (図 7)．また，視聴中に画

面をタップするとチャンネル選択ボタンと 15 秒間隔

のスキップ再生のボタンが表示される．

本実験における 3 チャンネルのライブ配信の番組編

成を図 8 示す．チャンネル 1 は試合のライブ中継であ

り，衛星放送向けのテレビ中継番組をそのまま配信し

た．チャンネル 2 は解説番組として，試合中はボール

支配率やシュート本数など試合のスタッツ画面を表示

し，ハーフタイムと試合終了後は大宮アルディージャ

にフォーカスした解説番組を視聴できるようにした．

チャンネル 3 は「選手追っかけ」として試合中に大宮

アルディージャの特定の選手を映し続ける映像である．

配信の設定は，3 チャンネルともエンコーダ・セグメ

ンタでセグメント長＝200ms の MPEG-DASH セグメン

トファイルに分割し，H.264 により画角＝960×540，

ビットレート＝800Kbps に圧縮している．IPDC ライブ

ストリーミング配信サーバでは，MPEG-DASH セグメ

ントファイルに AL-FEC を Reed-Solomon 符号で冗長化

率=70％で付与し， IP レート 1.6Mbps で配信した．ま

た，第 4 章で述べた検証実験で機種によって遅延時間

がばらついた事を考慮し，プレイヤ内のバッファサイ

ズを遅延時間が最短の Nexus7 でも 2.5 秒程度の遅延に

27

アプリダウンロードMPEG-DASH

エンコーダ

NACK５スタジアム大宮内にシステムを設置し映像配信と視聴を実現

約70台のWi-Fi機器最大1万5千人の観客（スマホ）

１台の配信サーバ

ライブ映像

マルチキャスト配信

IPDCライブストリーミング配信サーバ

チャンネル1：試合中継

チャンネル3：選手追っかけ

チャンネル2：解説番組

図 6：システム構成

チャンネル1の画面

15秒前に戻る/15秒進む(最大3分前まで戻ることが可能)

チャンネル選択

「LIVE動画」をタップ

図 7：公式アプリと LIVE 動画の視聴画面

ハーフタイム 後半 試合後

試合中継

試合のスタッツ(数分毎に更新)

選手追っかけ

チャンネル1

チャンネル2

チャンネル3

試合中継

試合のスタッツ(数分毎に更新)

選手追っかけ

衛星放送のCM

衛星放送のCM

衛星放送のCM

前半解説 試合解説前節の

ハイライト

試合前のピッチ映像

フィールド試合後のピッチ映像

試合前 前半

図 8：番組編成

図 9：3 チャンネル配信時のレートの測定結果

なるように設定して公式アプリに搭載している．

スタジアム内では各スタンドの最上部，および，サ

ポーター席の通路部分に一定間隔で向きを調整した

Wi-Fi AP が設置されていた．場内でスマートフォン用

のアプリを使って Wi-Fi の電界強度を測定したところ，

Wi-Fi AP からの距離が最も遠くなるスタンドの最前列

付近でも，-70～ -75dBm 程度であることが確認できた．

試合前に観客席が無人の状態で 3 台の端末を使って

1 チャンネルずつの受信を行ったときの IP レートの測

定結果を図 9 に示す．この結果から，1 チャンネルず

つマルチキャストで配信されていることが確認できた．

筆者も 3 試合とも観客席で Galaxy S6 edge を使って

LIVE 動画の各チャンネルを視聴したところ，稀に映像

が途切れることはあったものの，問題なく視聴できる

ことを確認した．画質はチャンネル 1 で背景に観客席

も入るようなシーンでの急なパンではブロックノイズ

が見られた程度で他は概ね良好であった．遅延時間は

現地で撮影した映像を直接入力しているチャンネル 3

で測定したところ，概ね 2.5～3 秒程度であった．

試合後のログ分析の結果から，公式アプリの利用者

の半数以上が LIVE 動画を視聴していたことが判明し

た．また，来場者へのアンケート結果から，このサー

ビスが新規のファンから特に好評であったことも分か

った [6]．コンテンツ次第で，さらに利用者が増えるこ

とが期待される．

この実証実験はメディアの注目も高く，新聞記事や

レポート記事での紹介 [7]，LIVE 動画のサービスを初

めて提供した 9 月 25 日の翌日のニュース番組では

LIVE 動画を楽しむファンの様子が紹介された．

6. おわりに

本報告では IPDC ライブストリーミング配信システ

ムの低遅延化の取り組みとスタジアムでの実証実験へ

の適用について報告した．

低遅延化では MPEG-DASH セグメント長の短縮，お

よび，配信サーバと受信クライアントそれぞれで処理

の見直しを行うことで最大で 3.9 秒の処理時間短縮が

できたことで，遅延時間が最短で 5.8 秒から 1.9 秒と

なり，目標とした「2 秒以内」の遅延を実現した．

また，スタジアムでの実証実験に本システムを適用

し，一般ユーザからも高い評価を得ることができた．

今後は他スタジアムへの横展開に取り組み，普及展

開を図っていく予定である．

文 献

[1] 本田崇智，他：”IPDC によるライブストリーミング配信システムの開発と性能評価 ”映情学技報，BCT2014-72，Vol.38，No.35，pp1-4(Sep.2014)．

[2] 電波産業会技術資料， ”エリア放送運用規定 ”， ARIB TR-B35 第 2.0 版 (Jul.2012)

[3] 3GPP TS 26.346 ：“ 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service (MBMS);Protocols and codecs(Release 11)”

[4] ATSC A/331 ： ”Candidate Standard: Signaling, Delivery, Synchronization, and Error Protection”

[5] 新たな感動と体験を～NACK5 スタジアム大宮から始まる新たなストーリー～NTT グループによる「スマートスタジアム」サービス

http://www.ntt.co.jp/news2016/1606/160624a.html http://www.ntt.co.jp/news2016/1609/160923a.html

[6] 多 様 化 す る ス タ ジ ア ム の ス ポ ー ツ 観 戦https://inforium.nttdata.com/foresight/smart-stadium.html

[7] 大宮アルディージャ本拠地の「Wi-Fi」が恐ろしく快適な理由 .Wi-Fi マルチキャスト実証実験が開始

http://japanese.engadget.com/2016/10/28/wi-fi-wi-fi/

28