【レポート】Webカメラを用いたリアルタイムストリームサーバー

[レポート]Webカメラを用いたリアルタイムストリームサーバを構築し、ネットワークの混み具合(帯域変動)などにより画像の品質が変化する様子を体験し観察

概要

Webカメラを用いたリアルタイムストリームサーバを構築し、ネットワークの混み具合(帯域変動)などにより画像の品質が変化する様子を体験し観察する。

システムの構成及び実験方法

実験システムの構成

今回の実験で用いた環境を簡単に表したものを図1に表記する。

図1:実験システムの構成

実験方法

(A)Webカメラのストリーミングサーバを構築する。

(B)ネットワークシュミレータにより帯域制限やパケットの遅延を発生させ、その度合いにより画像の見え方がどのように変わるかを観察する。

通常状態による映像の見え方を観測する

測定内容

パケットシュミレータを通常状態(設定を一切変えない)で映像の見え方をTCPとUDPそれぞれの値を観測した。また、エンコーダのビットレートを1128[Kbps]に固定した。

観測するポイントは以下の4点とした。

  • 映像の状態
  • 受信の平均通信量[Kbps]
  • 送信の平均通信量[Kbps]
  • サーバとノートPC間での映像の遅延時間[秒]
  • 映像状態と波形の表示の仕方を表1に表す。

表1:波形の状態の基準

状態番号 状態
S1 目標ビットレート通りの通信が行われ、画像も安定している
S2 目標ビットレートには届かずビットレートが不安定であるが、画像は安定している
S3 目標ビットレートには届かずビットレートが不安定であるが、画像は不安定(時たま止まる等)
S4 動画状態と静止画状態を繰り返す。ビットレートは不安定。キーフレーム伝送状態もたまに発生
S5 キーフレームのみの伝送。画像はキーフレームの間隔毎に動くがその間は静止画
S6 画像が映らないあるいは静止画音声のみが聞こえる
S7 トラヒックもなく音声も画像も何も映らない(接続断の状態)
O その他(状況を記述する)

測定結果

TCPとUDPの通常状態の通信を行った時の4つの観測ポイントを表2に記載する。

表2:TCPとUDPの通信状態

  映像状態 受信平均通信量 [Kbps] 送信平均通信量 [Kbps] 遅延時間[秒]
TCP S1 1128[Kbps] 23[Kbps] 25秒
UDP S1 1128[Kbps] 0[Kbps] 14秒

分析と考察

TCPの場合もUDPの場合も観測ポイントである映像の状態、受信平均通信の値は全く一緒であった。しかし、送信平均通信量と遅延時間の数値には違いが生じたことが表2からわかる。送信平均量はUDPが0[Kbps]、TCPが23[Kbps]となり、遅延時間がUDPの方が14秒、TCPの方が25秒となった。このことから、遅延時間が少ないUDPの方がTCPよりも転送する速度が速いということがわかる。その理由としてTCPは送られたパケットに対してACK と呼ばれる受信側から送信側へ無事に届いたことを知らせるといったことを返しているがUDPは返していないことが遅延時間と送信平均量に違いが生じたことが考えられる。この実験から、UDPの方がTCPよりも転送時間が短くて済むことが分かった。その他に映像の状態がS1だったことから今回の実験3では、パケットシュミレータの設定を一切変えずに行い、目標ビットレート1128[Kbps]に届いていたからだと考えられる。

ネットワークの帯域に制限をかけた時の通信状態

測定内容

パケットシュミレータの設定を変更し、ネットワーク帯域に制限をかける。帯域制限の変化によって、映像の見え方などの違いを観測した。観測のポイントは実験3で用いたa~dの4点とした。この4点をTCPとUDPの場合両方を行い帯域制限20~1600[Kbps]を観測した。

測定結果

ネットワーク帯域に制限をかけ、通信状態の変化を表す。TCPの場合で観測した4つのポイントを表3に記載し、UDPの場合で観測した4つのポイントを表4に記載する

