JPH11215480A - 映像通信システム及び映像送信装置及び映像受信装置及びそれらの制御方法及び記憶媒体 - Google Patents

Abstract

(57)【要約】 【課題】 ネットワークの伝送帯域を十分に活かして映
像データの転送速度を適宜調整することで映像データを
効率良く転送する。 【解決手段】 映像送信元である送信側端末１−１は撮
像して得た画像データを分割し、それぞれにシーケンス
番号を付したパケットとして受信側端末１−２にネット
ワーク１−３を介して送信する。受信側端末１−２は、
例えば３秒毎に、最新の受信したパケットのシーケンス
番号と受信レートを含む受信レポートを送信側端末１−
１に送信する。これを受けた送信側端末１−１では、今
現在送信中のデータが１フレームの途中である場合には
そのフレームの終了時点で最大目標値となるように算出
し、且つ、次のフレームの転送する時期を決定する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、映像データをネッ
トワークを介して通信する映像通信システム及び映像送
信装置及び映像受信装置及びそれらの制御方法及び記憶
媒体に関するものである。

【０００２】

【従来の技術】ネットワークを介して、映像データを送
受信する際に、伝送帯域などのネットワーク資源やネッ
トワークの輻輳状態に応じて如何に送出レートを決めて
やるかが問題となってくる。

【０００３】例えば、送信レートを高く設定しすぎる
と、ネットワーク上にあるネットワーク機器のバッファ
にデータが溜り、結果としてその溜まったデータ分だけ
伝送遅延が大きくなることになる。また、ネットワーク
で使用可能な伝送容量を越えてデータを送出し続けると
バッファ溢れが起こりパケットロスが起こる。逆に送出
レートを低くしすぎるとネットワークの使用可能帯域を
十分使いきれず、映像のフレームレートが落ちてしま
い、満足する品質を得られないということになってしま
う。

【０００４】このため、送出レートを調整するため、ネ
ットワークでのデータのロスを監視し、ロスが起こると
送出レートを下げるという方法がとられている。

【０００５】

【発明が解決しようとする課題】しかし、ネットワーク
の送信側と受信側の間に分散して存在するノードには、
それぞれがデータを溜めることのできるバッファを保有
しており、過剰にデータを送出してロスが生じる時に
は、そのネットワーク上のバッファのいずれかが溢れて
いる可能性が高い。したがって、ロスが生じてから送出
レートを下げても、ネットワーク上のどこかのバッファ
が一杯になっていることになり、そのバッファに溜まっ
ているデータをネットワークが処理できる時間だけは必
ず伝送遅延が生じ、送信側からのデータが受信側に遅れ
て到着することになる。

【０００６】リアルタイム性を重視するデータ通信、特
にその映像データをもとにインタラクティブ操作を行う
ようなアプリケーションにおいては、伝送遅延は非常に
大きな問題となる。

【０００７】従って、ネットワーク上に溜まったデータ
量を調整することで映像フレームの到着するまでの遅延
を最小限にし、且つ伝送可能なネットワークの帯域を十
分に使った送出レートでデータを送出することが最大の
課題となる。

【０００８】本発明はかかる問題点に鑑みなされたもの
であり、ネットワークの伝送帯域を十分に活かして映像
データの転送速度を適宜調整することで映像データを効
率良く転送することを可能ならしめる映像通信システム
及び映像送信装置及び映像受信装置及びそれらの制御方
法及び記憶媒体を提供しようとするものである。

【０００９】

【課題を解決するための手段】この課題を解決するた
め、例えば本発明の映像通信システムは以下の構成を備
える。すなわち、ネットワークを介して映像送信装置か
ら映像受信装置に向けて映像データを送信する映像通信
システムであって、前記映像送信装置は、前記映像受信
装置からの受信状況情報を受信する受信手段と、受信し
た受信状況情報を元に、前記ネットワーク上にあって前
記映像受信装置に到達していないデータ量であるネット
ワークバッファデータ量を算出する算出手段と、前記算
出したネットワークバッファデータ量に基づいて、映像
データの送信レートを決定し、当該決定した送信レート
でもって映像データを前記映像受信装置に向けて送信す
べく前記ネットワーク上に映像データを放出する制御手
段とを備える。

【００１０】

【発明の実施の形態】先ず、実施形態におけるその概念
を簡単に説明する。尚、本実施形態では、リアルタイム
データの転送が望まれる、カメラを有するカメラサーバ
と、そのカメラサーバから転送されてくる映像データを
受信し、表示するクライアント間について説明する。

