( ) ( ) ( ) ( ) ( )

(1)

NAIST-IS-MT0851074

修士論文

複数映像同時視聴のための自律型

ALM

構築手法の

提案

中川隆広

2012年 3 月 2 日奈良先端科学技術大学院大学情報科学研究科情報システム学専攻

(2)

本論文は奈良先端科学技術大学院大学情報科学研究科に修士 (工学) 授与の要件として提出した修士論文である。中川隆広審査委員：藤川和利教授 (主指導教員) 山口英教授 (副指導教員) 猪俣敦夫准教授 (副指導教員) 砂原秀樹教授 (慶應義塾大学)

(3)

複数映像同時視聴のための自律型

ALM

構築手法の

提案

∗

中川隆広

内容梗概近年，高速なインターネットの普及と高速化に伴い，人々が映像コンテンツを視聴する機会・時間が多くなってきている．その中に複数の映像を同時に視聴しようとする研究が行われている．しかし，現在一つの映像を視聴することは想定されているが，複数の映像を同時に視聴することは想定されていない．そのため，複数の映像を同時に見ようとすると，それぞれの映像の再生タイミングにズレが生じてしまう．また，できるだけ高画質で複数の映像を視聴しようとした場合，全部の映像を一か所のサーバにまとめて送信しようとするとサーバの帯域がひっ迫してしまう．そこで本研究では，複数地点のサーバからのストリーミングパケットにタイムスタンプを基にした同期情報を付与した P2P ストリーミングシステムを構築し，各再生クライアント側で揃えることによって各映像を同期して再生する機構を実現する．この P2P ストリーミングシステムの参加の際に行うブロードキャストの範囲をリダイレクト法によりブロードキャストの範囲を制限する方法を提案する．これにより，複数地点からの映像を組み合わせて同時に再生するときに生じる，再生タイミングのズレを抑えることが可能となる．キーワード ALM,ストリーミング, 映像間同期, ツリー構築, 遅延 ∗_{奈良先端科学技術大学院大学情報科学研究科情報システム学専攻修士論文,} NAIST-IS-MT0851074, 2012年 3 月 2 日.

(4)

Proposal of How to Build Autonomy Type ALM

for

Simultaneous Viewing Multi Videos

∗

Takahiro Nakagawa

Abstract

In recent years, an opportunity and the time when people view to image con-tents are increasing with spread and improvement in high-speed Internet. Re-search which is going to view to two or more images simultaneously is done. Although viewing to one image was assumed, but viewing to two or more images simultaneously was not assumed. Therefore, if it is going to view two or more images simultaneously, gap will arise to the reproduction timing of each image. Moreover, when it is going to view to two or more images by high definition as much as possible, the bandwidth of a server will be tight, if all images tend to be summarized to one server and it is going to transmit. So, in this research, the P2P streaming system which gave the synchronous information based on a time stamp to the streaming packet from the server of two or more points, and the mechanism which synchronizes and reproduces each image is proposed by arrang-ing by each reproduction client side. Thereby, when reproducarrang-ing simultaneously combining the image from two or more points, it becomes possible to suppress gap of the arising reproduction timing.

Keywords:

ALM, streaming, synchronization between videos, tree construction, delay

∗_{Master’s Thesis, Department of Information Systems, Graduate School of Information}

(5)

第 1 章はじめに 1 第 2 章大規模な映像配信における同時視聴を実現するための技術 5 2.1. 大規模映像配信技術 . . . . 5 2.2. メディア同期技術 . . . . 7 2.3. 各技術の比較 . . . . 8 第 3 章関連研究 9 3.1. ALM . . . . 9 3.1.1 配信ツリー型（プッシュ型） . . . . 9 3.1.2 データ駆動型（プル型） . . . . 15 3.1.3 ハイブリッド型 . . . . 16 3.2. メディア同期 . . . . 17 3.3. メディア同期を考慮した ALM . . . . 17 3.4. 関連研究のまとめ . . . . 18 第 4 章遅延時間を考慮した自律型複数 ALM ツリー構築手法 19 4.1. 想定環境 . . . . 20 4.2. 要求事項 . . . . 21 4.3. 設計 . . . . 22 4.3.1 システムの通信データ . . . . 24 4.3.2 システムの処理フロー . . . . 24 4.3.3 映像同期方法 . . . . 25 4.3.4 遅延測定方法 . . . . 28 4.3.5 ツリー構築法 . . . . 30

(6)

4.4. 実装 . . . . 33 4.4.1 インデックスサーバ . . . . 33 4.4.2 配信サーバ . . . . 36 4.4.3 視聴クライアント . . . . 38 第 5 章実験と評価 40 5.1. 予備実験 . . . . 40 5.1.1 予備実験の概要 . . . . 40 5.1.2 予備実験結果と評価 . . . . 41 5.1.3 予備実験のまとめ . . . . 43 5.2. 提案システムの検証実験 . . . . 45 5.2.1 検証実験の概要 . . . . 45 5.2.2 検証実験の結果と評価 . . . . 48 5.2.3 フレームレートと映像ビットレートの違いによる影響 . . . 51 5.2.4 ネットワーク遅延時間の変化による影響 . . . . 54 5.3. 実験のまとめ . . . . 55 第 6 章結論 57 6.1. まとめ . . . . 57 6.2. 現状と今後の課題 . . . . 57

(7)

図目次

1.1 複数の角度から同時視聴 . . . . 2 3.1 配信ツリー型（プッシュ型）ALM . . . . 10 3.2 管理サーバ方式の配信ツリー構築 . . . . 11 3.3 データ駆動型（プル型）ALM . . . . 15 4.1 提案（同遅延のノードに接続） . . . . 19 4.2 提案（リダイレクトとブロードキャストの組み合わせ） . . . . 23 4.3 提案システム処理フロー . . . . 25 4.4 タイムスタンプとメディア間同期 . . . . 26 4.5 提案（メディア間同期） . . . . 27 4.6 遅延時間の求め方 . . . . 28 4.7 接続と遅延の測定 . . . . 29 4.8 提案（リダイレクト） . . . . 31 4.9 提案（ブロードキャスト） . . . . 32 4.10 提案（離脱と復旧） . . . . 33 4.11 インデックスサーバ . . . . 34 4.12 配信サーバ . . . . 36 4.13 視聴クライアント . . . . 38 4.14 転送バッファと再生バッファ . . . . 39 5.1 予備実験 1 環境 . . . . 41 5.2 予備実験 2 環境 . . . . 42 5.3 パケット転送時間の分布 . . . . 43 5.4 パケット転送遅延時間の範囲 . . . . 44

(8)

5.5 ホップ毎の遅延時間 . . . . 45 5.6 ホップ毎の平均遅延時間 . . . . 46 5.7 実験環境 . . . . 46 5.8 参加ノード数とブロードキャスト受信数 . . . . 49 5.9 参加ノード数とストリーム間遅延差 . . . . 50 5.10 配信経過時間と受信タイミングのズレ . . . . 51 5.11 映像ビットレートとストリーム間の遅延時間差 . . . . 52 5.12 映像ビットレートと受信タイミングのズレ . . . . 53 5.13 遅延の分布設定 . . . . 54 5.14 遅延時間を変化させたときの受信タイミングのズレ . . . . 55

(9)

表目次