表3:帯域制限の変化時の通信状態(TCP)

帯域制限[Kbps] 映像状態 受信平均[Kbps] 送信平均[Kbps] 遅延時間[秒]
1600 S1 1128 23 23
1400 S1 1128 22.5 30
1000 S3 673 17 30
800 S3 655 15 42
400 S4 276 7.5 55
200 S6 165 5 測定不能
50 S6 30 0 測定不能
20 S7 0 0 測定不能

表4:帯域制限の変化時の通信状態(UDP)

帯域制限[Kbps] 映像状態 受信平均[Kbps] 送信平均[Kbps] 遅延時間[秒]
1600 S1 1128 0 14
1400 S1 1135 0 15
1000 S5 130 0 17
800 S5 130 0 18
400 S5 128 0 18
200 S6 127 0 18(音声のみ)
50 S6 41 2 18(音声のみ)

分析と考察

 表3と表4を見ると、帯域制限の値が小さくなるにつれて、映像の状態が悪くなっていることがわかる。これは今回の実験で使用しているストリーミング方式が動画、音声データをリアルタイムで再生する方式であるため、帯域の値が大きくなればよりリアルタイムに近いデータを送ることができ、反対に値が小さいと動画にブレなどが生じてしまうということは容易に推測することができる。今回パケットキャプチャに帯域制限をかけるということは、通信量を制限するということであり、同じデータ量で動画をリアルタイムで視聴しているため、帯域の制限の値が小さくなると極端に映像が悪くなるのではないかと考えられる。

次に受信平均を比べてみた。TCPの方の受信平均が1400[Kbps]まではビットレートが1128[Kbps]を維持してその後、徐々に受信平均が落ちていったのに対しUDPは1000[Kbps]を超えたあたりから一気に映像の状態が悪くなっているのがわかる。

このことから、TCPの方がUDPよりも多少帯域の値が低くても、映像状態の維持という点ではTCPが優れていることがわかる。その一方で、遅延時間に大きく差が出ているのがわかる。帯域が400[Kbps]の時点で比べると、映像状態はTCPの方がいいが、遅延時間ではUDPでは18秒TCPでは55秒と大きく差が出たことがわかる。これはUDPがとにかく転送速度を速くしていると考えられる。また帯域が200,50[Kbps]の時は映像の状態は同じだがTCPの方では音は聞こえるものの大部分が途切れていて、遅延時間を判断することができなかったが、UDPでは音声は届いていたため遅延時間を測ることができた。

これらのことから、UDPはTCPよりも早く転送できるが、帯域がある値よりも低くなると極端に映像の質が落ちるのではないかと考えられる。

パケット破棄率の変化による通信状態の変化

測定内容

パケットシュミレータの設定(実験4と同じ状態)を変更し通信路を通るパケットを一定の割合で削除するようにした。この破棄率の変化により映像の見え方の違いを観測した。

観測のポイントは実験3で用いたa~dの4点とした。

この4点をTCPで2~18[%]を観測し、UDPで2~35[%]を観測した。

測定結果

通信路を通るパケットを一定の割合で削除し、通信状態の変化を表す。

TCPの場合で観測した4つのポイントを表5に記載し、

UDPの場合で観測した4つのポイントを表6に記載する

表5:破棄率の変化による通信状態(TCP)

破棄率[%] 映像状態 受信平均[Kbps] 送信平均[Kbps] 遅延時間[秒]
2 S1 1128 22 22
4 S1 1128 22 23
6 S1 1128 22 23
8 S2 1000 20 23
10 S4 750 15 23
12 S6 400 13 測定不能
15 S6 350 10 測定不能
18 S7 0 0 測定不能

表6:破棄率の変化による通信状態(UDP)

破棄率[%] 映像状態 受信平均[Kbps] 送信平均[Kbps] 遅延時間[秒]
2 S1 1128 0 15
6 S1 1128 4 15
10 S1 1128 12 16
15 S1 1128 12 16
20 S1 1128 18 16
25 S1 1128 19 16
35 S1 1128 23 15

