(57)【要約】【課題】  動画伝送中にバーストエラーが発生した場合に、リアルタイム性の要求を損なわない範囲でフレームの欠落を補償する技術を提供する。【解決手段】  通常は第１のフレームレートで取得されたフレーム情報を順に外部装置へ送出する。バーストエラーの発生が検出された場合、第１のフレームレートよりも低い第２のフレームレートで取得されたフレーム情報を順に保持手段に保持させる。バーストエラーが検出されなかった場合、第２のフレームレートで取得されたフレーム情報を順に保持手段に保持させるとともに、該保持手段に保持されたフレーム情報を古い順に第１のフレームレートで外部装置へ送出する。【選択図】  図３
2007166023.tif 000002
【特許請求の範囲】
【請求項１】
複数のフレーム情報を含む動画情報を外部装置に送出する情報処理装置であって、
フレーム情報を取得する取得手段と、
前記取得手段において第１のフレームレートで取得された前記フレーム情報を順に前記外部装置へ送出する送出手段と、
前記外部装置との通信におけるバーストエラーを検出する検出手段と、
フレーム情報を保持可能な保持手段と、
前記検出手段においてバーストエラーの発生が検出された場合、前記取得手段において前記第１のフレームレートよりも低い第２のフレームレートで取得されたフレーム情報を順に前記保持手段に保持させるように制御する第１制御手段と、
前記検出手段においてバーストエラーが検出されなかった場合、前記取得手段において前記第２のフレームレートで取得されたフレーム情報を順に前記保持手段に保持させるとともに、該保持手段に保持された前記フレーム情報を古い順に前記第１のフレームレートで前記送出手段に送出させるように制御する第２制御手段と、を備えることを特徴とする情報処理装置。
【請求項２】
前記保持手段に保持された前記フレーム情報を間引く間引手段を更に備えることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記間引手段は、前記保持手段の空き容量が予め定められた値を下回った場合に処理を行うことを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記第２制御手段の制御による前記送出により、前記保持手段が保持するデータ量が予め定められた値を下回った場合、前記第２制御手段は、前記取得手段において前記取得されたフレーム情報を前記保持手段に保持させずに、順に前記送出手段に前記外部装置へ送出させることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記取得手段は、撮像により前記複数のフレーム情報を取得することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
前記第１制御手段及び前記第２制御手段の少なくともいずれかは、
前記取得手段により取得される前記複数のフレーム情報において、互いに連続する該フレーム情報の差分が予め定められた値以下の場合は、当該連続するフレーム情報のうちの１つを前記保持手段に保持させることを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
【請求項７】
フレーム情報の解像度変換を行う変換手段を更に備え、
前記第１制御手段及び前記第２制御手段の少なくともいずれかは、前記取得されたフレーム情報を前記変換手段により縮小してから前記保持手段に保持させることを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
【請求項８】
複数のフレーム情報を含む動画情報を外部装置に送出する情報処理装置であって、
フレーム情報を取得する取得手段と、
前記取得手段において取得された前記フレーム情報を順に前記外部装置へ送出する送出手段と、
前記外部装置との通信におけるバーストエラーを検出する検出手段と、
フレーム情報を保持可能な保持手段と、
前記検出手段においてバーストエラーの発生が検出された場合、前記取得手段において取得されたフレーム情報を順に前記保持手段に保持させるように制御する第１制御手段と、
前記検出手段においてバーストエラーが検出されなかった場合、前記保持手段に保持された前記フレーム情報を古い順に読み出し、該読み出されたフレーム情報と前記取得手段において取得されたフレーム情報とに基づいて合成フレーム情報を生成し、該合成フレーム情報を前記送出手段に送出させるように制御する第２制御手段と、を備えることを特徴とする情報処理装置。
【請求項９】
複数のフレーム情報を含む動画情報を外部装置に送出する情報処理装置であって、
フレーム情報を取得する取得手段と、
前記取得手段において取得された前記フレーム情報を順に前記外部装置へ送出する送出手段と、
前記外部装置との通信におけるバーストエラーを検出する検出手段と、
フレーム情報を保持可能な保持手段と、
前記検出手段においてバーストエラーの発生が検出された場合、前記取得手段において取得されたフレーム情報を順に前記保持手段に保持させるように制御する第１制御手段と、
前記検出手段においてバーストエラーが検出されなかった場合、前記保持手段に保持された前記フレーム情報を古い順に読み出し、該読み出されたフレーム情報と前記取得手段において取得されたフレーム情報とを混在させて前記送出手段に送出させるように制御する第２制御手段と、を備えることを特徴とする情報処理装置。
【請求項１０】
前記第２制御手段は、前記読み出されたフレーム情報と前記取得されたフレーム情報とを交互に前記送出手段に送出させることを特徴とする請求項９に記載の情報処理装置。
【請求項１１】
前記フレーム情報の送出はＲＴＰに基づいて行われることを特徴とする請求項１乃至１０のいずれか１項に記載の情報処理装置。
【請求項１２】
前記検出手段は、前記外部装置による通信応答の有無に基づいて前記検出を行うことを特徴とする請求項１乃至１１のいずれか１項に記載の情報処理装置。
【請求項１３】
前記検出手段は、前記外部装置とのＲＴＣＰによる通信の有無に基づいて前記検出を行うことを特徴とする請求項１乃至１１のいずれか１項に記載の情報処理装置。
【請求項１４】
外部装置からフレーム情報を受け取り、該フレーム情報を表示する情報処理装置であって、
前記外部装置から前記フレーム情報及び当該フレーム情報の通し番号を受信する受信手段と、
フレーム情報を表示する表示手段と、
前記通し番号に基づいて、前記受信されたフレーム情報が第１フレーム情報と第２フレーム情報のいずれかに該当するかを判定する判定手段と、
前記判定手段において前記受信されたフレーム情報が第１フレーム情報と判定された場合は第１の解像度で、第２フレーム情報と判定された場合は第２の解像度で、該受信されたフレーム情報を前記表示手段に表示させる表示制御手段と、を備えることを特徴とする情報処理装置。
【請求項１５】
複数のフレーム情報を含む動画情報を外部装置に送出する撮像装置であって、
フレーム情報を撮像し、取得する取得手段と、
前記取得手段において第１のフレームレートで取得された前記フレーム情報を順に前記外部装置へ送出する送出手段と、
前記外部装置との通信におけるバーストエラーを検出する検出手段と、
フレーム情報を保持可能な保持手段と、
前記検出手段においてバーストエラーの発生が検出された場合、前記取得手段において前記第１のフレームレートよりも低い第２のフレームレートで取得されたフレーム情報を順に前記保持手段に保持させるように制御する第１制御手段と、
前記検出手段においてバーストエラーが検出されなかった場合、前記取得手段において前記第２のフレームレートで取得されたフレーム情報を順に前記保持手段に保持させるとともに、該保持手段に保持された前記フレーム情報を古い順に前記第１のフレームレートで前記送出手段に送出させるように制御する第２制御手段と、を備えることを特徴とする撮像装置。
【請求項１６】
フレーム情報を保持可能な保持手段を備え、複数のフレーム情報を含む動画情報を外部装置に送出する情報処理装置の制御方法であって、
フレーム情報を取得する取得工程と、
前記取得工程において第１のフレームレートで取得された前記フレーム情報を順に前記外部装置へ送出する送出工程と、
前記外部装置との通信におけるバーストエラーを検出する検出工程と、
前記検出工程においてバーストエラーの発生が検出された場合、前記取得工程において前記第１のフレームレートよりも低い第２のフレームレートで取得されたフレーム情報を順に前記保持手段に保持させるように制御する第１制御工程と、
前記検出工程においてバーストエラーが検出されなかった場合、前記取得工程において前記第２のフレームレートで取得されたフレーム情報を順に前記保持手段に保持させるとともに、該保持手段に保持された前記フレーム情報を古い順に前記第１のフレームレートで送出するように制御する第２制御工程と、を備えることを特徴とする情報処理装置の制御方法。
【請求項１７】
コンピュータを請求項１乃至１４のいずれかに記載の情報処理装置として機能させるためのプログラム。
【請求項１８】
請求項１７に記載のプログラムを格納したコンピュータで読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は動画の伝送技術に関し、特に、リアルタイムな伝送が要求される動画の伝送技術に関する。
【背景技術】
【０００２】
従来より、テレビ電話やテレビ会議システム、監視カメラシステムのように、カメラにより撮影されているリアルタイムな動画を遠隔地に伝送して閲覧及び蓄積するシステムが実用化されている。
【０００３】
このようなシステムの動画伝送においては、動画フレームそれぞれの信頼性よりも動画フレーム伝送のリアルタイム性が重視される。このため、例えば、通信路のデータ転送能力が低い場合においては、動画のフレームレートを下げたり、画質そのものを下げてでもリアルタイムに動画フレームを伝送する必要がある。また、通信路上でのエラーが生じたときには、リアルタイム性を損なわない範囲での再送信を行い、リアルタイム性を損なう場合においては動画フレームを破棄するような構成が求められる。
【０００４】
ただし、動画フレームを破棄する場合、動画がＭＰＥＧのように前方参照を行う画像圧縮方式により符号化されているシステムおいては、破棄された動画フレームが後に参照されるフレームであった場合には、後のフレームの復号も不可能となってしまう。この問題を回避するために、エラーが生じた場合には、前方参照をしない、イントラフレームを生成、送信する構成が知られている（例えば、特許文献１）。この構成によれば伝送エラーがおきた時点から時間的に後方の動画フレームに与える影響を最小限に抑えることができる。
【０００５】
また、このようなリアルタイムな動画を伝送し、通信路の性能に応じた最適な通信方式を選択できるようにするためのプロトコルが知られている。例えば、ＲＴＰ／ＲＴＣＰ（非特許文献１）、Ｈ．２６１ビデオストリームのＲＴＰペイロードフォーマット（非特許文献２）、また、動画ストリームを制御するためのプロトコルであるＲＴＳＰ（非特許文献３）が規格化され、実用化されている。
【０００６】
ＲＴＰ（Realtime Transport Protocol）は、フレームデータ等の動画データそのものの伝送に係る規格である。これに対し、ＲＴＣＰ(Realtime Control Protocol)は、ＲＴＰパケットの伝送において有益となる付加情報の伝送に係る規格である。ＲＴＣＰは、例えば、パケットロスの割合や遅延等の通信路に関する品質の周期的な検出、通知に関する規格を規定している。ＲＴＰは一般的にＴＣＰ（Transmission Control Protocol）ではなくＵＤＰ（User Datagram Protocol）上で実装され、ＲＴＣＰと共に用いられる。
【０００７】
更に通信路の発達、多様化に伴い、動画を無線上で伝送する機会も増えてきた。このため、例えば、テレビ電話のような通信路の途中に８０２．１１ｘに代表される無線ＬＡＮが介在する状況が一般化すると考えられる。しかしながら、このような無線通信は、必ずしも常時一定の通信帯域が保証されるわけではなく、外乱にも弱い。このため、無線による動画データ伝送においては、有線による動画データ伝送においてよりも、連続して通信エラーがおきる、いわゆるバーストエラーが発生しやすい。
【０００８】
通信路でのバーストエラー等の通信エラーによる画像劣化を最小限にするために、現状では、エラーの発生した通信パケットを必要に応じて再送したり、動画像に対してフレーム内補間やフレーム間補間を可能な限り行う等の対処がなされている。
【特許文献１】特開平７−１９３８２１号公報
【非特許文献１】ＲＦＣ１８８９:ＲＴＰ
【非特許文献２】ＲＦＣ２０３２:RTP Payload Format for H.261 Video Streams
【非特許文献３】ＲＦＣ２３２６:ＲＴＳＰ
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、動画を伝送するにあたって、通信路上でバーストエラーが発生した場合に、エラーの発生したフレームのすべてについて再送を行うと、動画のリアルタイム性が大きく損なわれてしまう。
【００１０】
一方で、バーストエラーが発生したフレームの伝送を全く行わないと、例えば、監視システムにおける動画伝送のように、周囲の変化を逐一監視、蓄積する必要のある用途の要求を満たすことができない。
【００１１】
本発明は、上記問題に鑑みなされたものであり、動画伝送中にバーストエラーが発生した場合に、リアルタイム性の要求を損なわない範囲でフレームの欠落を補償する技術を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記目的を達成するため、本発明による情報処理装置は以下の構成を備える。即ち、
複数のフレーム情報を含む動画情報を外部装置に送出する情報処理装置であって、
フレーム情報を取得する取得手段と、
前記取得手段において第１のフレームレートで取得された前記フレーム情報を順に前記外部装置へ送出する送出手段と、
前記外部装置との通信におけるバーストエラーを検出する検出手段と、
フレーム情報を保持可能な保持手段と、
前記検出手段においてバーストエラーの発生が検出された場合、前記取得手段において前記第１のフレームレートよりも低い第２のフレームレートで取得されたフレーム情報を順に前記保持手段に保持させるように制御する第１制御手段と、
前記検出手段においてバーストエラーが検出されなかった場合、前記取得手段において前記第２のフレームレートで取得されたフレーム情報を順に前記保持手段に保持させるとともに、該保持手段に保持された前記フレーム情報を古い順に前記第１のフレームレートで前記送出手段に送出させるように制御する第２制御手段と、を備える。
【発明の効果】
【００１３】
本発明によれば、動画伝送中にバーストエラーが発生した場合に、リアルタイム性の要求を損なわない範囲でフレームの欠落を補償する技術を提供することができる。
【発明を実施するための最良の形態】
【００１４】
以下、添付図面を参照して本発明に係る実施の形態を詳細に説明する。ただし、この実施の形態に記載されている構成要素はあくまでも例示であり、本発明の範囲をそれらのみに限定する趣旨のものではない。
【００１５】
＜＜第１の実施形態＞＞
（システム構成）
まず、本実施形態に係る情報処理装置を組み込んだシステム構成について、図１２を参照して説明する。図１２は本実施形態に係る情報処理装置を組み込んだシステム構成を示す図である。
【００１６】
図１２において、１２０１は、後述の受信装置１２０２へ動画を送信する送信装置である。送信装置１２０１は、例えば、監視カメラ、パーソナルコンピュータ（ＰＣ）やワークステーション（ＷＳ）、或いは、携帯電話、ＰＨＳ、携帯情報端末（ＰＤＡ）等で実現される。以下、送信装置１２０１は、監視カメラにより実現され、撮像された動画像を送信する状況を想定して説明を行う。
【００１７】
１２０２は、送信装置１２０１から送信された動画像を受信し、表示部に表示する受信装置である。受信装置１２０２は、例えば、ＰＣやＷＳ、或いは、携帯電話、ＰＨＳ、携帯情報端末（ＰＤＡ）等で実現される。
【００１８】
１２０３は、送信装置１２０１と受信装置１２０２が接続されたネットワークである。ネットワーク１２０３は、典型的には、インターネットであるが、有線／無線を問わず、公衆回線（アナログ回線、ＩＳＤＮ等）やＬＡＮ、ＷＡＮ、無線ＬＡＮ等のデータ送受信可能な回線であれば、どのような構成でもよい。ネットワークを用いた通信プロトコルは、例えば、ＴＣＰ／ＩＰ等を採用することができる。以下、送信装置１２０１、受信装置１２０２は、無線ＬＡＮ等の無線媒体を経由してネットワーク１２０３に接続している状況を想定する。
【００１９】
（ハードウェア構成）
次に、本実施形態における送信装置１２０１、受信装置１２０２のハードウエア構成について、図１を参照して説明する。図１は本実施形態におけるハードウェア構成を示すブロック図であり、図１（ａ）は送信側（送信装置）１２０１、図１（ｂ）は受信側（受信装置）１２０２を示している。
【００２０】
図１（ａ）において、１０１は、入射された光を電気信号に変換してフレームデータ（画像データ）を取得する撮像部であり、レンズや、レンズを通した光を電気信号に変換する光電変換素子等から構成される。
【００２１】
１０２は、送信装置１２０１全体の動作の制御や演算を行うＣＰＵ（Central Processing Unit）である。ＣＰＵ１０２は、アプリケーションプログラム、オペレーティングシステム（ＯＳ）や制御プログラム等を実行し、ＲＡＭ１０３にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。
【００２２】
１０３は、ＲＡＭ（Random Access Memory）であり、演算のワーク領域やバッファとして用いるためのランダムアクセスメモリである。１０４は、ＲＯＭ（Read Only Memory）であり、基本プログラム、基本データ等を格納した読込専用メモリである。
【００２３】
１０５は、撮像部１０１において電気信号に変換された画像データに対して、所定の符号化方式に基づき符号化（画像圧縮）処理を行う符号化部である。送信装置１２０１と受信装置１２０２との間におけるデータ伝送は符号化された画像データが通信される。
【００２４】
１０６は、外部装置とのフレームデータの送受信を含む通信を行うための通信部であり、ネットワークカード、無線通信アンテナ等から構成される。
【００２５】
１０７は、時刻を計時するリアルタイムクロック（ＲＴＣ：Real Time Clock）である。ＲＴＣ１０７は、画像圧縮された画像と音声の同期や、通信路上を伝送させるパケットへのタイムスタンプの付加等の処理において利用される。
【００２６】
１０８は、１０１〜１０７の各ブロックの間でデータの送受信を行うためのバスである。
【００２７】
一方、  図１（ｂ）において、１１１は、受信装置１２０２全体の動作の制御や演算を行うＣＰＵである。ＣＰＵ１１１は、アプリケーションプログラム、ＯＳや制御プログラム等を実行し、ＲＡＭ１１２にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。
【００２８】
１１２は、ＲＡＭであり、演算のワーク領域やバッファとして用いるためのランダムアクセスメモリである。１１３は、ＲＯＭであり、基本プログラム、基本データ等を格納した読込専用メモリである。
【００２９】
１１４は、復号部であり、送信装置１２０１から受けとった符号化データを復号する処理を行う。
【００３０】
１１５は、外部との通信を行うための通信部であり、ネットワークカード、無線通信アンテナ等から構成される。画像データの受信は通信部１１５を介して行われる。
【００３１】
１１６は、時刻を計時するＲＴＣである。ＲＴＣ１０７は、受信した動画の画像と音声の同期を行うための指標等として利用される。
【００３２】
１１７は、受信した動画等の表示を行うための表示部である。
【００３３】
１１８は、１１１〜１１７の各ブロックの間でデータの送受信を行うためのバスである。
【００３４】
（状態遷移）
本実施形態において送信装置１２０１、受信装置１２０２がとりうる、通信に係る状態について図２を参照して説明する。図２は、送信装置１２０１と受信装置１２０２の間における通信の状態に係る状態遷移図である。
【００３５】
図２において、２０１は、送信装置１２０１と受信装置１２０２が通信を切断している状態である「通信切断状態」である。２０２は、送信装置１２０１と受信装置１２０２の間で接続処理を行っている最中の状態である「伝送準備中状態」である。そして、２０３は、動画を実際に伝送している状態である「動画伝送中状態」である。
【００３６】
また、動画伝送中状態２０３中には更に、「正常伝送状態」２０３ａ、「バーストエラー状態」２０３ｂ、「エラー復帰中状態」２０３ｃが含まれる。正常伝送状態２０３ａは、送信装置１２０１と受信装置１２０２との間で正常な画像伝送を行っている状態である。バーストエラー状態２０３ｂは、送信装置１２０１と受信装置１２０２との間の通信においてバーストエラーが発生した場合に遷移する状態である。エラー復帰中状態２０３ｃは、バーストエラーから復帰するための処理を行っている状態である。
【００３７】
状態の遷移は次のように行う。即ち、通信切断状態２０１において、動画の受信側（受信装置１２０２）から動画の送信側（送信装置１２０１）に通信要求を発行したことに伴い、伝送準備中状態２０２に遷移する。また、送信装置１２０１と受信装置１２０２との間の通信が確立し、動画の送信をする準備ができたら動画伝送中状態２０３の初期状態である、正常伝送状態２０３ａに遷移する。正常に動画送信が行われている状態（正常伝送状態２０３ａ）においてバーストエラーが検出されると、バーストエラー状態２０３ｂに遷移する。そして、バーストエラー状態２０３ｂにおいて、バーストエラーから復帰したことが検出されると、エラー復帰中状態２０３ｃに遷移する。エラー復帰中状態２０３ｃにおいてエラー復帰処理が行われ、処理が終了すると通常伝送状態２０３ａに戻る。また、動画の転送を終了すると、通信の切断を行い、通信切断状態２０１に遷移する。
【００３８】
送信装置１２０１と受信装置１２０２は、それぞれ、外部装置との通信の状況等に基づいて、上記のような状態遷移図に対応する状態遷移の管理を行う。
【００３９】
（動画伝送中状態における状態遷移）
次に、動画伝送中状態２０３における状態遷移について、図３を参照して説明する。図３は、動画伝送中状態２０３における通信のシーケンスを表す図である。
【００４０】
[正常伝送状態]
正常伝送状態２０３のある瞬間に、ステップＳ３０１のように、送信側（送信装置１２０１）は受信側（受信装置１２０２）へ、ｎ番目の動画フレームを転送した状況を考える。この場合、送信装置１２０１は、パケットを構成するデータに動画フレームの画像だけでなく、フレーム番号も付加して送信する。なお、図３には矢印１本で表現しているが、実際には複数の通信パケットで構成される場合もあり得る。
【００４１】
送信側１２０１はｎ番目のフレームを転送した直後に、送信したフレーム、即ち、ｎ番目のフレームをバファリングする（ステップＳ３０２）。フレームが前方または後方参照する符号化方式により符号化されている場合は、イントラフレームに再符号化して、バファリングする。以下、説明の簡略化のため、フレームのバファリングはイントラフレームに再符号化して行うものとする。なお、フレームのバファリングは、図１（ａ）の構成であれば、例えば、ＲＡＭ１０３にフレームデータを蓄積することにより行う。
【００４２】
受信側１２０２はｎ番目のフレームを受信したら、受信した旨のＡｃｋを送信装置１２０１へ返す（ステップＳ３０３）。ただし、Ａｃｋには、フレーム番号を識別する情報が含まれる。Ａｃｋを受信した、動画の送信側１２０１は、Ａｃｋの受信に応じて、バファリングされたｎ番目のフレームをバッファから削除する（ステップＳ３０４）。正常に動画が伝送されている間はこのような処理を繰り返す。
【００４３】
[バーストエラー状態]
次に、バーストエラーがおきた場合の動作について説明する。ステップＳ３２１において、ｍ番目の動画フレームを送信側１２０１から受信側１２０２に転送を試みるがパケットロスし、受信側１２０２には到達しなかった状況を考える。この場合、ステップＳ３２１の時点では、まだ送信側１２０１と受信側１２０２に伝送エラーの有無は検出できていない。送信装置１２０１は、正常配信状態２０３ａにおける処理と同様に、ｍ番目の動画フレームの送信に応じて当該動画フレームをイントラフレームに再符号化して、バファリングする（ステップＳ３２２）。
【００４４】
送信装置１２０１は、次のｍ＋１番目の動画フレームに関しても同様に、ステップＳ３２３で転送を試みるとともに、当該フレームをイントラフレームに再符号化して、バファリングする（ステップＳ３２４）。この場合、バーストエラーの状態から復帰していないため、ｍ＋１番目のフレームはパケットロスし、受信側１２０２に到達できない。
【００４５】
一方、受信側１２０２は期待したｍ番目のフレームのデータが一定時間経過しても到達しないことを検出し、フレーム番号ｍの再送要求を出す（ステップＳ３２５）。再送要求に係る情報にはフレーム番号を識別する情報が含まれる。しかし、再送要求（ステップＳ３２５）したパケットもバーストエラーにより、画像送信側１２０１に再送要求が到達しない。
【００４６】
次にｍ＋２番目の動画フレームについて動画送信側１２０１は転送を試みるとともに、当該フレームをイントラフレームに再符号化してバファリングする（ステップＳ３２７）。このフレームもバースト（パケット）エラーにより受信側１２０２に到達しない（ステップＳ３２６）。
【００４７】
受信側１２０２は、ｍ番目のフレームの再送要求に対する動画フレームの転送を待つが、ｍ番目のフレームの動画データが一定期間到達しなければ、再送要求を繰り返し行う（ステップＳ３２８、Ｓ３３１、Ｓ３３４）。また、送信側１２０１も送信した動画に対するＡｃｋが一定期間帰ってこなければ、リアルタイムに送るべき次の動画フレームの送信を中断し、イントラフレームに再符号化してバファリングする処理のみ行う（ステップＳ３２９、Ｓ３３０、Ｓ３３３）。この時点で、送信装置１２０１、受信装置１２０２は、それぞれバーストエラー状態２０３ｂに遷移する。
【００４８】
バーストエラー状態２０３ｂに遷移した時点で、送信側１２０１が本来リアルタイムに送信すべき動画フレームのフレームレートが高い場合、全てのフレームをバファリングすると、送信装置１２０１のバッファ領域がすぐに満杯になってしまう。このため、バーストエラー状態２０３ｂにおいて、送信装置１２０１は、動画データのフレームレートを通常時よりも下げてバファリングを行う。なお、フレームレートは、単位時間当たりに取得又は送出されるフレーム数である。
【００４９】
また、更に、バッファの空き状態を監視しておき、バッファの空き容量が少なくなったことに応じて、バッファ蓄積された画像データを間引く処理を行うようにしてもよい。バッファの空き容量が少なくなったことは、例えば、バッファの空き容量が所定値を下回ったことに基づいて検出することができる。図３の例では、ステップＳ３３２において、フレーム番号ｎ＋１、ｎ＋３のフレームデータを削除（間引き）している様子を示している。
【００５０】
もし、バファリングされている動画フレームが他のフレームから前方参照又は後方参照される画像である場合、このフレームを削除してしまうと、このフレームを参照する他のフレームの復号ができなくなってしまう。このため、フレームデータを間引く処理を行う場合、フレームデータをイントラフレームに変換してからバッファに蓄積することが必須である。
【００５１】
[エラー復帰中状態]
通信環境が、バーストエラーの状態から正常の状態に復帰すると、受信側１２０２から送信側１２０１への再送要求が成功する。即ち、再送要求が送信側１２０１へ到達する（ステップＳ３４１）。再送要求が送信装置１２０１へ到達すると、エラー復帰中状態２０３ｃへ遷移する。
【００５２】
送信側１２０１はフレーム番号ｍの再送要求Ｓ３４１に応じて、バッファ中のフレーム番号ｍのフレームを受信側１２０２へ送信する（ステップＳ３４２）。さらに、本来ならば（正常伝送状態２０３ａであれば）この時点でリアルタイムに送信するフレーム番号ｒを、受信側１２０２へ送信せずにイントラフレームに符号化して、バファリングする（ステップＳ３４３）。
【００５３】
そして、画像の受信側１２０２はステップＳ３４４において、フレーム番号ｍの画像フレームの受信に応じて、フレーム番号ｍのフレームについてのＡｃｋを返す。一方、画像の送信側１２０１は、Ａｃｋの受信に応じて、バファリングしたフレーム番号ｍのデータをバッファから削除する。
【００５４】
このように、送信側１２０１は、既にバファリングされた古い動画フレームから順次受信側１２０２に送信しながら、リアルタイムに送信すべき画像フレームをバッファに蓄積する。ここで重要なのは、本実施形態に係る構成においては、本来ならばリアルタイムに送信すべき画像フレームを、古い動画フレームの送信・削除に係るレートよりも、十分低い（遅い）フレームレートでバッファに蓄積するということである。これにより、受信側１２０２は、追いかけ再生的な動画表示を行うことができる。
【００５５】
このように、本来ならばリアルタイムに送信すべき動画フレームを、十分遅いフレームレートで蓄積しながら、既に蓄積された動画フレームを送信することで、ある一定の時間経過後に、バファリングされた動画データがなくなる。そして、リアルタイムに送信すべきデータをそのままリアルタイムに受信側１２０２に転送可能となる。バファリングされた動画データがなくなった時点で、正常伝送状態２０３ａに戻る。
【００５６】
（伝送準備処理）
次に、図３を参照して上述した処理を実現するために、送信側１２０１と受信側１２０２が実行する処理について図４〜７を参照して説明する。
【００５７】
図４は、通信切断状態２０１から伝送準備中状態２０２、動画伝送中状態２０３になるまでの処理の流れを示したフローチャートである。図４において、図４（ａ）は動画送信側（送信装置）１２０１、図４（ｂ）は動画受信側（受信装置）１２０２のフローチャートである。
【００５８】
まず、動画送信側１２０１、動画受信側１２０２それぞれ初期化を行い（ステップＳ４０１、Ｓ４１１）、送信側１２０１は、受信側１２０２から通信要求を受信するまで待機する（ステップＳ４０２）。
【００５９】
動画受信側１２０２は動画受信を開始するときに、動画送信側１２０１に対して動画送信要求を行う（ステップＳ４１２）。動画送信要求は、例えば、受信装置１２０２のユーザによる指示入力や、タイマーイベントの発生等を契機として実行するように構成することができる。そして、ステップＳ４１３へ進み、後述する送信パラメータの問い合わせを送信側１２０１から受信するまで待機する。
【００６０】
動画送信側１２０１は、この動画送信要求Ｓ４１２を受信すると（ステップＳ４０２でＹＥＳ）、ステップＳ４０３へ進み、送信パラメータの問い合わせを動画受信側１２０２に行う。送信パラメータとは本実施形態の場合は、動画の解像度、フレームレート、動画の圧縮フォーマットのように、動画受信側１２０２が再生処理を行うのに適した動画に関するパラメータである。送信パラメータの問い合わせを動画受信側１２０２へ行った後、動画送信側１２０１は、送信パラメータを受信するまで待機する（ステップＳ４０４）。
【００６１】
動画受信側１２０２は動画送信パラメータの問い合わせを受信すると（ステップＳ４１３でＹＥＳ）、動画受信側１２０２での再生処理に適した動画に関するパラメータを動画送信側１２０１へ返信する（ステップＳ４１４）。そして、動画受信側１２０２の伝送準備処理を終了し、動画伝送中状態２０３へ遷移する。
【００６２】
動画送信側１２０１は、このパラメータを受信すると（ステップＳ４０４でＹＥＳ）、ステップＳ４０５において送信パラメータとして設定し、動画伝送中状態２０３に遷移する。
【００６３】
（動画伝送処理）
次に、動画伝送中状態２０３において動画送信側１２０１、動画受信側１２０２が実行する処理について、図５を参照して説明する。図５は、動画伝送中状態２０３において動画送信側１２０１、動画受信側１２０２が実行する処理の流れを示すフローチャートであり、図５（ａ）は動画送信側１２０１、図５（ｂ）は動画受信側１２０２の動作の流れを示している。
【００６４】
動画送信側１２０１は、送信する動画を構成する全てのフレームについて、先頭のフレームから順にステップＳ５０１〜Ｓ５１３の処理を行う。
【００６５】
動画送信側１２０１は、撮像部１０１において、ある番号ｎの動画フレームをキャプチャし（ステップＳ５０１）、続けて符号化部１０５においてフレームｎを予め設定された符号化方式により動画圧縮する（ステップＳ５０２）。そして、符号化されたフレームｎを動画受信側１２０２へ送信する（ステップＳ５０３）。
【００６６】
動画受信側１２０２は動画送信側１２０１から情報を受信すると（ステップＳ５２１でＹＥＳ）、この受信内容が強制通信終了通知であるか（ステップＳ５２２）、動画フレームであるか（ステップＳ５２３）を判定する。受信した情報が動画フレームの場合（ステップＳ５２３でＹＥＳ）は、受信したフレームに対応するＡｃｋを動画送信側１２０１に返す（ステップＳ５２４）。強制通信終了通知の場合（ステップＳ５２２でＹＥＳ）は、動画受信の処理を終了する。
【００６７】
一方、動画送信側１２０１はステップＳ５０３で動画フレームｎを伝送した後、フレームｎが他のフレームを参照するインターフレームであれば、ステップＳ５０４においてフレーム参照をしないイントラフレームに変換する。ここで、変換が不要な場合はステップＳ５０４の処理はスキップすることは言うまでもない。次に、必要に応じて変換されたフレームをバッファに蓄積する（ステップＳ５０５）。なお、正常伝送状態２０３ａでは、バッファの空き容量を確保しておく必要がある。このため、バッファが満杯、即ち、バッファの空き容量がない場合、又は、バッファの空き容量が所定値を下回った場合（ステップＳ５０６でＹＥＳ）は、バッファに蓄積されたフレームを間引く（ステップＳ５１１）。フレームの間引き方は上述の通りである。
【００６８】
次に、通信エラーが許容範囲であるかどうかをステップＳ５０７において判定する。具体的には、例えば、以前送ったフレームに対するＡｃｋの受信状況を監視し、送信したフレームに対するＡｃｋが一定時間内に帰ってきているかどうかを監視する。或いは、通信エラーが許容されるものであるか否かを、送信したフレームの数に対する返信のあったＡｃｋの数の割合に基づいて判定するようにしてもよい。通信エラーが許容範囲を超えていた場合（ステップＳ５０７でＮＯ）は、後述するバーストエラー処理を行い（ステップＳ５１２）、通信路が復帰したら、後述するエラー復帰処理（追いかけ送信処理）を行う（ステップＳ５１３）。
【００６９】
通信エラーが許容範囲内の場合（ステップＳ５０７でＹＥＳ）は、ステップＳ５０８、Ｓ５０９において、動画受信側１２０２から受信したＡｃｋに対応するフレームをバッファから削除する処理を行う。即ち、ステップＳ５０８において、既に送った動画フレームのＡｃｋの受信があるかどうかを確認する（ステップＳ５０８）。Ａｃｋがあった場合（ステップＳ５０８でＹＥＳ）は、Ａｃｋに相当するフレーム番号のフレームをバッファから削除する。
【００７０】
全てのフレームが送信されて、動画の送信そのものを終了する場合（ステップＳ５１０でＹＥＳ）は処理を終了し、全てのフレームの送信が終了していない場合（ステップＳ５１０でＮＯ）はステップＳ５０１に戻る。
【００７１】
（バーストエラー処理）
次に、図６を参照して、バーストエラー状態２０３ｂ時における処理について説明する。図６（ａ）は動画送信側１２０１、図６（ｂ）は動画受信側１２０２において実行する処理の流れを示したフローチャートである。また、図６（ａ）の処理は図５のバーストエラー処理（ステップＳ５１２）に相当する。
【００７２】
図６（ａ）のように、動画送信側１２０１は、所定の周期でステップＳ６０１〜Ｓ６０６の処理を繰り返し実行するループ処理を行う。まず、ステップＳ６０１において、動画のフレームのキャプチャ、即ち、撮像部１０１を用いた画像データの取得を行う。次に、キャプチャしたフレームをイントラフレームに変換し（ステップＳ６０２）、バッファに蓄積する（ステップＳ６０３）。もしこのときにバッファが満杯の場合、又は、空き容量が所定値を下回った場合（ステップＳ６０４でＹＥＳ）は、ステップＳ６０５でバッファに蓄積したフレームを間引き、ステップＳ６０６へ進む。バッファが満杯でない場合（ステップＳ６０４でＮＯ）は、何もせずにステップＳ６０６へ進む。
【００７３】
ステップＳ６０６では、以前にステップＳ６０６の処理を行ってから現時点までに、再送要求を受信していたか否かを判定する。再送要求を受信していた場合（ステップＳ６０６でＹＥＳ）は、バーストエラー状態２０３ｂからエラー復帰中状態２０３ｃに遷移し、バーストエラー処理を終了する。再送要求を受信していない場合（ステップＳ６０６でＮＯ）は、バーストエラー状態２０３ｂを継続し、ステップＳ６０１からステップＳ６０６のループ処理を継続する。尚、キャプチャを含むループ処理は、その周期が、正常伝送状態２０３ａにおけるループ処理（図５のステップＳ５０１〜Ｓ５１０）の周期よりも大きくなるように実行する。バーストエラー処理を終了するとステップＳ５１３の追いかけ送信処理、即ち、後述のエラー復帰処理を行う。
【００７４】
一方、図６（ｂ）のように、動画受信側１２０２は、所定の周期で、ステップＳ６１１〜ステップＳ６１３の処理を繰り返すループ処理を行う。即ち、ステップＳ６１１において動画送信側１２０１へ再送要求を行う。次に、ステップＳ６１２において、動画送信側１２０１からの情報の受信があったか否かの判定を行う。受信があった場合（ステップＳ６１２でＹＥＳ）はステップＳ６１１へ戻り、受信がなかった場合（ステップＳ６１２でＮＯ）はステップＳ６１３へ進む。ステップＳ６１３では、受信した情報が動画フレームであるか否かの判定をを行う。動画フレームの場合（ステップＳ６１３でＹＥＳ）は、通信路が復帰したと判断し、バーストエラー状態２０３ｂからエラー復帰中状態２０３ｃに遷移し、バーストエラー処理を終了する。動画フレームでない場合は、ステップＳ６１１へ戻り、ループ処理を継続する。なお、動画受信側１２０２のループ処理は、その周期が、正常伝送状態２０３ａにおけるループ処理（図５のステップＳ５２１〜Ｓ５２４）の周期よりも大きくなるように実行する。これにより、通常時よりも低いフレームレートで、取得されたフレーム情報を順にバッファに保持させることができる。
【００７５】
（エラー復帰処理）
次に、エラー復帰中状態２０３ｃでの処理の流れについて、図７を参照して説明する。図７は、エラー復帰処理の流れを示したフローチャートである。図７において、図７（ａ）は動画送信側１２０１のエラー復帰処理の流れ、図７（ｂ）は動画受信側１２０２のエラー復帰処理の流れをそれぞれ示している。なお、図７（ａ）は図５のステップＳ５１３のエラー復帰処理（追いかけ送信処理）に相当する。
【００７６】
動画送信側１２０１は、ステップＳ７０１において、ステップＳ６０６で受信した再送要求に含まれるフレーム番号ｍを参照し、フレーム番号ｍの画像をバッファから抽出する。そして、抽出したフレーム（番号ｍ）を動画受信側１２０２に送信する（ステップＳ７０２）。
【００７７】
次に、ステップＳ７０３において、送信したフレームに対応する番号ｍのＡｃｋが動画受信側１２０２から戻ってきたか否かを判定する。戻ってきている場合（ステップＳ７０３でＹＥＳ）はステップＳ７０４へ進む。戻ってきていない場合（ステップＳ７０３でＮＯ）はステップＳ７０２へ戻って再び番号ｍのフレームを送信する。尚、ステップＳ７０２、ステップＳ７０３の処理を繰り返す場合は、所定の周期毎に実行するように制御する。
【００７８】
ステップＳ７０４では、バッファにたまったフレームから、Ａｃｋに含まれるフレーム番号（ｍ）に対応するフレームとそれより古いフレームを削除する。そして、次（フレーム番号ｍ＋１）のフレームを送信する（ステップＳ７０５）。次に、ステップＳ７０６において、もし動画フレームキャプチャを行うタイミングであるか否かを判定する。動画フレームキャプチャを行うタイミングの場合（ステップＳ７０６でＹＥＳ）はステップＳ７０７へ進み、そうではない場合（ステップＳ７０６でＮＯ）はステップＳ７０９へ進む。ステップＳ７０７においては、キャプチャ、即ち、撮像部１０１を用いた画像データの取得を行う。次に、ステップＳ７０８において、キャプチャした画像データをバッファに蓄積する。そして、ステップＳ７０９へ進む。
【００７９】
なお、動画フレームをキャプチャするタイミングは、このエラー復帰中状態２０３ｃにおいて、バーストエラー状態２０３ｂに蓄積した動画フレームをいちはやく送信しつつ、送信中に発生した事象を少しづつキャプチャして実時間に追いつけるように設定する。このため、キャプチャは、比較的低いフレームレートで実行する必要がある。例えば、動画フレームキャプチャのタイミングを、図５のステップＳ５０１〜Ｓ５１０の周期と同等以上の大きさの周期に基づいて決定されるように構成することができる。
【００８０】
ステップＳ７０９においては、既に送信した動画フレームのＡｃｋが帰ってきていたか否かを判定する。Ａｃｋが帰ってきていた場合（ステップＳ７０９でＹＥＳ）はステップＳ７１０へ進み、帰ってきていない場合（ステップＳ７０９でＮＯ）はステップＳ７０５へ戻って処理を繰り返す。ステップＳ７１０では、帰ってきたＡｃｋに対応するフレームをバッファから削除する。ステップＳ７１１へ進む。
【００８１】
以上の処理により、バッファが空となれば、ステップＳ５１３の追いかけ処理（エラー復帰処理）は終了する。即ち、ステップＳ７１１では、バッファが空であるか否かを判定し、空の場合（ステップＳ７１１でＹＥＳ）はエラー復帰処理を終了する。空でない場合（ステップＳ７１１でＮＯ）はステップＳ７０５へ戻り、処理を終了する。なお、ステップＳ７１１では、バッファの保持するデータ量が所定値を下回っているか否かを判定し、下回っている場合はバッファが空であると見なして（ステップＳ７１１でＹＥＳ）エラー復帰処理を終了するようにしてもよい。この時点で、エラー復帰中状態２０３ｃから正常伝送状態２０３ａへ遷移する。
【００８２】
なお、上記の処理の途中において、再送要求を更に受信した場合はステップＳ７０１に戻り、再送要求に対応するフレームとそれ以前のフレームを削除する（ステップＳ７０４）ように構成することもできる。
【００８３】
一方、動画受信側１２０２は、図５（ｂ）の正常伝送状態２０３ａと同等の処理を実行する。即ち、ステップＳ７２１において、動画送信側１２０１から情報を受信するまで待機し、受信した場合（ステップＳ７２１でＹＥＳ）はステップＳ７２２へ進む。ステップＳ７２２では、受信した情報が動画フレームか否かを判定し動画フレームの場合（ステップＳ７２２でＹＥＳ）はステップＳ７２３へ進み、動画フレームでない場合（ステップＳ７２２でＮＯ）はステップＳ７２１へ戻る。ステップＳ７２３では、受信した動画フレームに対応するＡｃｋを動画送信側１２０１へ返す。
【００８４】
以上のように、本実施形態に係る構成は、バーストエラーが発生した場合に、バーストエラー中に起きた事象を通常よりも低いフレームレートで撮影・バファリングしつつ、エラー復帰時にはバファリングされた動画データを通常のフレームレートで転送する。これにより、追いかけ再生を実現することができ、特に監視用途においては、バーストエラー中におきた事象も細切れではあるが記録、再生することが可能である。また、バーストエラーが発生していない場合には、従来どおり良好なリアルタイムな監視画像の伝送が可能である。
【００８５】
なお、本実施形態においては、バーストエラー中に、定期的にキャプチャ動画フレームをバファリングする構成について説明したが、これに限られない。即ち、例えば、キャプチャした動画フレームと前のフレームとを比較して、動きがあったかどうかを検出し、動きがあったと検出された場合のみバファリングするように構成してもよい。動きの検出は、例えば、キャプチャしたフレームとその前のフレームとの差分を求め、この差分が所定の閾値以下であることに基づいて行うように構成することができる。なお、動きが検出された場合にのみ行うバファリングは、バーストエラー状態２０３ｂと、エラー復帰中状態２０３ｃの少なくともいずれかにおいて実行するように構成することができる。
【００８６】
また、本実施形態においては、送信側１２０１で動画フレームをバファリングするときに、イントラフレームに変換していたが、イントラフレームに変換するだけでなく、縮小してバファリングするように構成してもよい。これにより、バファリングするデータを削減することができる。
【００８７】
また、本実施形態においては、Ａｃｋを動画フレームごとに返していたが、複数の動画フレームに対応するＡｃｋをまとめて返すように構成してもよい。これにより、通信路の伝送量を軽減することができる。
【００８８】
＜＜第２の実施形態＞＞
以下、図８〜図９を参照して、本発明に係る第２の実施形態を説明する。本実施形態においては、国際標準規格として勧告されているＲＴＰ／ＲＴＣＰを用いた構成例について説明する。尚、システム構成やハードウエア構成、とりうる状態等、第１の実施形態と同様の構成部分については説明を省略する。
【００８９】
（動画伝送中状態における状態遷移）
図８は、ＲＴＰ／ＲＴＣＰを用いた動画伝送における通信のシーケンスを表す図である。なお、本実施形態においては、ＲＴＰ／ＲＴＣＰを用いた通信は、ＴＣＰではなくＵＤＰによるデータ伝送で実装される。ＵＤＰによるデータの伝送には、ＴＣＰと異なり、受信したパケットについてＡｃｋを返したり、自動的な再送を行うようなことは規定されていない。このため、ＵＤＰによる通信はリアルタイムな動画伝送に適している。
【００９０】
送信側１２０１は、動画フレームを動画フレームに相当するシーケンスナンバーとともにＲＴＰパケットに格納して受信側１２０２へ伝送する。更に、伝送遅延を検出するためのタイムスタンプや、送信ＲＴＰパケット数等の情報をＲＴＣＰパケットに格納して受信側１２０２へ伝送する。受信側１２０２は、受信したＲＴＰパケットの損失率や損失パケット数等の情報をＲＴＣＰに格納して送信側１２０１へ送る。
【００９１】
［正常伝送状態］
正常伝送状態２０３ａにおいて、送信側１２０１が受信側１２０２へ動画データを伝送している状況を考える（ステップＳ８０１〜Ｓ８０９）。送信側１２０１は、受信側１２０２へ、周期的にＲＴＣＰパケットを伝送する（ステップＳ８０１）。送信側１２０１から周期的に受信側１２０２へＲＴＣＰ伝送されるパケットをセンダ・レポート（以下ＳＲ）と呼ぶ。ＲＴＣＰ（ＳＲ）には、送信時のタイムスタンプや、前のＲＴＣＰ（ＳＲ）を伝送した後に送信したＲＴＰパケットの数等の情報が格納される。一方、受信側１２０２は、ＲＴＣＰ（ＳＲ）の受信に応じて、遅延時間やパケットロス率等を算出し、これらの情報が含まれるＲＴＣＰパケットをレシーバ・レポート（以下ＲＲ）として送信側１２０１へ送出する。ＳＲ、ＲＲの詳細は非特許文献１に開示されている。
【００９２】
また、送信側１２０１は、所定のタイミングでキャプチャして取得されたフレームを、ＲＴＰパケットに格納して受信側１２０２へ伝送する（Ｓ８０２、Ｓ８０４、Ｓ８０６）。そして、伝送した画像フレームをイントラフレームに変換してバファリングする（Ｓ８０３、Ｓ８０５、Ｓ８０７）。第１の実施形態では、受信側１２０２はフレームの受信ごとにＡｃｋを返していたが、本実施形態では、ＲＴＰの規格に順ずる実施形態のため、Ａｃｋは返さない。
【００９３】
このような動作を行う送信側１２０１の処理について、図９を参照して説明する。図９は、送信側１２０１の動作の流れを示すフローチャートである。図９のように、送信側１２０１は、ステップＳ９０１〜Ｓ９１５の処理を、送信する全てのフレームについてそれぞれ実行する。
【００９４】
まず、所定のタイミングでステップＳ９０１において動画を１フレームキャプチャし、所定の動画圧縮フォーマット（例えばＭＰＥＧ２）で圧縮する（ステップＳ９０２）。次に、圧縮されたフレームデータを含む情報に基づいてＲＴＰパケットを生成し、ＲＴＰヘッダを加えて受信側１２０２へ送信する（ステップＳ９０３）。
【００９５】
送信したフレームが、イントラフレームでなければ、ステップＳ９０４において、イントラフレームに変換して、ステップＳ９０５で、バッファに蓄積する。送信したフレームがイントラフレームの場合はステップＳ９０４の処理は不要である。バファリングの際にバッファが満杯（空き容量が所定値を下回る場合を含む）であるか否かを判定する（ステップＳ９０６）。満杯の場合（ステップＳ９０６でＹＥＳ）は、バッファに蓄積したフレームを間引き（ステップＳ９０７）、ステップＳ９０８へ進む。満杯でない場合（ステップＳ９０６でＮＯ）はステップＳ９０８へ進む。
【００９６】
ステップＳ９０８では、ＲＴＳＰ（ＳＲ）を送信するタイミングであるか否かを判定する。ＲＴＳＰ（ＳＲ）を送るタイミングの場合（ステップＳ９０８でＹＥＳ）は、センダ・レポートパケットを生成し、受信側１２０２へ送信し（ステップＳ９０９）、ステップＳ９１０へ進む。ＲＴＳＰ（ＳＲ）を送るタイミングでない場合（ステップＳ９０８でＮＯ）は、ステップ９１０へ進む。
【００９７】
ステップＳ９１０では、ＲＴＳＰ（ＲＲ）を受信したか否かを判定する。受信した場合（ステップＳ９１０でＹＥＳ）は、ステップＳ９１２へ進む。ステップＳ９１２では、バッファに蓄積された動画フレームから、その受信したパケットに対応するフレームデータ以前の全てのフレームデータを削除する。例えば、図８の例であれば、ステップＳ８０９において、直前に受信したステップＳ８０８のＲＴＣＰ（ＲＲ）に対応する動画フレーム迄、バッファに蓄積した動画フレームデータを削除する。そして、ステップＳ９１５へ進む。
【００９８】
送信側１２０１は、上記の処理を送信する全てのフレームについて実行する。ステップＳ９１５では、全てのフレームの送信処理が終了したか否かを判定し、終了している場合（ステップＳ９１５でＹＥＳ）は動画の送信処理を終了する。終了していない場合（ステップＳ９１５でＮＯ）はステップＳ９０１へ戻り処理を繰り返す。
【００９９】
［バーストエラー状態］
次に、図８のステップＳ８２１においてＲＴＳＰ（ＳＲ）を送信側１２０１から受信側１２０２に転送した直後にバーストエラーが発生した場合の処理について説明する。
【０１００】
はじめは送信側１２０１は、正常伝送状態２０３ａにおいてと同様にＲＴＰで動画フレームを受信側１２０２へ転送し（ステップＳ８２２、Ｓ８２４、Ｓ８２７・・）、動画フレームのバファリングを継続する（ステップＳ８２３、Ｓ８２５、Ｓ８２８・・）。この後、バーストエラーが発生すると、ＲＴＣＰのパケットは相互に届かない状態になる。送信側１２０１、受信側１２０２それぞれにおいて、相互にパケットの到達時間が推定できるが、このパケット到達時間を超えても到達しない場合伝送エラーがおきていると、送信側１２０１、受信側１２０２はそれぞれ判定する。
【０１０１】
この場合、送信側１２０１では、新たに動画フレームをキャプチャしても、伝送せずにイントラ画像に変換してバファリングする（ステップＳ８３４、Ｓ８３７）。バーストエラー状態２０３ｂにおいては、正常伝送状態２０３ａにおいてと同じフレームレートで動画をキャプチャしてバファリングしていては、すぐにバッファが一杯になってしまうため、フレームレートを落としてバファリングを行う。また、バッファがいっぱいになるかどうかを監視しておき、バッファがいっぱいになった場合（或いは空き容量が所定値を下回った場合）は既に蓄積された動画フレームを間引く処理を行う（ステップＳ８３６）。
【０１０２】
また、受信側１２０２については、ＲＴＣＰ（ＲＲ）を定期的に送信するが、最後に送信１２０１側から到着したＲＴＣＰ（ＳＲ）に対応するＲＴＣＰ（ＲＲ）を送信しつづける（ステップＳ８２６、Ｓ８３２、Ｓ８３５）。
【０１０３】
以上の処理は、図９のステップＳ９１３のバーストエラー処理を実行することにより行われるが、この処理は第１の実施形態における処理と同様のため、説明を省略する。
【０１０４】
［エラー復帰中状態］
ここで、ステップＳ８４１において、ＲＴＣＰ（ＲＲ）の伝送が成功すると、エラー復帰中状態２０３ｃへ遷移する。また、送信側１２０１はその受信したＲＴＣＰパケットに相当する送信側１２０１のパケットの次のバファリングされている動画フレームから順に転送をはじめる。図８の例では、ステップＳ８４１のＲＴＣＰ（ＲＲ）は、ステップＳ８２１のＲＴＣＰ（ＲＲ）に相当するパケットであり、このＳ８２１以後の動画フレームを伝送できていない可能性が高い。このため、送信側１２０１は、ステップＳ８２２で伝送すべき、実際にはバファリングされている動画フレーム（フレーム番号ｍ）をステップＳ８４２において伝送する。以後、送信側１２０１は、バファリングされている動画フレームを順に送る（ステップＳ８４４、Ｓ８４５、Ｓ８４７…）。
【０１０５】
また、この間にも、送信側１２０１は、少ないフレームレートで動画をキャプチャしながらバファリングをつづける（Ｓ８４３、Ｓ８４８…）。バッファに伝送すべき動画フレームがまだ残っている間は、キャプチャしたときには伝送せずに、バファリングのみ行う。また、ステップＳ８４１の、バーストエラーから復帰した後は、ＲＴＣＰについて正常伝送時と同様に送受信を行う。そして、動画送信側１２０１は、ＲＴＣＰ（ＲＲ）を受信したＲＴＣＰ（ＲＲ）に対応する、バファリングされた送信済み動画フレームを削除する（ステップＳ８５１、Ｓ８５８）。既にバファリングされている画像のうち、即座にＲＴＰで伝送すべき動画フレームがなくなったら、正常伝送状態２０３ａに戻る。
【０１０６】
以上の処理はステップＳ９１４のエラー復帰処理を実行することにより行われるが、この処理は第１の実施形態における処理と同様のため、説明を省略する。
【０１０７】
以上により、本実施形態においては、動画伝送の標準的なプロトコルである、ＲＴＰ／ＲＴＣＰを用いて第１の実施形態と同様の処理を行う。即ち、伝送のためのバーストエラーが発生した場合、バーストエラーからの復帰時にバーストエラー時にキャプチャした画像を古い順に伝送し、リアルタイムに追いつくように動画伝送の制御を行う。
【０１０８】
これにより、第１の実施形態と同様に、通信状態が良好な場合はリアルタイムに近い動画伝送が行えると同時に、バーストエラーが発生した場合においても、画像の取りこぼしを極力少なくすることができる。即ち、バーストエラーが発生した場合においても、動画をバファリングしておき、バーストエラーから復帰したときに、バーストエラー時の転送を行うことで、画像のとりこぼしを極力少なくすることができる。
【０１０９】
＜＜第３の実施形態＞＞
次に、図１０を参照して、本発明に係る第３の実施形態を説明する。第２の実施形態においては、国際標準規格として勧告されているＲＴＰ／ＲＴＣＰを用いた構成例について説明したが、本実施形態では、更にＡＲＱ（Automatic Repeat reQuest）を用いた構成例について説明する。
【０１１０】
システム構成や機器構成、とりうる状態等については、第１の実施形態で説明したものと同様であるため、説明を省略する。
【０１１１】
図１０は、ＲＴＰ／ＲＴＣＰに加えて、更にＡＲＱを用いた動画伝送における通信の流れを表す図である。なお、ＡＲＱは、ＲＴＰ／ＲＴＣＰとは別に、フレーム番号を指定して、再送要求を自動的に行うプロトコルに係るものである。図１０に示された通信の流れは、第２の実施形態において参照した図８に類似しているが、本実施形態では、動画フレームの再送要求をＡＲＱを用いて明確に行う点において相違する。
【０１１２】
図１０において、例えば、正常伝送状態２０３ａにおいて、フレーム番号がｎ＋２のフレームについてＲＴＰパケットロスがたまたま発生した状況を考える（ステップＳ１００６）。ただし、このパケットロスはバーストエラーによるものではない。
【０１１３】
この場合、受信側１２０２は、所定のタイムアウトイベントの発生に応じて、ｎ＋２番目のフレームに対する再送要求（ＮＡＣＫ）を発行し、送信側１２０１へ送出する（ステップＳ１００８）。ただし、この再送要求はＡＲＱに基づくものである。送信側１２０１はこの再送要求の受信に応じて、ｎ＋２番目のフレームを受信側１２０２へ再送する。受信側１２０２は、パケットエラーを発見するたびに再送要求を行ってもよいし、全てのエラーに対してではなく、必要に応じて再送要求を発行しても良い。
【０１１４】
次に、バーストエラーが発生した状況を考える。この場合、送信側１２０１からのＲＴＰ、ＲＴＣＰ（ＳＲ）と、受信側１２０２からのＲＴＣＰ（ＲＲ）、ＮＡＣＫの全てが通信相手に届かない。このような状況においては、受信側１２０２は、再送要求を定期的に送信しつづける（ステップＳ１０２９、Ｓ１０３５）。一方、送信側１２０１は、第１、２の実施形態と同様にキャプチャするフレームレートを下げて、動画フレームのデータをバファリングする（ステップＳ１０２３、Ｓ１０２５、Ｓ１０２８…）。バッファの空き容量が少なくなったときに、フレームを間引いたりする処理等は第１、第２の実施形態と同様である。
【０１１５】
バーストエラーから復帰し、ステップＳ１０４１において再送要求が送信側１２０１に到達すると、送信側１２０１は再送要求に係るフレーム番号ｍの動画フレームを受信側１２０２へ再送する。以後、バファリングされている動画フレームを順番に受信側１２０２へ送信し、同時に定期的にリアルタイムな動画フレームをキャプチャする。キャプチャした画像は、バッファが空になるまですぐには送信せず、バファリングのみを行う（ステップＳ１０４３、Ｓ１０４８…）。
【０１１６】
第１、第２の実施形態と同様に、エラー復帰時に、バッファに溜まった動画フレームを転送するよりもキャプチャとバファリングをする頻度が低ければ、ある時点で、バファリングされた動画フレームがなくなる。この時点で正常伝送状態２０３ａへ復帰することになる。
【０１１７】
以上により、本実施形態に係る構成においては、ＲＴＣＰのパケットの到着を待って更にＲＴＣＰの内容を解釈せずに再送要求（ＮＡＣＫ）により直接的に再送すべきものを特定することができる。このため、第２実施形態に係る構成よりも、処理負荷が減り、また、パケットの到着する頻度の低いＲＴＣＰよりも、状態の変化に対するレスポンスが良いシステムが構築される。
【０１１８】
＜＜第４の実施形態＞＞
次に、図１１を参照して、本発明に係る第４の実施形態を説明する。第１〜第３の実施形態においては、バーストエラーからの復帰時に、先にバーストエラー時にキャプチャした画像を全て転送した後、バーストエラーから復帰した後にキャプチャされた画像を伝送していた。そして、リアルタイムに追いついた、即ち、バッファが空になったら、正常伝送状態２０３ａに戻る処理を行っていた。これに対し、本実施形態においては、エラー復帰中状態２０３ｃにおいて、バーストエラー時に蓄積された画像の伝送と、エラー復帰中状態２０３ｃにおいてキャプチャされた画像の伝送の両方を行う。
【０１１９】
図１１は、本実施形態における通信の流れを表すシーケンス図である。正常伝送状態２０３ａと、バーストエラー状態２０３ｂにおける通信の流れは、第３の実施形態と同様であるため、説明を省略する。また、本実施形態では、第３の実施形態と同様に、ＲＴＰ／ＲＴＣＰ、ＡＲＱを用いる構成について例示的に説明するが、これに限られない。例えば、第１の実施形態と同様に、これらのプロトコルを用いない構成に本実施形態に係る構成を適用してもよい。
【０１２０】
バーストエラーから復帰して、送信側１２０１が、受信側１２０２から送られた再送要求を受信した状況（ステップＳ１１４１）を考える。この場合、送信側１２０１ではバーストエラーから復帰したと認識し、動画の伝送を再開する。
【０１２１】
動画の伝送をするにあたり、たまたま画像をキャプチャしたタイミングであれば、ＲＴＰパケットにのせて、キャプチャした動画フレーム（フレーム番号ｒとする）を伝送する。（ステップＳ１１４２）。次に、通信路が許す、または受信側１２０２が許すタイミングで、バーストエラー時にバファリングした動画フレームを受信側１２０２へ伝送する（ステップＳ１１４４、Ｓ１１４５）。以後、バーストエラー時にバファリングされた動画フレームを全て伝送するまで、これを繰り返す。
【０１２２】
受信側１２０２では、ＲＴＰパケットにのせてリアルタイムな動画フレーム（フレーム番号ｒ＋ｉ）を受信した場合は、画面全体に表示する。一方、バーストエラー時の動画フレームを受信した場合は、リアルタイムな動画に対してピクチャインピクチャで、小さく表示しても良いし、或いは、表示はせずに、ハードディスク装置等の大容量記憶装置（不図示）に蓄積するように構成してもよい。
【０１２３】
なお、受信側１２０２は、リアルタイムな動画フレームとバーストエラー時の動画フレームとの区別を、受信したフレームのフレーム番号に基づいて行うように構成することができる。例えば、エラーの復帰後に取得されたフレーム番号を参照し、この番号がバーストエラー発生の直前に取得したフレームの番号に連続する場合は、バーストエラー時の動画フレームと判定し、そうでない場合はリアルタイムな動画フレームと判定することができる。なお、エラーの復帰後に取得されたフレーム番号を参照し、この番号がバーストエラー発生の直前に取得したフレームの番号に連続するか否かの判定は、これらの番号の差分が所定値以下であるか否かに基づいて決定することができる。
【０１２４】
このように、可能な限りリアルタイムな動画を監視し、バーストエラーによりリアルタイムに表示することができなかったものは大容量記憶装置し、ユーザの指示入力等に応じて表示するような構成は、システムの用途によって要件を満たすことができる。例えば、監視システムの用途等において要件を満たすことができる。
【０１２５】
また、本実施形態においては、バーストエラーから復帰するための処理で、ＲＴＰパケットごとに、リアルタイムな動画フレームと、過去にバファリングされた動画フレームを別々に伝送していたが、これに限られない。例えば、リアルタイムな動画フレームと過去の動画フレームを画面分割して合成したり、ピクチャインピクチャの画像を生成してから、伝送するように構成してもよい。これにより、受信側１２０２は、リアルタイムな動画像と、バーストエラー時における動画像とを表示することができる。
【０１２６】
＜＜その他の実施形態＞＞
以上、本発明の実施形態例について詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様を取ることが可能である。具体的には、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。
【０１２７】
尚、本発明は、前述した実施形態の機能を実現するプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
【０１２８】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明の技術的範囲に含まれる。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含む。
【０１２９】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。
【０１３０】
プログラムを供給するための記録媒体としては、例えば、次のものが含まれる。即ち、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）等が含まれる。
【０１３１】
その他、プログラムの供給形態としては、次のようなものも考えられる。即ち、クライアント装置のブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明に係るコンピュータプログラム、或いは、圧縮され自動インストール機能を含むファイルをＨＤ等の記録媒体にダウンロードする形態も考えられる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０１３２】
また、次のような供給形態も考えられる。即ち、まず、本発明に係るプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布する。そして、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報の使用により暗号化されたプログラムを実行してコンピュータにインストールさせて本発明に係る構成を実現する。このような供給形態も可能である。
【０１３３】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他次のような実現形態も想定される。即ち、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【０１３４】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づいても前述した実施形態の機能が実現される。即ち、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【０１３５】
【図１】本実施形態におけるハードウェア構成を表す図である。
【図２】本実施形態における通信の状態遷移を表す図である。
【図３】第１の実施形態における通信のシーケンスを表す図である。
【図４】第１の実施形態における起動から通信伝送中状態になるまでの処理の流れを表す図である。
【図５】第１の実施形態における通信伝送中状態での処理の流れを表す図である。
【図６】第１の実施形態におけるバーストエラー状態での処理の流れを表す図である。
【図７】第１の実施形態におけるエラー復帰中状態での処理の流れを表す図である。
【図８】第２の実施形態における通信のシーケンスを表す図である。
【図９】第２の実施形態における通信伝送中状態での処理の流れを表す図である。
【図１０】第３の実施形態における通信のシーケンスを表す図である。
【図１１】第４の実施形態における通信のシーケンスを表す図である。
【図１２】本実施形態におけるシステム構成を表す図である。
【図１】
2007166023.tif 000003
【図２】
2007166023.tif 000004
【図３】
2007166023.tif 000005
【図４】
2007166023.tif 000006
【図５】
2007166023.tif 000007
【図６】
2007166023.tif 000008
【図７】
2007166023.tif 000009
【図８】
2007166023.tif 000010
【図９】
2007166023.tif 000011
【図１０】
2007166023.tif 000012
【図１１】
2007166023.tif 000013
【図１２】
2007166023.tif 000014