1.1 コンシューマインターネットトラフィック予測 . . . . 1 4.1 視聴者数と最適な配信技術 . . . . 20 4.2 想定環境 . . . . 21 4.3 システムの構成要素 . . . . 24 5.1 場所ごとの遅延時間の目安 . . . . 44 5.2 実験に使用した映像視聴ノードマシンのハードウェア構成 . . . . 47 5.3 実験に使用した映像配信サーバマシンのハードウェア構成 . . . . 47 5.4 実験の映像仕様 . . . . 48

(10)

第

1

章はじめに

近年インターネットの普及発達，高速化，低価格化により，高速で大容量な通信が一般家庭でも扱えるようになった．これにより人々がインターネットを通じて様々な情報を手に入れたり自ら発信することがしやすくなり，映像コンテンツを視聴する機会や時間が多くなってきている．そしてインターネット経由によるビデオ通話やインターネットビデオなどのマルチメディア通信が増加している． Ciscoの全世界のコンシューマインターネットトラフィック（2010 年∼ 2015 年）の予測 [1] を表 1.1 に示す．これによると，インターネットビデオによる通信は 2010年で月に 4672PB の量が流れており，今後年間成長率 48%の割合で増加していくと予測している．表 1.1 コンシューマインターネットトラフィック予測 (PB/月) 2010 2011 2012 2013 2014 2015 CAGR （2010∼2015年）ファイル共有 4,968 6,017 7,277 8,867 11,040 13,797 23% インターネットビデオ 4,672 8,079 12,146 17,583 24,357 33,620 48% Web、Eメール、データ 2,393 3,113 4,146 5,325 6,769 8,592 29% ビデオ通話 308 442 659 905 1,251 1,736 41% オンラインゲーム 49 68 95 133 187 290 43%

Voice over IP（VoIP） 138 147 153 157 160 168 4%

現在流れているインターネットビデオはビデオオンデマンドとライブ放送に分けられる．ビデオオンデマンドとはあらかじめ録画された映像をユーザが好みの時間に視聴する方法である．一方ライブ放は現在行われている出来事をリアルタ

(11)

図 1.1 複数の角度から同時視聴イムで放送する方法である．また近年，ユーザ発信型のコンテンツが増加 (CGM の増加 (Wiki，動画投稿サイト，生配信サイト)) し，さらにソーシャルネットワークでの情報発信などリアルタイムに情報をやりとりする機会が増えている．それに伴いライブ放送にも様々なサービスが登場してきている．例えば図 1.1 に示すような様々な角度から撮影された映像をユーザが好みに応じて選んで視聴するサービスが考えられている．ニコファーレ [2] ではライブ会場に設置した複数のカメラからユーザーが任意のカメラを選択してコンサートなどの中継を様々な角度から視聴することができる．またスポーツ中継においても球場に複数のカメラを設置し，同時に複数のカメラの映像を視聴できるサービス [3] が登場している．このように複数の映像を同時に視聴しようとするサービスが近年注目されている．しかしこのような複数の映像を同時に提供するサービスは高画質にしたりユーザーが増えたりするとそれだけサーバ側の帯域がひっ迫したりハイスペックな配信サーバが必要になったりするなどコストアップにつながってしまう．そこで近年，ALM(Application Layer Multicast) という各コンピュータのアプリケーショ

(12)

ン同士が直接映像データを転送していく P2P 技術よってビデオストリーミングの転送を行うことにより，サーバ側の配信コストを下げる研究が行われている． ALMを使えば，個人のような資金の乏しい配信者でも高品質な映像を低コストかつスケーラブルに配信することが可能である．しかし，ALM を使って複数の映像コンテンツを同時に視聴するということも可能となってきているが，現在それぞれの映像は単独で視聴することが想定されており，複数の映像を同時に視聴することは想定されはいない．このため，同じ対象を撮影した複数の映像を同時に視聴しようとした場合，それぞれの映像間に時間的な再生タイミングのズレが生じてしまう．そして，ALM によってマルチアングル放送を実現しようとするとデータの転送遅延によりさらにズレが大きくなる．これでは複数の映像を同時に再生させたときの価値が損なわれてしまうことになる．そこで ALM によるマルチアングルの映像でも視聴者側でズレなく再生できる必要がある．本研究では複数地点からのマルチアングルの映像配信を ALM で行う際，サーバからの映像パケットにタイムスタンプをつけることによって，複数映像を同時に再生するときに生じる，時間的な再生ズレを抑える機構を提案する．ユーザは映像に付与された映像データ生成時のタイムスタンプを元に，クライアント側で映像を揃えることによって視聴者が各映像を同期して再生する．これにより，複数地点からの映像を組み合わせて同時にズレなく視聴することが可能となる．また，ユーザーが増えても問題がなく参加できるようにするため，ALM ツリーへの参加処理を行う際ノード管理サーバを使わず，各参加ノード同士で計算して映像配信ノードからの遅延時間のズレが少ない位置を参加する．これによって特定サーバへの負荷を軽減させる．そしてこの参加処理行う際，リダイレクトとブロードキャストを組み合わせて参加する方法を用いる．これにより，ブロードキャストの対象ノード (ブロードキャストの範囲) を限定することができるようになり，処理負担が少ない参加処理を行えるようになる．本提案機構は参加処理を行う際ノード管理サーバを使わず各参加ノード同士で計算してタイムスタンプに応じて一番遅延時間の差が少ないノードの位置に参加する．これによってノード管理サーバへの負荷を軽減させた．またこの参加処理行う際，ブロードキャストの範囲を選択できるようにすることによって，処理負担

(13)

が少ない参加処理を行えるようにした．さらに映像配信ノードから映像視聴ノードまでの遅延時間を各ノード間のデータ転送遅延時間と転送処理時間を足していくことによって擬似的に求める機能を備える．これらの設計と実装を行い，マルチアングル ALM 配信を実現し，評価実験により提案手法の有効性を確かめた．本論文では第 2 章に大規模映像配信と複数映像の同時視聴における技術を述べ，第 3 章で本研究に関連する研究についてまとめ，第 4 章に本研究が提案するシステムについて述べ，第 5 章に提案システムに関する評価実験を行った結果を述べ，弟６章に本研究の結論を述べる．

(14)

第

2

章大規模な映像配信における同

時視聴を実現するための技術

本章ではまず大規模な映像配信を行う際に使用される技術について述べ，その次に複数の映像を同時に視聴する際に使用される技術について述べる．

2.1. 大規模映像配信技術

本節では大規模な映像配信を行う際に使用される技術について述べる．大規模な映像配信とは視聴者数が多い映像の配信のことである．映像を配信する際に使用される配信方法によって様々な特徴を持つ．この配信方法の種類について次に述べる．

クライアントサーバ方式

クライアントサーバ方式は従来の Web サービスなどに使われてきた手法である．配信サーバに対してユーザが映像コンテンツを要求し，サーバが直接ユニキャストによってユーザに映像を届ける．この方式の場合サーバがユーザの状況を把握しやすいため，パケットロスに対して再配送を行うなど細かなサービスが行える．しかし同時に視聴するユーザの数が増えるにつれ，サーバの処理は増えていき多くの CPU パワーやメモリーが必要となる．また，映像データを各クライアントに個別に配信するので，サーバ側のネットワーク回線の帯域も多く必要になる．

(15)

Contents Delivery Network(CDN)