【００１１】２つの端末間（映像データ発信元であるカ
メラサーバと、受信し表示するクライアント間）でネッ
トワークを通してデータをやりとりする際について考察
すると、ネットワークに送出されたデータで、そのネッ
トワークの途中のノードのバッファに存在し、未だ受信
側に到達していないデータというものが存在する。途中
のノードのバッファに溜まっているデータも伝送遅延の
原因となるため、映像の伝送遅延を最低限に抑えるため
には、このデータ量が大きくなりすぎないように送信レ
ートを制御しなければならない。しかし、ネットワーク
の途中のノードのバッファに溜まっているデータ量は送
受信側の端末では知ることができないことが多い（特に
インターネットのように不特定多数のネットワークが接
続されたようなネットワークなどでは）。そこで、受信
側での受信状況を送信側に伝えることにより、送信側で
送信され受信側に未到着であるデータ量を予測する。映
像フレームの遅延を参照にするためには、新しい映像フ
レームの１パケット目を送出しはじめる時点で、そのネ
ットワーク上のバッファに溜まっているデータ量がゼロ
であればよい。また、ある程度、映像フレームの途中の
パケットを送出している際には、ある程度バッファにデ
ータを溜めて、バッファのオーバーフローが起こらない
範囲で、データを送った方が、利用可能なネットワーク
帯域の使用率が上がると考えられる。

【００１２】そこで、本実施形態では映像の１フレーム
全体を送出し終わった時点でバッファに目標のデータ量
が溜まっているように送信レートを制御することを特徴
とする。そして、そのバッファに溜まったデータがちょ
うど無くなるタイミングに、最新の映像データの送出が
始められるように映像のキャプチャのタイミングを調整
し、最初のパケットの送信を始める。

【００１３】以下、添付図面に従って本発明に係る実施
形態を詳細に説明する。

【００１４】図１は送信側端末１−１が送信するデータ
をネットワーク１−３を通して受信側端末１−２でデー
タを受信する際の構成図である。ここでネットワーク１
−３とは組織内で運営されているＬＡＮから、いわゆる
インターネットのような不特定多数のネットワークが結
合したようなものまで含み、その形態について特定する
ものではない。以下に図１の各端末について説明する。

【００１５】送信側端末（実施形態ではカメラサーバ）
１−１は映像データ生成部１−１１においてデータを生
成する。特に実施形態では送信側端末としてカメラサー
バとする例を説明しているので、データ生成部１−１１
は撮像部（必要であればキャプチャ部を含む）と撮像さ
れた映像データを圧縮符号化する部分を含むことにな
る。データ生成部１−１１は、レート調整部１−１３に
よってフレームを送信し始めるタイミングを指定されそ
のタイミングにちょうど間に合うように、次のフレーム
の映像の取り込を決める。

【００１６】データ生成部１−１１で生成されたデータ
（撮像して得られた圧縮画像データ）はデータ送信部１
−１２に送られる。送られたデータはデータ送信部１−
１２によって適当な大きさに分割され、分割されたデー
タ毎にシーケンス番号がつけられたパケットデータとし
てネットワーク１−３に送出される。この時に、データ
送信部は、分割するデータの大きさや分割したデータを
送り出す間隔を調整することで、送信ビットレートをレ
ート調整部１−１３によって指定されたビットレートに
調整する。

【００１７】一方、受信レポート受信部１−１５は、受
信側端末１−２から送信されてくる受信レポートを受
け、レポートの内容をネットワークバッファデータ量計
算部１−１４に送る。レート調整部１−１３は、ネット
ワークバッファデータ量計算部１−１４において計算さ
れたデータ量及び受信レートに基づいて、フレームの送
信開始タイミング及び送信ビットレートを決定し、映像
データ生成部１−１１にフレームの送信開始タイミング
をデータ送信部１−１２にビットレートを指定する。こ
の映像フレームの送信開始タイミング及び送信ビットレ
ートを決定する方法が実施形態の特徴となるが、これに
ついては後述する。

【００１８】受信側端末（受信した画像データを順次表
示するクライアント）１−２は、ネットワーク１−３を
通して届いたデータを、データ受信部１−２１で受信さ
せる。受信されたデータはデータ処理部１−２２に送ら
れ映像を表示するための処理が行われる。具体的には、
パケットを再構成して、映像フレームにまとめ、圧縮さ
れたデータの解凍（復号）を行う。

