JP2008193510A - 映像送信装置、映像受信装置、及び映像伝送システム - Google Patents

Abstract

【課題】エラーが発生した場合に、その状況に応じて適応的にエラーデータを取得できるとともに、リアルタイム性の要求されるデータをリアルタイムに再生できるようにする。
【解決手段】送信側では、再送用のＵＲＬをセッション情報とともに受信側に通知し、ＲＴＰパケットを送信する。一方、受信側では、ＲＴＰパケットにエラーが検出された場合に、送信側から通知されたセッション情報に基づいて、エラーが検出されたパケットの再送要求を行い、再送要求したパケットを受信するようにして、エラーが発生した場合に、その状況に応じて適応的にエラーデータを取得できるとともに、リアルタイム性の要求されるデータをリアルタイムに再生できるようにする。
【選択図】図１

Description

本発明は映像送信装置、ネットワークカメラ、映像受信装置、映像伝送システム、映像送信方法、映像受信方法、プログラム、及び記憶媒体に関し、特に、通信回線を介して映像情報等を伝送するために用いて好適な技術に関する。

近年の通信システムの発展により、カメラのライブ映像や蓄積された動画映像をインターネットなどの通信回線を通じて見ることが一般的に行われるようになってきた。また、無線通信機器が安価になったことや、回線が大容量化されてきたことにより、家庭内や職場内においても、ネットワークで接続された機器で動画像データを参照する機会が増加している。

このような動画像データは、単位時間あたりのデータ量が大きくなりがちである。そこで、ライブ映像などのような、リアルタイム性が特に高い動画像データを長時間にわたり参照するために、ＲＴＰ（Real-time Transport Protocol、RFC 3550、The Internet Society）などの通信プロトコルが利用されてきた。

このようなＲＴＰプロトコルに代表されるリアルタイム通信においては、一般的に、データの信頼性が必ずしも高いとは言えない。一方、比較的単純で通信速度の向上を期待できるＵＤＰ／ＩＰなどの低層プロトコルも利用されており、ＲＴＰにおいてもこれを前提としないまでも、強く想定したものとなっている。

このような、ＵＤＰ／ＩＰなどのプロトコルを用いた場合、リアルタイム性には優れているものの、その性質上、パケット損失などのエラーが発生しやすいという問題点がある。もし、エラーが発生すれば、動画像データの一部が欠落するといった現象が発生する可能性が高く、このため、様々な工夫がなされてきている。

例えば、圧縮符号化された動画像データに対し、符号化時点でエラーの波及する範囲を限定する仕組みを組み込んだり、一度発生したエラーに対して再生表示する際の動画像データの欠落を目立たなくしたりするといったことが実際に行われている。また、通信設備の側面からは、より信頼性の高い通信回線が提案され、特定条件下では、エラー率はかなり低くなってきた。

一方、一度エラーが発生した場合には、この発生したエラーを回復することも重要な課題となっている。この最も典型的な例は、ライブ映像を用いた監視システムであり、カメラによって撮影された動画像を遠隔地よりリアルタイムにモニタリングしながら、一方で、その記録を蓄積するようなケースである。

従来、発生したエラーを回復することを目的とした技術としては、以下のような技術が開示されている。例えば、特許文献１には、リアルタイム性を重視する通信チャネルと、エラーが発生した場合にエラーデータの再送に用いる通信チャネルとを用意し、これを適宜使い分けるリアルタイム通信装置が開示されている。

なお、特許文献１に記載されている技術では、通信回線が複数になるため、エラーデータの再送に用いる回線においてデータ量が増加することにより、エラーや伝送遅延を却って招きかねない。この課題を解決するために、例えば、特許文献２には、同様に複数のチャネルを用いながら、エラーデータの再送を通常の伝送の終了後に行うようにスケジュールするという通信システムが開示されている。

また、リアルタイム性及び信頼性を再生用と保管用とでとらえ、あらかじめ準備した再生用のＵＤＰと保存用のＴＣＰとを利用することにより、これを適宜使い分けてエラーを回避するという通信制御装置が提案されている（例えば、特許文献３参照）。さらに、エラーが発生した場合に、ＵＤＰからリアルタイム性は劣るが信頼性の高いＴＣＰに切り替えるといった通信装置も提案されている（例えば、特許文献４参照）。

特開平５−１４５５９４号公報 特開平１０−３１３３５０号公報 特開２００２−１９９０１９号公報 特開２０００−１５１６８０号公報

しかしながら、前述した従来技術では、リアルタイム性を重視することにより信頼性が欠けてしまう再生用通信回線と、リアルタイム性には欠けるが信頼性の高い保存用通信回線（あるいはエラー再送用通信回線）とを予め準備しなければならない問題点があった。また、これらの２つの通信回線を物理的に１つの通信回線にした場合、再生用通信回線と保存用通信回線との２つの通信回線を同時に利用すると、通信トラフィックが増大し、エラーを増長させる結果を招きかねない問題点があった。このため、エラーが発生した場合に、受信側がその状況に応じてエラーデータを適応的に取得することが困難であるという問題点があった。

この問題点を解消するために、これらの２つの通信回線を同時に使用せず、まず、再生用通信回線にて再生データを受信しながらエラーを検知する。そして、エラーを検知した場合は、再生データの受信を完了した後に保存用通信回線（エラー再送用通信回線）にてエラーデータの再送を要求し、エラーデータを取得する方法も考えられる。

しかしながら、この方法を行う場合、通信接続の管理を厳密に行ってエラーの部分を特定し、エラーデータの再送を行う時は信頼性の高い通信回線に切り替えて通信を行う必要がある。また、ライブデータのようなリアルタイム性が特に要求される動画像データであっても、最終的に通信が終了するまでエラーデータの再送に備えて動画像データを送信側で保持しなければならない。このため、エラーを検知した場合は、エラーデータが再送されるまで受信側で動画像データの再生を行うことができず、リアルタイムに再生できないという問題点があった。

さらに、エラーが検知された場合に、リアルタイム性の高い再生用通信回線から信頼性の高い保存用通信回線に切り替える場合であっても、エラーの発生を極めて短時間で判断し、通信回線の切り替えを瞬時に行わなければならなかった。このため、エラーの検出及び通信回線の切り替えを瞬時に行わないとエラーを回復させるためのタイムロスが大きくなってしまう。さらに、通信回線の切り替え後はリアルタイム性に欠ける通信回線を使用するため、これらの技術を使用してもリアルタイム性を充分に得ることができないという問題点があった。

本発明は前述の問題点に鑑み、エラーが発生した場合に、その状況に応じてエラーデータを適応的に取得できるとともに、リアルタイム性の要求されるデータをリアルタイムに再生できるようにすることを目的としている。

本発明の映像送信装置は、動画像データを含む映像情報を映像受信装置に対して通信回線を介して送信する映像送信装置であって、前記映像受信装置に送信する映像情報を再送するための情報を含む再送要求接続情報を提供する再送要求接続情報提供手段と、前記映像受信装置との通信の接続制御を行う接続制御手段と、前記接続制御手段によって接続制御された通信により、前記再送要求接続情報提供手段により提供される再送要求接続情報と前記映像情報とを前記映像受信装置に送信する映像情報送信手段と、前記映像受信装置から送られる前記再送要求接続情報に基づいた再送要求を受信する再送要求受信手段と、前記再送要求受信手段により受信された再送要求に従って、前記映像情報の特定の部分を再送する映像情報再送手段とを備えることを特徴とする。

本発明のネットワークカメラは、前記に記載の映像送信装置と、撮像手段とを備えたことを特徴とする。

本発明の映像受信装置は、動画像データを含む映像情報を映像送信装置から通信回線を介して受信する映像受信装置であって、前記映像送信装置との通信の接続制御を行う接続制御手段と、前記接続制御手段によって接続制御された通信により、前記映像送信装置から送信される再送要求接続情報と前記映像情報とを受信する映像情報受信手段と、前記映像情報受信手段により受信された映像情報のエラーを検出するエラー検出手段と、前記エラー検出手段により検出されたエラーに従って、前記映像情報の特定の部分を前記映像送信装置に再送要求する再送要求手段と、前記再送要求手段により再送要求した映像情報の特定の部分を受信する再送映像情報受信手段と、前記映像情報受信手段により受信された映像情報を再生する再生手段とを備えることを特徴とする。

本発明の映像伝送システムは、前記に記載の映像送信装置または前記に記載のネットワークカメラと、前記に記載の映像受信装置とを備えたことを特徴とする。