分析と考察

 パケットを一定の割合で削除した結果UDPは常に安定した映像と音声を届けていて、ビットレートも常に1128[Kbps]を維持していた。また遅延時間の変化も15~16秒とさほど変化はなかったことがわかる。このことから、UDPはパケットを破棄しても映像の状態が変わらないということがわかる。このことからパケットが破棄されたことに対する処置を行っていないのではないかと考えられる。

一方TCPではパケット破棄率の上昇とともに映像状態が悪くなっているのが表5からわかる。ここから、UDPとTCPの違いがわかる。TCPの方ではパケット破棄率が18%で映像状態がS7になったのに対し、UDPではパケット破棄率35%でも映像状態をS1に保っていることがわかる。ここからパケットを破棄した状態で映像をリアルタイムで見るには、UDPの方が適しているということがわかる。

UDPの方はリアルタイムに映像を伝えるのを最優先としているためデータの中身が破棄されても破棄された映像が映るため、映像状態は変わらなかったと考えられる。一方でTCPは、破棄されるとACKを返したりするため、遅延時間が増えリアルタイムに放映できなくなったために、映像状態の質が落ちたと考えられる。

もう一つUDPの送信平均が出ていることが表6からわかる。UDPはACKを返したりしないため、送信平均は出ないと考えられる。つまりこれはUDPが関係していることではなく、今回の実験で用いているストリームプロトコルであるRTSPが原因であると考えられ、RTSPとはリアルタイム性のあるデータの配布を制御するためのプロトコルで、クライアント側からサーバに操作するためのメッセージを送信する機能があり、この機能が原因で送信平均が出たと考えられる。また、破棄率を大きくすることによってデータを破棄されて、操作するためのメッセージを送る量が増えていったために送信平均量が増えたのではないかと考えられる。

パケット遅延時間の変化による通信状態の変化

測定内容

パケットシュミレータの設定(実験4と同じ)を変更し、通信路を通るパケットをパケットシュミレータによって遅延を発生させた。

観測のポイントは実験3で用いたa~dの4点とした。

この4点をTCPで100~2000[ms]を観測し、UDPで100~4000[ms]を観測した。

測定結果

通信路を通るパケットをパケットシュミレータで遅延を発生させ、通信状態の変化を示す。

TCPの場合で観測した4つのポイントを表7に記載し、

UDPの場合で観測した4つのポイントを表8に記載する

表7:パケット遅延の変化による通信状態(TCP)

遅延制限値[ms] 映像状態 受信平均[Kbps] 送信平均[Kbps] 遅延時間[秒]
100 S1 1128 23 23
200 S1 1128 23 23
300 S1 1128 23 23
400 S1 1128 23 23
500 S6 130 0 測定不能
1000 S6 125 0 測定不能
1500 S7 30 0 測定不能
2000 S7 0 0 測定不能

表8:パケット遅延の変化による通信状態(UDP)

遅延制限値[ms] 映像状態 受信平均[Kbps] 送信平均[Kbps] 遅延時間[秒]
100 S1 1128 0 23
300 S1 1128 0 23
500 S1 1128 0 23
900 S1 1128 0 23
1500 S1 1128 0 17
2500 S5 130 0 19
3500 S5 130 0 19
4000 S6 130 0 測定不能

分析と考察

 表7,表8を見ると遅延時間が伸びるほど映像の状態が悪くなっているのがわかる。

これは遅延時間が伸びることによってパケットを受信するまでの時間が伸びてしまうのではないかと考えられる。またTCPの方では500msパケットを遅延しただけで映像の状態がS6になったのに対してUDPの方では2500ms遅延してやっと映像状態がS5になっていることがわかる。ここからはUDPの方がTCPよりも、パケットが遅延しても、映像をより速く届けられるのではないかと考えられる。