CDNは前述のクライアントサーバ方式における，クライアントとサーバの間にキャッシュサーバのような中継サーバを置き，サーバの負担を分散する技術である．配信サーバ自体は中継サーバのみと通信すればいいので，サーバのネットワーク回線の帯域や CPU パワーやメモリーなどを低く抑えることができる．しかし，ネットワーク上にいくつか配布場所を用意し，ユーザの位置に応じた配布場所から映像を受信する DNS を使った CDN 特許を akamai が持っていることや，中継サーバを含めたサーバ群の総ネットワーク帯域はクライアントサーバ方式と変わらないことなどから配信するためのコストはクライアントサーバ方式の次に大きくなる．

IP

マルチキャスト

IPマルチキャストはサーバとクライアントの間にあるネットワーク機器（ルータや L2 スイッチなど）がデータを複製して各クライアントに届ける技術である．サーバはクライアントの数によらず一つの映像データだけを送信すればいいので，サーバ側のネットワーク帯域や CPU パワーなどを低く抑えることができる．さらに各ネットワーク機器がデータの複製をするので，全体のネットワークトラフィックを抑えることができる．しかし，IP マルチキャストは配信対象の ISP が IP マルチキャストに対応している必要があり，ISP 間を越えるマルチキャストにおいては，ISP 間であらかじめ取り決めをしておく必要があるため，普及には至っていない．

Application Layer Multicast(ALM)

ALMはクライアント同士が映像データをバケツリレーのようにして転送する P2Pを使った技術である．サーバは一部のクライアントのみ映像データを送信すればよく，サーバ側のネットワーク帯域や CPU パワーなどを抑えることができる．しかし，クライアント自身が他のクライアントに対してデータを転送するの

(16)

で，クライアントの上り帯域が必要になったり，配信の安定性に欠けたりする．詳細については第３章にて説明する．

2.2. メディア同期技術

複数のメディア (映像，音声，文字情報など) を合わせて一つのマルチメディアとして提供する技術をメディア同期という．メディア同期は内容によってメディア内同期，メディア間同期，端末間同期の３つに分けられる [4]．

メディア内同期

単一メディアにおける MU(MediaUnit) の時間間隔に関するものであり，ビデオフレームの表示間隔の制御などがある．つまりインターネットのジッターによる影響などを調整して，メディアを一定間隔で再生させるなど，フレームレートを一定に保つ機能の役割がある．

メディア間同期

メディア間同期は音声と映像などのような複数メディア間の時間関係の保持を行う．代表的なメディア間同期の技術に人間が喋る音声と口元の映像を合わせるリップシンクがある．その他にも映像と映像を合わせたり映像と文字を合わせたりするなど複数のメディアを繋げて再生する技術が開発されている．

端末間同期

端末間同期はマルチキャスト伝送されたひとつの MU が異なる端末で同時に出力されるように制御するものである．マルチメディア会議や複数人の遠隔学習に必須の機能である．複数のシステム (コンピュータ) 間で同時にメディアを再生するテレビ会議システムや，複数の端末に映像を同時に再生させる時報システムな

(17)

どがある．端末間同期をするにはあらかじめシステムどうしで時刻情報の共有されていることが前提である．

2.3. 各技術の比較

BBブロードキャストのマーケット戦略 [6] によると映像配信に使われる技術をその視聴者数の規模によって３つに分けている．まず視聴者数 1 人から 100 人規模の映像配信はサーバがそれぞれのクライアントにつなぐ手法が望ましい．次に 10万人以上の配信には無線電波による放送が望ましい．そして 100 人から 1 万人規模の映像配信は ALM が望ましいとしている．メディア同期については複数の映像を同期させて視聴するにはメディア内同期，メディア間同期，端末間同期の３つが必要である．

(18)

第

3

章関連研究

本章では，3.1 節で大規模な映像配信に使われる ALM について説明し，その種類ごとに最近の研究を説明する．3.2 節では複数の映像間においてズレなく再生させるためのメディア同期について説明し，最近の研究を説明する．3.3 節で映像間のズレを考慮した ALM の研究についての最近の研究を説明する．そして 3.4 節で関連研究のまとめを行う．

3.1. ALM

本節では ALM について説明する．ALM は別名 OLM(Over Lay Multicast) や P2Pマルチキャストとも呼ばれ，データの転送に P2P 技術を使用した方法である．ALM は配信サーバから送られたデータを一部のクライアントが受け取り，受け取ったクライアントが別のクライアントにバケツリレーのようにデータを複製してユニキャストで転送していく．各ホスト間のアプリケーション層でデータをバケツリレー方式でコピーしていくことによって，全体としてマルチキャストのような動作をする．このようにデータの複製をサーバやルータで行うのではなく，各クライアントで行うのが特徴である．配信サーバは一部のクライアントだけにデータを転送するだけでよいので，配信元のネットワーク帯域が低くサーバのマシンスペックが低くても大規模な配信ができるようになる． ALMはデータ配信経路の構築方法によって次のいくつかの種類に分けられる．

3.1.1 配信ツリー型（プッシュ型）

配信ツリー型 ALM はプッシュ型とも呼ばれ，ノード同士で親子関係を作り多段階層化して参加ノード群がマルチキャストのためのデータ配信ツリー（ALLM

(19)

ツリー）を構築し，木構造に沿って配信元である根から葉に向かってデータを転送していくことによってマルチキャストを実現する．この方式について図 3.1 に示す．この方式ではツリーの根にあたる映像配信ノードが放送局となり，上流ノードから下流ノードへ，データをバケツリレー方式で転送していくことで，全参加ノードに，ほぼ同時に同じデータを配信することができる．これにより，リアルタイムのストリーミング中継が可能となる．図 3.1 配信ツリー型（プッシュ型）ALM 配信ツリー型 ALM は配信ツリーの作り方によってさらに次に挙げるような様々な方式に分かれる．管理サーバ方式 ALM ツリーを構築する際，ノード管理サーバによって集中的につなぐ場所を管理する方法が管理サーバ方式である．管理サーバ方式について図 3.2 に示す．例えば ShareCast[7] では新規参加ノードはノード管理サーバに問い合わ

(20)

図 3.2 管理サーバ方式の配信ツリー構築せ，つなぐ場所を決めて配信ツリーを構築している． ALMI[8] では，まず新規参加ノードが他のノードとの遅延時間情報を session controlerと呼ばれる管理サーバに送り，管理サーバは最も効率的な配信ツリーを決定し接続するノード先を決める．これによってあらかじめ参加者がわかっている場合のような小規模な環境において，低遅延な配信

(21)

ツリーを構築することができる．一方，文献 [9] では参加ノードがあらかじめ決まっているのではなく，順次参加していくことを想定した低遅延ツリーについて提案している．新規参加ノードは管理サーバから通知された既存参加ノードの中から，ツリーの高さが低くノード間の遅延時間が短いノードに接続することによって，低遅延なツリーを実現している．これら管理サーバ方式の手法は全体の状況を把握しながら適切な参加位置を決められるので，目的に応じた最適な配信ツリーを構築しやすい．一方参加ノードが増えるとノード管理サーバがボトルネックとなる．例えば，管理サーバ方式の ALM に 1000 ノードがつなぐ場合，管理サーバに 1000 回の参加位置決定処理をし，参加完了時にも管理サーバに 1000 回の登録処理を行い，離脱時も管理サーバに 1000 回の離脱処理を行う必要がある．このため管理サーバ方法ではノード数が増えるにつれノード管理サーバの負担が大きくなるという問題がある．自律参加方式自律参加方式はノード管理サーバを用いず，各ノード同士で計算して参加位置を決める方式である．管理サーバを使わないことによって配信規模の拡張性を実現している．例えば PeerCast[10] では既にツリーに参加しているノードに対して，ルートノードから一つずつ問い合わせていくことにより，自分の参加位置を決める．以下に PeerCast が提案するツリー構築手法のうち一つの例を示す．まず問い合わせを受けたノードはあらかじめ決めた自身が決めた最大受け入れ子ノード数（自身が提供可能な最大の上り帯域に応じて決める）に達していないかどうかで子に受け入れるか判断する．この時子ノードの数が最大受け入れ子ノード数に達していない場合，自身の子として受け入れる．受け入れができない場合は自身の子ノードの中から，ラウンドロビンによって一つの子ノードを選択して返す．これをリダイレクトと呼ぶ．このリダイレクトを受け入れ可能になるまで繰り返す．受け入れ可能な位置までリダ