【００１９】また、データ受信部１−２１で受け取った
データのシーケンス番号（送信側端末１−１が付加した
情報）、データを受け取った時刻、受け取ったデータ量
などについての情報は受信レポート生成部１−２３に送
られる。受信レポート生成部１−２３はその情報を元に
受信レポートに必要な受信レートを計算し、受信シーケ
ンス番号と受信レートを受信レポート送信部１−２４に
伝える。但し、受信レポート送信部１−２４は１つのパ
ケットを受信するたびにレポートを送信するのではな
く、映像フレームの最後のパケットを受け取る毎に、そ
の時点で最新の受信したパケットに含まれるシーケンス
番号を含む受信レポートをネットワーク１−３を介して
送信側端末１−１の受信レポート受信部１−１４へ送信
する。

【００２０】従って、送信側端末１−１では、送信する
最新のパケットのシーケンス番号と、受信側端末からの
受信レポートに記述されたシーケンス番号との差でもっ
てネットワーク上に停滞しているパケット数を把握でき
ることになる。以後、ネットワーク上のこの未到着のデ
ータの量をットワークバッファデータ量という。尚、受
信側端末から送信側端末に受信レポートが到達するまで
にも時間がかかるので、厳密にはその点についても加味
する必要はある。しかしながら、現実問題としてはそれ
ほどの影響がないことが確かめられたので、本実施形態
でも受信レポートの到達時間は無視して説明する。

【００２１】以下、図２〜図５のフローチャートに従っ
て送受信端末の動作手順、送信レートの決定方法につい
て具体的に説明する。送信側端末の処理は、映像データ
生成部２−１、データ送信部２−２、レート調整部２−
３に分けられ、それぞれが平行して動作しているのでそ
れぞれについて説明する。

【００２２】先ず、映像データ生成部２−１の動作処理
手順を図２のフローチャートに従い説明する。

【００２３】映像データ生成部２−１は、映像キャプチ
ャのためのタイマを設定する（ステップＳ２０１）。こ
の時間は、レート調整部１−１３によって、計算される
映像フレーム送信間隔に応じて決められる。タイマで設
定した時刻がくると（ステップＳ２０２）、映像のキャ
プチャを行う（ステップＳ２０３）。キャプチャした映
像データを圧縮し、パケット化しシーケンス番号などを
つけ送信できるデータに変更して、データ送信部１−１
２にデータを渡す。以後映像データ生成部はステップＳ
２０１〜Ｓ２０５の処理を繰り返す。

【００２４】次に、データ送信部２−２の処理について
図３を用いて説明する。

【００２５】まず、映像データ生成部から渡される送信
データがあるかどうか調べる（ステップＳ２１１）、送
信すべきデータがあった場合、レート調整部から指定さ
れている送信レートを確認する（ステップＳ２１２）。
指定されているビットレートにより、パケットの送出間
隔を求め、前のパケットを送信してから経過した時間を
元に、あとどれだけの時間待てばいいかを計算し、必要
な時間待ったあと１パケットのデータを送信する。以後
データ送信部１−１２は、ステップＳ２１１〜Ｓ２１３
の処理を繰り返す。送信データのフォーマット例として
図６に示す。図示の如く、各送信データには、そのデー
タのシーケンス番号（そのデータを特定する為の情
報）、送信時刻（送信側端末の時刻）、パケットサイ
ズ、そして圧縮符号化された画像データで構成される。

【００２６】次に、レート調整部２−３の処理を図４に
従って説明する。

【００２７】レポート調整部は、受信レポートが来るの
をまって（ステップＳ２２１）、受信レポートが到着す
るごとに、映像フレーム（１画面分の撮像映像データ）
を送信開始するタイミングを決定する計算、及び、送信
ビットレートを決定する計算の処理を行う。受信レポー
トのフォーマット例を図７に示す。受信レポートには、
受信シーケンス番号と受信レート（単位時間当たりの受
信したビット数で後述するＲrecvに相当する）が含まれ
ているものとする。受信時刻情報は本実施形態では特に
用いていないが、例えば送信側端末と受信側端末の時刻
が一致していればより詳しいネットワークデータバッフ
ァ量を知ることができる。さて、受信レポートが到着す
ると（ステップＳ２２１）、そのレポートをもとに、送
信端末からネットワークに送出されたが未だ受信端末に
到着していないデータの量を計算する（ステップＳＳ２
２２）。尚、受信レポートがきた場合に割り込み処理を
行ったり、別タスクで行っているのであれば、必ずしも
その受信のを待つ必要はない。