本発明の映像送信方法は、動画像データを含む映像情報を映像受信装置に対して通信回線を介して送信する映像送信方法であって、前記映像受信装置に送信する映像情報を再送するための情報を含む再送要求接続情報を提供する再送要求接続情報提供工程と、前記映像受信装置との通信の接続制御を行う接続制御工程と、前記接続制御工程において接続制御した通信により、前記再送要求接続情報提供工程において提供する再送要求接続情報と前記映像情報とを前記映像受信装置に送信する映像情報送信工程と、前記映像受信装置から送られる前記再送要求接続情報に基づいた再送要求を受信する再送要求受信工程と、前記再送要求受信工程において受信した再送要求に従って、前記映像情報の特定の部分を再送する映像情報再送工程とを備えることを特徴とする。

本発明の映像受信方法は、動画像データを含む映像情報を映像送信装置から通信回線を介して受信する映像受信方法であって、前記映像送信装置との通信の接続制御を行う接続制御工程と、前記接続制御工程において接続制御した通信により、前記映像送信装置から送信される再送要求接続情報と前記映像情報とを受信する映像情報受信工程と、前記映像情報受信工程において受信した映像情報のエラーを検出するエラー検出工程と、前記エラー検出工程において検出したエラーに従って、前記映像情報の特定の部分を前記映像送信装置に再送要求する再送要求工程と、前記再送要求工程において再送要求した映像情報の特定の部分を受信する再送映像情報受信工程と、前記映像情報受信工程において受信した映像情報を再生する再生工程とを備えることを特徴とする。

本発明のプログラムは、動画像データを含む映像情報を映像受信装置に対して通信回線を介して送信する映像送信方法の各工程をコンピュータに実行させるプログラムであって、前記映像受信装置に送信する映像情報を再送するための情報を含む再送要求接続情報を提供する再送要求接続情報提供工程と、前記映像受信装置との通信の接続制御を行う接続制御工程と、前記接続制御工程において接続制御した通信により、前記再送要求接続情報提供工程において提供する再送要求接続情報と前記映像情報とを前記映像受信装置に送信する映像情報送信工程と、前記映像受信装置から送られる前記再送要求接続情報に基づいた再送要求を受信する再送要求受信工程と、前記再送要求受信工程において受信した再送要求に従って、前記映像情報の特定の部分を再送する映像情報再送工程とをコンピュータに実行させることを特徴とする。
また、本発明のプログラムの他の特徴とするところは、動画像データを含む映像情報を映像送信装置から通信回線を介して受信する映像受信方法の各工程をコンピュータに実行させるプログラムであって、前記映像送信装置との通信の接続制御を行う接続制御工程と、前記接続制御工程において接続制御した通信により、前記映像送信装置から送信される再送要求接続情報と前記映像情報とを受信する映像情報受信工程と、前記映像情報受信工程において受信した映像情報のエラーを検出するエラー検出工程と、前記エラー検出工程において検出したエラーに従って、前記映像情報の特定の部分を前記映像送信装置に再送要求する再送要求工程と、前記再送要求工程において再送要求した映像情報の特定の部分を受信する再送映像情報受信工程と、前記映像情報受信工程において受信した映像情報を再生する再生工程とをコンピュータに実行させることを特徴とする。

本発明の記憶媒体は、前記の何れかに記載のプログラムを記憶したことを特徴とする。

本発明によれば、映像情報を再送するための情報を含む再送要求接続情報を映像受信装置に送信するようにした。これにより、受信側では、エラーが発生した場合に、その状況に応じて適応的にエラーデータを取得できるとともに、リアルタイム性の要求されるデータをリアルタイムに再生できる。したがって、再送用の通信接続を常に利用する必要がなくなったため、再送による通信資源を有効に活用できる。また、リアルタイム性が要求される映像通信を行いながら、受信側の判断において、通信エラーに応じて所望の時間に所望の映像データを再送することができる。

（第１の実施形態）
以下、本発明の映像送信装置を通信機能を備えたネットワークカメラに適用し、本発明の映像受信装置を通信機能を備えた再生装置に適用した場合の第１の実施形態について図面を参照しながら説明する。
図１は、本実施形態に好適なシステムの構成例を示す概念図である。
図１に示すように、このシステムは、動画像データを生成し、ＬＡＮ（Local Area Network）などのネットワーク上に配信するネットワークカメラ１０１と、配信された動画像データを受信して表示する再生装置１０２とから構成されている。

ネットワークカメラ１０１は、撮像手段と通信機能を備えた撮像装置であり、近年、特に監視用途などで用いられるカメラとして普及されているものである。ネットワークカメラ１０１は、概念的な機能面からは、接続制御サーバモジュール１０５と、ストリームサーバモジュール１０６と、動画像生成モジュール１０７とから構成されている。

送信側接続制御手段として機能する接続制御サーバモジュール１０５は、再生装置１０２との間で通信回線を介して通信を行いながらセッション制御を行う。これにより、動画像生成モジュール１０７が生成した動画像データをストリームサーバモジュール１０６が好適な形式で再生装置１０２に送出するようにしている。

一方、再生装置１０２は、ネットワークカメラ１０１に対応して通信機能を備えた動画像の再生を行う装置である。再生装置１０２は、例えば、ＰＣ（パーソナルコンピュータ）上で動作するアプリケーション・プログラムとして実現されている場合もあれば、専用のディスプレイを備えた監視装置の一部として実現される場合もある。再生装置１０２は、概念的な機能面からは、接続制御クライアントモジュール１０４と、ストリームクライアントモジュール１０８と、動画像表示モジュール１０９と、記録装置１１０とから構成されている。

受信側接続制御手段として機能する接続制御クライアントモジュール１０４は、例えば、利用者による操作部１０３の操作により、ネットワークカメラ１０１との間で通信を行いながらセッションを確立する。この接続情報を元に、ストリームクライアントモジュール１０８が動画像データを受信し、再生手段として機能する動画像表示モジュール１０９により受信した動画像データを再生表示する。また、記録装置１１０は、受信した動画像データなどを保管している。

ここで、図１を参照しながら、一般的な処理の流れについて説明する。まず、再生装置１０２の操作部１０３が利用者により操作されると、再生装置１０２はネットワークカメラ１０１に対して動画像データを取得するように指示を出す。この操作は、例えば、ＧＵＩ（グラフィカル・ユーザ・インターフェース）を用いてネットワークカメラ１０１のＵＲＬ（Uniform Resource Locator）を入力する操作であってもよい。また、再生装置１０２にあらかじめ通信接続定義しておいた情報を用いて、スイッチが押下されるような操作であってもよい。

画像取得の指示は、接続制御クライアントモジュール１０４から接続制御サーバモジュール１０５に対して、接続制御のメッセージ１１１として通信を介して通知される。なお、接続制御のための通信は、ＳＩＰ（Session Initiation Protocol）やＸＭＬ（extensible Markup Language）を用いたWeb Serviceによる方法など、様々な手段が普及されている。この中で最も一般的な方法のひとつは、ＲＴＳＰ（Real Time Streaming Protocol、RFC 2326、The Internet Society）によるものである。本実施形態では、このＲＴＳＰによる接続制御を行うものとする。

なお、図１では説明の簡略化のため、接続制御のメッセージ１１１を単純化した矢印にて記載しているが、例えば、ＲＴＳＰプロトコルにおいては、複数回のメッセージ交換により行われることが一般的である。

接続制御サーバモジュール１０５は、次に、ストリームサーバモジュール１０６に対し、ストリーム送出の指示を行う（１１２）。ストリームサーバモジュール１０６は、この指示を受けて、動画像生成モジュール１０７が生成した動画像データを取得し（１１３）、再生装置に向けて動画像を送出する（１１５）。

一方、再生装置１０２では、接続制御クライアントモジュール１０４が接続制御サーバモジュール１０５との接続制御を行った結果を基に、ストリームクライアントモジュール１０８に対して、動画像データの受信の指示を行う（１１４）。これによって、ストリームクライアントモジュール１０８は、ストリームサーバモジュール１０６が送出する動画像データを受信することが可能となる。

先に例として挙げたＲＴＳＰプロトコルは、接続制御のメッセージ１１１中のＳＤＰ（Session Description Protocol、RFC 2327、The Internet Society）により、送出される動画像の詳細な情報を含む。このため、この情報がストリームサーバモジュール１０６とストリームクライアントモジュール１０８との間の共通情報として利用される。そして、受信した動画像データは、動画像表示モジュール１０９に再生動画像データ１１６として送出されて表示されたり、あるいは、保管動画像データ１１７として記録装置１１０に記録されたりする。