(22)

イレクトを繰り返してツリーに参加すると，映像データの受信を開始する．そしてある程度映像データのバッファが貯まったら再生を開始する．親ノードが離脱した場合は，子ノードは祖父ノードにつなぐ．以上が PeerCast による自律参加方式の例である．この方式は映像データが ALM を流れる時，既に流通経路が定まっているため，データがあるノードに到達するまでの時間，すなわち遅延と，遅延の揺らぎ（ジッタ）を低く抑えやすいという利点がある．また配信ツリーの形状がデータの流通経路になるので，配信ツリーの構築を通してデータの流通経路を厳密に制御できるという利点もある．このことにより帯域幅の狭い経路や不安定な経路を明示的に避けるといったことを可能とする．文献 [11] では PeerCast が一つのルータを挟んでデータを転送するごとに約 30ms の転送遅延が発生することを示した．文献 [12] では現在参加しているツリーの位置から上流に位置するノードにつなぎかえていくことにより全体的に低遅延のツリーを実現できることを示した．文献 [13] では最も子が少ない枝にリダイレクトしていくことによって深さを抑えて全体的に低遅延なツリーを実現している．文献 [14] では，新規参加ノードは参加時に参加要求を配信ツリーにブロードキャストして，各中継ノードが各自の評価値に応じて返信問い合わせ結果を返信する．この返信する時に，返信するタイミングを目的 (木の深さ等) の重みづけによって遅らせる方法を提案している．これにより低い木で，ノード間の遅延が少ないツリーの構築を行うことができる．しかし，参加ノードが増えると返信時に DOS のような状態が起こってしまう．一方でノードの故障や，日常的に起こる突然の離脱に際しては，素早く配信ツリーを修復しなければならず，ここで問題が生じると映像の停止などの失敗が生じることになる．そしてこの離脱したノードが配信ツリーのルートノードに近かった場合，その影響はより大きくなる．そこで上流ノードが脱退した時にストリームが途切れないように，内部にバッファを多く持

(23)

つことで一定時間は再生が途絶えないようにして，その間に別の上流ノードに再接続をする．このようにして切断されて途切れずに再生を続けることが可能となる．この再接続先候補のノードを，あらかじめ準備しておくことで素早く復旧したり，転送方法を工夫するなどして耐故障性を上げる提案がされている．耐故障性を上げる方法の一つにマルチツリーがある．文献 [15] では映像をいくつかのストリームに分割し，ストリームを多く受信した分だけ高画質な映像になるという符号化を前提に，それぞれのストリームを複数の経路で流し，二つ目以降のツリー参加時に，既接続ツリーの経路ノードに途中の経路に重複した親がないような経路パスを設定する．このように中継ノードの重複を避けることによって耐故障性を上げている．また，文献 [16] では親が離脱した際の予備親を決めておく．このとき，叔父ノードの下位ノードに予備親を設定することにより，ツリーの深さが局所的に深くならないように工夫している． メッシュ(プッシュ) 方式 メッシュ方式は事前にノード群でメッシュネットワークを構成しておいて，その上に配信ツリーを構築する方法である．映像のデータ転送はその構築した配信ツリーによって行われる．配信途中のノードが離脱した際は，すでにメッシュネットワークで接続済みの別のノードに対して即座に再接続処理を開始することができる． Narada[17] ではまずメッシュネットワークを張り，その中で IP マルチキャストで使われる DVMRP（Distance Vector Multicast Routing Protocol）を使い，隣接ノードと遅延情報や帯域情報を計測して最適な配信ツリーを構築する．文献 [19] ではまず全てのノードとフルメッシュでオーバレイを構築し，配信ノードからの遅延を計測する．その遅延情報を元にグループ化して，そのグループ間で許容遅延時間内に全てのノードに配信できるように経路パスを探索して，配信ツリーを構築している．

(24)

構造化オーバレイ方式 Scribe[20] は分散ハッシュを用いた構造化オーバレイの手法である Pastry を用いて ALM を実現する．Pastry によって構築されたオーバレイから，配信ノードへの経路をたどり，その経路を逆順にデータ転送することによって，マルチキャストを実現している．

3.1.2 データ駆動型（プル型）

文献 [22] ではデータ駆動型ネットワーク（DONet: Data-driven Overlay Net-work）を提案している．これは別名プル型と呼ばれる．データ駆動型はまずメッシュネットワークを構築することから始まる．データ駆動型の ALM について図 3.3に示す．

図 3.3 データ駆動型（プル型）ALM

(25)

加者ノードリストから代理の情報提供ノードを紹介する．代理の情報提供ノードは自身の mCache を新規参加ノードに提供する．新規参加ノードはその中からいくつかをパートナーとして接続する．mCache の情報は離脱検知時や新規参加時に更新される．パートナーとして接続されたノード同士はストリーミングデータ転送の親子の役割を決めず，利用できる映像データ情報（既に受信している映像データの情報）を定期的にパートナー同士で交換する．利用できるデータをパートナーに提供したり，足りないデータをパートナーから受け取ったりする．定期的に送信帯域が少ないパートナーを削除して新しいパートナーに繋ぎ換えることで，最適にネットワーク更新する．データの方向を決めず複数のノードから分割された小さなデータを受信したり送信したりするので効率的である．また定期的にパートナーを変更することが前提なので，離脱に対して丈夫で回復力がある．しかし，ツリー型においては視聴ノードは映像データをネットワークのゆらぎを吸収する分だけバッファにためて再生させればいいのに対して，データ駆動型ではあるまとまりの映像データ分割し，分割された映像データは個別に転送される．この分割された映像データはネットワーク全体に確実に拡散させてから再生を開始する必要があるため，タイムラグが大きくなる傾向がある．

3.1.3 ハイブリッド型

OceanGrid[23]はツリー型とデータ駆動型を組み合わせたツリーメッシュハイブリッド型と呼ぶことができる．映像配信ノードからまずツリー型でいくつかのノードにデータをプッシュで転送する．そしてツリー型でデータを受け取ったノードは次にデータ駆動型のルートノードとしてメッシュネットワークを作りデータを転送する．こうすることによってツリー型の高速性とデータ駆動型の堅牢性を組み合わせている．高い耐故障性と低遅延を兼ね備えた方法であるが，ツリーで受け取るノードの選別が大事になる．

(26)

3.2. メディア同期