【００２８】ネットワークバッファデータ量の計算法は
以下の通りである。

【００２９】送信側端末が送出した最後（最新）のパケ
ットのシーケンス番号ＳＥＱsendと受信側端末から受信
レポートによって報告のあった受信シーケンス番号ＳＥ
Ｑrecvの差にパケットサイズＰsizeをかけ、 ＢＵＦcur＝Ｐsize×（ＳＥＱsend−ＳＥＱrecv） のようにして、ネットワークバッファデータ量を求め
る。このようにして求めたネットワークバッファデータ
量が適切に変動する（目標とするバッファ量ＢＵＦdes
に近づくようにする）ため、送信ビットレートおよび映
像フレーム送信開始タイミングを決定するのが、図４の
フローチャートのステップＳ２２３とＳ２２５とに当た
る。

【００３０】まず、これらの計算法について述べる。実
際には図８で示すように１フレームのデータを送信し終
わった時点で、バッファのデータ量が目標値に一致する
ように、映像フレームのデータを送信しはじめる時点で
バッファのデータがゼロになっているように、ネットワ
ークバッファデータ量が推移するように決定する。

【００３１】ここで計算するものとしては、受信レポー
トがあった時点で、現在送信中の映像フレームについて
この後の送信ビットレート、及び、次のフレームの送信
開始タイミングを修正する点、更に、次のフレーム以降
について送信ビットレートとフレーム送信間隔を決定す
ることであるが、まず、次のフレーム以降について送信
ビットレートと映像フレーム送信間隔を求める方法につ
いて説明する。映像フレーム送信間隔ＦＴは受信レポー
ト中の受信レートＲrecvをもとに、 ＦＴ＝ＦｒａｍｅＳｉｚｅ／Ｒrecv と求める。尚、このＦｒａｍｅＳｉｚｅは、撮像して得
られた最新の画像データ（符号化済みデータ）サイズを
示すものであり、一定であるものではない。

【００３２】さて、このＦＴが算出されると、それが映
像データ生成部に伝えられ（ステップＳ２２５）、映像
キャプチャタイマの設定（ステップＳ２０１）に使われ
ることになる。

【００３３】次に送信ビットレートであるが、送信して
いる時間ＳＴ（図８の区間Ｉ）は、 ＳＴ＝（ＦｒａｍｅＳｉｚｅ−ＢＵＦdes）／Ｒrecv と求められる。従って、その間の送信ビットレートＲse
ndは、 Ｒsend＝（Ｒrecv×ＦｒａｍｅＳｉｚｅ）／（Ｆｒａｍ
ｅＳｉｚｅ−ＢＵＦdes） と求めればよい。

【００３４】次に、受信レポートが到着した時点で送信
中のフレームについて、送信レート及び次の映像フレー
ムの送信開始時間の修正のための計算法について説明す
る。このときの計算法は送信側がデータ送信中（図８に
おける区間Ｉ）に受信レポートを受け取るか、データを
送信せず、次のフレームの送信開始を待っている状態
（区間II）にあるかによって異なる。

【００３５】まずデータ送信中（区間Ｉ）に受信レポー
トを受け取った場合について説明する。図９（ａ）のよ
うに、Ｔ３の時点で受信レポートを受け取り、ネットワ
ークバッファ量が黒丸で示した値ＢＵＦcurだったとす
る。このとき、もともとは、図９の点線のようにバッフ
ァ量が推移すると想定して送信レートＲsend及び次のフ
レームの送信を始める時刻が決められている。ここで、
実線のようにバッファ量を推移させるように送信レート
及び次フレームの送信開始タイミングを決める。送信中
の映像フレームのうちまだ送信されないで残っているデ
ータ量をＦｒａｍｅＲｓｔとすると Ｒ２send＝Ｒrecv×ＦｒａｍｅＲｓｔ／｛ＦｒａｍｅＲ
ｓｔ−（ＢＵＦdes−ＢＵＦcur）｝ として、残りの映像フレームのデータの送信レートをＲ
２sendと求める。次のフレームを送信しはじめる時間
は、受信レポートが到着した時点から計って、 ＦＴ２＝（ＦｒａｍｅＲｓｔ＋ＢＵＦcur）／Ｒrecv のようにして求まるＦＴ2だけ経過した時点にすればよ
い。ただし、ＦｒａｍｅＲｓｔ＜Ｂｕｆdes−Ｂｕｆcur
の場合には、上式の計算では送信レートＲ２sendが負の
値になり適当ではない。この場合には、図９（ｂ）の実
線のようにネットワークバッファデータ量が変動するよ
うに決める。この場合の送信レートＲ２sendは予め定め
られている送信可能レートの最大値Ｒmaxとする。この
時、次の映像フレームを送信開始する時刻は、受信レポ
ートが到着した時刻Ｔ３から次のようにして求まるＦＴ
２だけ経過した時刻となる。