次に、図１に示したシステム構成の概念図をより具体的に示した図２を参照しながら、動画像データがネットワークカメラ１０１より送信されて再生装置１０２にて表示されるまでの流れについて説明する。図２は、本実施形態に係るネットワークカメラ１０１及び再生装置１０２の内部構成例を示すブロック図である。

撮影しようとする被写体像は、光学系からなる撮影レンズユニット２０１を通って光学センサ２０５に結像する。撮影レンズユニット２０１は、例えば焦点を合わせるためにモーターなどによりレンズ群を移動する仕組みになっており、その直接の制御は、撮影レンズユニット駆動回路２０２によって行われる。この時、絞りを含む絞りユニット２０３が絞りユニット駆動回路２０４によって操作され、結像する光は適切に光量調整される。

光学センサ２０５は、固体撮像素子（ＣＣＤやＣＭＯＳセンサなど）によって構成され、入射した光を光量に応じて電荷に変換、蓄積する機能をもっている。この電荷を読み出し、Ａ／Ｄコンバータ２０７でデジタル化することにより、圧縮されていないデジタル画像データが生成される。

また、光学センサ２０５は、光学センサ駆動回路２０６から出力されるパルス信号などによって適切に制御される。そして、指示されたタイミングで指示された時間の間に蓄積された電荷を読み出す一連の動作を連続することによって、連続したデジタル画像データが得られることになる。このようにして取得された連続したデジタル画像データが動画像データである。

次に、連続して取得されるデジタル画像データは、圧縮符号化を行うために、画像信号処理回路２０８に受け渡される。そして、画像信号処理回路２０８において、ホワイトバランス補正やガンマ補正といった画像データの補正を行った上で、符号圧縮回路２０９に受け渡される。このような処理間のデジタル画像の受け渡しは、例えばＤＭＡ（Direct Memory Access）回路を利用した高速なメモリ２１０のアクセスにより行われることによって、大量のデータ処理をリアルタイムで行うことを可能にしている。

一方、符号圧縮回路２０９内には、符号化のアルゴリズムが実装されていて、動画像データが圧縮処理される。例えば、連続したＪＰＥＧ（ISO/IEC 10918）符号化による、いわゆるモーションＪＰＥＧ画像データでは、画像信号処理回路２０８から入力がされるデジタル画像がＲＧＢ信号である場合、輝度信号Ｙとクロマ信号ＣｂＣｒとからなるＹＣ信号にされる。そして、これらの信号を、例えば８×８画素のブロックに分割したのち、離散コサイン変換、量子化、ハフマン符号化といった処理が行われて最終的な圧縮画像データが生成されて出力される。

また、圧縮符号化方式がＭＰＥＧ−２（ISO/IEC 13818）やＭＰＥＧ−４（ISO/IEC 14496）などのフレーム間予測を行う形式である場合、圧縮しようとする特定の１枚の画像データ（フレーム）に対し、前後のフレームを参照する。そして、動き補償予測、マクロブロック処理などを行って、前後が相互に依存した圧縮画像データ（ビットストリーム）が生成されて出力される。

このようにして生成された動画像の圧縮画像データは、メモリ２１０に一時保管され、通信に適した形式に変換されて、ネットワークコントローラ２１１を介して通信回路２１２より通信路上に出力される。

この一連の動作をリアルタイムに制御し、各ブロックの処理を最適化する役割は、ＣＰＵ（Central Processing Unit）２１４によって行われる。すなわち、一般的な表現で言われる制御プログラム（ファームウェア）などによるプログラム動作である。通常、制御プログラム（ファームウェア）は、静的な情報として、通常、ＲＯＭ（Read Only Memory）２１３に格納されている。

ネットワークカメラ１０１は、起動時から必要に応じて、このＲＯＭ２１３より制御プログラム（ファームウェア）を読み出し、ＣＰＵ２１４で処理することにより、全体の動作を行う。ＣＰＵ２１４で処理される制御プログラム（ファームウェア）は、これ以外にもいくつかの処理機能を担っている。例えば、先に説明した撮影レンズユニット２０１の動作の指示を行って、ズーム動作（焦点距離の移動）やオートフォーカスといった処理を行う。

一方、再生装置１０２側では、通信路上に伝送された動画像の圧縮画像データは、通信回路２２１を介してネットワークコントローラ２２２により、通信路上の形式から再生装置１０２において利用する好適な形式に変換され、メモリ２３０に一時保管される。図２に示すように、これらの処理の制御を含め、再生装置１０２上の様々な処理機能は、ＣＰＵ２２９、ＲＯＭ２２８などにより構成される動作機構により、ネットワークカメラ１０１と同様に処理される。

符号伸長回路２２３は、符号圧縮回路２０９と対となるものであり、メモリ２３０に一時保管された圧縮画像データを伸長するものである。伸長された画像データは、画像信号処理回路２２４にて、例えばエッジ平滑化処理などにより、表示するのに適した画像データへ変換される。そして、表示装置２２６がアナログインターフェースを備えた表示装置であれば、Ｄ／Ａコンバータ２２５を介して駆動回路２２７により駆動される表示装置２２６へ画像データが受け渡される。このようにして、再生装置１０２では、ネットワークカメラ１０１より動画像データを受信し、これを表示装置２２６に表示させることができる。

なお、再生装置１０２の機能として、受信した画像データが保存される場合、ネットワークカメラ１０１より送信された動画像データは、ＣＰＵ２２９によって処理される制御プログラムにより記録ファイル形式に変換される。そして、変換された動画像データはＩ／Ｏコントローラ２３１を介してメモリカードやハードディスクのような記録装置２３２に出力される。記録装置２３２で利用される物理的な記録媒体は、内蔵フラッシュメモリであってもよいし、ＣＤ−ＲやＤＶＤ−Ｒといった記録型光学ディスク、光磁気ディスクなどであってもよい。

図２では図示していないが、音声を必要とする場合には、例えば、光学センサと同様にマイクロフォンが実装され、これをＡ／Ｄコンバータでデジタル化し、音声信号処理回路と音声圧縮回路を介して圧縮符号化する。これにより、動画像データと同様にネットワークカメラ１０１上でこれを処理することができる。この場合、再生装置１０２側には、この逆に、音声伸長回路、音声信号処理回路、Ｄ／Ａコンバータ、スピーカなどが実装されていればよい。

以上、図２を参照しながら、動画像データがネットワークカメラ１０１より再生装置１０２に送信され、再生装置１０２の表示装置２２６にて表示されるまでの流れについて、より詳細に説明を行った。一方、例えば、符号圧縮回路２０９により処理される動画像データの圧縮処理は、ＣＰＵ２１４で、ファームウェアにより処理されてもよい。一方で、例えば上に述べた記録ファイル形式への変換は、必要に応じて、ハードウェア処理に置き換えてもよい。

また、メッセージ１１１の交換は、ＣＰＵ２２９によって処理される制御プログラムにより制御され、ネットワークコントローラ２２２を介して再生装置１０２よりネットワークカメラ１０１へと通知されることにより実現される。この詳細については、以下に説明する。

図３は、ＲＴＳＰ、及びＲＴＰ（Real-time Transport Protocol、RFC 3550、The Internet Society）を動画像データの送出に利用したシステム構成例を示すブロック図である。ここでは、図１を参照しながら説明した接続制御のメッセージ１１１の交換、及び動画像データの送出処理１１５について、ＲＴＳＰプロトコルと対で一般的に広く利用されるＲＴＰプロトコルを例にとり、より詳しく説明する。また、図３の説明を容易にするために、図４にＲＴＳＰプロトコルによるメッセージ交換の例を示す。

図３に示すように、接続制御クライアントモジュール１０４、及び接続制御サーバモジュール１０５は、それぞれ、ＲＴＳＰクライアント３０１とＲＴＳＰサーバ３０２とから構成されている。

ＲＴＳＰプロトコルにおいては、その低層の通信プロトコルを特に定義していないが、その目的上、一般にはＴＣＰ／ＩＰによる信頼性の高いプロトコルが利用される。また、接続制御における手順を大まかに定義しているものの、利用形態によってその詳細手順を柔軟に変更することが可能となっている。このため、以下では、最も一般的となる手順により説明を行う。