次に表8から遅延制限値が2500msと3500msで映像状態がS5となっていることがわかる。この時に生じたキーフレームとはビデオクリップに一定の間隔で挿入される完全なビデオフレームである。キーフレーム間のフレームには発生する動きやシーンの変化に関する情報が入っている。

片方の回線のみの制限をした場合の通信状態の観察

測定内容

上り回線(ノートPC →サーバ)のethBLOCK設定メニューの詳細設定(eth2→eth1)を選択し、ネットワークを制限した場合の変化を観測した。観測のポイントは実験3で用いたa~dの4点とした。また実験7は2通りのやり方を行った。

(A)上り回線のパケット破棄率を100%にしたとき、TCPとUDPの違いを観測した。

A-1接続後に値を100%にした

A-2接続前に値を100%にした

(B)上り回線のパケット遅延を最大値としたときTCPとUDPの違いを観測した。

B-1接続後に4000msにした

B-2接続前に4000msにした

測定結果

上り回線のパケット破棄率を100%にしたときのTCPの値を表9に記載しUDPの値を表10に記載する。

上り回線のパケット遅延を最大4000msとしたときTCPの値を表11に記載しUDPの値を表12に記載する。

表9:接続前後に破棄率100%(TCP)

接続 映像状態 受信平均[Kbps] 送信平均[Kbps] 遅延時間[秒]
接続前 S7 0 0 測定不能
接続後 S7 0 0 測定不能

表10:接続前後に破棄率100%(UDP)

接続 映像状態 受信平均[Kbps] 送信平均[Kbps] 遅延時間[秒]
接続前 S7 0 0 測定不能
接続後 S1→S7 1128→0 0 16

表11:接続前後に遅延4000ms(TCP)

接続 映像状態 受信平均[Kbps] 送信平均[Kbps] 遅延時間[秒]
接続前 S7 0 0 測定不能
接続後 S7 0 0 測定不能

表12:接続前後に遅延4000ms(UDP)

接続 映像状態 受信平均[Kbps] 送信平均[Kbps] 遅延時間[秒]
接続前 S6 130 0 測定不能
接続後 S1→S6 1128→130 0 測定不能

分析と考察

 表9をみると、パケットの破棄率を100%に設定するとTCPの場合接続前後どちらも映像状態はS7であったが、UDPの方は表10を見てわかるとおり接続後に破棄率100%にした場合、初めはS1であったが、そのあとすぐにS7になったことがわかる。これはUDPで行うと、一方的に送るため相手からの応答待ち時間などがないため送り続けられるということが考えられる。しかしすぐにS7になっていることがわかった。この原因として挙げられるのは今回の実験で用いているRTSPがコンテンツ送信を行う際に関係しているRTPが原因だと考えられる。RTPはリアルタイムデータを再生するために定期的に再生時間の付与などを行うため、送信した時に破棄率が100%になった後しばらくしてコンテンツの送信を行ったために映像状態がS7になったのではないかと考えられる。

次に表11を見ると最大の4000ms遅らせるとTCPの方は接続前後で映像状態がS7であるのに対し、表12では接続後に遅延した場合S1→S6となっていたこれもUDPが一方的に送るため相手からの応答待ち時間などがないため送り続けられるから初めは映像状態が良かった。また、すぐに映像状態がS6となった理由はRTPが原因だと考えられる。

まとめ

 今回の実験でTCPとUDPの違いをみた。条件付きの場合UDPの場合転送する速度は速いが、パケットを破棄したり、遅延したときに確認の再送信せずにデータを送るためパケットに誤りがあってもそのまま転送してしまい、間違った映像などが放映されてしまうのではないかと思われる。その一方で、TCPは再送処理を行うため、映像に正確性があると思われる。TCPとUDPにはそれぞれの特徴があり条件によって使い分けることが重要であると思われる。

【参考文献】

実験指導書D2.PDF  

D2実験手順の詳細.PDF 

D1,D2参考.PDF

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です