【００３６】ＦＴ２＝｛ＢＵＦcur＋（Ｒmax−Ｒrecv）
×ＦｒａｍｅＲｓｔ／Ｒmax｝／Ｒrecv データを送信しないで次のフレームの送信を開始を待機
している状態のとき（区間II）に受信レポートを受け取
った場合、図９（ｃ）の実線のように次のフレームの送
信開始時刻を決める。具体的には、 ＦＴ２＝ＢＵＦcur／Ｒrecv として求める。

【００３７】以上の説明では受信レポートで報告のあっ
た受信レートをそのまま用いることとしたが、過去のデ
ータの数個をもとに平均を求めたり、自己回帰的に求め
たりする手法を用いることも考えられる。

【００３８】尚、図９においてＴ１は１フレームのデー
タの転送が完了した時点を示し、Ｔ２は次フレームの転
送を開始する時点を示している。図示の如く、１フレー
ムの映像データの転送が完了した時点（Ｔ１）では、そ
のネットワークの最大許容バッファ量になるようにし、
次フレームの転送を開始する段階ではそれを最小になる
ようにする。Ｒmaxはネットワークの帯域幅に対して十
分大きな値に設定しておけばよい。

【００３９】図４のフローチャートでの説明に戻ると、
上で説明した。ＲsendとＲ２sendの計算が、ステップＳ
２２３の処理にあたり、その結果が、データ送信部に伝
えられ、それぞれが次フレーム以降及び現在送信中のフ
レームの送信ビットレートを指定する（ステップＳ２２
４）。次に、上で説明したＦＴとＦＴ２が計算される処
理が行われる。これがステップＳ２２５に当たる。そし
てそれが、映像データ生成部２−１に伝えられ（ステッ
プＳ２２６）、映像フレームのキャプチャタイミングの
設定に使われる。この後、レート調整部は、受信レポー
トを待って、ステップＳ２２１〜Ｓ２２６の処理を繰り
返す。

【００４０】次に、受信側端末１−２の処理を図５に従
って説明する。

【００４１】ネットワークを介して送信されてきたデー
タをデータ受信部１−２１で受信する（ステップＳ３０
１）。送られてきたデータは、データ処理部１−２３で
処理される（ステップＳ３０４）。ここでは、映像デー
タが送られてきた場合、それを復号して映像の表示など
を行う。また、データを受信した時刻、データ量、受信
シーケンス番号の情報は、受信レポート生成部１−２４
に送られる。そしてその情報をもとに１フレームの最後
のパケットを受け取るごとに受信レポートが生成される
（ステップＳ３０３）。従って、受信したパケット全て
に対して受信レポートを作成するものでなく、１フレー
ム毎に受信したデータ中の最新のデータのシーケンス番
号及び受信レートの情報を含む受信レポートを生成す
る。生成された受信レポートはネットワークを通して、
送信側端末１−１の受信レポート受信部１−１５へと送
信される（ステップＳ３０３）。受信レポートのフォー
マット例は、先に示したように図７の通りである。

【００４２】以上のようなステップを繰り返し、送受信
端末間でデータの送受信を行いつつ、受信側端末が受信
レポートを定期的に送信し、送信側端末に報告する。

【００４３】一方、送信側端末では受信レポートを基に
ネットワークバッファデータ量が図８のように変化する
ことによって、まず、目標値のバッファ量だけデータを
溜めるように、データを送信するため、十分に使用可能
な伝送帯域を使い、他のデータトラフィックに負けずに
データが送信されることが期待される。また、新しい映
像フレームを送信しはじめる時点では、バッファに溜ま
っているデータをゼロにするため、映像のフレームごと
の遅延を最小に抑えることが期待される。

