平成 12 年度
学士学位論文マルチビデオスト リーム配送における同時性保証に関する研究

A Guarantee Method for Synchronization distributedof Multi Video Streams through networks

1010394

坂田青児

指導教員

島村和典

2001 年 2 月 5 日
高知工科大学 情報システム工学科

要 旨

マルチビデオストリーム配送における同時性保証に関する研究坂田青児

近年ネットワークの高速・広帯域化に伴い, 音声・動画像を配信するサービ スが行われるようになってきた. そこで本稿では次世代高速ネットワークにおいて同時性を持つ複数のス
トリームを利用したアプ リケーションを想定し , そのストリーム群の配送網の同時性の保障
方式について検討を行った . ネットワークによるパケットのロス, 遅延, 遅延の揺らぎによってストリームパケットの同時性は崩されると予想される. それゆえストリームの特性を調べるために 2 ストリームの配信実験を行った . その結果ストリームパケットの到着間隔とストリーム同士の相対遅延時間によって数フレームに相当するずれが生じた. 同時性の保障を行うためには , この数フレーム相当のずれを吸収しなければならないことが分かった .
キーワード

パケットロス, 遅延, 遅延のゆらぎ , ストリーミング , マルチビデオストリーム{i{Abstract
A Guarantee Method for Synchronization distributed ofMulti Video Streams through networks
Sakata Seiji

According to the network of recent years getting higher, network application services
that utilise transfers audio and video data is coming up to date.This paper examines
the guarantee of synchronization for the new application that transfers a synchronizedmulti stream on the next generation broadband network.
It seems that those streams can't keep synchronization a ected by packet-loss,delay,anddelay-jitter.The experiment transfering two streams was done with a purpose of checking
network delivery quality of multi video streams.As the result ,the arrival interval of eachstream packet and the relative deley time between the streams were equivalent to thetime for a few TV signal frames.To guarantee the delivivery quality should be necessary
for some synchronization techniques.
key words

packet-loss,delay,jitter,streaming,multi video stream{ ii {

目次
第

1章

研究の目的

1

第

2章

研究の背景

2

2.1

高速ネットワークの QoS

2.2

映像の多重化転送

3章

配送ネット ワークから見たマルチビデオスト リームの問題点

3.1

要求条件

...................................

4

3.2

配送系における技術的課題 . . . . . . . . . . . . . . . . . . . . . . . . . .

5

4章

転送予備実験

6

4.1

実験目的

...................................

6

4.2

実験内容

...................................

6

4.3

検証項目

...................................

7

4.4

実験結果

...................................

8

4.4.1

各ストリーム毎の結果 . . . . . . . . . . . . . . . . . . . . . . . . .

8

4.4.2

ストリーム同士の結果 . . . . . . . . . . . . . . . . . . . . . . . . .

9

4.5

実験の考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

105章

同時性保障方式の検討

15

5.1

パケットの同時性..............................

15

5.2

時間的な対応 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

5.3

追加検討課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

6章

考察

18

6.1

まとめ

第

第

第

第

...........................

2..............................

3....................................
{ iii {

4

18

目次

6.2

今後の課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

謝辞

19

参考文献

20

付録

A

A.1

スト リーミング

21

ストリーミング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

A.1.1 ダウンロード 型とストリーム型 . . . . . . . . . . . . . . . . . . . .

21

A.1.2 ストリーミングに関するプロトコル . . . . . . . . . . . . . . . . .

22

TCP と UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
RTP と RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
付録

B

22

24

マルチビデオスト リーム

B.1

マルチビデオストリームとは........................

24

B.2

マルチビデオストリーム利用例.......................

26

付録

C

29

情報圧縮技術C.1

情報圧縮の必要性..............................

29

C.2

動画像の圧縮の考え方............................

29{ iv {

図目次
4.1

実験系

.....................................

6

4.2

無負荷の時の到着間隔 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

4.3

サブネットへ 30Mbps の負荷をかけた時の到着間隔 . . . . . . . . . . . . . .

9

4.4

サブネットへ 60Mbps の負荷をかけた時の到着間隔 . . . . . . . . . . . . . .

10

4.5

バックボーンへ 30Mbps の負荷をかけた時の到着間隔. . . . . . . . . . . . 11

4.6

バックボーンへ 60Mbps の負荷をかけた時の到着間隔. . . . . . . . . . . . 12

B.1 蓄積型ストリーム配信の概念図 . . . . . . . . . . . . . . . . . . . . . . . .

25

B.2 サーバとクライアントの概念図 . . . . . . . . . . . . . . . . . . . . . . . .

25

B.3 テレビとチャンネル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

B.4 ストリームと内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

B.5 ボクシングにおけるマルチビデオファイル撮影 . . . . . . . . . . . . . . . .

28

C.1 双方向予測符号化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

{v{

表目次
4.1

実験条件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74.2

平均到着間隔.................................

10

4.3

最大到着間隔.................................

11

4.4

最小到着間隔.................................

12

4.5

各ストリームの損失率 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

4.6

完全到着率 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

4.7

相対遅延時間の平均値, 最大値, 最小値 . . . . . . . . . . . . . . . . . . . . .

13{ vi {

第1章

研究の目的

近年, ネットワークの高速・広帯域化には目を見張るものがある. 高速・広帯域化に伴い通信・放送の融合が起こり, ネットワーク上で音声・動画像を扱ったアプ リケーションが増加している. そこで次世代高速ネットワークにおいて同時性を持つ複数のビデオストリームを使用したアプ リケーションの実現を目指し , そのストリーム1 同士の同時性を保障することが本研究の目的である.

1 ストリーミングについては付録

A 参照

{1{

第2章

研究の背景
2.1

高速ネット ワークの

QoS

高速ネットワークにおいては通信サービ スと放送サービ スの融合により音声・動画といったリアルタイム性を要求する通信が増える. これまでメールや HTML といったテキストベー
スのデータはリアルタイム性を要求せず時間に対してそれほど の厳しい制約を必要としなかった. そのためパケットの到着が遅れるよりも確実に届けることを優先的に行う手法が採られてきた. 各々のパケットが同一経路をたど りあて先に届けられるかは一意には決まらな
い, つまりネットワーク帯域をあらかじめ確保して通信を行うわけではないので通信品質が流動的に変化する. このことは音声や動画といった実時間通信を必要とするデータにとっては非常に深刻な問題となる. 通信品質を定量的に表すものとして , ネットワーク帯域やパケッ
トロス, 遅延, 遅延の揺らぎなどがある.
従来型のデータ通信ではある程度許容されてきた遅延や遅延の揺らぎに対して , 実時間通信では遅延が低く, 遅延の揺らぎが少ないことが要求される. またデータ通信においてはパケッ
トロスは許されず , 再送を行うなどして必ず届けられなければならなかった. しかし実時間通信パケットロスにより再生品質はおちるがリアルタイムで処理するためロス率が低ければ深刻な問題にならない.
このようにデータ通信と実時間通信では求められる通信品質に違いがある. そのため高速
ネットワークにおいてはデータ通信と実時間通信に対して , それぞれに合った通信品質を割り当てなくてはならない . 特に実時間通信においては時間的制約を解決することが最大の問
題となる.

{2{

2.2 映像の多重化転送

2.2

映像の多重化転送

通常映像が多重化される際には内部, もしくは外部から同期情報が付加され , それに従い同期の取れた再生が実現されている. 映像を多重化して転送しているものにはアナログテレビ
編集, デジタルテレビ放送, デジタルビデオエフェクト等が挙げられる.
アナログテレビの編集においては対象となる機材とは別に外部から同期信号を送り, その同期信号に合わせて各装置を同期させ編集が行われる.
デジタルテレビ 放送では ,MPEG2 トランスポート ストリームにより多重化されている. 各
チャンネルはパケットヘッダによって識別されタイムスタンプに従い再生が行われる．
デジタルビデオエフェクトではデジタル化された映像に CG や, テロップといった情報はフレーム単位でタイムコード と呼ばれる同期参照情報によって関連付けられ同期が行われる.
このように多重化を行った映像の取り扱いには同期を保つ仕組みが必要なる.

{3{

第3章

配送ネット ワークから見たマルチビ
デオスト リームの問題点
3.1

要求条件

マルチビデオストリーム1 配信のシステムは大きく 3 つの要素に分けられる. マルチビデ
オファイルをコンテンツを蓄積・管理する蓄積系, マルチビデオストリームを受信し同期再生を行う表示系, さらにそれらを結ぶネットワークを主体とする配送系の 3 つである.
マルチビデオストリーム配信における配送系に対する要求は

1. 送信ストリームパケットを同期再生可能な範囲内に届ける
2. ユーザからのストリーム制御の監視機能を持つ
3. サーバは同期管理されたビデオファイル群の同時配送機能を持つ
4. クライアントはストリーム毎の遅延揺らぎを吸収するバッファを持つことである.

1 付録

B 参照

{4{

3.2 配送系における技術的課題

3.2

配送系における技術的課題

はじめにストリーム単体における問題を考える. ストリームの再生を行うためには , サー
バから送信されるタイミングをクライアント端末側で正しく復元されなければならない . しかし ストリームパケットはネットワークを経由して送られてくるため, 送信時のタイミング
を完全に保ったまま送られない場合がある. ネットワークによるパケットのロス, 遅延, 遅延
揺らぎが起こるからである.
ストリーミングにおいては普通パケットの再送制御を行わない. パケットのロスが発生してもそのデータは再送されないまま再生される. そのためある程度のロスならば再生にそれほど の影響を与えないが , バースト 的なパケットのロスが発生すると一時的に再生不可能になってしまうのである. またネットワークを経由するために遅延を避けることはできないが ,遅延時間が一定であれば 送信タイミングを復元することは容易である. しかし遅延時間は一定ではなく揺らぎが発生するためタイミングを復元することは難し くなる. そのためストリーミング技術ではバッファリングが行われる. 再生を行う際に数秒分のデータをクライア
ント端末に蓄積した後再生を開始する. その後も常に数秒分を蓄えながらそのデータの再生を行う. 数秒分のデータを蓄積することで遅延の揺らぎを吸収している.

同時性を持つマルチビデオストリームではパケットのロス, 遅延, 遅延揺らぎによる影響がさらに深刻なものとなる. シングルストリームにおいてはバースト的なパケットロスによって再生が一時的に停止しても , その後パケットの到着に合わせて問題無く再生が再開される.
しかしマルチビデオストリームでは一時的な中断で同期関係が崩れてしまう. また遅延の揺らぎによっても同期関係が崩される. そのため同期再生を実現するには , 各ストリームの同時性を保証し同期関係を保つ必要がある.

{5{

第4章

転送予備実験
4.1

実験目的

実験は同時性保証方式を検討するための判断材料として , 転送系におけるビデオストリー
ムパケットの伝送特性を調べることを目的として行った .

4.2

実験内容

実験系の構成を図 4.1 に示す. 実験はサーバからクライアント端末に 2 つのストリームを

図 4.1 実験系

同時に送信した. その際クライアント端末の存在するサブネットへ負荷をかけた場合と転送系バックボーンに負荷をかけた場合とで実験を行った .

{6{

4.3 検証項目
実験条件を表 4.1 に示す.
ストリーム間の相対的な差をみるため 2 ストリームで行った. ストリームの種類は MPEG2表 4.1

実験条件

ストリーム数
ストリーム送信レート
ストリーム送信パケットサイズ
ストリーム転送プロトコル
負荷送信レート
負荷パケットサイズ
負荷転送プロトコル

2
15Mbps1880byte,37600byte
UDP/IP
0Mbps,30Mbps,60Mbps
1500byte
UDP/IPTS である. 送信レートについてはビデオファイルの符号化が現行テレビよりも高品質である 15Mbps であることを想定している. 現行テレビ品質は 4 〜 6Mbps である.
またパケットサイズについては TS パケットサイズの 10 倍である 1880byte とさらにその20 倍とで比較を行った. 負荷レートは Fast Ethernet の使用率がストリームの送信レートと負荷によって 60

4.3

検証項目

検証項目は ,

 各ストリーム毎のパケットの到着間隔
各ストリームにおける到着パケットと前回到着パケットとの到着時間の差である.

 各ストリーム毎のパケット損失率
各ストリームの送信パケットが全て損失したとき , その値は 1 となる.

 ストリーム同士のパケット完全到着率
同時に送信されたパケットの両方が完全に到着した時, 値は 1 となる.

 ストリーム同士の相対遅延時間
同時送信されたパケットが完全に到着した時のそれらのパケットの到着間隔である.

{7{

4.4 実験結果

4.4

実験結果

4.4.1

各スト リーム毎の結果

以下 2 つのストリームを A,B とする.

A,B それぞれのパケット到着間隔を, 無負荷の場合, サブネットにそれぞれ負荷をかけた場
合, バックボーンに負荷をかけた場合に分け A,B を左右に対比させ , 図 4.2,4.3,4.4,4.5,4.6 に示す.
なお上の段が送信パケットサイズ 1880byte であり下の段が 37600byte である.
それぞれ縦軸は到着間隔 (msec) を表し , 横軸は到着パケットと前回到着パケットを一つの単位としている.

図 4.2

無負荷の時の到着間隔{8{4.4 実験結果

図 4.3 サブネットへ 30Mbps の負荷をかけた時の到着間隔

到着間隔の平均値, 最大値, 最小値をそれぞれ , 表 4.3,4.4,4.2 に示す. 精度は 10msec である. 表 4.5 に各ストリームパケットの損失率を示す.

4.4.2

スト リーム同士の結果

表 4.6 にパケットの完全到着率を示す.
各条件における相対遅延の平均値, 最大値, 最小値を表 4.7 に示す. なお精度は 10msec で
ある.

{9{

4.5 実験の考察

図 4.4 サブネットへ 60Mbps の負荷をかけた時の到着間隔

平均到着間隔

表 4.2
無負荷

パケットサイズ

1880byte
パケットサイズ37600byte

4.5

サブネットへの負荷

バックボーンへの負荷

30Mbps 60Mbps 30Mbps
ストリーム A
6.871
6.652
7.401
7.895
ストリーム B
6.872
6.652
7.401
7.894
ストリーム A
24.201 24.249 24.190 24.136
ストリーム B
24.182 24.229 24.158 24.128

60Mbps
6.936
6.937
24.16424.142

実験の考察

まず個々のストリームについて見ると , 図 4.2 〜 4.6 から送信パケットサイズが 1880byteの時その到着間隔は 0 〜 20msec の範囲に集中することが読み取れ ,37600byte になると到着間隔の集中は 20 〜 30msec に見られる. 到着間隔の平均を見てみると送信パケットサイズ
が 1880byte の時は約 7msec で 37600byte では約 25msec となっている. 送信パケットサイ{ 10 {

4.5 実験の考察

図 4.5 バックボーンへ 30Mbps の負荷をかけた時の到着間隔

最大到着間隔表 4.3
無負荷

パケットサイズ

1880byte
パケットサイズ37600byte

A
ストリーム B
ストリーム A
ストリーム B
ストリーム

60
60
70
70

サブネットへの負荷

バックボーンへの負荷

30Mbps 60Mbps 30Mbps
60
60
60
60
60
60
70
110
70
70
70
70

60Mbps60
60
70
80

ズが増えることで平均値は増加している. しかし送信パケットのサイズに関わらず平均では１フレーム分に相当する時間, 即ち 1 秒が 30 フレームで 33msec 以内に届いている.
しかしパケットサイズが 1880byte の時, 最大到着間隔は 60msec である, これは 1 フレーム相当の遅れである. また 37600byte の時には最大で 110msec であり 3 フレーム相当のずれが生じている. マルチビデオストリームとしてはこの時間のずれは同期再生に影響を及ぼす.

{ 11 {

4.5 実験の考察

図 4.6 バックボーンへ 60Mbps の負荷をかけた時の到着間隔

最小到着間隔表 4.4
無負荷

パケットサイズ

1880byte
パケットサイズ37600byte

A
ストリーム B
ストリーム A
ストリーム B
ストリーム

0
0
10
10

サブネットへの負荷

バックボーンへの負荷

30Mbps 60Mbps 30Mbps
0
0
0
0
0
0
10
0
0
0
10
0

60Mbps00010

たった 3 フレーム相当のずれではあるが何度か積み重なることによって , 数フレーム, 数十
フレーム分のずれへと加算されて全く同期のとれていない状態になる.
また 損失率に ついてみると , 例えば 15Mbps で 符号化を 行った 10 分のデ ータが 損失率

3.5e-4 で受信されたとする. 単純に考えると失われた時間は 0.21 秒分にしかならない. つまり約 6 フレーム分であり,10 分間で 6 フレーム分しか損失していない. ストリームの再生と{ 12 {

4.5 実験の考察
表 4.5

パケットサイズ

1880byte
パケットサイズ37600byte

A
ストリーム B
ストリーム A
ストリーム B
ストリーム

各ストリームの損失率
無負荷

サブネットへの負荷

バックボーンへの負荷

3.8e-44.3e-40.0e-41.9e-430Mbps 60Mbps 30Mbps
3.7e-42.8e-43.4e-43.5e-42.2e-43.0e-40.0e-41.0e-43.8e-40.0e-40.0e-41.0e-460Mbps3.4e-44.0e-40.1e-46.7e-4表 4.6 完全到着率
無負荷

サブネット

バックボーン

30Mbps 60Mbps 30Mbps 60Mbps
1880byte 99.96e-2 99.96e-2 99.98e-2 99.98e-2 99.97e-2
37600byte
1
1
99.96e-2 99.99e-2 99.99e-2
いう点では損失率が低く抑えられるならば , 到着間隔の方が同期再生に対して大きな影響を及ぼす.
またストリーム同士についてみると完全到着率は負荷, パケットサイズが増加しても急激に変化しないことが分かった. これは損失率の低さから考えれば当然のことである.

平均相対遅延時間は約 6msec, 最大でも 7.1msec である. これは１フレーム分に相当する
表 4.7

相対遅延時間の平均値, 最大値, 最小値
無負荷

平均値
最大値

1880byte

最小値
平均値
最大値

37600byte

最小値

6.3
70
0
5.3
50
0

サブネットへの負荷

バックボーンへの負荷

30Mbps 60Mbps 30Mbps
5.2
5.2
7.1
60
60
60
0
0
0
5.6
4.8
5.7
60
60
60
0
0
0

{ 13 {

60Mbps
5.0
70
0
6.0
60
0

4.5 実験の考察範囲内に収まっている. しかし 最大相対遅延時間は 50 〜 70msec であり, これは 2 〜 3 フ
レーム分に相当する. またパケットサイズの変化による大きな違いは平均到着間隔にだけ見られた. それ以外の項目については , それほど 際立った違いはなかった . これは今回行った実験が限られた環境の中で行われたことに起因する. パケットが異経路を通るケースや通過するノード 数の増加に伴う処理時間の差異が見られないために大きな違いが生じ ることはな
かった.
同時性の保障という点では個別ストリームの到着間隔によるもので 3 フレーム, パケット同士の相対遅延でも 3 フレームに相当するずれが生じた.
そのためこうした限られた環境でさえ同時性の保障を行うためには , 最低この数フレーム分のずれを解消しなければならないことが判明した.

{ 14 {

第5章

同時性保障方式の検討

5.1 パケット の同時性実験の結果, 同時性を保障するためには数フレーム相当のずれを解消しなければならない.
これは単純に捉えるならば クライアント端末において , その数フレーム分をバッファリングを行い吸収すればよいことになる. クライアント側は数フレームに相当するバッファを持つ,
これにより数フレーム相当のずれは吸収され個別のストリームとしては , ほぼ問題無く再生される. しかし同期の取れた再生を行うには大きな問題がある.
実験によってほぼ同時に送信されたパケットは最大で数フレーム相当のずれの範囲内に届くことが分かった . これはクライアントに用意されるバッファによって吸収され問題なく再生される範囲である, しかし必ずしもほぼ同時に送信されたパケットが再生時に同じ時刻を表しているわけではない. 実験はあくまで同時に送信されたパケットが同じ時刻を表すことを前提として扱った .
通常ネットーワーク上では音声・動画像は情報の圧縮が行われて扱われる1 . 情報はできる限り圧縮される. そのため圧縮されていない同じ時間分のデータが 2 つある時,2 つのデータの圧縮後のサイズが同じになるとは限らない. 例え同じ符号化レートで圧縮しても元データの内容によってサイズは全く異なってしまう.
このため圧縮後の 2 つのデータをストリーム配信する際, ほぼ同時に配信されたパケットの同時性が保障されても同期のとれた再生は行えない. 各々のパケットに含まれるデータが再生時に同時性を持つものを , できるだけ同時に送信し , 受信する必要がある.
1 付録

C 参照

{ 15 {

5.2 時間的な対応

5.2 時間的な対応
ストリームの同時性を保障するためには , パケットに含まれるデータに時間的対応が取れていることが前提となる.
時間的な対応が取れているならば , それに従いサーバ側での配信スケジュールの調節によって時間的対応が取れたパケットを同時に配信することも可能になり, またクライアント側で対応のとれたパケットをバッファリングすることによりそのパケットのデータを同時性が保障されるようにデコーダに渡すなどして同時性の保障が行える. 以下時間的対応付けについて検討する.

パケット 同士の時間的対応を行う上で問題となるのは , エンコード された状態では各パケットがど のような内容を表すのかを判断できないことである. そのためパケットの時間的な対応はエンコード される時に行わなければならない. エンコード 時に時間的な対応付けを行うための基準時刻参照情報を抽出してやり, 同時性を保障するためにその基準時刻がサーバ , クライアントで用いられる. 問題は何を基準となる情報として利用するかである.

MPEG などによる圧縮ではフレーム間予測符号化が行われている. その際基本となるフレー
ムのまとまりを一つのグループとして扱う. これは GOP(Gruop of Picture) と呼ばれ一般
的には 15 フレームで一つの GOP としている. この GOP を単位とする基準時刻情報として扱うことを考えると ,1GOP 毎のデータを参照できる情報をエンコード 時に GOP テーブルとして用意する.
その GOP テーブルによってパケット内にど の位置の GOP を含んでいるかを参照できる.
それによって時間的な対応の取れたパケットを同時に送信でき,GOP テーブルをストリーム
送信開始以前にサーバとクライアントが共有することにより, 同時性を保障するパケットをバッファリングし同期再生を行えると考えられる.

{ 16 {

5.3 追加検討課題

5.3 追加検討課題
今回の実験においては 2 ストリームだけの配信を行った. しかし 想定するアプ リケーショ
ンでは 3,4 ストリームとさらにその数は多くなる. ストリームの増加により同時性に対する要求はさらに厳しくなる. 特定のストリームだけの遅れや, 相対遅延時間の乱れが発生するな
どの問題点が考えられる. また今回はネットワークノードが限られていた , しかしパケットが通過するノード 数の増加によりパケットへの影響が大きくなることは容易に想像でき, それ
により数十フレーム, 数百フレームに相当するずれが発生する. その際にはクライアント側での 1GOP ほどのバッファリングでは対応しきれない. このような場合は各ネットワークノードにおいてパケットに対して優先的な処理を行うなどの処理を必要とする.

{ 17 {

第6章

考察

6.1 まとめ
本稿ではマルチビデオストリームの配送時に要求される, ストリームの同時性の保障について検討を行った. ２ストリーム配送実験の結果, 同期再生と言う点で個別ストリームの到
着間隔によっても , パケット同士の相対遅延時間によっても数フレームに相当するずれが生じた. また同時に送信されるパケットが必ずしも同時に再生されるべきデータを保有していないため, パケットに含まれるデータの時間的対応が取れていなければ同期再生が望めない.
圧縮されたデータからは時間的な対応が取れないため,GOP という単位を用いる対応を提案
した.

6.2 今後の課題
しかしまだ検討の始めの段階で終わっており, 今後更なる検討を積み同時性を保障する方式を設計しなければならない.

{ 18 {

謝辞
本研究は , 多くの方々の多大な支援と協力のもとに行われた. 高知工科大学工学部情報シス
テム工学科の方々に深く感謝の意を表する.

筆者と同研究室に所属する学部生, 大学院生の各氏には , ミーティング , 研究室などで研究に対する参考になる意見を頂いたり, 知識不足を補っていただいた. また研究活動以外でも励まし合い, 有意義な一年余りを過ごすことが出来たことを , ここに感謝致します.
また通信・放送機構高知リサーチセンターの皆様にも的確な指摘, 貴重な助言をして頂きました事をここに深く感謝致します.
副指導教員を引き受けて頂いた清水明弘助教授, 福本昌弘講師の両氏にも感謝致します.
指導教員であられる島村和典教授には , 折にふれ研究者としての物事の考え方, 取り組み方をご指導して頂きました. 深謝致します.

{ 19 {

参考文献[1] 中平, 島村:超高速ネットワークにおけるマルチビデオストリームアプ リケーション , 電
子情報通信学会総合大会 予稿集 B-7-143,2000[2] 中平, 坂田, 島村:「 LAN 環境におけるマルチビデオスト リーム配送時の相対遅延特性」, 電気関係学会四国支部連合大会 予稿集 12-23,2000{ 20 {

付録

A

スト リーミング

A.1 スト リーミング
A.1.1 ダウンロード 型とスト リーム型
音声・動画像などの連続したデータをネットワークを用いて利用する場合, 大きく 2 つに分類される.「ダウンロード 」タイプと「ストリーミング 」タイプである.
この両者をテレビ やラジオなど 従来の放送技術に対応させて考えるならば , 前者は一度データを蓄積させた後に再生を行うのでビデオやテープ ,MD への録画・録音に対応し , 後者
は電源を入れると直ちに画像, 音声が流れる, 通常我々がテレビ・ラジオを利用する形に似ている.
これまでインターネットで扱われるものは主にテキストや静止画像といったデータであった. これらのデータはダウンロードし 利用する. このため音声や動画など もこれと同様に各データをダウンロードしそれから再生を行うという方法が採られていた. しかしこの場合,
音声・動画像はたとえ圧縮されていてもデータ量が多く, データを蓄積するのに必要な HDDなど 蓄積媒体に大容量なものを必要とすることと , ダウンロード の終了を待たなければならないといった問題が発生する.
そこでインターネット上でもテレビやラジオのように , 送られてきたデータを蓄積せずに再生できないだろうかと考えられたのがストリーミングである.

{ 21 {

A.1 ストリーミング

A.1.2 スト リーミングに関するプロト コル
TCP と UDP
インターネットでは TCP/IP プロトコルが代表的なプロトコルである. しかし 現在インターネットで行われているストリーミングに関するサービスでは , 通常はデータ転送に UDPを採用している.
これはストリーミングは音声や動画像などのデータをリアルタイム再生するために通信手順の処理を省くためである.

TCP は誤り訂正, フロー制御, パケットがクライアントに届かなかったときの再送の処理などの特徴を持つ. その分だけデータ以外の制御情報を多く含み, 処理のオーバヘッドが増加
する. ストリーミングにおいて重要なことは , できるだけ効率良くデータパケットだけを取り出し リアルタイム再生を実現することである. そのためストリーミングでは ,TCP に比べてオーバヘッドが少ない UDP を使用している.

RTP と RTSP
インターネットで扱われるデータの多くは , テキストや静止画といった時系列のないデー
タである. これらのパケットの通信中にパケットのロス, 遅延, 遅延の揺らぎが起こったとしても,TCP に見られるような誤り訂正や再送要求処理などを行うことで , 完全な形でデータが受信されれば良かった.
しかし音声や動画像は時間が大きな意味を持つデータである. こうしたデータをリアルタイ
ムで再生を行うためには重要なことは , 受信側において送信側から送信されるデータのタイ
ミングを忠実に再現し再生することである. またパケットの到着間隔, 順序などといったことも重要である. これまでこうしたことを想定したものは無かった. そこでリアルタイムデータの通信のために考えられたプロトコルが RTP(Realtime Trancefer Protocol) である.

RTP(Real-time Transport Protocol)：リアルタイム性が要求されるデータを伝送する 際の, 送信側と受信側の両端間のプロトコルを規定している.(RFC 1889){ 22 {

A.1 ストリーミング
ペイロード（ 伝送するデータ) タイプの指定, シーケンス番号の付与, タイムスタンプの付与,
送監視の機能など を含むが ,RTP それ自体は QoS(サービ ス品質) を保証する機構を備えていないため, こうした機能は下位層における機能に依存することになる.
リアルタイム通信においては , 受信側において送信されるデータのタイミングの再生が重要であるが , イン ターネット 層ではこのタイミングが 保証され るとは限らず , パケット の到着順序も保証され るとは限らない. このデ ータのタイミング , および パケット の到着順
序を再生するために ,RTP ではシーケン ス番号とタイムスタンプが 用意されている. シー
ケンス番号を用いて , 受信側はペイロード を参照しなくてもパケットを送信順に整列させることができる. そして整列後にタイムスタンプを使用し 相対的な時間間隔でデータを再生することができるのである. さらに ,RTCP(RTP Control Protocol：回線上の帯域幅の変化や伝送遅延など を上位アプ リケーションに通知する機能を持つ) によって , 受信側からのフィード バックにより, 送信側は通知された回線品質に合わせたビットレートで送信する.

RTSP(Real Time Streaming Protocol) :リアルタイムデータ伝送を制御するアプリケー
ションレベルのプロトコル (RFC2326)

IP ネットワーク上でストリーム形式のデータ配送を効果的に行なうプロトコルである.RTSP
はアプ リケーション層のプロトコルで , 一本または複数の時間同期された連続メディアスト
リームを確立し 制御を行う. また連続したストリームデータ自体を運ぶものではなく, マル
チメディアサーバーのためのネットワーク遠隔制御用プロトコルである, つまりサーチやス
キップといった機能を提供する.RTSP にコネクションの概念はなく, 代わりにサーバーは識別子によって識別されたセッションを保つ.RTSP のオペレーションは連続メディアを運ぶために使われるトランスポート機構に依存しない. また RTSP は意図的にシンタックスやオ
ペレーションが HTTP/1.1(Hyper Text Transport Protocol) に似ており,HTTP に対する機能拡張は多くの場合 RTSP にも加えられる.

{ 23 {

付録

B

マルチビデオスト リーム

B.1 マルチビデオスト リームとは
現在一つのストリームを用いたサービ スが , インターネット上で行われていることは第１章で述べた. しかし 複数のストリームを扱ったしたサービ スはまだ行われていない. そこで
このストリーミング技術を応用し , 高速・広帯域ネットワーク上で同時性を持つ音声・動画
像などのファイルの配信を複数のストリームを用いて行おうという考え方がマルチビデオス
トリームである. またストリーミングを利用したサービ スとしてライブ方式とオンデマンド方式が挙げられる. ライブ方式はスポーツや音楽ライブなどの生中継を提供するサービ スである.
一方オンデマンド 方式は音声・動画像など のデータがあらかじめサーバに蓄積されており,ユーザがそのデータを選択することで再生が開始される. 現在のところマルチビデオスト
リームの配信では , 後者の蓄積型オンデマンド 方式の実現を目指している.

蓄積オンデマンド 型ストリーム配信は ,1. データの蓄積とデータ配信を行うサーバ
2. 利用者がそのデータを受信するクライアント端末
3. それらを結ぶネットワークの 3 つから成り立っている.

{ 24 {

B.1 マルチビデオストリームとは

図 B.1

蓄積型ストリーム配信の概念図

図 B.2 サーバとクライアントの概念図

図 B.2 に示すようにサーバは

 コンテンツ蓄積部：エンコード (符号化) されたビデオファイルが蓄積される.
 制御部：ユーザ利用状況の監視・管理や要求に応じてビデオファイルを呼び出し配信を行う.

 通信インターフェース部：ネットワークとのインターフェースである.

{ 25 {

B.2 マルチビデオストリーム利用例
から成り立つ.
またクライアント端末は

 制御部：操作部から送られる要求をサーバに通知する. またデコード 部の制御も行う.
 操作部：ユーザのコンテンツ選択や映像操作要求を受け付ける. 表示部の一部とも考えられる.

 デコード 部：ストリームデータを復号し表示部に送る.
 表示部：復号されたデータを表示する.
 通信インターフェース：サーバと同様にネットワークとのインターフェースである.
から成り立つ.

B.2 マルチビデオスト リーム利用例
マルチビデオスト リーム配信においてその利用法を考えると , それぞれのスト リームが別々の内容を持つ場合と複数で一つの意味のある内容を持つ場合が考えられる.
それぞれが別々の内容を持つ場合はテレビやラジオと似ている. つまり一つ一つのストリー
ムがテレビにおけるチャンネルを意味し , それぞれが別の番組を流していることによく似ている.

しかしここでマルチビデオストリームを利用した形として目指すのは , 複数のスト

図 B.3 テレビとチャンネル

リームを用いて各ストリームが関連性のある同時性を持ったコンテンツの配信を行う.

{ 26 {

B.2 マルチビデオストリーム利用例

図 B.4

ストリームと内容同時性を持つマルチビデオストリームの考え方として , 時間が同じ , 空間が同じ , 時間も空
間も同じ場合, また内容が同じなどであるなどが挙げられる.

 時間が同じ：同時刻に起こる事象を対象とする.
たとえば 日本各地の天気の情報や渋滞状況など , 遠方において起こっていることを扱ったりする場合である. しかしこの利用法は蓄積コンテンツとしてよりも, リアルタイム性を重要とする場合が多いように思われる.

 空間が同じ：同じ空間, 場所で起こる事象を対象とする.
同じ場所を違う時間に撮影することで時間による変化を見ることができる. 例えば , 観光
名所などを季節毎に撮影したものなどが挙げられる.

 時間, 空間が同じ：同時間, 同じ空間内で起こる事象を対象とする.
例えば 野球, サッカー, カーレースといったスポーツや音楽ライブやクラシックバレエ,
演劇などの舞台を対象とする場合である. 蓄積型マルチビデオストリーム配信においては , この形で利用されることが多くなると思われる.

 内容が同じ：各ストリームの表す内容が同じような意味を含んでいる.
例えばサッカーなどで似たような状況にあるシュートシーンを集め各選手の動きの特徴を比べたり, テレビで見られるような野球選手のバッティング , ピッチングフォームのチェックなどというような同じ意味を含んだものである.

{ 27 {

B.2 マルチビデオストリーム利用例

図 B.5 ボクシングにおけるマルチビデオファイル撮影

ここで時間・空間が同じである場合の具体的な例をひとつ挙げる. 図 B.5 のようにある会
場でボクシングが行われている時, カメラを複数用意し 撮影が行われる. 図 B.5 ではカメラ

A,B,C,D はそれぞれの方向からリング 上の両者を映し , カメラ E,F はボ クサー一人一人を対象として撮影している.
通常テレビなどでもこのようにして複数のカメラで撮影されている. しかし放送されるのは編集者の編集した視点のみである. 複数の視点で撮影されていたとしても, 我々が目にするのは受動的な映像だけである. たとえあるカメラが決定的な KO シーンをとらえていたとしても, それが編集者の意にそぐ わなければカットされてしまうこともあり得る.
それに比べマルチビデオストリームで配信されるコンテンツでは各ストリームの同期が保たれた状態で再生され , 複数のカメラの視点を全て再現することができる. それゆえカメラの全視点をみることやユーザが見たい視点だけを見ることも可能である.

{ 28 {

付録

C

情報圧縮技術C.1 情報圧縮の必要性
情報の圧縮を行う大きな理由は , 現在の蓄積メディア , 通信メディアが大容量のデータを扱
うには力不足だということがあげられる. 例えば 何十 MB, 何百 MB のデータを送受信していたのでは時間が掛かりすぎ , また通信費なども膨大なものになってしまう. こうした問題を解決するには , 単純に通信ネットワークの帯域を拡大させたり, コンピュータの処理能力を上げるといったことで解決することはある程度可能である. しかしデータ容量は年々増加の傾向にあり, 情報量が膨大に増えつづける世の中でこうした力任せの方法では対処では根本的な解決は行えない. しかしデータの圧縮行うことで同じ 内容のデータをより短い時間, 安
いコストで取り扱うことができるようになるのである. 世の中でどんどん情報化が行われていく中で , 情報を圧縮する技術は大容量データを扱うために必要不可欠なものなのである.

C.2 動画像の圧縮の考え方
動画像の圧縮方法は基本的には静止画の考え方と同じである. 圧縮技術には可逆圧縮と非可逆圧縮があり, 通常テキストデータなどの圧縮にはデータロスが発生しない可逆圧縮が行
われ , 静止画や動画データへの圧縮はデータロスが発生する非可逆圧縮が行われる. 非可逆圧
縮は圧縮効率が非常に高いが圧縮率を上げるとデータの品質が損なわれるという特徴を持っている.
このように静止画, 動画とも非可逆圧縮で圧縮されるが , 動画像を静止画の連続したものと{ 29 {

C.2 動画像の圧縮の考え方
して考えて圧縮を行うだけでは効率の良い圧縮は行うことはできない.
例えば 動画像を静止画の連続するパラパラ漫画のようにとらえて ,TV と同じ ように１秒
間が 30 枚の画像からなっていると考える. すると１枚の静止画が圧縮されて 100KB であるとした時 30 枚で 3MB なり, たった 1 分間で 180MB もの容量になってし まう.128kbps の回線で受信しようとした場合, 一秒間に受信できるデータ量は最大で 16KB である. これではど う考えても動画の再生は行えない , 動画の再生を行うには単純に静止画を連続して送れば良いのではないことが分かる. 動画一枚一枚について考えると , それぞれの画は連続したものである. そこで現在の画と一つ前の画を比べて見ると , 全く異なる画ではなくほとんど 同じ画像であることが多いのである. このことから動画像の圧縮には時間的な要素を加えた圧縮が行われる, こうした技術を予測符号化という.

図 C.1 双方向予測符号化{ 30 {