利用者により、再生装置１０２の操作部１０３が操作されて、ネットワークカメラ１０１から画像データを取得するよう指示を行うことを先に説明した。この指示においては、ＲＴＳＰクライアント３０１を介して、ＲＴＳＰサーバ３０２に対し、ＵＲＬにより指定されるリモートリソースを取得するよう要求している。すなわち、ＲＴＳＰプロトコルにより、ＲＴＳＰクライアント３０１から、DESCRIBEメソッドを送信することになる。

これに対して、ＲＴＳＰサーバ３０２は、ＳＤＰプロトコルによるセッション情報を送り返す。ＳＤＰプロトコルは、任意の拡張が認められ、かつ、多くの項目が選択的となっているが、バージョン情報やセッションＩＤなどの必須項目とともに、メディアのMIMEタイプ（m=）やそのメディア固有の属性（a=）を含む。すなわち、動画像の映像データを例にとるならば、ＲＴＳＰクライアント３０１は、映像情報受信手段として機能し、以下のような映像データの詳細な情報を取得することができる。
m=video 0 RTP/AVP 97
a=rtpmap:97 MP4V-ES/90000

このような詳細な情報は、再送要求接続情報提供手段として機能するＲＴＳＰサーバ３０２がシステムを構成する情報として保持し、映像情報送信手段として機能してこの情報を送信してもよい。あるいは、再送要求接続情報提供手段として機能するストリームサーバモジュール１０６から情報を取得して、ＲＴＳＰサーバ３０２が映像情報送信手段として機能し、この情報を送信してもよい。

このメッセージ交換については、DESCRIBEメソッド４０１、DESCRIBEメソッド４０１のレスポンス４０２、及びレスポンス４０２に含まれるＳＤＰメッセージ４０３を図４に示した。ここで、ＳＤＰメッセージ４０３の最終行には、「a=retransmit:http://hostname/retransmit.cgi」という記載がある。この行は、一般的に利用されるＲＴＳＰプロトコル、及びＳＤＰプロトコルの拡張であり、再送要求を行うＵＲＬを示している。これについての詳細は、後で詳細に説明する。

次に、ＲＴＳＰクライアント３０１はＲＴＳＰサーバ３０２に対し、SETUPメソッド４０４を送信し、そのレスポンス４０５が返される。これは、ＲＴＳＰクライアント３０１からＲＴＳＰサーバ３０２に対してメディア伝送の準備を行うよう要求するものである。結果として、双方がその通信ポート等を了解し、具体的な動画像データの伝送が可能となる。

この時、ＲＴＳＰサーバ３０２は、ＲＴＰ／ＲＴＣＰサーバ３０３に対して動画像データを伝送するための具体的なアドレスやポート番号を指示する。一方、ＲＴＳＰクライアント３０１は、ＲＴＰ／ＲＴＣＰクライアント３０４に対して、同様に動画像データを伝送するための具体的なアドレスやポート番号を指示する。これにより、具体的な動画像データの伝送が実現される。

実際の動画像データの伝送開始は、PLAYメソッド４０６とそのレスポンス４０７により開始される。具体的には、ＲＴＳＰクライアント３０１からPLAYメソッド４０６が送信されることにより、ＲＴＳＰサーバ３０２は、ＲＴＰ／ＲＴＣＰサーバ３０３に対して動画像データの送信を開始するよう指示する。また、これとともに、ＲＴＳＰサーバ３０２は、ＲＴＰ／ＲＴＣＰサーバ３０３から送信される動画像データのＲＴＰタイムスタンプの基本情報をＲＴＳＰクライアント３０１に返す。そして、ＲＴＳＰクライアント３０１がＲＴＰタイムスタンプの基本情報をＲＴＰ／ＲＴＣＰクライアント３０４に通知することによって、ＲＴＰ／ＲＴＣＰクライアント３０４は受信を開始する。

ここで、ＲＴＰパケットの送出の流れを説明する前に、図４のTEARDOWNメソッド４０８とそのレスポンス４０９について簡単に説明する。このメッセージは、セッションの終了を通知するためのものであり、その他のメソッドと同様にＲＴＳＰクライアント３０１とＲＴＳＰサーバ３０２との間で正常な終了を行うために利用される。このメッセージにより、例えばＲＴＳＰサーバ３０２は、ＲＴＰ／ＲＴＣＰサーバ３０３に対して、動画像データの伝送を停止するよう要求を行うことができる。

ここで、PLAYメソッド４０６により、ＲＴＰ／ＲＴＣＰサーバ３０３からＲＴＰ／ＲＴＣＰクライアント３０４へ動画像データを伝送するしくみについて、説明を加える。映像情報送信手段として機能するＲＴＰ／ＲＴＣＰサーバ３０３から、映像情報受信手段として機能するＲＴＰ／ＲＴＣＰクライアント３０４へ動画像データを伝送する処理は、ＲＴＰプロトコルにより行われる。

ＲＴＰプロトコルでは、送出データ（この場合は、符号化された動画像データ）は、通信経路上のデータの最小単位に分割され、ＲＴＰヘッダと呼ばれる付加情報が付与されて送出される。この送信単位をＲＴＰパケットと呼ぶ。このようにするため、動画像生成モジュール１０７で生成された動画像データは、映像情報蓄積手段として設けられている符号化バッファ３０５に一度蓄積される。そして、符号化バッファ３０５に蓄積された動画像データが、ＲＴＰパケット化モジュール３０６によりＲＴＰパケット化されて、送信バッファ３０７に一時的に保管される。そして、保管されたＲＴＰパケットは、ＲＴＰ／ＲＴＣＰサーバ３０３より送信される。

なお、符号化バッファ３０５、及び送信バッファ３０７は、メモリでもよいし、ハードディスクのような記録媒体であってもよい。通常は、処理の高速化が要求されるため、図２に示したようなメモリ２１０がこの場合利用される。ＲＴＰ／ＲＴＣＰクライアント３０４は、この送信されたＲＴＰパケットを受信し、受信バッファ３０８に順次格納する。

ここで、受信したＲＴＰパケットは、必ずしも送信された順序で受信するわけではなく、かつ、分割されている。このため、復号化するためには、元の符号化データに再構成を行う必要があり、この機能を担っているのが再構成モジュール３０９である。受信データに全く問題がなければ、再構成モジュール３０９は、再構成した符号化データを復号化バッファ３１０に蓄積し、動画像表示モジュール１０９は、復号化及び再生を確実に行うことができる。

説明をより明確にするため、図５にＲＴＰパケットの生成を模式的に示す。
図５に示すように、動画像の符号化データ５０１は、フレーム（ピクチャ）からなるシークエンスがバイナリの列として生成されており、これをビットストリーム５０２と呼ぶ。このビットストリーム５０２を、好適な伝送単位へと分割する役割を担うのがＲＴＰパケット化モジュール３０６である。この好適な伝送単位がＲＴＰプロトコルにおいては、ＲＴＰパケットの形式となる。

このように分割を行った場合、本来、一連となるビットストリーム５０２が細分化されるため、その順序を表す付加情報が必要である。そのために、分割されたビットストリームに加えて、この付加情報が付与されているのが、ＲＴＰパケットの特徴である。図５には、パケットの順序を与えるシークエンス番号５０４、フレームのその瞬間の時刻を与えるタイムスタンプ５０５、分割されたビットストリームである実際のペイロードデータ５０６を代表的な付加情報の例として示した。

なお、図５では、簡略化のために示していないが、これらの情報以外にも、フレームを構成するＲＴＰパケットの終わりを示す情報や、ＲＴＰパケット仕様のバージョン情報など様々な情報がＲＴＰパケットには含まれている。

なお、今回は受信データに全く問題がない場合について説明したが、ＲＴＰパケットは、リアルタイム性及び高速性の観点から信頼性が充分とはいえないＵＤＰプロトコル上に構成されたＲＴＰプロトコルにより伝送される。このため、ノイズなどの外乱要因によりパケットロスなどが発生し、復号化を完全に行うことができないエラーが発生する可能性がある。そこで、再構成モジュール３０９は、エラー検出手段として機能するエラー検出モジュール３１１と連携して、エラーの検出を行うようにしている。

