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

概要

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

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

実験システムの構成

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

実験方法

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

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

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

測定内容

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

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

• 映像の状態
• 受信の平均通信量[Kbps]
• 送信の平均通信量[Kbps]
• サーバとノートPC間での映像の遅延時間[秒]

• 映像状態と波形の表示の仕方を表1に表す。

表1：波形の状態の基準

測定結果

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

表2：TCPとUDPの通信状態

分析と考察

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)

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

分析と考察

　表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)

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

分析と考察

　パケットを一定の割合で削除した結果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)

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

分析と考察

　表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)

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

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

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

分析と考察

　表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　

D１，D２参考.PDF