【００４４】なお、本発明は、上記の実施形態を実現す
るための装置及び方法のみに限定されるものではなく、
上記システムまたは装置、更には汎用のコンピュータ
に、上記実施形態を実現するためのソフトウェアのプロ
グラムコードを供給し、このプログラムコードに従って
上記システムあるいは装置のコンピュータが上記各種デ
バイスを動作させることにより上記実施形態を実現する
場合も本発明の範疇に含まれる。

【００４５】またこの場合、前記ソフトウェアのプログ
ラムコード自体が上記実施形態の機能を実現することに
なり、そのプログラムコード自体、およびそのプログラ
ムコードをコンピュータに供給するための手段、具体的
には上記プログラムコードを格納した記憶媒体は本発明
の範疇に含まれる。

【００４６】このようなプログラムコードを格納する記
憶媒体としては、例えばフロッピーディスク、ハードデ
ィスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、
磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用
いることができる。

【００４７】また、上記コンピュータが、供給されたプ
ログラムコードのみに従って各種デバイスを制御するこ
とにより、上記実施の形態の機能が実現される場合だけ
でなく、上記プログラムコードがコンピュータ上で稼働
しているＯＳ（オペレーティングシステム）、あるいは
他のアプリケーションソフトなどと共同して上記実施形
態が実現される場合にもかかるプログラムコードは発明
の範疇に含まれる。

【００４８】さらに、この供給されたプログラムコード
が、コンピュータの機能拡張ボードやコンピュータに接
続された機能拡張ユニットに備わるメモリに格納された
後、そのプログラムコードの指示に基づいてその機能拡
張ボードや機能拡張ユニットに備わるＣＰＵなどが実際
の処理の一部または全部を行い、その処理によって上記
実施形態が実現される場合も本発明の範疇に含まれる。

【００４９】以上のように本実施形態によれば、送信側
端末からネットワークに送出され未だ受信側端末に到着
していないデータ量（ネットワークバッファ量）を映像
の１フレームを送信し終わった時点では最大バッファ量
の目標値に、また次の映像フレームの送信を開始すると
きには最低値に保つように送信レートを調整する。これ
により、ネットワークの途中の経路にある程度データを
溜めるように送信することにより、使用可能な伝送帯域
を十分に使い切り、且つ映像のフレーム単位では伝送遅
延を最小限に抑えることが期待できる。

【００５０】尚、実施形態では、送信側端末１−１はカ
メラサーバ（カメラを有し、撮影した映像データをクラ
イアントに転送サービス屡する装置）として説明した
が、上記実施形態から理解できるように、必ずしもカメ
ラサーバである必要はなく、例えば予め所定の記憶媒体
に記憶された映像データをクライアントに転送する場合
にも適用できるので、本発明がこれによって限定される
ものではない。

【００５１】

【発明の効果】以上説明したように本発明によれば、ネ
ットワークの伝送帯域を十分に活かして映像データの転
送速度を適宜調整することで映像データを効率良く転送
することが可能になる。

【００５２】

【図面の簡単な説明】

【図１】実施形態における装置のブロック図である。

【図２】実施形態における送信側の映像データ生成部の
動作処理手順を示すフローチャートである。

【図３】実施形態における送信側のデータ沿う深部の動
作処理手順を示すフローチャートである。

【図４】実施形態における送信側のレート調整部の動作
処理手順を示すフローチャートである。

【図５】実施形態における受信側の動作処理内容を示す
フローチャートである。

【図６】実施形態における送信データのフォーマット例
を示す図である。

【図７】実施形態における受信レポートのフォーマット
例を示す図である。

【図８】実施形態における理想的なネットワークバッフ
ァデータ量、送受信レートの変化の様子を表す一例を示
す図である。

【図９】実施形態において、現在送信中の映像フレーム
について、送信レート、次のフレームの送信開始タイミ
ングの決め方を示す図である。

Claims (13)

【特許請求の範囲】
1. 【請求項１】 ネットワークを介して映像送信装置から
   映像受信装置に向けて映像データを送信する映像通信シ
   ステムであって、 前記映像送信装置は、 前記映像受信装置からの受信状況情報を受信する受信手
   段と、 受信した受信状況情報を元に、前記ネットワーク上にあ
   って前記映像受信装置に到達していないデータ量を生成
   する生成手段と、 前記生成したデータ量に基づいて、映像データの前記ネ
   ットワーク上への送出を前記映像データの画面間にする
   制御手段とを備えることを特徴とする映像通信システ
   ム。