このようにしてエラーが検出された場合には、エラーが検出されたパケットを再送要求するように再送要求クライアント３１２に対して指示を行う。再送要求クライアント３１２は再送要求手段として機能して、再送サーバ３１３に再送要求を行うための通信を行う。この時、再送要求受信手段として機能する再送サーバ３１３のリソース、すなわち映像情報の格納先を示す再送要求のＵＲＬは、ＳＤＰメッセージ４０３に含まれていることは前述した通りである。再送要求のＵＲＬは、ＲＴＳＰクライアント３０１を経由して通知されてもよいし、その他のＳＤＰ情報などとともにＲＴＰ／ＲＴＣＰクライアント３０４を経由して取得してもよい。図３では、ＲＴＰ／ＲＴＣＰクライアント３０４を経由して取得することを矢印で示している。

再送サーバ３１３は映像情報再送手段として機能して、再送要求クライアント３１２から送られた再送要求に従って、エラーとなったパケットを送信バッファ３０７より取得する。そして、この取得したパケットを再送映像情報受信手段として機能する再送要求クライアント３１２に送信する。このように処理することにより、エラーとなったパケットも取得され、これが受信バッファ３０８に再び格納されることによりエラーが回復する。

ここまで、ＲＴＰパケットについて説明してきたが、ＲＴＰプロトコルでは、ＲＴＰパケットと密接に関連したＲＴＣＰ（Real-time Control Protocol）パケットも利用される。ＲＴＣＰパケットの詳細については標準規格であるためその詳細な説明は省略する。ＲＴＣＰパケットは、ＲＴＰ／ＲＴＣＰサーバ３０３及びＲＴＰ／ＲＴＣＰクライアント３０４の双方がＲＴＰパケットの送信あるいは受信状況について統計的な情報を交換するために利用される。

一般的には、ＲＴＣＰパケットは、リアルタイムに送信されるＲＴＰパケットとは異なり、５秒程度に一度、統計的なサマリ情報として送受信するよう実装される。これにより、ＲＴＰ／ＲＴＣＰサーバ３０３は、例えば、送信したＲＴＰパケットの受信時のエラー率や時刻などを知ることができる。また、このＲＴＣＰパケットの送受信によって、通信トラフィックの少ないタイミングを認知できるようにしている。

次に、ＳＤＰメッセージ４０３に含まれる再送要求のＵＲＬについて、より具体的な例について説明する。ここでは、例として、図４の中で例示した再送要求のＵＲＬを用いて説明する。再送要求のＵＲＬの例の１つは、以下に示すようなものである。
「http://hostname/retransmit.cgi?ses=23456789&seq=24680」

これは、ＳＤＰメッセージ４０３に含まれるＵＲＬに加えて、そのパラメータを付与した形式になっている。第１のパラメータは、「ses=23456789」となっており、これは、ＲＴＳＰのメッセージ交換にて、SETUPメソッド４０４のレスポンスなどで指定されたセッションＩＤを意味している。このセッションＩＤにより、再送サーバ３１３は、どのセッションからの再送要求であるかを判別することができる。

第２のパラメータは、「seq=24680」となっており、ＲＴＰパケットにて指定されたパケットの順序を与えるシークエンス番号５０４を意味している。このシークエンス番号５０４により、再送サーバ３１３は、どのパケットの再送要求であるかを判別することができる。

すなわち、この例によれば、エラー検出モジュール３１１により検知されたエラーに該当する特定のセッションの特定のパケットを、再送要求クライアント３１２から再送サーバ３１３に通知することが可能となる。この例であれば、ＨＴＴＰプロトコルにより安全に取得することが可能となる。

また、本実施形態によれば、ストリームクライアントモジュール１０８の都合により、必要なパケットを任意のタイミングで要求することが可能であるということである。すなわち、受信した動画像データの表示においてはリアルタイム性を重視する。また、同時にエラーのない記録保存を行うならば、動画像表示モジュール１０９での表示においては、エラーの有無にかかわらず表示を継続し、通信トラフィックの少ないタイミングで再送要求を行う。そして、エラー部分を順次に更新して保存するといったことが可能となる。

また、他の例を示すと、以下のようなＵＲＬがある。
「http://hostname/retransmit.cgi?ses=23456789&ts=1234900」

この例では、第１のパラメータは先の例と同じであるが、第２のパラメータは、「ts=1234900」となっており、これは、再送要求を行うフレームのタイムスタンプ５０５を意味している。このタイムスタンプ５０５により、再送サーバ３１３は、どのタイムスタンプの再送要求であるかを判別することができる。

もし、第３のパラメータとして、パケットの先頭から終端までの順序などを付与すれば、ただ１つのパケットを特定することも可能である。この例では、むしろ、パケットを特定するのではなく、タイムスタンプ５０５を指定することにより、指定されたタイムスタンプ５０５に該当するフレーム全体を取得している。

以上、２つの再送要求時のＵＲＬの例では、パラメータの１つとしてセッションＩＤを指定したが、これを含まない例を以下に示す。
「http://hostname/retransmit.cgi?rtpmap=97&&seq=24680」

第１のパラメータは、ＳＤＰメッセージ４０３に含まれるrtpmap情報である。rtpmap情報は、再利用される可能性があるため、ＲＴＰプロトコルによる伝送を一意に特定することができない場合もある。ところが、ＲＴＰプロトコルによる伝送においても、この例におけるＨＴＴＰプロトコルにおいても、ストリームクライアントモジュール１０８をＩＰアドレスにより特定することが可能である。よって、ストリームクライアントモジュール１０８が該当ＩＰアドレスにて唯一のＲＴＰプロトコルの伝送を行っている場合は、rtpmap情報と第２のパラメータであるシークエンス番号５０４とにより再送サーバ３１３はどのパケットの再送要求であるかを判別できる。

以上説明してきたように、再送要求のＵＲＬに再送対象をパラメータ指定することにより、エラーなどが検出された動画像データの一部を特定して再送要求することが可能となる。なお、再送要求のＵＲＬの取得は、必ずしもＳＤＰメッセージ４０３によらなくてもよい。

ＳＤＰメッセージ４０３は、前述したように、ＲＴＳＰプロトコルにおけるDESCRIBEメソッド４０１のレスポンス４０２となる情報の一部である。一方、例えば、SETUPメソッド４０４のレスポンス４０５中にＲＴＳＰプロトコルの一部として含まれていても同様に処理を行うことができる。これは、例えば、SETUPメソッド４０４のレスポンス４０５中に、以下のように記述することによって実現できる。
「retransmit: url=http://hostname/retransmit.cgi」

以上、本実施形態について、図３に示したシステム構成図を中心に詳細に説明してきたが、ここで、より明確に説明するため、処理の流れについて再度説明する。図６は、本実施形態において、接続制御クライアントモジュール１０４やストリームクライアントモジュール１０８などからなる再生装置１０２による処理手順の一例を示すフローチャートである。

処理が開始されると、最初に、動画像データを送信する側となるネットワークカメラ１０１、より具体的には、接続制御サーバモジュール１０５を接続先として内部的に設定する（ステップＳ６０１）。この設定は、受信指示６０２として操作端末から行ってもよいし、あらかじめ設定済みの情報を用いてもよい。なお、本フローチャートでは、操作端末から行うことを想定して説明する。この場合、この処理は、図１に示した利用者による操作部１０３の操作に応じて行われる。

具体的な接続先の設定の後、実際の通信の開始を行うが、まず、セッション情報の取得を行う（ステップＳ６０３）。この処理の具体的な流れについては、前述した図４を参照しながらＲＴＳＰプロトコルによる例を示した。このセッション情報の取得により、動画受信情報６０４と再送要求接続情報６０５とを取得する。

動画受信情報６０４は、例えば、ＲＴＰプロトコルにおけるペイロード情報であったり、接続ポート番号であったりするが、その具体的な情報については、ここでは説明を省略する。もう一方の再送要求接続情報６０５は、例えば、前述した再送要求のＵＲＬであり、再送サーバ３１３へ接続する時に用いられる。

次に、動画受信情報６０４に基づき、動画像データの受信を行う（ステップＳ６０６）。なお、受信された動画像データは、受信バッファ３０８に格納される。ここで、受信された動画像データは、前述したＲＴＰプロトコルの例においてＲＴＰパケットに相当する。

なお、本実施形態においては、受信にかかわる処理負荷とその他の処理の処理負荷などのバランスから、ステップＳ６０６を本フローチャートの処理の流れと平行して非同期に行うようにしてもよい。この場合、必要に応じて受信バッファ３０８を介して動画像データを処理するようにすれば同等の処理を行うことができる。ここでは、処理コストが無視できる程度であるとして説明する。