従来より様々なメディア同期の研究が行われている．文献 [24] では複数のサーバにある映像などの素材を，ネットワーク上の処理ノードが同期させて組み合わせる方法について述べている．受信側から送られた同期信号に同期して送信側はストリームデータを転送する．これを一つのタイムコードで組み合わせて複数のストリームを同期させてメディア間同期を実現させる．しかし，この研究ではサーバ側でフレーム送信時間間隔を調整する手法を用いてるため，ALM のように各クライアント同士でデータをコピーしていくシステムの場合この手法を適用することはできない．メディア同期について述べた文献 [5] によると，要求されるメディア同期の制度は，対象とするメディアに大きく依存しており，例えば口元の動きの映像と音声を同期させるリップシンクの場合，音声に対して口元の動きが± 80ms のメディア間同期の誤差までなら同期は良好としている．一方で音声とポインタに対してのメディア間同期は [-500ms, +750ms] の間にあればよいとしている．このように対象とするメディアの内容によって要求される同期精度は変わる．

3.3. メディア同期を考慮した

ALM

ここではメディア同期について考慮した ALM の研究について述べる．従来は一つのサーバに複数のカメラの映像を組み合わせてそのサーバからユーザに向けて映像が提供されてきた．しかしこの方法だと映像間のズレはサーバで調整するだけでよいので楽であるが，カメラの数が増えてくるとカメラの組み合わせの数だけ合成する必要があり，全部の組み合わせを用意するにはそれだけコストがかかる．一方，複数のカメラの映像を各ユーザ側で調整して再生する方法が考えられる．しかしこの場合は，映像配信に ALM を使うことを想定した時のメディア同期に問題が生じる．ALM では通信経路によってはデータの到着時間（遅延時間）が異なる．そして ALM により複数の映像を同期させて再生させようとする場合，参加位置が必ずしも最適な場所になるとは限らない．ノードの参加位置によっては

(27)

各映像データの到着時間にズレが発生してしまい，映像間の再生にズレが生じてしまう．そこで文献 [30] では遅延時間を基に同時視聴のために適した ALM ツリーの構築手法を提案している．すべての参加ノードの情報をノード管理サーバに集め，遅延情報などから接続先の位置を決める．こうすることにより，視聴者が複数の映像を組み合わせて，時間的にズレずに映像を視聴することができる．しかし，一方でツリー構築のためにノード管理サーバに大きく依存している点，全参加ノードが NTP で時刻を調整する必要がある点により規模の拡張性に問題がある．

3.4. 第

4

章遅延時間を考慮した自律型複

数

ALM

_{ツリー構築手法}

本研究が提案するシステムの概要を述べる．まず本提案システムではプロ野球中継のような一つのコンテンツを複数の角度から撮影する．次にそれぞれのクライアントはたくさんの角度の映像から視聴したい地点の映像を選択し再生を開始する．すると各クライアントでは複数地点からそれぞれの映像が送られ，それぞれの映像は同期して再生される．こうして視聴者は同時に複数角度からの映像を楽しむことができる．図 4.1 はある角度からの映像を流すストリーム A に接続したノード A が，別の角度からの映像を流すストリーム B に接続する際に同じ遅延時間になるノードに参加することを示している．図 4.1 提案（同遅延のノードに接続）

(29)

4.1. 想定環境

本研究が想定している環境を述べる．本研究では個人配信や，小規模な団体，スポーツの地方大会，プロ野球独立リーグなど，低予算で全国の視聴者に見てもらいたいような一つのイベントを，複数の角度から見たり切り替えて見たりすることができるシステムを想定している．イベント配信の規模は特定の人向けの少数のものから全国民が注目するようなものまで様々存在する．一般的に多数の視聴者数が想定されるシステムには高性能なサーバスペックや広帯域なネットワーク回線など多数のコストがかかることになる．例えば，プロ野球中継を行っている BB ブロードキャストのマーケット戦略 [6] では ALM のターゲットを表 4.1 のようにしてる．表 4.1 視聴者数と最適な配信技術視聴者数最適な配信技術 1人∼1 万人（クライアントサーバ型の）通信が有利数万∼数 100 万人 ALM(BBブロードキャスト) のターゲット 10万人∼1000 万人以上放送が有利 ※全国ネット１％の視聴者数で 50 万人とした場合，1000 万人で 20 ％この表ではインターネットを使った中継を行う場合は数百万人以下の規模を想定するのが望ましいとしている．また BB ブロードキャストが行ったのプロ野球日本シリーズの中継では 8 万人の同時視聴者数を記録した．本研究では地方独立リーグのような低予算の試合を想定し，小規模な中継として 1 万人以下の規模を想定することにする．この環境に複数の角度からの映像ストリームを配信して同時にズレなく視聴する．なお視聴者数は時間によって増減があり，開始時間に視聴者が増え，その後一定の人数で推移し，最後の試合決定の時間に増えるというデータに基づき，視聴者数の増減を想定することにする．

(30)

まとめると想定しているシステムの必要なカメラの台数やネットワーク回線帯域は以下の表 4.2 のとおりである．表 4.2 想定環境対象プロ野球独立リーグ中継規模最大数人∼1万人視聴者数の推移試合開始直後に増え，最後の試合決定の時間に人数のピークがくる配信環境カメラ10台，それぞれにノートパソコンを繋げ有線LANで配信回線 100Mbpsの光ファイバー映像品質 384kbps∼800kbps 再生バッファ 4秒

4.2. 要求事項

本研究の要求事項を述べる．本研究では複数の映像を同時に視聴した際，それぞれの映像間にズレなく視聴できる必要がある．本研究では 10 つ程度のカメラから視聴者が見たいカメラを 4 つまで選択して切り替えながら同時に視聴することを想定している．メディア同期について述べた文献 [5] によると，要求されるメディア同期の制度は，対象とするものに大きく依存しており，例えばリップシンクの場合，音声に対して± 80ms のメディア間同期の誤差までなら同期は良好としている．そこで本研究ではメインとなる音声ストリームがあるとして，それに複数の映像が同期すると想定する．その場合リップシンクと同精度の± 80ms 以内に映像間のズレであれば同期しているとみなす．視聴者は安定したネットワーク回線でつなぎ自宅など光回線の通った安定した環境で視聴するものとする．また想定している映像配信の規模は日本のプロ野球独立リーグとし，最高でも 1 万人とする．現在の既存サービスではプロ野球中継の

(31)

配信をする場合 360kbps∼1Mbps 程度で行われることが多い．本研究でもそれと同等の映像品質の配信を目指す．またプロ野球に比べ独立リーグでは大きなスポンサーがつきにくいため，できるだけ低コストで配信する必要がある．そこで現在日本の市場に販売されているノートパソコン程度のマシン性能で，ネットワーク環境も一般消費者が使用している光回線の 100Mbps 程度で配信することを目指す．一方で近年ツイッターなど個人が情報発信をする機会が増えてきている．その場合，リアルタイムで視聴している人と比べ遅れて発信してしまうのは防ぎたい．そのため，低遅延で伝送できるツリー型で構築することとする．まとめると，要求事項は以下の通りである． • 視聴者が多くても動作する • 複数のアングルからの映像を同時に視聴できる • 映像同士が時間的にズレなく視聴できる • 高スペックではない配信環境で配信できる

4.3. 設計

本節では高スペックではない配信環境で配信するために，大規模な配信のときにボトルネックとなるノード管理サーバを用いないマルチ ALM 同期視聴システムを構築する方法を述べる．まず一つの会場に複数のカメラを設置する．複数のカメラはそれぞれコンピュータにつながれ，そこでエンコードされインターネットに配信される．ユーザーは複数のカメラの中からいくつか選んで同時に視聴する．これにより様々なアングルから視聴できるようになる．この目的を実現するために次のシステムを提案する．提案システムでは，まず送信サーバ側で同期情報を追加したパケットを作る．次にサーバ側のバッファから順次クライアントにパケットを送る．クライアント側はまず送られてきたパケットをバッファに入れる．そしてバッファにあるパケットを見て同期情報から再生するタイミングをそ

