(57)【特許請求の範囲】
【請求項１】
圧縮された映像データを伝送する映像情報伝送方式において、
送信側は、圧縮された映像データをフレーム単位もしくは小領域の符号化単位でパケット化して送出する送出手段と、ネットワークの輻輳情報に基づいてネットワーク輻輳状態を判断し、該判断の結果に従って送出ビットレートを変えて輻輳を回避するように前記送出手段における送出を制御する送出制御手段とを備え、
前記ネットワークの輻輳情報は、少なくともネットワークジッタとパケットロス率を含み、
前記送出制御手段は、第３の閾値が第１の閾値より小さく、第４の閾値が第２の閾値より小さいとしたとき、ネットワークジッタの変動値が第１の閾値以下かつパケットロス率が第２の閾値以下の場合であって、ネットワークジッタの変動値が第３の閾値以下の場合あるいはパケットロス率が第４の閾値以下の場合のみ、輻輳が極めて僅かであり、回復傾向あるいは回復状態にあるとして送出ビットレートの上昇を前記送出手段に指示することを特徴とする映像情報伝送方式。
【請求項２】
前記ネットワークの輻輳情報は、ネットワークを介して外部から入力されることを特徴とする請求項１に記載の映像情報伝送方式。
【請求項３】
前記送出制御手段は、送出ビットレートを時間的に変更することにより前記送出手段における送出を制御することを特徴とする請求項１または２に記載の映像情報伝送方式。
【請求項４】
前記ネットワークの輻輳情報は、受信した前記映像データのパケットからネットワークの輻輳情報を取得する輻輳情報取得手段と、該輻輳情報取得手段で取得されたネットワークの輻輳情報を送出する輻輳情報送出手段とを備えた受信側から送出されることを特徴とする請求項１ないし３のいずれかに記載の映像情報伝送方式。
【請求項５】
前記輻輳情報送出手段は、RFC1889記載のRTCP(RTP ControlProtocol)を用いて前記ネットワークの輻輳情報を送出することを特徴とする請求項４に記載の映像情報伝送方式。
【請求項６】
圧縮された映像データを伝送する映像情報伝送方式において、
送信側は、圧縮された映像データをフレーム単位もしくは小領域の符号化単位でパケット化してデータ送出する送出手段と、ネットワークを介して外部から入力される送出ビットレートに従って前記送出手段における送出ビットレートを変更する送出制御手段とを備え、
受信側は、受信した前記映像データのパケットから少なくともネットワークジッタとパケットロス率を含むネットワークの輻輳情報を取得する輻輳情報取得手段と、前記輻輳情報取得手段により取得されたネットワークの輻輳情報を用いてネットワーク輻輳状態を判断し、該判断の結果に従って送出ビットレートを決定する送出ビットレート決定手段と、前記送出ビットレート決定手段により決定された送出ビットレートを送信側に送出する送出ビットレート送出手段とを備え、
前記送出ビットレート決定手段は、第３の閾値が第１の閾値より小さく、第４の閾値が第２の閾値より小さいとしたとき、ネットワークジッタの変動値が第１の閾値以下かつパケットロス率が第２の閾値以下の場合であって、ネットワークジッタの変動値が第３の閾値以下の場合あるいはパケットロス率が第４の閾値以下の場合のみ、輻輳が極めて僅かであり、回復傾向あるいは回復状態にあると判断して送出ビットレートを大きくすることを特徴とする映像情報伝送方式。
【請求項７】
前記パケットロス率は、一定時間間隔で測定されたものであることを特徴とする請求項１ないし６のいずれかに記載の映像情報伝送方式。
【請求項８】
前記パケットロス率は、送信または受信開始から現時点までの時間間隔で測定されたものであることを特徴とする請求項１ないし６のいずれかに記載の映像情報伝送方式。
【請求項９】
前記送出制御手段は、送出ビットレートを上下させながら輻輳を回避するように前記送出手段における送出を制御することを特徴とする請求項１ないし８のいずれかに記載の映像情報伝送方式。
【請求項１０】
前記ネットワークの輻輳状態の判断の結果は、パケットロス率の度合いを含み、前記パケットロス率の度合いは、それに応じて送出ビットレートの下げ幅を調節するために供されることを特徴とする請求項９に記載の映像情報伝送方式。
【請求項１１】
前記ネットワークの輻輳状態の判断の結果は、ネットワークジッタの変動値の度合いを含み、前記ネットワークジッタの変動値の度合いは、それに応じて送出ビットレートの下げ幅を調節するために供されることを特徴とする請求項９または１０に記載の映像情報伝送方式。
【請求項１２】
前回送出ビットレートが下げられてから一定時間経過後にはじめて送出ビットレートの上昇が指示されて送出ビットレートの安定制御が行われることを特徴とする請求項９ないし１１のいずれかに記載の映像情報伝送方式。
【請求項１３】
圧縮された映像データを伝送する映像情報伝送方式におけるコントロール信号を受信する送信制御タイミング毎に以下のＳ１〜Ｓ４の手順をコンピュータに実行させるためのプログラム。
Ｓ１：少なくともネットワークジッタとパケットロス率を含むネットワークの輻輳情報を入力とし、該ネットワークジッタとパケットロス率をそれぞれ閾値と比較することにより、少なくともネットワークに極度な輻輳が起こっているか、僅かな輻輳が起こっているか、輻輳が極めて僅かであり、回復傾向あるいは回復状態にあるかを判定する手順
Ｓ２：ネットワークに極度な輻輳が起こっていると判定された場合には、第１の割合により送出ビットレートを低下させる手順
Ｓ３：ネットワークに僅かな輻輳が起こっていると判定された場合には、第２の割合により送出ビットレートを低下させる手順
Ｓ４：輻輳が極めて僅かであり、回復傾向あるいは回復状態にあると判定された場合には、送出ビットレートを第３の割合により上昇させる手順。
ここで、Ｓ１では、第３の閾値が第１の閾値より小さく、第４の閾値が第２の閾値より小さいとしたとき、ネットワークジッタの変動値が第１の閾値以下かつパケットロス率が第２の閾値以下の場合であって、ネットワークジッタの変動値が第３の閾値以下の場合あるいはパケットロス率が第４の閾値以下の場合のみ、輻輳が極めて僅かであり、回復傾向あるいは回復状態にある判定する。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、映像情報伝送方式およびプログラムに関し、特に、QoS（quality of service）非保証のネットワーク上で輻輳制御することにより、映像品質の劣化を抑えながら効率的にライブ映像などの映像情報をリアルタイム伝送する映像情報伝送方式およびプログラムに関する。
【０００２】
【従来の技術】
インターネットを始めとするQoS非保証のIPネットワークでは、伝送帯域や伝送エラーレート、ジッタなどが時間とともに変動するため、映像や音声情報のような連続メディアを圧縮伝送して連続再生する場合、品質劣化が生じてしまいスムーズな再生が困難な場合が多い。
【０００３】
図１４は、従来の映像情報伝送装置を示す機能ブロック図である。同図において、送信側では、カメラ141から入力した映像情報をリアルタイムエンコーダ142において固定の送出ビットレートで逐次圧縮処理し、送信制御部143においてパケッタイズした後、IPネットワーク140に送出する。
【０００４】
一方、受信側では、ネットワーク140からのパケットを受信制御部144でリアルタイム受信し、パケットのリアセンブルを行った後、リアルタイムデコーダ145においてデコードし、再生表示部146において再生表示する。
【０００５】
この場合、ネットワーク140の状態が変化し、その帯域が減少した場合でも送信側は、その帯域以上の固定の送出ビットレートでデータを伝送し続けるため、ネットワークの輻輳を招き、パケット伝播遅延の増大およびパケットロス誘発により受信側での再生品質の劣化が顕著に現れるという問題点がある。
【０００６】
この問題点に対し、受信側でのパケットロス率がある閾値を越えた場合、その越えた割合に応じて送出ビットレートを低下させる対処方法が、「J.C.Bolt, T.Turletti,“Scalable feedback control for multicast video distribution in the Internet”, ACM Proc. Sigcomm, pp.58-67, London, UK, Sept. 1994.」や 「I.Busse, B.Deffner, H.Schulzrinne,“Dynamic QoS Control of Multimedia Application based on RTP”, ACM Computer Communications, Jun.1996.」に記載されている。しかしながら、この対処方法ではパケットロスが発生して再生品質劣化が起こるまで送出ビットレートの制御が行われないという問題点がある。さらに、パケットロスの原因がネットワーク上のゲートウェイにおけるバッファ溢れにある場合、この対処方法ではネットワーク上のバッファが一杯になるまで送出ビットレートを上昇させてしまうため、ネットワークバッファのサイズ分だけ必ず遅延が発生してしまうという問題点もある。
【０００７】
また、ネットワークスイッチのキュー長をフィードバックして伝送遅延の増減を予測し、輻輳制御する対処方法が、「H.Kanakia, P.Mishra, A. Reibman, “An adaptive congestion control scheme for real-time packet video transport”, ACM Proc. Sigcomm, pp.20-31, Sep. 1993.」に記載されている。しかしながら、この対処方法では各ネットワークスイッチがキュー長情報をフィードバックする仕組みが必要となり、実装が複雑になるばかりか、IETFのRFC1889で標準化されているRTP(real-time transport protocol)／RTCP(RTP control protocol)といった標準プロトコルを用いて実現することができないという問題点がある。
【０００８】
さらに、ネットワークバッファ値を目標値に近づけることにより輻輳制御ならびに伝送遅延の固定化を行う対処方法が、「矢野他、“連続メディアのリアルタイム転送に適したラウンドトリップ時間に基づくレート制御法”、IN98-23, CS98-23, MVE98-23, pp.85-90, Apr. 1998」に記載されている。しかしながら、この対処方法では、目標バッファ値の最適な設定が困難であるばかりか、ネットワークの帯域が変動する度ごとに目標バッファ値を設定し直す必要がある。また、仮に目標バッファ値を固定して制御を行った場合、例えば帯域が半分になった場合には、遅延は２倍に増加してしまうという問題点がある。
【０００９】
【発明が解決しようとする課題】
本発明は、前記した従来技術の問題点を解決するものであり、ネットワークの輻輳状態を、例えば、映像情報の受信状況をモニタすることにより判定し、この判定結果に基づいて送信側における映像情報の送出を制御することにより、QoSの保証されないネットワークでもライブ映像などのリアルタイム圧縮映像情報をスムーズかつ高品質で伝送および再生することができる映像情報伝送方式およびプログラムを提供することを目的とするものである。
【００１０】
【課題を解決するための手段】
本発明は前記課題を達成するために、圧縮された映像データを伝送する映像情報伝送方式において、送信側が、圧縮された映像データをフレーム単位もしくは小領域の符号化単位でパケット化して送出する送出手段と、ネットワークの輻輳情報に基づいてネットワーク輻輳状態を判断し、該判断の結果に従って送出ビットレートを変えて輻輳を回避するように前記送出手段における送出を制御する送出制御手段とを備え、前記ネットワークの輻輳情報は、少なくともネットワークジッタとパケットロス率を含み、前記送出制御手段は、第３の閾値が第１の閾値より小さく、第４の閾値が第２の閾値より小さいとしたとき、ネットワークジッタの変動値が第１の閾値以下かつパケットロス率が第２の閾値以下の場合であって、ネットワークジッタの変動値が第３の閾値以下の場合あるいはパケットロス率が第４の閾値以下の場合のみ、輻輳が極めて僅かであり、回復傾向あるいは回復状態にあるとして送出ビットレートの上昇を前記送出手段に指示する点に第１の特徴がある。
【００１１】
また、本発明は、前記ネットワークの輻輳情報が、ネットワークを介して外部から入力される点に第２の特徴がある。
【００１２】
また、本発明は、前記送出制御手段が、送出ビットレートを時間的に変更することにより前記送出手段における送出を制御する点に第３の特徴がある。
【００１３】
また、本発明は、前記ネットワークの輻輳情報が、受信した前記映像データのパケットからネットワークの輻輳情報を取得する輻輳情報取得手段と、該輻輳情報取得手段で取得されたネットワークの輻輳情報を送出する輻輳情報送出手段とを備えた受信側から送出される点に第４の特徴がある。
【００１４】
また、本発明は、前記輻輳情報送出手段が、RFC1889記載のRTCP(RTP Control Protocol)を用いて前記ネットワークの輻輳情報を送出する点に第５の特徴がある。
【００１５】
また、本発明は、圧縮された映像データを伝送する映像情報伝送方式において、送信側が、圧縮された映像データをフレーム単位もしくは小領域の符号化単位でパケット化してデータ送出する送出手段と、ネットワークを介して外部から入力される送出ビットレートに従って前記送出手段における送出ビットレートを変更する送出制御手段とを備え、受信側が、受信した前記映像データのパケットから少なくともネットワークジッタとパケットロス率を含むネットワークの輻輳情報を取得する輻輳情報取得手段と、前記輻輳情報取得手段により取得されたネットワークの輻輳情報を用いてネットワーク輻輳状態を判断し、該判断の結果に従って送出ビットレートを決定する送出ビットレート決定手段と、前記送出ビットレート決定手段により決定された送出ビットレートを送信側に送出する送出ビットレート送出手段とを備え、前記送出ビットレート決定手段は、第３の閾値が第１の閾値より小さく、第４の閾値が第２の閾値より小さいとしたとき、ネットワークジッタの変動値が第１の閾値以下かつパケットロス率が第２の閾値以下の場合であって、ネットワークジッタの変動値が第３の閾値以下の場合あるいはパケットロス率が第４の閾値以下の場合のみ、輻輳が極めて僅かであり、回復傾向あるいは回復状態にあると判断して送出ビットレートを大きくする点に第６の特徴がある。
【００１９】
また、本発明は、前記パケットロス率が、一定時間間隔で測定される点に第７の特徴がある。
【００２０】
また、本発明は、前記パケットロス率が、送信または受信開始から現時点までの時間間隔で測定される点に第８の特徴がある。
【００２１】
また、本発明は、前記送出制御手段が、送出ビットレートを上下させながら輻輳を回避するように前記送出手段における送出を制御する点に第９の特徴がある。
【００２２】
また、本発明は、前記ネットワークの輻輳状態の判断の結果が、パケットロス率の度合いを含み、前記パケットロス率の度合いは、それに応じて送出ビットレートの下げ幅を調節するために供される点に第１０の特徴がある。
【００２３】
また、本発明は、前記ネットワークの輻輳状態の判断の結果が、ネットワークジッタの変動値の度合いを含み、前記ネットワークジッタの変動値の度合いは、それに応じて送出ビットレートの下げ幅を調節するために供される点に第１１の特徴がある。
【００２５】
また、本発明は、前回送出ビットレートが下げられてから一定時間経過後にはじめて送出ビットレートの上昇が指示されて送出ビットレートの安定制御が行われる点に第１２の特徴がある。
【００２６】
さらに、本発明は、少なくともネットワークジッタとパケットロス率を含むネットワークの輻輳情報を入力とし、該ネットワークジッタとパケットロス率をそれぞれ閾値と比較することにより、少なくともネットワークに極度な輻輳が起こっているか、僅かな輻輳が起こっているか、回復傾向あるいは回復状態にあるかを判定する手順と、ネットワークに極度な輻輳が起こっていると判定された場合には、第１の割合により送出ビットレートを低下させる手順と、ネットワークに僅かな輻輳が起こっていると判定された場合には、第２の割合により送出ビットレートを低下させる手順と、ネットワークが輻輳状態から回復傾向あるいは回復状態にあると判定された場合には、送出ビットレートを第３の割合により上昇させる手順とを、映像情報伝送方式におけるコントロール信号を受信する送信制御タイミング毎にコンピュータに実行させるためのプログラムであって、第３の閾値が第１の閾値より小さく、第４の閾値が第２の閾値より小さいとしたとき、ネットワークジッタの変動値が第１の閾値以下かつパケットロス率が第２の閾値以下の場合であって、ネットワークジッタの変動値が第３の閾値以下の場合あるいはパケットロス率が第４の閾値以下の場合のみ、輻輳が極めて僅かであり、回復傾向あるいは回復状態にある判定する点に第１３の特徴がある。
【００２７】
第１ないし第１３の特徴によれば、ネットワークの輻輳状態に応じて映像情報の送出を制御することができ、QoSの保証されないネットワークでもライブ映像などのリアルタイム圧縮映像情報をスムーズかつ高品質で伝送および再生することができる。
また、ネットワークの輻輳が回復傾向あるいは回復状態にある場合を適切に判断し、この場合に送出ビットレートを上昇させて映像情報を効率的に伝送することができる。
【００２８】
また、第５の特徴によれば、インターネット標準によりネットワークの輻輳情報を送出することができる。
【００２９】
また、第６の特徴によれば、受信側で送出ビットレートを決定して送信側にフィードバックするので、各種輻輳情報をフィードバックする場合に比較してフィードバックする情報量を減らすことができ、ネットワークを有効に利用することができる。
【００３２】
また、第１２の特徴によれば、スロースタート制御により輻輳状態の再来や伝送ビットレートの大幅な振動を防止することができる。
【００３３】
さらに、第１３の特徴によれば、コンピュータへのプログラムのインストールにより容易に映像情報の伝送制御を行うことができる。
【００３４】
【発明の実施の形態】
以下、図面を参照して本発明を詳細に説明する。
図１は、本発明の一実施態様を示す機能ブロック図であり、図示都合上、Ａ点を境にして（ａ）、（ｂ）に分割して示している。同図（ａ）の送信側において、カメラ11から入力された映像情報は、リアルタイムエンコーダ12において送信制御部13により指定された送出ビットレートでリアルタイムエンコードされる。リアルタイムエンコーダ12における送出ビットレートは、送信制御部13からのビットレートフィードバック情報により指定される。リアルタイムエンコーダ12により送出ビットレートで符号化されて圧縮された映像データは、送信制御部13においてパケットロス時でもその位置から再同期復号可能なフレーム単位もしくはスライス単位でパケッタイズされた後、ネットワーク10に送出される。
【００３５】
この送出のデータフォーマットは、送信したパケットの順序ならびに再生タイミングが受信側で分かるようにパケット毎にシリアル番号が付与され、そのパケットに含まれるデータの再生タイミングを表すタイムスタンプも同様に付与されたものとなっている。各送出パケットにシリアル番号ならびにタイムスタンプを格納したフォーマットの一例として、図２に示すRFC1889準拠のRTP(Real-time Transport Protocol)データフォーマットが挙げられ、送信制御部13より、例えばこのフォーマットに従った映像データパケットが送出される。なお、図２の「シーケンス番号」がシリアル番号に相当するものである。
【００３６】
ネットワーク10により伝送された映像データパケットは、図１（ｂ）の受信側の受信制御部14により受信される。受信制御部14において、受信した映像データパケットに格納されているシリアル番号に基づいて映像データパケットのロスや到着順序入替り、重複受信などのイレギュラーな映像データパケットの受信状況が検出される。また、再生タイミングを表すタイムスタンプに基づいて受信された映像データパケットが再生時刻に間に合っているかどうかの判定が行われ、間に合っていないと判定された場合には該映像データパケットはロスと見なされて捨てられる。
【００３７】
再生時刻に間に合ったと判定された映像データパケットからは、そのペイロード内に格納されている映像データが取り出される。この映像データは、タイムスタンプと共にリアルタイムデコーダ15に渡されてリアルタイムでデコードされた後、タイムスタンプに従って再生表示部16において再生表示される。なお、ロスおよびロスとみなされたパケットの映像データは、再生表示部16においてフレーム間補間もしくはフレーム内補間により生成され、この生成された映像データがシーケンス番号の並びから予測された表示タイミングで再生表示される。
【００３８】
受信側において受信されたパケットが再生時刻に間に合っているかどうかの具体的な判定手法の一例を以下に示す。まず、下記（１）式により、受信された映像データパケットの再生時刻{PT0, PT1, PT2, PT3, ・・・, PTn}を求める。これは、受信された映像データパケットに付与されているタイムスタンプ{TS0, TS1, TS2, TS3, ・・・, TSn}を、最初に到着した映像データパケットのタイムスタンプ値を基準時刻0[ms]として換算することを意味する。
【００３９】
次に、下記（２）式により、映像データパケットが受信された時点のローカルクロックによる受信時刻{CKRT0, CKRT1, CKRT2, CKRT3, ・・・, CKRTn}を、最初に到着したパケットの受信時刻を基準時刻0[ms]として換算した受信時刻{RT0, RT1, RT2, RT3, ・・・, RTn}を求め、続いて、下記（３）式により（１）式および（２）式で求めた時刻の差PRDIFFk｛k=0,1,2,・・,n｝を求める。
【００４０】
これら時刻の差PRDIFFk｛k=0,1,2,・・,n｝が0以上であれば、受信された映像データパケットは再生時刻に間に合っていると判定され、一方、0未満（マイナス値）であれば間に合っていないと判定される。なお、受信された映像データパケットは、再生時刻に間に合っていると判定された場合には、その後の復号および再生処理に渡され、間に合っていないと判定された場合には、パケットロスとみなされて復号および再生処理には渡されない。上記説明したTSk，CKRTk，PTk，RTkの関係を図３に示す。
【００４１】
PTk = TSk - TS0  ｛k=0,1,2,・・,n｝      ・・・（１）
RTk = CKRTk - CKRT0  ｛k=0,1,2,・・,n｝  ・・・（２）
PRDIFFk = PTk - RTk  ｛k=0,1,2,・・,n｝  ・・・（３）
【００４２】
ここまでは映像情報の圧縮伝送および受信再生について説明したが、送信制御部13からは、映像データパケット以外に、ネットワークの品質パラメータを測定し輻輳状態を判定するために、コントロール信号SR（Sender Report）パケット（以下、SRパケットという。）が送出される。このSRパケットは、送信制御部13から図１（ｂ）の受信側の受信制御部14に対して定期的に送出される。
【００４３】
SRパケットのフォーマット中には送信した時の時刻情報（送信タイムスタンプ）が含まれており、このフォーマットとしては、例えば、例えば、図４に示すRFC1889準拠のSR：Sender report RTCP Packetのデータフォーマットを用いることができる。
【００４４】
また、受信制御部14からも送信制御部13に対してコントロール信号RR（Receiver Report）パケット（以下、RRパケットという。）が定期的に送出される。このRRパケットのフォーマット中には、それまで受信されたSRパケットの中で最新のSRパケット中に含まれていた送信タイムスタンプ情報および受信側がSRパケットを受信してからRRパケットを送信するまでの経過時間情報が格納される。RRパケットのフォーマットとしては、例えば、図５に示すRFC1889準拠RTCP(RTP Control Protocol)のRRフォーマットを用いることができる。
【００４５】
RRパケットを受信した送信制御部13において、コントロール信号パケット（SRパケット、RRパケット）の往復伝播遅延（ラウンドトリップタイム）を下記（４）式により求めることができる。
【００４６】
Trnd = (Trcv - Tsnd) - Tstay    ・・・（４）
ここで、
Trnd：コントロール信号パケットの往復伝播遅延
Trcv：送信制御部が最新のRRパケットを受信した時刻
Tsnd：送信制御部が最新のSRパケットを送信した時刻（RRパケットに格納されている送信タイムスタンプ情報）
Tstay：受信制御部が最新のSRパケットを受信してからSRパケットを送信するまでの時間（RRパケットに格納されている経過時間情報）
である。
【００４７】
また、RRパケットのフォーマット中には、受信制御部14で受信された映像データパケットに関するパケットロス率と伝播遅延のゆらぎを表すジッタ情報などのネットワークの輻輳情報も格納される。ｎ番目に伝送されるRRパケットに含まれるパケットロス率およびジッタは、受信制御部14において、例えば、下記（５）、（６）および（７）式により求めることができる。
【００４８】
PLRn = TRUNC (Nloss-n / Nrcv-n * 256)        ・・・（５）
Jn = Jn-1 + (|D| - J n-1)/16                 ・・・（６）
D = (CKRTk - TSk) - (CKRTk-1 - TSk-1)        ・・・（７）
ここで、
PLR：映像データパケットのパケットロス率
TRUNC：少数点以下を切り捨てることを意味する
Nloss：前回RRパケットを送出してから今回RRパケットを送出するまでの間の映像データパケットロス数
Nrcv：前回RRパケットを送出してから今回RRパケットを送出するまでの間に受信した全映像データパケット数
Jn：ｎ番目のジッタ
Jn-1：ｎ−１番目のジッタ
D：映像データパケットの伝播遅延の差
CKRTk：最後に受信された映像データパケットの受信時刻
TSk：最後に受信された映像データパケットに含まれているタイムスタンプ（送信時刻に相当）
CKRTk-1：最後から１つ前に受信された映像データパケットの受信時刻
TSk-1：最後から１つ前に受信された映像データパケットに含まれているタイムスタンプ（送信時刻に相当）
である。
【００４９】
なお、パケットロス率PLRは、NlossとNrcvの代わりに伝送開始時から現在までの積算の映像データパケットロス数と受信された全映像データパケット数を用いて求めることもできる。
【００５０】
受信側の受信制御部14から送出されたRRパケットを受信した送信制御部13は、その中に格納されているパケットロス率と伝播遅延のゆらぎを表すジッタ情報に基づいてネットワークの輻輳状態を判定し、この判断結果を用いて輻輳回避のための送出ビットレートを決定する。この送出ビットレートは、ビットレートフィードバック情報としてリアルタイムエンコーダ12にフィードバックされ、リアルタイムエンコーダ12での符号化ビットレートが制御される。
【００５１】
次に、パケットロス率と伝播遅延のゆらぎを表すジッタ情報に基づくネットワークの輻輳状態の判定およびこの判定結果による輻輳回避のための送出ビットレートの決定について具体的に説明する。
【００５２】
まず、ネットワークの伝送帯域が変化した場合にジッタ、ジッタの差分絶対値、パケットロス率にどのような推移がみられるかの予備実験の結果を図６に示す。図６より、受信時刻(ReceiveTime)が全体の３/４程度のところで、伝送帯域（BnadWidth）が送出ビットレート(EncodeRate)を下回ると、それまで０で推移していたパケットロス率(PacketLossRate)が大幅に増加していることが分かる。これは、極度な輻輳状態に陥っていると考えられる。
【００５３】
そしてパケットロス率が増加し始める手前でジッタ（Jitter）、ジッタの差分絶対値（JitterDiff）の値が増大しているのが分かる。これは、ネットワーク上のルータ内などに存在するキューが一杯に近づき映像データパケットの伝播遅延が増大しつつあることを示しており、パケットロスが発生する手前の中程度の輻輳状態と考えられる。
【００５４】
この予備実験の結果は、パケットロス率とジッタの差分絶対値とを用いてネットワークが現在どの状態にあるのかを判定することができることを示しており、本例では、この判定によりネットワークの輻輳状態を以下のようにCase1からCase５までモデル化し、送出ビットレートを決定している。なお、ここでジッタの差分絶対値を用いたのは、ジッタに比べて閾値設定が容易になるためである。
Case１：極度の輻輳が起こっている場合
Case２：中程度の輻輳が起こっている場合
Case３：僅かな輻輳が起こっている場合
Case４：輻輳が極めて僅かであり、回復傾向にある場合
Case５：輻輳を回避した場合
【００５５】
図７は、ネットワークの輻輳状態の判定と送出ビットレート（伝送ビットレート）の決定を含む送信制御アルゴリズムを示すフローチャートである。なお、図７で用いている各種パラメータの意味内容を図８に示している。
【００５６】
まず、S19において、設定可能なビットレートのMIN／MAX値などのパラメータ初期値の設定を行う。次にS20においてパケットロス率を閾値εと比較し、極度の輻輳が起こっているかどうかの判定を行う。この判定がNoの場合、次の判定S21に遷移し、Yes（Case1）の場合には、Ｓ25において現在の伝送ビットレートrateをパケットロス率に応じて下げる。なお、この際、伝送ビットレートrateが極端に下がらないように限度rate_minを設けている。以下のS26、S27でも同様である。また、state_congパラメータに１を代入すると同時に極度な輻輳の後すぐにレートを上げないようにヒステリシスパラメータkeep_countに、例えば10〜20程度の値Ｎを代入してS24において次の制御タイミングを待つ。
【００５７】
Case1にあてはまらなかった場合（S20での判定がNoの場合）には、S21においてジッタ差分絶対値を閾値βと比較し、中程度の輻輳が起こっているかどうかの判定を行う。この判定がNoの場合、次の判定S22に遷移し、Yes（Case2）の場合には、S26において伝送ビットレートrateをパラメータBで指定される値で除することにより下げ、state_congパラメータに１を代入してS24において次の制御タイミングを待つ。
【００５８】
Case２にあてはまらなかった場合（S21での判定がNoの場合）には、S22においてジッタ差分絶対値を閾値α（＜β）と比較し、僅かな輻輳が起こっているかどうかの判定を行う。この判定がNoの場合、次の判定S23に遷移し、Yes（Case３）の場合には、S27において伝送ビットレートrateをパラメータA（＜B）で指定される値で除することにより下げ、state_congパラメータに１を代入してS24において次の制御タイミングを待つ。
【００５９】
Case3にあてはまらなかった場合（S22での判定がNoの場合）には、S23においてジッタ差分絶対値と閾値α／２とを比較し、また、パケットロス率と閾値δとの比較を行う、この比較においてジッタ差分絶対値が閾値α／２より小さい、あるいはパケットロス率が閾値δより小さい場合（Yes）には、輻輳が極めて僅か、あるいは回避されたと判定できる。この判定がNoの場合、どちらとも言えない場合と判定してS24に遷移して次の制御タイミングを待つ。
【００６０】
Yesの場合には、S28 のkeep_count値の判定に遷移する。この判定において、Keep_countを１マイナスした後の値が0より大きい場合には、伝送ビットレートを上げるのをやめS24に遷移して次の制御タイミングを待つ。このループは、輻輳が極めて僅か、あるいは回避されたとしてもＮの値に応じた一定時間は送出ビットレートをそのまま保つためのものである。また、0以下の場合には、S29において前回輻輳していたかの判定をstate_congを用いて行う。
【００６１】
この判定がYesの場合（Case４）には、S30において伝送ビットレートrateを前回輻輳時の伝送ビットレートと現在の伝送ビットレートの中間値に設定した後、state_congに0を代入し、S24に遷移して次の制御タイミングを待つ。なお、この際、伝送ビットレートrateが極端に上がらないように限度rate_maxを設けている。以下のS31でも同様である。
【００６２】
S29での判定がYESの場合（Case５）には、S31において伝送ビットレートrateをｂ倍し、S24に遷移して次の制御タイミングを待つ。この時点で初めて前回輻輳時の伝送ビットレートを越えた設定の可能性を与えている。すなわち、伝送ビットレートを上昇させる際、TCP制御でも用いられているスロースタート制御を用いて輻輳状態の再来や伝送ビットレートの大幅な振動を防止するようにしている。
【００６３】
また、本例のように、極度の輻輳が起こっている場合、伝送ビットレートをパケットロス率に応じて下げ、それ以下の輻輳が起こっている場合には伝送ビットパラメータを固定のパラメータに応じて下げることにより、迅速にかつ安定に送出ビットレートを変更して輻輳を回避することができる。なお、ネットワークジッタの変動値に応じて伝送ビットレートを下げるようにすることもできる。また、上記フローチャートにおける送信制御タイミングは、定期的に受信側から伝送されてくるRRパケットを送信側が受け取るタイミングとすることができる。
【００６４】
上記フローチャートに従った判定によりネットワークの輻輳状態Case1〜Case5が取り得る範囲をパケットロス率ΔLossRateとジッタ差分絶対値Jitterdiffの２次元グラフにおいて図示したのが図９である。同図から明らかなように、ネットワークジッタの変動値がα以下かつパケットロス率がε以下の場合であって、ネットワークジッタの変動値がα／２以下あるいはパケットロス率がδ以下の場合に送出ビットレートの上昇が可能となる。
【００６５】
図１０は、本発明で使用できるリアルタイムエンコーダの一例を示す機能ブロック図であり、この例は、MPEGエンコーダを示している。以下、このリアルタイムエンコーダの動作の概略を説明する。
【００６６】
まず、入力された映像情報の最初のフレームを含むイントラ符号化フレームをDCT部17において離散コサイン変換する。続いて、量子化部18においてレート制御部25により指定される量子化スケールファクタで量子化（情報量削減）し、VLC部19で可変長符号化した後、圧縮映像出力ストリームとして出力する。また、量子化部18で量子化した後のイントラ符号化フレームの映像データを、逆量子化部20、逆DCT部21において逆量子化および離散コサイン逆変換した後、フレームメモリ22に格納する。
【００６７】
続いて入力される映像情報の順方向予測フレームおよび両方向予測フレームについては、動き推定部24において動き予測を行い、その結果算出された動きベクトルを動き補償部23に与え、フレームメモリ22に保存されている画像、すなわち参照画像を動き補償し、この動き補償された参照画像と原画像との差分を減算器で求め、差分画像を得る。この差分画像をDCT部17で離散コサイン変換し、量子化部18においてレート制御部25により指定される量子化スケールファクタで量子化し、VLC部19で動き情報とともに可変長符号化した後、圧縮映像出力ストリームとして出力する。
【００６８】
ここで、順方向予測フレームは、参照画像として使われるため、量子化した後のデータを、逆量子化部19、逆DCT部21で逆量子化および離散コサイン逆変換した後、差分画像生成時に用いた参照画像の動き補償後のフレームデータを足し込んでフレームデータを再構築し、フレームメモリ22に保存する。
【００６９】
通常の伝送を前提にした符号化時には、固定ビットレート（CBR）符号化が用いられるため、レート制御部25では、同一ビットレートをターゲットとしてレート制御を行うが、本発明は、このビットレートをネットワークの輻輳状態に合わせてダイナミックに変更するものであるため、レート制御部25は、送信制御部13からの、ネットワークの輻輳状態に応じたビットレート変更指示に従いターゲットとなるビットレートを変更し、それに合わせた送出ビットレート制御を行う。
【００７０】
以上説明した実施態様においては、送信側より圧縮され、パケット化された映像データおよびコントロール信号がネットワークに送出され、受信側は、ネットワークから受信した映像データおよびコントロール信号を元にパケットロス率やジッタなどのネットワークの輻輳情報を取得し、このネットワークの輻輳情報を送信側にフィードバックする。送信側では、フィードバックされたネットワークの輻輳情報に基づいてネットワークの輻輳状態を判定し、送出ビットレートを決定する。このようにして送出ビットレートがネットワークの輻輳状態に応じてダイナミックに設定されるので、ネットワークの伝送帯域や伝送エラーレート、ジッタなどが時間とともに変動しても、常にスムーズかつ高品質で映像情報の伝送が行われる。
【００７１】
次に、本発明の他の実施態様について説明する。上記実施態様は、受信側よりフィードバックされたネットワークの輻輳情報に基づいて送信側でその輻輳状態を判定し、送出ビットレートを決定していたが、本実施態様は、ネットワークの輻輳状態の判定ならびに送出ビットレートの決定を受信側で行い、受信側で決定された送出ビットレートを変更ビットレート値として送信側にフィードバックするものである。なお、ビットレート値に変更がない場合にはフィードバックする必要はない。
【００７２】
全体システムの構成およびの輻輳状態の判定ならびに送出ビットレートの決定については上記実施態様と同様であるので、詳細な説明は省略するが、輻輳状態の判定および送出ビットレートの決定は、図１の受信制御部14において行われ、ここで決定された送出ビットレートが送信側にフィードバックされる。  なお、受信側で決定された送出ビットレートを送信側にフィードバックする必要があるため、RRパケットのフォーマット中に送出ビットレートを格納する領域を設ける必要がある。このフォーマットとしては、例えば、図１１に示すデータフォーマットを用いることができ、本フォーマットでは、送出ビットレートを格納する32ビットのSending Bitrate Requested (SBR)エリアを設けている。
【００７３】
本実施形態によれば、ネットワークの輻輳情報に基づいて受信側において決定した送出ビットレートを送信側にフィードバックすればよいので、ネットワークの各種輻輳情報を伝送する上記実施形態に比較して伝送する情報量を減らすことができ、ネットワークの有効利用を図ることができる。
【００７４】
本発明における送出制御部13での輻輳状態の判定と送出ビットレートの決定の手順を、コンピュータに実行させるためのプログラムとしても構成することができる。このプログラムは、定期的なコントロール信号を受信する送信制御タイミング毎に以下の手順をコンピュータに実行させるためのものである。
（Ｓ１）入力されたネットワークの輻輳情報を閾値と比較し、少なくともネットワークに極度な輻輳が起こっているか、僅かな輻輳が起こっているか、輻輳が極めて僅かであり、回復傾向あるいは回復状態にあるかを判定する手順
（Ｓ２）ネットワークに極度な輻輳が起こっていると判定された場合には、第１の割合により送出ビットレートを低下させる手順
（Ｓ３）ネットワークに僅かな輻輳が起こっていると判定された場合には、第２の割合により送出ビットレートを低下させる手順
（Ｓ４）輻輳が極めて僅かであり、回復傾向あるいは回復状態にあると判定された場合には、送出ビットレートを第３の割合により上昇させる手順
【００７５】
コンピュータに以上のような手順を実行させる伝送制御プログラムを、例えば、図１２に示すコンピュータ読み取り可能な記録媒体300に記録し、この記録媒体300に記録された伝送制御プログラムを同図に示すコンピュータ200に読み込ませ、実行するようにすることができる。
【００７６】
コンピュータ200は、読み込んだ伝送制御プログラムを実行するCPU201と、キーボード、マウス等の入力装置202と、各種データを記憶するROM(Read Only Memory)203と、演算パラメータ等を記憶するRAM(Random Access Memory)204と、記憶媒体300から伝送プログラムを読み取る読取装置205と、ディスプレイ、プリンタ等の出力装置206と、装置各部を接続するバスBUSとから構成されている。
【００７７】
CPU201は、読取装置205を経由して記録媒体300に記録されている送出制御プログラムを読み込んだ後、この送出制御プログラムを実行することにより送出制御処理を行う。記録媒体300には、光ディスク、ＦＤ、ハードディスク等の可搬型の記録媒体が含まれることはもとより、ネットワークのようにデータを一時的に記録保持するような伝送媒体も含まれる。
【００７８】
以上、本発明の実施形態について説明したが、具体的な構成は、これら実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等があっても本発明に含まれる。例えば、上記実施態様では、ネットワークジッタの変動値としてジッタの差分絶対値を用いたが、現在のジッタあるいは現在のジッタを含めた複数のジッタの平均値とジッタの最小値との差分値をネットワークジッタの変動値として用いてもよい結果が得られ、そのようなものも本発明のネットワークジッタの変動値に含まれる。
【００７９】
また、請求項に記載された送信側の装置と受信側の装置とは、種々に組み合わせて映像情報伝送方式を構成することができる。
【００８０】
【発明の効果】
以上の説明から明らかなように、本発明によれば、リアルタイムで受信する映像データパケットおよびコントロール信号からパケットロス、ジッタなどのネットワークの輻輳情報を取得し、それら輻輳情報からネットワークの輻輳状態を判定し、この判定結果に基づいて送出ビットレートをダイナミックに制御することにより、QoSが保証されないネットワークでもスムーズかつ高品質で映像情報のリアルタイム伝送が可能となる。
【００８１】
図１３に本発明による伝送シミュレーション結果を示す。ネットワークの伝送帯域が変化した場合でもパケットロスを最小限に抑えつつその伝送帯域が十分有効に使われるように送出ビットレートが制御され、結果として効率良く、スムーズかつ高品質に映像情報の伝送が可能になることが分かる。
【００８２】
本発明は、映像情報をリアルタイムで圧縮伝送するMPEG伝送システム、双方向映像伝送システム、TV会議システム、ビデオチャットシステム、映像中継システムなどに応用可能である。
【図面の簡単な説明】
【図１】  本発明の一実施態様を示す機能ブロック図である。
【図２】  本発明で用いられるデータフォーマットの一例を示す図である。
【図３】  映像データパケットの受信時刻と再生時刻との関係を説明するための説明図である。
【図４】  本発明で用いられるSRフォーマットの一例を示す図である。
【図５】  本発明で用いられるRRフォーマットの一例を示す図である。
【図６】  伝送帯域が変化した場合のジッタ、ジッタの差分絶対値、パケットロス率の推移の実験結果を示すグラフである。
【図７】  輻輳状態の判定と符号化ビットレートの決定を含む送信制御アルゴリズムの一例を示すフローチャートである。
【図８】  図７で用いられている各種パラメータの意味内容の説明図である。
【図９】パケットロス率とジッタ差分絶対値に対する各輻輳状態が取り得る範囲を示すグラフである。
【図１０】  本発明で使用できるリアルタイムエンコーダの一例を示す機能ブロック図である。
【図１１】  送出ビットレートを送信側にフィードバックする場合のRRパケットのフォーマットの一例を示す図である。
【図１２】  本発明をプログラムとして構成する場合の例を説明するためのブロック図である。
【図１３】  本発明による伝送シミュレーション結果を示すグラフである。
【図１４】  従来の映像情報伝送装置を示す機能ブロック図である。
【符号の説明】
10,140・・・ネットワーク、11,141・・・カメラ、12,142・・・リアルタイムエンコーダ、13,143・・・送信制御部、14,144・・・受信制御部、15,145・・・リアルタイムデコーダ、16,146・・・再生表示部、17・・・DCT部、18・・・量子化部、19・・・VLC部、20・・・逆量子化部、21・・・逆DCT部、22・・・フレームメモリ、23・・・動き補償部、24・・・動き推定部、25・・・レート制御部、200・・・コンピュータ、201・・・CPU、202・・・入力装置、203・・・ROM、204・・・RAM、205・・・読取装置、206・・・出力装置、300・・・記録媒体
【図１】
0003900413.tif 000002
【図２】
0003900413.tif 000003
【図３】
0003900413.tif 000004
【図４】
0003900413.tif 000005
【図５】
0003900413.tif 000006
【図６】
0003900413.tif 000007
【図７】
0003900413.tif 000008
【図８】
0003900413.tif 000009
【図９】
0003900413.tif 000010
【図１０】
0003900413.tif 000011
【図１１】
0003900413.tif 000012
【図１２】
0003900413.tif 000013
【図１３】
0003900413.tif 000014
【図１４】
0003900413.tif 000015