続いて、受信した動画像データのエラーを判断するために、エラー検出を行う（ステップＳ６０７）。この処理には、例えば、エラー検知用のチェックサムによるビット欠落の判定や、ＲＴＰパケットのシークエンス番号５０４の検査によるパケット欠落の判定などが含まれる。ここで検出されたエラーは、ＲＴＰパケットのシークエンス番号５０４などの情報の形式でエラー位置６０８として記憶される。

次に、エラー検出の結果、エラーがあるか否かを判定する（ステップＳ６０９）。この判定の結果、エラーが検出されなかった場合は、ステップＳ６１１に進む。一方、ステップＳ６０９の判定の結果、エラーが検出された場合には、再送動画取得処理Ｓ６１０を行う（ステップＳ６１０）。

この処理において使用される情報は、ステップＳ６０３で取得した再送要求接続情報６０５と、エラー位置６０８とである。これらの情報により、再送サーバ３１３から必要な動画像データを取得し、受信バッファ３０８に格納することができる。なお、前述したように、このような処理負荷が発生すると予想される部分については、非同期的に動作するようにしてもよいが、ここでは、処理コストが無視できる程度であるとする。

次に、このようにして受信された動画像データを、通信上に最適化された形式から動画像として利用しやすい形式に変換するために動画像データの再構成を行う（ステップＳ６１１）。ここで、通信上に最適化された動画像データは、これを動画像として処理できる形式にするのに十分な再構成が行われなければならない。そこで次に、再構成が完了したかどうかを判断する（ステップＳ６１２）。

この判断の結果、再構成が完了していない場合は、ステップＳ６０６に戻り、継続して動画像データを受信する処理に入る。一方、ステップＳ６１２の判断の結果、再構成が完了した場合は、再構成された動画像データを、例えば復号化バッファ３１０に一時記録する。そして、動画像表示処理により、動画像を表示装置６１４に表示する（ステップＳ６１３）。

次に、再構成された動画像データを記録装置６１６に記録する（ステップＳ６１５）。そして、このようにして再構成された動画像データの処理を終了するかどうかを判断する（ステップＳ６１７）。この判断の結果、終了でない場合は、ステップＳ６０６に戻る。動画像は時間軸に沿って継続するものであるため、次のフレームが必要であれば、ステップＳ６０６に戻り、処理を継続する。一方、ステップＳ６１７の判断の結果、終了である場合は、処理を終了する。

なお、本実施形態を明確にするため、ステップＳ６１３とステップＳ６１５とが連続して行うようにフローチャートで説明したが、本発明を適用するシステムによって、必ずしもその両方を同時に必要としない場合がある。

例えば、ステップＳ６１０は、本フローチャートの処理の流れに対して、再送による動画取得の処理を非同期処理として起動、もしくは、委託し、ステップＳ６１３は専らリアルタイムに行い、ステップＳ６１５は、再送が完了した後に行うようにしてもよい。このようにすることで、表示装置６１４に表示する動画像はエラーを含むもののリアルタイムに表示することができる。また、記録装置６１６に記録する動画像データは、遅延が発生するもののエラーを含まない状態の動画像データとすることができる。

エラーを含む状態で動画像が表示装置６１４に表示される場合、エラーとなっている部分の画像が乱れるといった弊害はあるものの、ＲＴＰプロトコルなどにおいては、エラーを含む表示は一般的に行われている。したがって、表示装置６１４に表示する動画像のリアルタイム性を重視する場合には有効な手法である。

本実施形態によれば、再送用のＵＲＬをセッション情報とともに受信側に通知することにより、受信側で再送のタイミングや必要性を任意に判断できる。このため、このようなリアルタイム性を重視する表示とデータ整合性を重視する保存とを両立させたい場合には、特に有効に機能する。

次に、動画像データを送信する側、すなわち、本実施形態におけるネットワークカメラ１０１側の動画像データを保存する送信バッファ３０７について説明する。一般に、動画像データの送信を行う場合、動画像データの符号化単位がフレーム（ピクチャ）やその連続（動画シークエンス）である。このため、送信時の送出揺らぎなどにも配慮して、送信バッファ３０７に一定の領域を確保する必要がある。特に、本実施形態に示すような送信時のエラーに配慮して、何らかの再送制御を行おうとした場合、再送のために必要十分なバッファサイズが必須である。

図７に、本実施形態に好適な送信バッファ処理の例を示す。
図７に示す例では、送信バッファ３０７には、実際に送信されるＲＴＰデータ７０１と、ＲＴＰデータ７０１を特定するためのセッションＩＤ７０２と、シークエンス番号７０３とが記録されている。

シークエンス番号７０３は、処理の高速化を配慮して設定されているものであり、図５に示したＲＴＰパケットに含まれるシークエンス番号５０４と同じ値を示す。このように記録することにより、例えば再送サーバ３１３は、再送要求クライアント３１２からのシークエンス番号による再送要求に対して、この送信バッファ３０７を参照して再送を行うことができる。

図７の下部は、ＲＴＰ／ＲＴＣＰサーバ３０３とＲＴＰ／ＲＴＣＰクライアント３０４とにおける時間軸に沿ったデータの送受信を示している。縦に引かれた線が時間軸を示し、上から下に向けて時刻が経過するように示している。図７に示すように、送信バッファ３０７に一時的に記録されたＲＴＰデータ７０１は、ＲＴＰ／ＲＴＣＰサーバ３０３からＲＴＰ／ＲＴＣＰクライアント３０４に順次送信される。なお、図７においては、対応を明確化するために、送信７０４に対して矢印で対応を図示している。

前述したように、ＲＴＰプロトコルでは、ＲＴＣＰパケットと呼ばれる送信あるいは受信状況について統計的な情報を交換するためのパケットも交換される。それらを同様に、「RTCP-SR(P)」７０５、「RTCP-SR(P+1)」７０６、「RTCP-RR(Q)」７０７、及び「RTCP-RR(Q+1)」７０８として示す。「RTCP-SR(P)」７０５の「SR」は、ＲＴＣＰパケットにおけるSender Reportを示し、「RTCP-RR(Q)」７０７の「RR」は、ＲＴＣＰパケットにおけるReceiver Reportを示す。また、(P)及び(P+1)は、それぞれ、Ｐ番目、及びそれよりひとつ大きいＰ＋１番目であることを示し、(Q)、及び(Q+1)も同様である。

さて、ＲＴＣＰプロトコルのReceiver Reportには、当該ＲＴＣＰパケットの報告対象となる期間のパケット廃棄率が標準的に含まれている。これにより、ＲＴＰ／ＲＴＣＰサーバ３０３は、このパケット廃棄率を参照することにより、パケットのエラーが発生したか否かを知ることができる。また、拡張情報としてビットエラーを含むエラー率を含めることにより、パケット単位ではなく、ビット単位でのエラーの発生率を知ることも可能である。

このパケット廃棄率が「０」である場合、あるいは、ビット単位でのエラーの発生率を含む場合においてそのエラーの発生率も「０」である場合は、明らかにこのＲＴＣＰパケットが報告対象とする期間に該当する部分を送信バッファ３０７からは削除できる。これは、エラー検出モジュール３１１がその期間にエラーを検知しなかったことを意味し、再送要求が発生しないため、削除が可能である。このような場合に送信バッファ３０７に記録されている対象データを削除する処理を明確化するため、図７では、削除７０９を矢印で示している。

なお、再送要求クライアント３１２と再送サーバ３１３との間で再送に利用される通信手順が充分信頼性の高いものである場合、再送済みの動画像データは、送信バッファ３０７より削除することができる。動画像データのデータサイズは概して大きなものである。このため、ＲＴＣＰパケットにおけるReceiver Reportによりエラーがないと判断される場合、または再送済みとなった場合に、それぞれの対象となるデータを送信バッファ３０７から削除する。これにより、送信バッファ３０７のサイズをより小さくすることができる。

（第２の実施形態）
本実施形態では、要求型の映像サーバシステムであるビデオ・オン・デマンドに適用した場合について説明する。本実施形態のネットワーク構成の論理接続図を図８に示す。本実施形態における映像伝送システムは、映像データを保存するネットワーク・ストレージ８０１と、映像取得の要求を管理するセッション・サーバ８０２と、映像を配信するメディア・サーバ８０３と、通信エラー状態を管理し要求に応じて再送処理を行う再送サーバ８０４と、映像を要求する再生装置１０２とから構成されている。

再生装置１０２は、図８には２つ示しているが、１つであってもよいし、３つ以上の複数であってもよい。また、再生装置１０２は、第１の実施形態で示した再生装置１０２と本質的に同等のものであるため、同一の番号を付している。