(32)

ろえて再生する．次に配信ツリーの参加処理方法について説明する．新規参加する際のノード N の動作を図 4.2 に示す．まず，あらかじめ各配信サーバはＮＴＰ図 4.2 提案（リダイレクトとブロードキャストの組み合わせ）で時刻を合わせておき，その後も定期的に時刻を同期させる．ノード N が一つ目のストリームに参加するときは自分の遅延時間を 0 に設定して参加処理を行う．二つ目以降のストリームに参加するときは，一つめのストリームの遅延時間を自分の遅延時間として設定して，参加処理を行う．ノード N がストリームに参加するときは，まず各中継ノードの子孫ノード数が閾値 T 以下になるまでリダイレクトをする．子孫ノードの数が閾値 T 以下になったらブロードキャストして問い合わせる．そして一番最初に返信があったノードに接続する．こうすることにより，応答パケットを送信するノード数を任意の値に制限できるようになり，DoS 攻撃のような状態になることを防ぐ．このようにして安定した視聴を実現することが可能となる．本章では，複数の映像を ALM 上で同時に再生する環境において，複数の映像

(33)

がズレなく再生するための位置を，参加中のノードが自律的に計算して決めるシステムを提案する．そのためにまずシステムの処理フローを示し，次の３つの手法を用いて，ALM における複数映像のズレない同期再生を実現する． (１) 映像間の同期方法・・・各映像の再生ズレをなくす (２) 遅延測定方法・・・映像配信ノードから自分のノードまでの遅延時間を計算する (３) ツリー構築法・・・複数映像の同期再生に適したツリーの構築を行う

4.3.1 システムの通信データ

本システムで通信の際に用いられるデータの要素について表 4.3 に示す．表 4.3 システムの構成要素 StreamID カメラの ID IPアドレスノードの送信側 IP アドレス (IP ｖ４) ポートノードの送信側ポート PictID 映像が再生されている場所子接続数その映像を転送している子の数遅延ルートノードから何フレーム分遅れているか説明カメラの説明

4.3.2 システムの処理フロー

サーバ同士で時刻を同期させておき，パケットにタイムスタンプを付けて送信する．そこから各ノードがそのタイムスタンプを見て再生するまでの一連の流れ

(34)

を述べる．なお，各ルートノード同士は定期的に NTP を使い時刻を同期させる．図 4.3 に提案システムの処理フローについて示す．図 4.3 提案システム処理フロー

4.3.3 映像同期方法

あらかじめ配信ソース側の各サーバはそれぞれ NTP で時刻を同期させておく．次に配信ソース側のサーバはインデックスサーバに自分の IP アドレスを登録する．ここでまず配信ソース側のサーバの処理を述べる．サーバにはひとつのカメラがつながっている．カメラのキャプチャの直前にタイムスタンプ情報を記録する．そしてキャプチャしたあとデータを圧縮しそこにタイムスタンプ情報を付与する．こうしてエンコード前のタイムスタンプ情報を追加したパケットを作る．このパケットを自身の送信バッファに入れ，順次接続済みのクライアントにパケットを送る．

(35)

一方視聴クライアント側の処理は次の通りである．クライアントはインデックスサーバに視聴したいストリームのソース IP アドレスを問い合わせ，その IP アドレスに対して接続要求処理を行う．そしてこの後述べる配信ツリーの参加方法によって自身の参加位置が決まり，ツリーに参加する．クライアントはツリーに参加したら親ノードから映像データとタイムスタンプが組み合わされたパケットが送られてくる．この送られてきたパケットをまずは転送バッファと再生バッファに入れる．この時自身に子ノードがいればすぐに子ノードに転送バッファからパケットを転送する．そしてクライアントは再生バッファにある複数のストリームのパケットタイムスタンプ情報を基に再生するタイミングをそろえて再生する．再生タイミングの同期方法図 4.4 に，再生タイミングを同期させる仕組みについて示す．図 4.4 タイムスタンプとメディア間同期まず，時間を同期させるために NTP サーバを用意する．次に各サーバは NTP

(36)

サーバで時間を合わせる．サーバはカメラからの映像データをエンコードし，アプリケーションの送信バッファに入れる際に，パケットにサーバの時刻情報を付与する．クライアントも同じ NTP サーバで時間を合わせる．クライアントは送られてきた複数の映像ストリームのパケットからそれぞれ時刻情報を取り出し，先に視聴しているストリームに合わせて再生することにより，再生のタイミングを同期させる．図 4.5 にメディア間同期の際のバッファ内の動作を示す．図 4.5 提案（メディア間同期）再生プレイヤーでは配信サーバが付けたタイムスタンプ情報が付けられている．視聴クライアントでは複数のサーバから映像データをまずクライアントバッファに溜める．このクライアントバッファ内でそれぞれの映像に付加されたタイムスタンプ情報を見て，映像間のタイムスタンプの差を計算して，その差分だけ遅らせて再生させたり，早く再生させたりして調整する．このようにしてズレなく同時に再生される．

(37)

4.3.4 遅延測定方法

ノード間の遅延測定方法として，転送遅延と内部処理遅延を組み合わせた方法について述べる．文献 [5] ではノード間のネットワーク遅延 (RTT) に，子ノード数に応じた内部処理遅延を加えた値を，新規ノード推定遅延時間とする．推定遅延時間を足していくことによって参加時のルートからの遅延時間を推定している．しかし，この論文では小さなデータを想定しているので転送バッファを考慮に入れていない．そこで本システムでは内部処理遅延を子ノード数ではなく，実際にタイムを測った値にする．図 4.6 に遅延時間の求め方について示す．図 4.6 遅延時間の求め方まず新規視聴ノードは視聴したいストリームツリーの最小遅延ノード (後述のブロードキャスト問い合わせによって求める) へ視聴接続要求を送る．この接続の際，接続先のノードへ映像データを転送してノード間の通信遅延時間を計る．このノード間の通信遅延時間と接続先のノード内の転送処理遅延時間を足すことによって 1 ホップの転送時間を計算する．そして，映像配信ノードから各中継ノード間の間の 1 ホップの転送遅延時間を加えていくことによって自身の映像配信ノードからの遅延時間とする．ソースから視聴までの遅延時間を次のように定義する

(38)

Source to End Delay ＝ルートノードから自ノードまでの各ホップ転送時間の合計

１ホップ転送時間＝ノード内の転送処理時間＋ノード間の通信遅延時間

この計算処理を図 4.7 に示す接続のタイミングで行う．

(39)

4.3.5 ツリー構築法

ツリー構築を各場面に分けて説明する．配信ツリー形成アルゴリズム時刻情報を基にした P2P ネットワークの形成アルゴリズムを述べる．まず最初に見たいチャンネルに接続する．次に現在の時ホストの遅延情報を計算し，二つ目に視聴したいチャンネルの最も遅延時間が近いノードにつながるように接続する．こうすることによって，参加ノード全体の再生同期待ち時間を減らすことができる．次に参加方法について例を示して説明する．参加方法新規参加ノード N がまずストリーム A の配信ツリーに参加して映像を受信し，その後ストリーム B に参加する場合の例を示して説明する．なお，返信の上限数 (閾値 T) は任意に設定ができ，ここでは仮に 100 とする．まず新規参加ノード N はルートノード R に参加希望要求を送る．自分の視聴遅延時間 (新規の場合は ” 0”) と自分の IP アドレスを，R の子孫数が閾値 T（100）以上ある場合，R は子の中で最も子孫の少ない子ノードにリダイレクトする．図 4.8 にリダイレクトの方法について示す．

