目次
目的
Webカメラを用いてリアルタイムストリームサーバを構築し、ネットワークの混み具合(帯域変動)などにより画像の品質が変化する様子を体験し観察する。
実験システムの構成および実験方法
・実験システム
実験システムを図1として以下に示す。

・実験方法
(1)Webカメラのストリーミングサーバを構築した。
(2)パケットシュミレータ(今回はethBLOCKを使用)により帯域制限やパケット遅延を発生させ、その度合いにより画像の見え方がどのように変わるかを観察した。
基本測定項目により実験
測定内容
パケットシュミレータを通常状態にし、映像をTCPとUDPの2つプロトコルでストリームを配信し、以下の4観点からストリームの状態を観測した、また、エンコーダのビットレートは1128Kbpsとした。
(a)映像の状態(S1~S7)
(b)受信の平均通信量(Kbps)
(c)送信の平均通信量(Kbps)
(d)サーバとノートPC間での映像の遅延時間(秒)
(a)映像の状態(81~87)の内容を表1として以下に示す。
表1:状態一覧
状態番号 | 状態 |
S1 | 目標ビットレート通りの通信が行われ、画像も安定している。 |
S2 | 目標ビットレートには届かずビットレートが不安定であるが、画像は |
安定している。 | |
S3 | 目標ビットレートには届かずビットレートが不安定であるが、画像は |
不安定(時たま止まる等)。 | |
S4 | 動画状態と静止画状態を繰り返す。ビットレートは不安定。キーフレー |
ム伝送状態もたまに発生。 | |
S5 | キーフレームのみの伝送。画像はキーフレームの間隔毎に動くが、そ |
の間は静止画。 | |
S6 | 画像映らない(あるいは静止)が音声のみ聞こえる。 |
S7 | トラヒックも無く、音声も画像も何も映らない。(接続断の状態) |
O; | その他。 |
測定結果
通常状態において、映像をTCPとUDPでストリームを配信したときの4観点の内容を表2として以下に示す。
表2 通常状態におけるTCPとUDPの通信状態
(a)映像状態(S1~S7) | (b)受信平均(Kbps) | (c)送信平均(Kbps) | (b)遅延時間(S) | |
TCP | S1 | 1130 | 23 | 23 |
UDP | S1 | 1130 | 0 | 10 |
分析と考察
表2より、TCPの場合の受信平均通信量は1130Kbps、UDPの場合は1130Kbpsであることがわかる。今回、ビットレートを1128Kbpsに設定している中で微小な誤差を除けば、受信平均通信量のTCPとUDPどちらにおいても、正常な送受信が行われと言える。
また、UDPの送信平均通信量がないのに対し、TCPでは23Kbpsであった。さらに、遅延時間はUDPが10秒に対し、TCPでは13秒遅い23秒であった。TCPは受信側から送信側にパケットが無事に届いたことを知らせるACKと呼ばれるものを送る。UDPはこの作業がなく一方的にパケットを送り続ける。この為、TCPの方が遅延時間が長いのである。
ネットワークの帯域に制限をかけることによる通信状態の変化による実験
観点(目的)と測定内容
パケットシュミレータの設定を変更し、ネットワークの帯域に人為的に制限をかけた。
この帯域制限の値の変化により、映像の見え方などの違いを測定した。
測定結果
TCPとUDPの場合で20~1600Kbpsの範囲でネットワークの帯域制限を行った結果を表3,4として以下に示す。
表3 TCPにおけるネットワークの帯域制限に伴う通信状態
帯域制限(Kbps) | TCP | |||
(a)映像状態 | (b)受信平均(Kbps) | (c)送信平均(Kbps) | 遅延時間(秒) | |
1600 | S1 | 1130 | 24 | 22 |
1400 | S1 | 1130 | 23 | 21 |
1000 | S4 | 700 | 18 | 50 |
800 | S4 | 660 | 18 | 69 |
400 | S5 | 280 | 20 | 90 |
200 | S6 | 130 | 7 | 測定不能 |
50 | S7 | 0 | 0 | 測定不能 |
20 | S7 | 0 | 0 | 測定不能 |
表4 UDPにおけるネットワークの帯域制限に伴う通信
帯域制限(Kbps) | UDP | |||
(a)映像状態 | (b)受信平均(Kbps) | (c)送信平均(Kbps) | 遅延時間(秒) | |
1600 | S1 | 1130 | 0 | 12 |
1400 | S1 | 1130 | 0 | 17 |
1000 | S5 | 150 | 0 | 17 |
800 | S5 | 180 | 0 | 17 |
400 | S5 | 180 | 0 | 16 |
200 | S7 | 0 | 0 | 測定不能 |
50 | S7 | 0 | 0 | 測定不能 |
20 | S7 | 0 | 0 | 測定不能 |
分析と考察
今回、パケットの種類ごとに、使用できる回線容量(通信速度)を制限する帯域制限が、小さくなるにつれてTCPは遅延時間が長くなるに対して、UDPは、ほとんど変化が見られない。これは、TCPは一度に送れないデータは再送しているのでその分、遅延時間がかかるのに対して、UDPは一方的にデータを送り続けているので遅延時間に変化はなかったと考えられる。
次に、帯域制限を小さくするにつれて、今回の実験ではビットレートを1128Kbpsとしたが、これ以下になると、映像の状態を見ても分かる通り、映像が乱れている。これは、ビットレートに対して帯域制限が小さすぎると、一度に送れるデータが少なくなり、映像データを送るのに時間がかかりすぎてしまうため、映像が時たま停止したり、キーフレーム転送状態になったり、映像は映らないが音声のみが聞こえるなどといった映像の乱れが生じると考えられる。キーフレームとはビデオクリップに一定の間隔で挿入される完全なビデオフレームであり、キーフレーム間のフレームには、キーフレーム間で発生する動きやシーンの変化に関する情報が入っている。
次に、TCPとUDPにおいて、どちらも帯域制限を小さくすると受信平均、送信平均は小さくなっていった。これは、帯域制限が小さくなると一度に送受信できる量も減ることになるからだと考えられる。
また、ビットレートが1128Kbpsなので帯域制限を1128Kbpsより小さい、今回だと1000Kbpsにすると十分なデータの送受信ができなくなってしまうので、TCPとUDPの二つにおいての1400Kbpsと1000Kbpsの受信平均の差が大きい原因が分かる。さらに、受信平均の差が大きくなるということはその分、受信する時間かかることになるので1400Kbpsと1000Kbpsにおいての遅延時間の差が大きいことも分かる。
パケット破棄率の変化による通信状態の変化による実験
観点(目的)と測定内容
パケットシュミレータの設定を変更し、通信路を通るパケットを一定の割合で削除するようにした。この破棄率の変化により、映像の見え方の違いを観測した。
測定結果
TCPの場合は2~15%の範囲で、UDPの場合は2~45%の範囲でパケットの破棄を行った結果を表5,6に示す。
表5 TCPにおけるパケットの破棄に伴う通信状態
パケット破棄率(%) | TCP | |||
(a)映像状態 | (b)受信平均(Kbps) | (c)送信平均(Kbps) | 遅延時間(秒) | |
2 | S1 | 1130 | 27 | 20 |
4 | S1 | 1130 | 30 | 25 |
6 | S1 | 1130 | 32 | 25 |
8 | S3 | 1000 | 30 | 44 |
10 | S4 | 800 | 22 | 76 |
12 | S6 | 600 | 19 | 測定不能 |
15 | S7 | 0 | 0 | 測定不能 |
表6 UDPにおけるパケットの破棄に伴う通信状態
パケット破棄率(%) | UDP | |||
(a)映像状態 | (b)受信平均(Kbps) | (c)送信平均(Kbps) | 遅延時間(秒) | |
2 | S1 | 1130 | 0 | 14 |
6 | S1 | 1130 | 0 | 15 |
10 | S1 | 1130 | 0 | 15 |
15 | S1 | 1130 | 0 | 20 |
20 | S5 | 1130 | 0 | 19 |
25 | S5 | 1130 | 0 | 20 |
35 | S6 | 1130 | 0 | 19 |
45 | S7 | 0 | 0 | 測定不能 |
分析と考察
表5より、TCPの場合ではパケット破棄率6%までは映像の状態はS1であったが、8%以上になると一気に映像の状態が悪くなり、受信平均も減少していくのがわかる。つまり、TCPではパケットが破棄されてしまうと、その分映像に影響してしまうことがわかる。このことは、TCPはパケットがきちんと送信できた場合、ACKパケットが返ってくるが、もし送信中にパケットが破棄されてACKが返ってこない場合、再送機能によって再送され、そしてその分の時間がかかるということからも言える。
一方、表6より、UDPの場合ではパケットの破棄率15%まで映像の状態がS1であった。これは、パケットの破棄による再送機能がなく、次々にパケットが送信されるため破棄率が高くなっても映像を配信することができたのだと考えられる。
パケット遅延時間の変化による通信状態の変化による実験
観点(目的)と測定内容
パケットシュミレータの設定を変更し、通信路を通るパケットをパケットシュミレータによって人為的に遅延を発生させた。
測定結果
TCPの場合は100~2000msの範囲で、UDPの場合は100~4000msの範囲でパケットの遅延を行った結果を表7、8に示す。
表7 TCPにおけるパケットの遅延に伴う通信状態
パケット遅延時間 (ms) | TCP | |||
(a)映像状態 | (b)受信平均(Kbps) | (c)送信平均(Kbps) | (d)遅延時間(秒) | |
100 | S1 | 1130 | 27 | 22 |
200 | S1 | 1130 | 25 | 22 |
300 | S1 | 1130 | 26 | 30 |
400 | S1 | 1130 | 26 | 30 |
500 | S2 | 800 | 20 | 30 |
900 | S2 | 1100 | 23 | 36 |
1500 | S6 | 300 | 10 | 測定不能 |
2000 | S7 | 0 | 0 | 測定不能 |
表8 UDPにおけるパケットの遅延に伴う通信状態
パケット遅延時間 (ms) | UDP | |||
(a)映像状態 | (b)受信平均(Kbps) | (c)送信平均(Kbps) | (d)遅延時間(秒) | |
100 | S1 | 1130 | 0 | 14 |
300 | S1 | 1130 | 0 | 15 |
500 | S1 | 1130 | 0 | 15 |
900 | S1 | 1130 | 0 | 15 |
1500 | S1 | 1130 | 0 | 15 |
3000 | S4 | 600 | 0 | 25 |
4000 | S6 | 200 | 0 | 測定不能 |
分析と考察
表7,8から、パケット遅延時間を増やすことによって、映像状態が悪くなっていき、パケットの送受信も減少することが分かった。しかしパケット遅延時間を増やすことによって、TCPは遅延時間が大きくなっていったのに対してUDPでは遅延時間に変化がほとんど見られなかった。これは、TCPでは、パケットを送信したときACKパケットが返ってこなければ次のパケットを送ることはできない。パケット遅延時間を長くしていくとACKが返ってくる時間も遅くなるため遅延時間が伸びたと考えられる。しかしUDPでは遅延時間に変化がなかった。これはUDPの仕組みとしてパケット送信はサーバ側とは関係なく次々に送るということに関係があると考えられる。パケット遅延時間を増やしておいくことで初めに送ったパケットがクライアント側に届くのが遅れる。しかし届くのを確認しないためサーバ側は随時パケットを送信している。これによりクライアント側も随時パケットを受信することになるので上記のような結果になったと考えられる。
片方の回線のみの制限をした場合の通信状態の変化による実験
観点(目的)と測定内容
(1)ethBLOCKで上り回線(ノートPC→サーバ)のパケット破棄率を100%した時のTCPとUDPによる違いを観察した。
(2)ethBLOCKで上り回線(ノートPC→サーバ)のパケット遅延を最大4000msとした時のTCPとUDPよる違いを観察した。
また、(1)、(2)の観察は動画再生の前後で行った。
測定結果
TCPとUDPの場合の(1)における動画再生前後の変化を表9、10として、(2)における動画再生前後の変化を表11、12に示す。
表9 TCPにおけるパケット破棄率を100%にしたときの動画再生前後の変化
動画再生 | TCP | |||
(a)映像状態 | (b)受信平均(Kbps) | (c)送信平均(Kbps) | (d)遅延時間(秒) | |
前 | S7 | 0 | 0 | 測定不能 |
後 | S1→S7 | 1130→0 | 22→0 | 22→測定不能 |
表10 UDPにおいてパケット破棄率を100%にしたときの動画再生前後の変化
動画再生 | UDP | |||
(a)映像状態 | (b)受信平均(Kbps) | (c)送信平均(Kbps) | (d)遅延時間(秒) | |
前 | S7 | 0 | 0 | 測定不能 |
後 | S1→S7 | 1130→0 | 0 | 20→測定不能 |
表11 TCPにおいてパケット遅延を最大値4000msにしたときの動画再生前後の変化
動画再生 | TCP | |||
(a)映像状態 | (b)受信平均(Kbps) | (c)送信平均(Kbps) | (d)遅延時間(秒) | |
前 | S6 | 300 | 7 | 測定不能 |
後 | S1→S7 | 1130→0 | 23→0 | 28→測定不能 |
表12 UDPにおいてパケット遅延を最大値4000msにしたときの動画再生前後の変化
動画再生 | UDP | |||
(a)映像状態 | (b)受信平均(Kbps) | (c)送信平均(Kbps) | (d)遅延時間(秒) | |
前 | S7→S1 | 0→1130 | 0 | 測定不能→37 |
後 | S1→S7 | 1130→0 | 0 | 14→14 |
分析と考察
表9、10は上り回線にパケット破棄率100%をかけた時であるが、表9、10での違いは動画再生の映像状態でTCPの場合すぐに画像が止まったのに比べ、UDPも画像が止まったがしばらく画像が安定していたところがある。今回、上り回線をかけているので、TCPの場合、きちんと届いたことを知らせるACKパケットが破棄されるわけだが、ACKパケットが破棄されたらサーバ側は再送されるわけだが、ACKパケットが毎回破棄されてしまい、ずっと再送を繰り返してしまう。そうなるとサーバ側がクライアント側はもう見ていないと判断し、接続が遮断されてしまうのですぐに画像がとまってしまうことが分かる。一方、UDPの場合、一方的にパケットをクライアント側に送信してさらに定期的にサーバ側に届いていることを知らせることを行っているプロトコルのRTPがあり、上り回線にパケット破棄率100%をかけると届いていることの知らせがサーバ側に届かなくなり、それが何回も繰り返すとサーバ側がクライアント側はもう見ていないと判断し、接続が遮断されてしまうがTCPと違い、届いていることの知らせは定期的なので画像はしばらくたってから消えた。
まとめ
今回の実験は条件付きのストリーミング配信においてTCPとUDPの2つのプロトコルを使って帯域制限、パケット破棄、遅延時間など状態を変化させることで通信状態がどのように変化するのかを観察した。どの場合でも状態を悪く設定すればTCP、UDPともに映像の状態、遅延時間、平均受信、平均送信、遅延時間が悪くなるということが分かった。またUDPの方がストリーミング配信が適していることがいえる。
【参考文献】
実験指導書D2
D1,D2参考
D2実験手順の詳細
信頼性のある通信を実現するTCPプロトコル http://www.atmarkit.co.jp/ait/articles/0312/25/news001.html
コメントを残す