セッション・サーバ８０２も同様に、第１の実施形態で示した接続制御サーバモジュール１０５を含んでいる。但し、第１の実施形態と大きく異なる点は、セッション・サーバ８０２に映像データを送出する機能を含んでいないという点である。すなわち、本実施形態では、第１の実施形態において前述した映像情報の送信機能（配信機能）は、メディア・サーバ８０３に含まれており、映像情報の再送機能は、再送サーバ８０４に含まれている。

また、第１の実施形態で示した動画像生成モジュール１０７は、本実施形態では含まれておらず、すでに生成された動画像データ、すなわち映像データがネットワーク・ストレージ８０１に保存されている。なお、本実施形態においては、第１の実施形態の基本的な構造と同等であり、第１の実施形態におけるネットワークカメラ１０１が分散されたサーバ群として構成されているものである。このため、ここでは、第１の実施形態と異なる部分についてのみ説明を行う。

図８に示すように、メディア・サーバ８０３には、映像情報送信モジュール８０５が含まれている。この映像情報送信モジュール８０５は、図３で示したＲＴＰ／ＲＴＣＰサーバ３０３に相当するものであり、専ら、接続制御サーバモジュール１０５の指示により、指定された映像情報を送信する機能を果たしている。

具体的には、接続制御サーバモジュール１０５と映像情報送信モジュール８０５とにおけるそれぞれの動作プロセスによりプロセス間通信によって互いに信号のやり取りを行う。接続制御サーバモジュール１０５は、映像情報送信モジュール８０５に対し、ネットワーク・ストレージ８０１に保存されている映像データなどを再生装置１０２に送信するように指示する。そして、映像情報送信モジュール８０５は送信を依頼されると、依頼された映像データを適切な形式で再生装置１０２に送信する。

また、再送サーバ８０４には、映像情報再送モジュール８０６が含まれている。この映像情報再送モジュール８０６は、図３で示した再送サーバ３１３に相当するものであり、専ら、要求に従って映像情報の必要な部分を再送する機能を果たしている。この場合、第１の実施形態において図３を参照しながら説明したように、再送要求クライアント３１２を含む再生装置１０２からの要求により、映像情報の必要な部分の再送を、直接行ってもよい。また、映像情報の必要な部分の再送を、接続制御サーバモジュール１０５のような別モジュールを介して行ってもよい。

次に、図８を参照しながら本実施形態における処理の大きな流れについて説明する。
まず、再生装置１０２は、例えばＵＲＬにより一意に与えられるアドレスにより、セッション・サーバ８０２に対して接続し、セッションを確立する。図８には、そのアドレスをＵＲＬ１（８１０）と示す。

セッションを確立すると、セッション・サーバ８０２の接続制御サーバモジュール１０５は、メディア・サーバ８０３の映像情報送信モジュール８０５に対して、要求された映像情報を指定して、映像情報の送信準備を行うように指示する。その一方で、接続制御サーバモジュール１０５は、準備が完了したことを確認するとともに、再生装置１０２に対して、メディア・サーバ８０３より映像情報を取得するためのＵＲＬ情報としてＵＲＬ２（８１１）を通知する。同時に、再送サーバ８０４よりエラー時の再送を行うためのＵＲＬを明らかにするため、再生装置１０２に対して、映像情報再送モジュール８０６を介して再送データを取得するためのＵＲＬ３（８１２）を通知する。

このようにすることにより、再生装置１０２は、映像情報を通常に受信するための方法と、再送を要求するための方法とを取得することができる。再生装置１０２は、映像情報の受信中にエラーを検知した場合、ＵＲＬ３（８１２）により、第１の実施形態と同様に再送要求を行って必要な映像情報の一部を取得することが可能となる。

より具体的に説明するために、図９を参照しながら、MPEG-2 TSデータをXML Web Serviceを用いて取得する例について説明する。図９は、XML Web Serviceを用いたセッション確立のメッセージ交換を含むデータフローの例を示す図である。

再生装置１０２からの映像データの要求は、最初にセッション・サーバ８０２に送られる。送られる映像データの要求し、セッションを確立する処理９０１におけるメッセージ９１１の例を図９に示す。このメッセージ９１１により、ＸＭＬデータ形式にて、映像コンテンツ（映像データ）の取得要求（Get Content）をそのソース情報（source）とともに送っている。ソース情報は、すなわち、要求する映像コンテンツを特定する情報である。

セッション・サーバ８０２は、セッション確立のため、内部的にこの接続を記録する処理を行うとともに、メディア・サーバ８０３に対して映像データそのものを送信するよう指示する処理９０２を行う。さらに、実装上必要であれば、再送サーバ８０４にもセッション情報を通知する処理９０３を行う。

また、セッション・サーバ８０２は、映像を要求してきた再生装置１０２に対しては、セッション確立のメッセージ９１４を送り返す処理９０４も行う。このメッセージ９１４では、ＸＭＬデータ形式にて、映像コンテンツの取得要求の返答（Get Content Response）であることを示している。このメッセージ９１４により、確立したセッションのＩＤ（session）とそのソース情報（source）と、再送要求のための接続情報（retransmit）とを送り返している。

ソース情報には、いくつかの付加情報が追加されているが、この付加情報は、再生装置１０２に対して映像情報の詳細を通知するためのものである。なお、付加情報には、再送要求のための接続情報が含まれている。この接続情報が含まれていることにより、再生装置１０２は、必要に応じて再送要求を行うことができる。

続いて、メディア・サーバ８０３は再生装置１０２にデータを送る処理９０５を行う。このデータは、映像情報そのものである。例えば、パケットが欠落し、再生装置１０２側で保存のために必要であるといった理由がある場合は、この時に再生装置１０２は再送を要求する処理９０６を行うことができる。この再送を要求する処理９０６により送られるメッセージが、図９に示すような再生装置１０２から再送サーバ８０４に送られるメッセージ９１６である。

図９に示すように、映像の再送要求を示すメッセージ（Retransmit）９１６に、セッションを特定するためのセッション情報（session）、ソース情報（source）、及び映像の必要部分を特定する部分指定情報（part）が含まれている。このセッション情報とソース情報とにより、再送サーバ８０４は、再送すべき映像情報を特定することができ、さらに、部分指定情報により、その特定された映像情報の中のさらに必要な特定部分を決定することができる。

具体的には、タイムスタンプ（ＴＳ）５０５とトランスポートストリーム中のパケットの位置（TS_ Packet）とにより必要な特定部分を決定することができる。なお、タイムスタンプやトランスポートストリームは、ＭＰＥＧ−２符号化によるストリーム形式内の情報であるが、ストリームの形式によって、こうしたパラメータ類は異なるものとなる。

このようにして送られた再送要求に対して、再送サーバ８０４は、再生装置１０２に返答するためにメッセージ９１７を送る処理９０７を行う。図９に示す例では、ＸＭＬデータ形式にて、映像の再送要求の返答（Retransmit Response）であることを示している。また、返答のメッセージ９１７には、要求された映像データの部分となる実際のデータをＸＭＬ中に適した形式にエンコード（encode）した形式が含まれている。

以上のように本実施形態においては、再送用のＵＲＬを受信側に通知することにより、受信側で再送のタイミングや必要性を任意に判断できる。このため、このようなリアルタイム性を重視する表示とデータ整合性を重視する保存とを両立させたい場合には、特に有効に機能する。

（本発明に係る他の実施形態）
本発明の目的は、以下の方法によっても達成される。まず、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵまたはＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施例の機能が実現される。また、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOperating System（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する方法がある。そして、前記ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。

また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、その他の方法として、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記録媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

本発明の第１の実施形態に好適なシステムの構成例を示す概念図である。 本発明の第１の実施形態に係るネットワークカメラ及び再生装置の内部構成例を示すブロック図である。 本発明の第１の実施形態において、ＲＴＳＰ、及びＲＴＰプロトコルを動画像データの送出に利用したシステム構成例を示すブロック図である。 本発明の第１の実施形態において、ＲＴＳＰプロトコルによるメッセージ交換の一例を示す図である。 ＲＴＰパケットの生成を模式的に示す図である。 本発明の第１の実施形態に係る再生装置における処理手順の一例を示すフローチャートである。 本発明の第１の実施形態に好適な送信バッファの処理の一例を示す図である。 本発明の第２の実施形態に係るネットワーク構成例を示す図である。 本発明の第２の実施形態において、セッション確立のメッセージ交換を含むデータフローの一例を示す図である。