2. 【請求項２】 前記映像データは、所定の撮像手段で撮
   像することで得られた動画映像データであることを特徴
   とする請求項第１項に記載の映像通信システム。
3. 【請求項３】 前記制御手段で映像データをネットワー
   クに送出する際、転送しようとする映像データを複数に
   分割し、分割した映像データそれぞれに対して当該映像
   データを特定するためのシーケンス情報を付加したパケ
   ット形式のデータを放出することを特徴とする請求項第
   １項に記載の映像通信システム。
4. 【請求項４】 前記映像受信装置は、所定時間間隔毎
   に、最新の受信データのシーケンス情報と受信レート情
   報を受信状況情報として前記映像送信装置に向けて送信
   する手段を備えることを特徴とする請求項第３項に記載
   の映像通信システム。
5. 【請求項５】 前記制御手段は、 １フレームの映像の途中のパケット形式のデータを転送
   している場合には注目フレームの残りのパケットの送信
   レート、 次のフレームの送信開始タイミング、 次のフレームの送信レートを算出する第２の算出手段を
   備えることを特徴とする請求項第４項に記載の映像通信
   システム。
6. 【請求項６】 前記第２の算出手段で算出する注目フレ
   ームの残りのパケットの転送レートを、ネットワークバ
   ッファデータ量が最大の目標値になるように算出するこ
   とを特徴とする請求項第５項に記載の映像通信システ
   ム。
7. 【請求項７】 前記第２の算出手段は、次のフレームの
   放出する時点で、前記データ量が所定以下になるように
   算出することを特徴とする請求項第５項に記載の映像通
   信システム。
8. 【請求項８】 ネットワークを介して映像受信装置に向
   けて映像データを送信する映像送信装置であって、 前記映像受信装置からの受信状況情報を受信する受信手
   段と、 受信した受信状況情報を元に、前記ネットワーク上にあ
   って前記映像受信装置に到達していないデータ量を生成
   する生成手段と、 前記生成したデータ量に基づいて、映像データの前記ネ
   ットワーク上への送出を前記映像データの画面間にする
   制御手段とを備えることを特徴とする映像送信装置。
9. 【請求項９】 請求項第８項に記載の映像送信装置から
   の映像データを受信する映像受信装置であって、 所定時間毎に、最新の受信データに対する受信状況情報
   を前記映像送信装置に向けて送出する手段を備えること
   を特徴とする映像受信装置。
10. 【請求項１０】 ネットワークを介して映像受信装置に
    向けて映像データを送信する映像送信装置の制御方法で
    あって、 前記映像受信装置からの受信状況情報を受信する受信工
    程と、 受信した受信状況情報を元に、前記ネットワーク上にあ
    って前記映像受信装置に到達していないデータ量を生成
    する生成工程と、 前記生成したデータ量に基づいて、映像データの前記ネ
    ットワーク上への送出を前記映像データの画面間にする
    制御工程とを備えることを特徴とする映像送信装置の制
    御方法。
11. 【請求項１１】 請求項第１０項に記載の映像送信装置
    からの映像データを受信する映像受信装置の制御方法で
    あって、 所定時間毎に、最新の受信データに対する受信状況情報
    を前記映像送信装置に向けて送出する工程を備えること
    を特徴とする映像受信装置の制御方法。
12. 【請求項１２】 コンピュータが読み込み実行すること
    で、ネットワークを介して映像受信装置に向けて映像デ
    ータを送信する映像送信装置として機能するプログラム
    コードを格納した記憶媒体であって、 前記映像受信装置からの受信状況情報を受信する受信工
    程のプログラムコードと、 受信した受信状況情報を元に、前記ネットワーク上にあ
    って前記映像受信装置に到達していないデータ量を生成
    する生成工程のプログラムコードと、 前記生成したデータ量に基づいて、映像データの前記ネ
    ットワーク上への送出を前記映像データの画面間にする
    制御工程のプログラムコードとを格納することを特徴と
    する記憶媒体。
13. 【請求項１３】 コンピュータが読み込み実行すること
    で、請求項第１２項に記載の映像送信装置からの映像デ
    ータを受信する映像受信装置として機能するプログラム
    コードを格納した記憶媒体であって、 所定時間毎に、最新の受信データに対する受信状況情報
    を前記映像送信装置に向けて送出する工程のプログラム
    コードを格納することを特徴とする記憶媒体。