(40)

図 4.8 提案（リダイレクト）このようにしてリダイレクトされたノードは R と同じ処理をノードの子孫数が閾値 T（100）以下になるまで繰り返す．閾値 T 以下になった時リダイレクト処理は終了し，今度はそのノードから子孫ノードに対してブロードキャストする．次にブロードキャスト処理について説明する．図 4.9 にブロードキャストの方法について示す．新規参加ノード N は閾値 T 以下になった子孫ノードに対してブロードキャストパケットを送る．そして最大 100 ノードが，ブロードキャストに対し遅延時間差に応じた時間を待って返信パケットを N に送る．この返信パケットを送る中継候補ノードが返信する際は，参加希望ノードの遅延時間から自分の遅延時間の差を基にした時間分待機して返信する．N は一番早く返信があったノードに接続する．この時の残りの返信は予備ノードとする． A:( 120ms - 110ms )× 2 = 20ms 20ms 待機して返信 B:( 120ms - 150ms )× 2 =-60ms 60ms 待機して返信

(41)

C:( 120ms - 110ms ) × 2 = 20ms 20ms 待機して返信 D:( 120ms - 160ms )× 2 =-80ms 80ms 待機して返信図 4.9 提案（ブロードキャスト）なお，待機時間の限界はあらかじめ決めておき，一定時間返信がない場合は再接続処理を行う．また各ノードは 2 秒に 1 回，子に子孫の数を問い合わせる．これにより各ノードは子孫ノードの数を知ることができるようになる．離脱と復旧方法図 4.10 に離脱と復旧方法について示す．各ノード間には TCP によってセッションが張られている．そのため離脱の際はセッションが切断され相手側に切断が通知される．切断されたノード A(子) は再接続処理をする (参加手続きと同じ)．

(42)

図 4.10 提案（離脱と復旧）

4.4. 実装

本提案手法の機能を実装したインデックスサーバと配信サーバ，視聴クライアントの仕様をまとめる．

4.4.1 インデックスサーバ

まず配信サーバを設置した際に自身の情報をインデックスサーバに登録する．インデックスサーバの機能を実装したものを図 4.11 に示す．インデックスサーバではサーバの情報を以下のようなデータフォーマットで登録する．

(43)

図 4.11 インデックスサーバソースコード 4.1 配信サーバの管理クラス 1 public r e f c l a s s node 2 { 3 public : 4 S t r i n g ˆ s t r e a m I d ; //映像ストリームのID 5 S t r i n g ˆ i p A d r e s s ; //配信サーバの I P アドレス 6 S t r i n g ˆ p o r t ; //配信サーバのポート番号 7 S t r i n g ˆ p i c t I d ; //ピクチャID 8 S t r i n g ˆ childNum ; //総視聴者数 9 S t r i n g ˆ d e l a y ; //配信サーバ自身の遅延時間（通常は０） 10 S t r i n g ˆ d e s c r i p t i o n ; //配信サーバの説明 11 （省略） 12 } ; このインデックスサーバに対して 4 つの処理を行うことにより，インデックスサーバとしての役割を果たす．４つの処理は配信サーバ登録，情報取得，配信サーバ削除，情報の更新で，以下のようにして実装されている．ソースコード 4.2 インデックスサーバのパケット処理 1 i f ( TextArr1 [0]−> Equals ( ” r e g i s t ” ) ) { //配信サーバ登録 2 （省略）

(44)

3 } else i f ( TextArr1 [0]−> Equals ( ” get ” ) ) { //情報取得 4 （省略）

5 } else i f ( TextArr1 [0]−> Equals ( ” d e l e t e ” ) ) { //配信サーバ削除 6 （省略）

7 } else i f ( TextArr1 [0]−> Equals ( ” update ” ) ) { //情報の更新 8 （省略）

9 }

この４つの処理で配信サーバの各情報を登録・取得・削除・更新することができる．

(45)

4.4.2 配信サーバ

次に配信サーバの仕様について説明する．配信サーバは自身の情報をインデックスサーバに登録し，自身に接続している子ノードに対してタイムスタンプのついたカメラからの映像データを転送する．配信サーバの機能を実装したものを図 4.12に示す．図 4.12 配信サーバまず配信サーバは自身のポート番号と映像の説明を入力し，インデックスサーバに自身の情報を登録する．登録が完了したらカメラのキャプチャとタイムスタンプのデータを組み合わせたパケットを作成し，子ノードの接続待ち状態になる．以降の配信サーバの説明は各視聴クライアントにおいてもサーバ機能として実装されている．この機能によりデータの転送を行い ALM を実現する．配信サーバはパケットを待ち受け，パケットの内容により以下の処理をする．ソースコード 4.3 ブロードキャストとリダイレクトの判定 1 i f ( TextArr1 [0]−> Equals ( ” c h i l d r e n ” ) ) { //子孫ノードの数を計算して返信する 2 （省略）

3 } else i f ( TextArr1 [0]−> Equals ( ” connect ” ) ) { 4 //ブロードキャストするかリダイレクトするか判断する

(46)

5 （省略） 6 i f ( I n t 3 2 : : P a r s e ( TextArr1 [ 4 ] ) > = cnum ){ 7 //自身の子孫の数がブロードキャストする子の数以下の場合 8 （省略） 9 } else {//リダイレクト 10 （省略） 11 }

12 } else i f ( TextArr1 [0]−> Equals ( ” broad ” ) ) { 13 //ブロードキャストパケットの転送と返信 14 （省略） 15 } childrenパケットの場合，自身の子孫ノード数を計算して返信する．connect パケットの場合，自身の子孫ノード数が相手のブロードキャスト閾値以下ならブロードキャストの処理を行う．ブロードキャスト閾値以上ならリダイレクト処理を行う．broad パケットの場合，自身の子ノードにブロードキャストパケットを転送して，自身とパケットの遅延時間の差分の 2 倍の時間待ってパケットに書かれたノードに返信する．配信サーバでは直下に接続している子ノードごとに以下のクラスを作成して，データを転送する．ソースコード 4.4 子ノード管理クラス 1 public r e f c l a s s S t a t e O b j e c t 2 { 3 S o c k e t ˆ w o r k S o c k e t ; //子ノードのソケット 4 S t r i n g ˆ i p p o r t ; // 子ノードの I P アドレス 5 i n t c l i e n t p o r t ; // 子ノードのポート番号 6 7 i n t s t r e a m i d , t i m e i d x ; // ストリームID 8 i n t c h i l d r e n n u m ; // 子ノードの下に接続している子孫ノードの数 9 i n t mydelay ; // 子ノードの遅延時間 10 11 a r r a y<Byte> ˆ s e n d ; // 送信バッファの一つのパケット 12 a r r a y<i n t> ˆ t r a n s t i m e ; // 遅延測定に使用 13 14 Queue ˆ s e n d b u f f e r q u e u e ; //送信バッファ 15 16 S t a t e O b j e c t ( void ){ //初期設定 17 (省略 ) 18 } 19 20 void s e n d r o u n d ( void ){ 21 //子ノードに対して送信バッファのデータを転送する 22 (省略 )

(47)

23 } 24 25 } 子ノードごとに転送バッファを作り send round 関数によってバッファにデータがたまり次第，データを子に転送する．