符号の説明

１０１ ネットワークカメラ
１０２ 再生装置
１０３ 操作部
１０４ 接続制御クライアントモジュール
１０５ 接続制御サーバモジュール
１０６ ストリームサーバモジュール
１０７ 動画像生成モジュール
１０８ ストリームクライアントモジュール
３０１ ＲＴＳＰクライアント
３０２ ＲＴＳＰサーバ
３０３ ＲＴＰ／ＲＴＣＰサーバ
３０４ ＲＴＰ／ＲＴＣＰクライアント
３０５ 符号化バッファ
３０６ ＲＴＰパケット化モジュール
３０７ 送信バッファ
３０８ 受信バッファ
３０９ 再構成モジュール
３１０ 復号化バッファ
３１１ エラー検出モジュール
３１２ 再送要求クライアント
３１３ 再送サーバ

Claims (17)

1. 動画像データを含む映像情報を映像受信装置に対して通信回線を介して送信する映像送信装置であって、
   前記映像受信装置に送信する映像情報を再送するための情報を含む再送要求接続情報を提供する再送要求接続情報提供手段と、
   前記映像受信装置との通信の接続制御を行う接続制御手段と、
   前記接続制御手段によって接続制御された通信により、前記再送要求接続情報提供手段により提供される再送要求接続情報と前記映像情報とを前記映像受信装置に送信する映像情報送信手段と、
   前記映像受信装置から送られる前記再送要求接続情報に基づいた再送要求を受信する再送要求受信手段と、
   前記再送要求受信手段により受信された再送要求に従って、前記映像情報の特定の部分を再送する映像情報再送手段とを備えることを特徴とする映像送信装置。
2. 前記映像情報を送信バッファに蓄積する映像情報蓄積手段を備え、
   前記映像情報送信手段は、前記送信バッファに蓄積された映像情報を前記映像受信装置に送信し、
   前記映像情報再送手段は、前記送信バッファに蓄積された映像情報を前記映像受信装置に再送することを特徴とする請求項１に記載の映像送信装置。
3. 前記映像情報蓄積手段は、前記映像受信装置において前記映像情報にエラーがないと判断した場合には、前記送信バッファから前記映像情報を削除し、
   前記映像受信装置において前記映像情報にエラーがあると判断した場合には、前記映像情報再送手段により前記映像情報の特定の部分を再送した後に、前記送信バッファから前記映像情報を削除することを特徴とする請求項２に記載の映像送信装置。
4. 前記再送要求接続情報は、前記映像情報の格納先を示すＵＲＬを含むことを特徴とする請求項１〜３の何れか１項に記載の映像送信装置。
5. 前記映像情報送信手段は、ＲＴＳＰプロトコルを用いた接続制御に基づいて、ＳＤＰプロトコルによる再送要求接続情報を送信することを特徴とする請求項１〜４の何れか１項に記載の映像送信装置。
6. 前記映像情報再送手段は、ＲＴＳＰプロトコルによる接続制御により利用されるセッションＩＤと、ＲＴＰプロトコルによる通信の制御によって指定されるシークエンス番号またはタイムスタンプとに基づいて、前記映像情報の特定の部分を再送することを特徴とする請求項１に記載の映像送信装置。
7. 前記映像情報再送手段は、rtpmap情報に基づいて、前記映像情報の特定の部分を再送することを特徴とする請求項１に記載の映像送信装置。
8. 請求項１〜７の何れか１項に記載の映像送信装置と、撮像手段とを備えたことを特徴とするネットワークカメラ。
9. 動画像データを含む映像情報を映像送信装置から通信回線を介して受信する映像受信装置であって、
   前記映像送信装置との通信の接続制御を行う接続制御手段と、
   前記接続制御手段によって接続制御された通信により、前記映像送信装置から送信される再送要求接続情報と前記映像情報とを受信する映像情報受信手段と、
   前記映像情報受信手段により受信された映像情報のエラーを検出するエラー検出手段と、
   前記エラー検出手段により検出されたエラーに従って、前記映像情報の特定の部分を前記映像送信装置に再送要求する再送要求手段と、
   前記再送要求手段により再送要求した映像情報の特定の部分を受信する再送映像情報受信手段と、
   前記映像情報受信手段により受信された映像情報を再生する再生手段とを備えることを特徴とする映像受信装置。
10. 前記再生手段により再生される映像情報を記録装置に保存する保存手段を備え、
    前記保存手段は、前記映像情報受信手段または再送映像情報受信手段によって受信された映像情報を前記記録装置に保存することを特徴とする請求項９に記載の映像受信装置。
11. 前記映像情報受信手段は、ＲＴＳＰプロトコルを用いた接続制御に基づいて、ＳＤＰプロトコルによる再送要求接続情報を受信することを特徴とする請求項９または１０に記載の映像受信装置。
12. 請求項１〜７の何れか１項に記載の映像送信装置または請求項８に記載のネットワークカメラと、請求項９〜１１の何れか１項に記載の映像受信装置とを備えたことを特徴とする映像伝送システム。
13. 動画像データを含む映像情報を映像受信装置に対して通信回線を介して送信する映像送信方法であって、
    前記映像受信装置に送信する映像情報を再送するための情報を含む再送要求接続情報を提供する再送要求接続情報提供工程と、
    前記映像受信装置との通信の接続制御を行う接続制御工程と、
    前記接続制御工程において接続制御した通信により、前記再送要求接続情報提供工程において提供する再送要求接続情報と前記映像情報とを前記映像受信装置に送信する映像情報送信工程と、
    前記映像受信装置から送られる前記再送要求接続情報に基づいた再送要求を受信する再送要求受信工程と、
    前記再送要求受信工程において受信した再送要求に従って、前記映像情報の特定の部分を再送する映像情報再送工程とを備えることを特徴とする映像送信方法。
14. 動画像データを含む映像情報を映像送信装置から通信回線を介して受信する映像受信方法であって、
    前記映像送信装置との通信の接続制御を行う接続制御工程と、
    前記接続制御工程において接続制御した通信により、前記映像送信装置から送信される再送要求接続情報と前記映像情報とを受信する映像情報受信工程と、
    前記映像情報受信工程において受信した映像情報のエラーを検出するエラー検出工程と、
    前記エラー検出工程において検出したエラーに従って、前記映像情報の特定の部分を前記映像送信装置に再送要求する再送要求工程と、
    前記再送要求工程において再送要求した映像情報の特定の部分を受信する再送映像情報受信工程と、
    前記映像情報受信工程において受信した映像情報を再生する再生工程とを備えることを特徴とする映像受信方法。
15. 動画像データを含む映像情報を映像受信装置に対して通信回線を介して送信する映像送信方法の各工程をコンピュータに実行させるプログラムであって、
    前記映像受信装置に送信する映像情報を再送するための情報を含む再送要求接続情報を提供する再送要求接続情報提供工程と、
    前記映像受信装置との通信の接続制御を行う接続制御工程と、
    前記接続制御工程において接続制御した通信により、前記再送要求接続情報提供工程において提供する再送要求接続情報と前記映像情報とを前記映像受信装置に送信する映像情報送信工程と、
    前記映像受信装置から送られる前記再送要求接続情報に基づいた再送要求を受信する再送要求受信工程と、
    前記再送要求受信工程において受信した再送要求に従って、前記映像情報の特定の部分を再送する映像情報再送工程とをコンピュータに実行させることを特徴とするプログラム。
16. 動画像データを含む映像情報を映像送信装置から通信回線を介して受信する映像受信方法の各工程をコンピュータに実行させるプログラムであって、
    前記映像送信装置との通信の接続制御を行う接続制御工程と、
    前記接続制御工程において接続制御した通信により、前記映像送信装置から送信される再送要求接続情報と前記映像情報とを受信する映像情報受信工程と、
    前記映像情報受信工程において受信した映像情報のエラーを検出するエラー検出工程と、
    前記エラー検出工程において検出したエラーに従って、前記映像情報の特定の部分を前記映像送信装置に再送要求する再送要求工程と、
    前記再送要求工程において再送要求した映像情報の特定の部分を受信する再送映像情報受信工程と、
    前記映像情報受信工程において受信した映像情報を再生する再生工程とをコンピュータに実行させることを特徴とするプログラム。
17. 請求項１５または１６に記載のプログラムを記憶したことを特徴とするコンピュータ読み取り可能な記憶媒体。

Images