4.4.3 視聴クライアント

次に視聴クライアントの説明をする．視聴クライアントを実装したものを図 4.13に示す．図 4.13 視聴クライアント視聴クライアントの転送バッファと再生バッファは図 4.14 のようになる．この再生バッファでどのようにして映像間の同期を実現するかを説明する．視聴クライアントは各映像ごとにどれだけ遅延が発生しているかの情報を接続時に計算して保持しておく．そしてその遅延時間の差分だけ映像のフレームを基準ストリームから早くしたり，遅くしたりして再生させることにより，映像間のズレを解消する．

(48)

ソースコード 4.5 映像間の同期再生方法 1 //一定間隔で４つの画面ごとに描画する

2 f o r ( i n t i =0; i <4; i ++){

3 // 50フレーム以上ズレている場合は破棄

4 while ( b u f f e r q u e u e [ i ]−>Count >50){ b u f f e r q u e u e [ i ]−>Dequeue ( ) ; }

5 //遅延時間分だけ遅らせるか早めるかの処理

6 while ( b u f f e r q u e u e [ i ]−>Count >10 + delay frame [ i ] ) {

7 //再生バッファからフレームを取り出す

8 FrameSet ˆ f s e t = s a f e c a s t<FrameSet ˆ>( b u f f e r q u e u e [ i ]−>Dequeue ( ) ) ;

9 //フレームの再生

10 B e g i n I n v o k e ( gcnew p i c t D e l e g a t e ( t h i s , &Form1 : : p i c t ) , f s e t , i ) ;

11 } 12 }

(49)

第

5

章実験と評価

本提案システムの有効性を示すために行った実験について説明する．まず本研究の前提となるパラメータを調べるために予備実験によって，実際のインターネット環境におけるホップ数と遅延時間の関係を調べた．そして次に予備実験の結果を元に検証実験を行い，提案システムの動作について確認し，実験結果についてまとめを行った．

5.1. 予備実験

5.1.1 予備実験の概要

予備実験では鏡 [31] という映像ストリーミング転送ソフトに遅延測定機能を追加して二つの実験を行った．この予備実験では時間を正確に測るために，同一 PC 内で時刻を計算するようにした．二つの予備実験で ALM における遅延時間の影響を調べ，本提案システムにおけるインターネット環境での影響について述べる． 予備実験 1 予備実験の 1 つ目として，パケット転送における内部転送処理遅延時間の測定を行った．実験の環境を図 5.1 に示す．予備実験 1 ではまずエンコーダから圧縮されたデータが鏡サーバに送られる．この鏡サーバに送られた時に，映像データの最初にタイムスタンプを付ける．タイムスタンプデータはシステム起動時からの時間（ミリ秒単位）を 10 バイト (+ 区切り 10 バイト) とした．このデータが内部の転送バッファに送られて，Send 関数を用いて送信される直前までの時間を処理遅延時間として測定した．

(50)

図 5.1 予備実験 1 環境 予備実験 2 図 5.2 に実際のネットワークを通じた転送遅延実験の方法を示す． WIDEネットワーク PC∼自宅 PC（eo 光ホームファイバー 100M コース）間の転送遅延を計測した．この間の ping による RTT は 9ms であった．これをホップなし，2 ホップ，4 ホップ，6 ホップ，8 ホップ，10 ホップの遅延時間を測定した．

5.1.2 予備実験結果と評価

予備実験 1 の結果 予備実験 1 の結果のうちパケット転送時間の分布については図 5.3 に示し，パケット転送遅延時間の範囲について図 5.4 に示す．

(51)

図 5.2 予備実験 2 環境図 5.3 はパケット転送における遅延時間の分布を示したものである．これを見ると，30 秒付近の，70 秒付近，120 秒付近にデータが分布していることがわかる．鏡では内部の転送バッファを定期的に調べ，転送バッファ内にデータがあればデータを転送するという処理をしている．これによりネットワークのゆらぎや転送処理に時間がかかり，処理タイミングが一つずつ遅れた結果によるものと考えられる．平均遅延時間は 80.18ms であった． 予備実験 2 の結果 予備実験 2 の結果のうちホップ毎の遅延時間について図 5.5 で示し，ホップ毎の平均遅延時間について図 5.6 に示す．この 2 つのグラフから，実際のインターネットの環境で ALM ストリーミングを流した場合，ホップ数が増えるごとごとに遅延時間は，10 ホップまで大体線形的に増えることがわかった．これは国内においてはネットワーク転送遅延による影響よりも PC 内の転送遅延による影響を受けるためだと考えられる．ここで仮

(52)

図 5.3 パケット転送時間の分布に 2 分木の ALM ツリーを想定した場合，2 ホップで 7 ノード，10 ホップで 1023 ノード参加していることになる．

5.1.3 予備実験のまとめ

予備実験ではノード間の RTT が 9ms と非常に高速な環境であったが，他のネットワークにおける RTT を計測した結果を表 5.1 に示す．この結果から国内では数 10ms 以内，日本∼米国では 100ms 以内，日本∼ペルーでは 300ms 以内で通信遅延が発生することがわかる．そして国内通信での ALM においては，ネットワークの転送遅延よりもクライアントにおける転送処理遅延の影響の方が大きいことがわかる．そのため映像データの転送遅延時間は転送処理を行うホップ数が増えるにつれ線形的に増えていったものだと考えられる．今回の予備実験 1，予備実験 2，により映像データの転送の際 1 ホップで 100ms

(53)

図 5.4 パケット転送遅延時間の範囲表 5.1 場所ごとの遅延時間の目安測定範囲 RTT yahoo.com− NAIST 128ms google.com− NAIST 60ms yahoo.co.jp− NAIST 10ms yahoo.com− eonet 47ms google.com− eonet 60ms yahoo.co.jp− eonet 13ms www.inei.gob.pe− NAIST 277ms WIDE− eonet 9ms

( ) ( ) ( ) ( ) ( )

修士論文

複数映像同時視聴のための自律型

ALM

構築手法の

提案

中川 隆広

複数映像同時視聴のための自律型

ALM

構築手法の

提案

中川 隆広

Proposal of How to Build Autonomy Type ALM

for

Simultaneous Viewing Multi Videos

Takahiro Nakagawa

目 次

図 目 次

表 目 次

第

1

章 はじめに

第

2

章 大規模な映像配信における同

時視聴を実現するための技術

2.1.

大規模映像配信技術

クライアントサーバ方式

Contents Delivery Network(CDN)

IP

マルチキャスト

Application Layer Multicast(ALM)

2.2.

メディア同期技術

メディア内同期

メディア間同期

端末間同期

2.3.

各技術の比較

第

3

章 関連研究

3.1. ALM

3.1.1

配信ツリー型（プッシュ型）

3.1.2

データ駆動型（プル型）

3.1.3

ハイブリッド型

3.2.

メディア同期

3.3.

メディア同期を考慮した

ALM

3.4.

関連研究のまとめ

第

4

章 遅延時間を考慮した自律型複

数

ALM

ツリー構築手法

4.1.

想定環境

4.2.

要求事項

4.3.

設計

4.3.1

システムの通信データ

4.3.2

システムの処理フロー

4.3.3

映像同期方法

4.3.4

遅延測定方法

4.3.5

ツリー構築法

4.4.

中川隆広

中川隆広

目次

図目次

表目次

章はじめに

章大規模な映像配信における同

章関連研究

章遅延時間を考慮した自律型複

_{ツリー構築手法}

章実験と評価