(57)【特許請求の範囲】
【請求項１】
１フィールド内のＮライン（Ｎは１以上）に相当する符号化単位で符号化された画像データを受信し、前記画像データに付加されたヘッダから前記画像データの復号開始時点を決定するための制御情報を検出するヘッダ検出部と；
前記画像データを前記符号化単位で割当てられた記憶領域にそれぞれ蓄積する蓄積部と；
前記ヘッダ検出部により検出された前記制御情報に基づいて前記画像データの復号開始時点を決定し、前記復号開始時点まで待機した後に前記符号化単位で復号開始を指示する復号開始指示部と；
前記復号開始指示部からの復号開始の指示を受けて前記蓄積部に蓄積された前記画像データを前記符号化単位で復号する復号部と；
前記画像データの送信開始時刻を指定する信号を前記画像データの送信元となる装置へ送信する同期制御部と；
を備え、
前記同期制御部は、通信環境の変動を吸収するための時間間隔を前記送信開始時刻との間に有する復号開始時刻を前記復号開始指示部に対して指定し、
前記復号開始指示部は、指定された前記復号開始時刻にさらに基づいて前記復号開始時点を決定する、
受信装置。
【請求項２】
前記ヘッダ検出部は、前記画像データに付加された通信ヘッダからデータ送信時点に対応する第１のタイムスタンプを検出する第１のヘッダ検出部と、前記画像データに付加された画像ヘッダから符号化時点に対応する第２のタイムスタンプを検出する第２のヘッダ検出部とを含む、請求項１に記載の受信装置。
【請求項３】
前記復号開始指示部は、前記ヘッダ検出部により検出された前記第１のタイムスタンプ及び前記第２のタイムスタンプの時間差に応じて前記復号開始時点を調整する、請求項２に記載の受信装置。
【請求項４】
前記復号開始指示部は、前記復号開始時点から順次前記符号化単位ごとに許容復号時間を計測し、前記許容復号時間が経過するごとに前記符号化単位での復号開始を指示する、請求項１に記載の受信装置。
【請求項５】
前記復号開始指示部は、前記符号化単位で復号させる対象の画像データの受信が完了していない場合に、受信が完了していない前記画像データの代わりにダミーデータを挿入する、請求項１に記載の受信装置。
【請求項６】
前記ダミーデータは、復号させる対象の前記画像データと同一のラインまたはラインブロックに対応する１ピクチャ以上前の画像データである、請求項５に記載の受信装置。
【請求項７】
前記復号開始指示部は、前記符号化単位での前記許容復号時間が終了した時点で、復号させる対象の画像データが残っている場合に、復号させる対象の前記画像データを削除させる、請求項４に記載の受信装置。
【請求項８】
前記復号開始指示部は、実行すべき処理を切替えるための切替え情報に基づいて、前記ヘッダ検出部によりピクチャの先頭を認識したことを示す制御情報が出力された後予め設定された一定の時間が経過した時点を前記復号開始時点として決定し、または、前記同期制御部により指定された前記復号開始時刻に基づいて前記復号開始時点を決定する、
請求項１に記載の受信装置。
【請求項９】
前記ヘッダ検出部は、前記画像データに付加された通信ヘッダからデータ送信時点に対応する第１のタイムスタンプを検出する第１のヘッダ検出部と、前記画像データに付加された画像ヘッダから符号化時点に対応する第２のタイムスタンプを検出する第２のヘッダ検出部とを含み、
前記復号開始指示部は、実行すべき処理を切替えるための切替え情報に基づいて、前記ヘッダ検出部により検出された前記第１のタイムスタンプ及び前記第２のタイムスタンプの時間差に応じて前記復号開始時点を調整し、または、前記同期制御部により指定された前記復号開始時刻に基づいて前記復号開始時点を決定する、
請求項１に記載の受信装置。
【請求項１０】
１フィールド内のＮライン（Ｎは１以上）に相当する符号化単位で符号化された画像データを受信する受信装置における受信方法であって：
前記画像データの送信開始時刻を指定する信号を前記画像データの送信元となる装置へ送信するステップと；
通信環境の変動を吸収するための時間間隔を前記送信開始時刻との間に有する復号開始時刻を指定するステップと；
前記送信元となる装置から前記画像データを受信するステップと；
前記画像データに付加されたヘッダから前記画像データの復号開始時点を決定するための制御情報を検出するステップと；
前記画像データを前記符号化単位で割当てられた記憶領域にそれぞれ蓄積するステップと；
指定された前記復号開始時刻及び検出された前記制御情報に基づいて前記画像データの復号開始時点を決定するステップと；
決定された前記画像データの復号開始時点まで待機するステップと；
前記符号化単位で復号開始を指示するステップと；
蓄積された前記画像データを前記復号開始の指示を受けて前記符号化単位で復号するステップと；
を含む、受信方法。
【請求項１１】
受信装置を制御するコンピュータを：
１フィールド内のＮライン（Ｎは１以上）に相当する符号化単位で符号化された画像データを受信し、前記画像データに付加されたヘッダから前記画像データの復号開始時点を決定するための制御情報を検出するヘッダ検出部と；
前記画像データを前記符号化単位で割当てられた記憶領域にそれぞれ蓄積する蓄積部と；
前記ヘッダ検出部により検出された前記制御情報に基づいて前記画像データの復号開始時点を決定し、前記復号開始時点まで待機した後に前記符号化単位で復号開始を指示する復号開始指示部と；
前記復号開始指示部からの復号開始の指示を受けて前記蓄積部に蓄積された前記画像データを前記符号化単位で復号する復号部と；
前記画像データの送信開始時刻を指定する信号を前記画像データの送信元となる装置へ送信する同期制御部と；
として機能させるためのプログラムであって、
前記同期制御部は、通信環境の変動を吸収するための時間間隔を前記送信開始時刻との間に有する復号開始時刻を前記復号開始指示部に対して指定し、
前記復号開始指示部は、指定された前記復号開始時刻にさらに基づいて前記復号開始時点を決定する、
プログラム。
【請求項１２】
１フィールド内のＮライン（Ｎは１以上）に相当する符号化単位で画像データを符号化する圧縮部；
及び、前記符号化単位で符号化された前記画像データの送信を受信装置から指定される送信開始時刻から開始する通信部；
を備える送信装置と：
前記符号化単位で符号化され、前記送信装置から送信された前記画像データを受信する通信部；
前記通信部により受信された前記画像データに付加されたヘッダから前記画像データの復号開始時点を決定するための制御情報を検出するヘッダ検出部；
前記画像データを前記符号化単位で割当てられた記憶領域にそれぞれ蓄積する蓄積部；
前記ヘッダ検出部により検出された前記制御情報に基づいて前記画像データの復号開始時点を決定し、前記復号開始時点まで待機した後に前記符号化単位で復号開始を指示する復号開始指示部；
前記復号開始指示部からの復号開始の指示を受けて前記蓄積部に蓄積された前記画像データを前記符号化単位で復号する復号部；
及び、前記送信開始時刻を指定する信号を前記送信装置へ送信する同期制御部；
を備える受信装置と：
を含む通信システムであって、
前記同期制御部は、通信環境の変動を吸収するための時間間隔を前記送信開始時刻との間に有する復号開始時刻を前記復号開始指示部に対して指定し、
前記復号開始指示部は、指定された前記復号開始時刻にさらに基づいて前記復号開始時点を決定する、
通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、受信装置、受信方法、プログラム、及び通信システムに関する。
【背景技術】
【０００２】
現在、インターネットやＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）など様々なネットワークを介して、画像データ（特に動画像データ）を転送するアプリケーションやサービスが広く利用されている。ネットワークを介して画像データを送受信する場合には、送信側で符号化（圧縮）処理によりデータ量を減少させた上でネットワークに送出し、受信側で符号化された受信データを復号（伸長）処理して再生するのが一般的である。  
【０００３】
例えば、画像圧縮処理の最も知られた手法として、ＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅｓ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）と呼ばれる圧縮技術がある。ＭＰＥＧ圧縮技術を用いる場合には、ＭＰＥＧ圧縮技術により生成されたＭＰＥＧストリームがＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）に従ったＩＰパケットに格納され、ネットワーク経由で配信される。そして、ＭＰＥＧストリームは、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）やＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔｓ）、携帯電話などの通信端末を用いて受信され、各端末の画面状に表示される。
【０００４】
このような状況の中、画像データの配信を主目的とする例えばビデオオンデマンドやライブ映像の配信、あるいはビデオ会議、テレビ電話などのアプリケーションにおいては、異なる能力を持つ端末に画像データが受信されることを想定する必要がある。
【０００５】
例えば、１つの送信源から送信される画像データは、携帯電話などの解像度の低いディスプレイと処理能力の低いＣＰＵを有する受信端末によって受信され、表示される可能性がある。また、それと同時に、デスクトップＰＣのように高解像度のモニタと高性能のプロセッサを有する受信端末によって受信され、表示される可能性もある。
【０００６】
このように、性能の異なる様々な受信端末に画像データが受信されることを想定する場合には、例えば送受信するデータの符号化を階層的に実行する、階層符号化と呼ばれる技術が利用される。階層符号化された画像データにおいては、例えば高解像度のディスプレイを有する受信端末向けの符号化データ、及び低解像度のディスプレイを有する受信端末向けの符号化データが選別して保持され、受信側で画像サイズや画質を適宜変更することができる。  
【０００７】
階層符号化が可能な圧縮・伸張方式としては、例えばＭＰＥＧ４とＪＰＥＧ２０００によるビデオストリームが挙げられる。ＭＰＥＧ４では、ＦＧＳ（Ｆｉｎｅ  Ｇｒａｎｕｌａｒｉｔｙ  Ｓｃａｌａｂｉｌｉｔｙ）技術が標準規格として取り込まれプロファイル化される予定であり、この階層符号化技術によりスケーラブルに低いビットレートから高いビットレートまで配信することが可能と言われている。また、ウェーブレット（Ｗａｖｅｌｅｔ）変換を基盤とするＪＰＥＧ２０００では、ウェーブレット変換の特徴を生かして空間解像度をベースにパケットを生成し、または画質をベースに階層的にパケットを生成することが可能である。また、ＪＰＥＧ２０００では、静止画だけではなく動画を扱えるＭｏｔｉｏｎ  ＪＰＥＧ２０００（Ｐａｒｔ３）規格により、階層化したデータをファイルフォーマットで保存することが可能である。
【０００８】
さらに、階層符号化を適用したデータ通信の具体案として提案されているものとして、離散コサイン変換（ＤＣＴ：Ｄｉｓｃｒｅｔｅ  Ｃｏｓｉｎｅ  Ｔｒａｎｓｆｏｒｍ）を基盤とするものがある。これは通信対象の例えば画像データをＤＣＴ処理し、ＤＣＴ処理により高域と低域とを区別して階層化を実現し、高域と低域との階層で区分したパケットを生成してデータ通信を実行する方法である。
【０００９】
このような階層符号化された画像データを配信する場合には、多くの場合リアルタイム性が要求されるが、現状ではリアルタイム性よりも大画面・高画質の表示が優先される傾向がある。
【００１０】
画像データの配信においてリアルタイム性を確保するためには、ＩＰベースの通信プロトコルとして、通常はＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）が用いられる。さらに、ＵＤＰの上のレイヤにおいてはＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）が用いられる。ＲＴＰパケットに格納されるデータフォーマットは、アプリケーションごと、即ち符号化方式ごとに定義された個々のフォーマットに従う。
【００１１】
また、通信ネットワークとしては、無線または有線によるＬＡＮ、光ファイバー通信、ｘＤＳＬ、電力線通信、またはＣｏ−ａｘといった通信方式が用いられる。これらの通信方式は年々高速化しているが、それを送信する画像コンテンツも高画質化している。
【００１２】
例えば、現在主流になっているＭＰＥＧ方式またはＪＰＥＧ２０００方式における代表的なシステムのコード遅延（符号化遅延＋復号遅延）は２ピクチャ以上であり、これでは画像データ配信における十分なリアルタイム性が確保されているとは言い難い。
【００１３】
そこで、近日、１ピクチャをＮ個のライン（Ｎは１以上）の集合に分割し、分割した集合（ラインブロックという。）ごとに画像を符号化することで遅延時間を短くする画像圧縮方式（以下、ラインベース・コーデックという。）が提案され始めている。ラインベース・コーデックの利点としては、低遅延のほか、画像圧縮の１単位で取り扱う情報が少ないことにより、高速処理やハードウェア規模の低減が可能といった利点がある。
【００１４】
ラインベース・コーデックを対象とする提案事例としては、次の例が挙げられる。下記特許文献１には、ラインベース・コーデックに基づく通信データについて、ラインブロックごとに適切に欠落データの補完処理を行う通信装置が記載されている。下記特許文献２には、ラインベース・コーデックを用いる場合の遅延の低減と処理の効率化を図った情報処理装置が記載されている。下記特許文献３には、ラインベース・ウェーブレット変換された画像データの低周波数成分を伝送することにより画質の劣化を抑える送信装置が記載されている。
【００１５】
【特許文献１】特開２００７−３１１９４８号公報
【特許文献２】特開２００８−２８５４１号公報
【特許文献３】特開２００８−４２２２２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１６】
しかしながら、ラインベース・コーデックによる画像圧縮方式については、技術的に未解決の点が残されている。その１つは、送受信端末間での同期獲得に関する問題である。
【００１７】
一般的に、ピクチャベースのコーデックでは、パケットのヘッダに挿入される時間情報（以下、タイムスタンプという）と、水平同期信号（ＶＳＹＮＣ）や垂直同期信号（ＨＳＹＮＣ）、ブランク期間の始めと終わりに付加される既知信号であるＳＡＶ（Ｓｔａｒｔ  ｏｆ  Ａｃｔｉｖｅ  Ｖｉｄｅｏ）及びＥＡＶ（Ｅｎｄ  ｏｆ  Ａｃｔｉｖｅ  Ｖｉｄｅｏ）を用いて、ピクチャまたはフレーム単位での再生処理が行われる。よって、受信側では、上記同期信号や上記既知信号を参考に、最短で１フレーム後に復号を開始することにより、比較的余裕を持って復号を行なうことができる。
【００１８】
これに対し、ラインベース・コーデックの場合、符号化単位時間がピクチャベースのコーデックに比べて短いため、必然的に、送受信の制御に使用できる時間がピクチャベースのコーデックに比べて短くなる。
【００１９】
また、ある符号化単位内で絵柄の難しいものをエンコードすると、一時的なデータ量が増大することにより、圧縮されたデータを伝送路に送信しきれず、データが送信バッファに一時的に蓄積される場合もある。そうした場合には、送信出力タイミングが本来送信すべき時間から遅れる状況が発生する。そして、送信出力タイミングが本来送信すべき時間から遅れると、受信側ではいつ復号を開始すればよいかの判断が難しい。よって、ラインベース・コーデックにおいても、低遅延のメリットを生かしながら、安定して容易に復号を開始すべきタイミングを判断できる方法が求められる。
【００２０】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、ラインベース・コーデックを用いた通信において安定して同期を獲得することのできる、新規かつ改良された受信装置、受信方法、プログラム、及び通信システムを提供することにある。
【課題を解決するための手段】
【００２１】
上記課題を解決するために、本発明のある観点によれば、１フィールド内のＮライン（Ｎは１以上）に相当する符号化単位で符号化された画像データを受信し、前記画像データに付加されたヘッダから前記画像データの復号開始時点を決定するための制御情報を検出するヘッダ検出部と、前記画像データを前記符号化単位で割当てられた記憶領域にそれぞれ蓄積する蓄積部と、前記ヘッダ検出部により検出された前記制御情報に基づいて前記画像データの復号開始時点を決定し、前記復号開始時点まで待機した後に前記符号化単位で復号開始を指示する復号開始指示部と、前記復号開始指示部からの復号開始の指示を受けて前記蓄積部に蓄積された前記画像データを前記符号化単位で復号する復号部と、を備える受信装置が提供される。
【００２２】
かかる構成によれば、ヘッダ検出部は、１フィールド内のＮライン（Ｎは１以上）に相当する符号化単位で符号化された画像データを受信し、前記画像データに付加されたヘッダから前記画像データの復号開始時点を決定するための制御情報を検出する。そして、蓄積部は、前記画像データを前記符号化単位で割当てられた記憶領域にそれぞれ蓄積する。また、復号開始指示部は、検出された前記制御情報に基づいて前記画像データの復号開始時点を決定し、決定した前記復号開始時点まで待機した後、前記符号化単位で復号開始を指示する。そして、復号部は、前記復号開始部からの指示を受けて、蓄積部により蓄積された前記画像データを、前記符号化単位で復号する。
【００２３】
また、前記ヘッダ検出部は、前記画像データに付加された通信ヘッダからデータ送信時点に対応する第１のタイムスタンプを検出する第１のヘッダ検出部と、前記画像データに付加された画像ヘッダから符号化時点に対応する第２のタイムスタンプを検出する第２のヘッダ検出部とを含んでもよい。
【００２４】
このとき、前記復号開始指示部は、前記ヘッダ検出部により検出された前記第１のタイムスタンプ及び前記第２のタイムスタンプの時間差に応じて前記復号開始時点を調整してもよい。
【００２５】
また、前記復号開始指示部は、前記復号開始時点から順次前記符号化単位ごとに許容復号時間を計測し、前記許容復号時間が経過するごとに前記符号化単位での復号開始を指示してもよい。
【００２６】
また、前記復号開始指示部は、前記符号化単位で復号させる対象の画像データの受信が完了していない場合に、受信が完了していない前記画像データの代わりにダミーデータを挿入してもよい。
【００２７】
このとき、前記ダミーデータは、復号させる対象の前記画像データと同一のラインまたはラインブロックに対応する１ピクチャ以上前の画像データであってもよい。
【００２８】
また、前記復号開始指示部は、前記符号化単位での前記許容復号時間が終了した時点で、復号させる対象の画像データが残っている場合に、復号させる対象の前記画像データを削除してもよい。
【００２９】
また、前記復号開始指示部は、前記ヘッダ検出部によりピクチャの先頭を認識したことを示す制御情報が出力された後、予め設定された一定の時間が経過した時点を、前記復号開始時点として決定してもよい。
【００３０】
また、前記受信装置は、さらに前記画像データの送信開始時刻を指定する信号を前記画像データの送信元となる装置へ送信する同期制御部を備えしてもよい。
【００３１】
また、前記同期制御部は、通信環境の変動を吸収するための時間間隔を前記送信開始時刻との間に有する復号開始時刻を前記復号開始指示部に対して指定し、前記復号開始指示部は、指定された前記復号開始時刻に基づいて前記復号開始時点を決定してもよい。
【００３２】
また、前記ヘッダ検出部は、前記画像データに付加された通信ヘッダからデータ送信時点に対応する第１のタイムスタンプを検出する第１のヘッダ検出部と、前記画像データに付加された画像ヘッダから符号化時点に対応する第２のタイムスタンプを検出する第２のヘッダ検出部とを含み、前記復号開始指示部は、実行すべき処理を切替えるための切替え情報に基づいて、前記ヘッダ検出部によりピクチャの先頭を認識したことを示す制御情報が出力された後予め設定された一定の時間が経過した時点を前記復号開始時点として決定し、または、前記ヘッダ検出部により検出された前記第１のタイムスタンプ及び前記第２のタイムスタンプの時間差に応じて前記復号開始時点を調整してもよい。
【００３３】
また、前記受信装置は、さらに前記画像データの送信開始時刻を指定する信号を前記画像データの送信元となる装置へ送信し、及び通信環境の変動を吸収するための時間間隔を前記送信開始時刻との間に有する復号開始時刻を前記復号開始指示部に対して指定する同期制御部を備え、前記復号開始指示部は、実行すべき処理を切替えるための切替え情報に基づいて、前記ヘッダ検出部によりピクチャの先頭を認識したことを示す制御情報が出力された後予め設定された一定の時間が経過した時点を前記復号開始時点として決定し、または、前記同期制御部により指定された前記復号開始時刻に基づいて前記復号開始時点を決定してもよい。
【００３４】
また、前記受信装置は、さらに前記画像データの送信開始時刻を指定する信号を前記画像データの送信元となる装置へ送信し、及び通信環境の変動を吸収するための時間間隔を前記送信開始時刻との間に有する復号開始時刻を前記復号開始指示部に対して指定する同期制御部を備え、前記ヘッダ検出部は、前記画像データに付加された通信ヘッダからデータ送信時点に対応する第１のタイムスタンプを検出する第１のヘッダ検出部と、前記画像データに付加された画像ヘッダから符号化時点に対応する第２のタイムスタンプを検出する第２のヘッダ検出部とを含み、前記復号開始指示部は、実行すべき処理を切替えるための切替え情報に基づいて、前記ヘッダ検出部により検出された前記第１のタイムスタンプ及び前記第２のタイムスタンプの時間差に応じて前記復号開始時点を調整し、または、前記同期制御部により指定された前記復号開始時刻に基づいて前記復号開始時点を決定してもよい。
【００３５】
また、上記課題を解決するために、本発明の別の観点によれば、１フィールド内のＮライン（Ｎは１以上）に相当する符号化単位で符号化された画像データを受信するステップと、前記画像データに付加されたヘッダから前記画像データの復号開始時点を決定するための制御情報を検出するステップと、前記画像データを前記符号化単位で割当てられた記憶領域にそれぞれ蓄積するステップと、検出された前記制御情報に基づいて決定される前記画像データの復号開始時点まで待機するステップと、前記符号化単位で復号開始を指示するステップと、蓄積された前記画像データを前記復号開始の指示を受けて前記符号化単位で復号するステップと、を含む受信方法が提供される。
【００３６】
また、上記課題を解決するために、本発明の別の観点によれば、受信装置を制御するコンピュータを、１フィールド内のＮライン（Ｎは１以上）に相当する符号化単位で符号化された画像データを受信し、前記画像データに付加されたヘッダから前記画像データの復号開始時点を決定するための制御情報を検出するヘッダ検出部と、前記画像データを前記符号化単位で割当てられた記憶領域にそれぞれ蓄積する蓄積部と、前記ヘッダ検出部により検出された前記制御情報に基づいて前記画像データの復号開始時点を決定し、前記復号開始時点まで待機した後に前記符号化単位で復号開始を指示する復号開始指示部と、前記復号開始指示部からの復号開始の指示を受けて前記蓄積部に蓄積された前記画像データを前記符号化単位で復号する復号部と、として機能させるためのプログラムが提供される。
【００３７】
また、上記課題を解決するために、本発明の別の観点によれば、１フィールド内のＮライン（Ｎは１以上）に相当する符号化単位で画像データを符号化する圧縮部、及び前記符号化単位で符号化された前記画像データを送信する通信部、を備える送信装置と、前記符号化単位で符号化され、前記送信装置から送信された前記画像データを受信する通信部、前記通信部により受信された前記画像データに付加されたヘッダから前記画像データの復号開始時点を決定するための制御情報を検出するヘッダ検出部、前記画像データを前記符号化単位で割当てられた記憶領域にそれぞれ蓄積する蓄積部、前記ヘッダ検出部により検出された前記制御情報に基づいて前記画像データの復号開始時点を決定し、前記復号開始時点まで待機した後に前記符号化単位で復号開始を指示する復号開始指示部、及び前記復号開始指示部からの復号開始の指示を受けて前記蓄積部に蓄積された前記画像データを前記符号化単位で復号する復号部、を備える受信装置と、を含む通信システムが提供される。
【発明の効果】
【００３８】
以上説明したように、本発明に係る受信装置、受信方法、プログラム、及び通信システムによれば、ラインベース・コーデックを用いた通信において安定して同期を獲得することができる。
【発明を実施するための最良の形態】
【００３９】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００４０】
まず、ラインベース・コーデックの一例として、ラインベース・ウェーブレット変換の仕組みについて説明する。
【００４１】
ラインベース・ウェーブレット変換とは、原画像のベースバンド信号の１ラインをスキャンするごとに横方向のウェーブレット変換を行い、一定数のラインを読み込むごとに縦方向のウェーブレット変換を行うコーデック技術である。
【００４２】
図１５は、ウェーブレット変換を実行する符号化器８００の構成例を示すブロック図である。図１５に示した符号化器８００は、最も一般的なウェーブレット変換であるオクターブ分割を３階層（３つのレベル）にわたって実行し、階層符号化された画像データを生成する。
【００４３】
図１５を参照すると、符号化器８００は、レベル１の回路部８１０、レベル２の回路部８２０、及びレベル３の回路部８３０を備える。また、レベル１の回路部８１０は、ローパスフィルタ８１２、ダウンサンプラ８１４、ハイパスフィルタ８１６、及びダウンサンプラ８１８を有している。レベル２の回路部８２０は、ローパスフィルタ８２２、ダウンサンプラ８２４、ハイパスフィルタ８２６、及びダウンサンプラ８２８を有している。レベル３の回路部８３０は、ローパスフィルタ８３２、ダウンサンプラ８３４、ハイパスフィルタ８３６、及びダウンサンプラ８３８を有している。
【００４４】
入力画像信号は、回路部８１０のローパスフィルタ８１２（伝達関数Ｈ０（ｚ））とハイパスフィルタ８１６（伝達関数Ｈ１（ｚ））によって帯域分割される。帯域分割によって得られた低域成分（１Ｌ成分）と高域成分（１Ｈ成分）は、それぞれ対応するダウンサンプラ８１４、８１８によって、解像度がそれぞれ２分の１倍に間引かれる。
【００４５】
ダウンサンプラ８１４で間引かれた低域成分（１Ｌ成分）の信号は、回路部８２０のローパスフィルタ８２２（伝達関数Ｈ０（ｚ））とハイパスフィルタ８２６（伝達関数Ｈ１（ｚ））によってさらに帯域分割される。帯域分割により得られた低域成分（２Ｌ成分）と高域成分（２Ｈ成分）は、それぞれ対応するダウンサンプラ８２４、８２８によって、解像度がそれぞれ２分の１倍に間引かれる。
【００４６】
さらに、ダウンサンプラ８２４で間引かれた低域成分（２Ｌ成分）の信号は、回路部８３０のローパスフィルタ８３２（伝達関数Ｈ０（ｚ））とハイパスフィルタ８３６（伝達関数Ｈ１（ｚ））によってさらに帯域分割される。帯域分割により得られた低域成分（３Ｌ成分）と高域成分（３Ｈ成分）は、それぞれ対応するダウンサンプラ８３４、８３８によって、解像度がそれぞれ２分の１倍に間引かれる。
【００４７】
このように、所定のレベルまで低域成分を階層的に帯域分割した帯域成分が順次生成される。図１５の例では、レベル３まで帯域分割した結果、ダウンサンプラ８１８で間引かれた高域成分（１Ｈ成分）、ダウンサンプラ８２８で間引かれた高域成分（２Ｈ成分）、ダウンサンプラ８３８で間引かれた高域成分（３Ｈ成分）、ダウンサンプラ８３４で間引かれた低域成分（３Ｌ成分）が生成される。
【００４８】
図１６は、レベル３まで２次元画像を帯域分割した結果得られる帯域成分を示す図である。図１６の例では、まずレベル１の帯域分割（水平・垂直方向）により４つの成分１ＬＬ、１ＬＨ、１ＨＬ、１ＨＨの各副画像が取得される。ここでＬＬは水平・垂直成分が共にＬであることを意味し、ＬＨは水平成分がＨで垂直成分がＬであることを意味している。次に、１ＬＬ成分は再度帯域分割されて、２ＬＬ、２ＨＬ、２ＬＨ、２ＨＨの各副画像が取得される。さらに、２ＬＬ成分は再度帯域分割されて、３ＬＬ、３ＨＬ、３ＬＨ、３ＨＨの各副画像が取得される。
【００４９】
このようにウェーブレット変換が繰り返し行われた結果、出力信号においては、副画像が階層構造を形成する。こうしたウェーブレット変換をさらにラインベースに拡張したのが、ラインベース・ウェーブレット変換である。
【００５０】
図１７は、ラインベース・ウェーブレット変換による変換処理を概念的に示した模式図である。ここでは、一例として、ベースバンドの８ラインごとに縦方向のウェーブレット変換を行うこととしている。
【００５１】
この場合、ウェーブレット変換を３階層で行うとすると、その８ラインに対して、最低域３ＬＬ副画像に１ライン、その次のレベルのサブバンド３Ｈ（副画像３ＨＬ、３ＬＨ、３ＨＨ）に各１ラインが生成される。また、さらに次のレベルのサブバンド２Ｈ（副画像２ＨＬ、２ＬＨ、２ＨＨ）に各２ライン、さらに最高域１Ｈ（副画像１ＨＬ、１ＬＨ、１ＨＨ）に各４ラインの符号化データが生成される。
【００５２】
なお、この各サブバンドのラインの集合をプレシンクトと称する。即ち、ラインベース・ウェーブレット変換におけるプレシンクトは、ラインの集合であるラインブロックの一形態として、ラインベース・ウェーブレット変換の符号化単位となるラインの集合である。ここで、符号化単位とは、符号処理の単位となるラインの集合という一般的な意味であり、上記ラインベース・ウェーブレット変換に限定されない。即ち、例えば符号化単位とは、ＪＰＥＧ２０００やＭＰＥＧ４のような既存の階層符号化における符号処理の単位であってもよい。
【００５３】
図１７を参照すると、図１７の左側に示されるベースバンド信号８０２において８ラインであったプレシンクト（図中斜線部分）は、図１７の右側に示されるように、ラインベース・ウェーブレット変換された変換後信号８０４の１Ｈにおいて、１ＨＬ、１ＬＨ、および１ＨＨのそれぞれの４ライン（図中斜線部分）、２Ｈにおいて、２ＨＬ、２ＬＨ、および２ＨＨのそれぞれの２ライン（図中斜線部分）、３ＬＬ、３ＨＬ、３ＬＨ、および３ＨＨのそれぞれの１ライン（図中斜線部分）として構成されている。
【００５４】
このようなラインベース・ウェーブレット変換処理によれば、ＪＰＥＧ２０００のタイル分割と同様、１枚のピクチャをより細かい粒度に分解して処理を行うことが可能となり、画像データの送受信時の低遅延化を図ることができる。さらに、ラインベース・ウェーブレット変換の場合、ＪＰＥＧ２０００のタイル分割とは異なり、１つのベースバンド信号に対する分割ではなく、ウェーブレット係数での分割であるため、さらに、タイル境界でのブロックノイズ的な画質劣化が発生しないという特徴も有する。
【００５５】
ここまで、ラインベース・コーデックの一例としての、ラインベース・ウェーブレット変換について説明を行った。なお、以下に説明する本発明の各実施形態は、ラインベース・ウェーブレット変換に限らず、例えばＪＰＥＧ２０００やＭＰＥＧ４のような既存の階層符号化など、任意のラインベース・コーデックに適用可能である。
【００５６】
以下、ラインベース・コーデックを用いた通信において安定して同期を獲得するための、本発明の第１〜３の実施形態について説明する。
【００５７】
〔１〕第１の実施形態
図１は、第１の実施形態に係る通信装置１００の構成を示すブロック図である。図１を参照すると、通信装置１００は、画像アプリ管理部１０２、圧縮部１１０、送信メモリ部１１２、通信部１０４、受信メモリ部１５４、及び復号部１５６を備える。さらに、通信部１０４は、送信データ生成部１１４、物理層Ｔｘ１１６、送受信制御部１３０、物理層制御部１３２、スイッチ部１４０、アンテナ部１４２、物理層Ｒｘ１５０、及び受信データ分離部１５２を備える。
【００５８】
画像アプリ管理部１０２は、撮影した画像データの伝送要求をアプリケーションから受け付け、経路制御やＱｏＳによる無線回線に関する制御、またはアプリケーションとの間の画像データの入出力管理を行う。また、画像アプリ管理部１０２における処理として、ＣＣＤ（Ｃｈａｒｇｅ  Ｃｏｕｐｌｅｄ  Ｄｅｖｉｃｅ）やＣＭＯＳ（Ｃｏｍｐｌｅｍｅｎｔａｒｙ  Ｍｅｔａｌ  ＯｘｉｄｅＳｅｍｉｃｏｎｄｕｃｔｏｒ）センサ等の画像入力装置の制御を含んでもよい。
【００５９】
圧縮部１１０は、前述のラインベース・コーデックに従い、画像アプリ管理部１０２から供給された画像データを１フィールド内のＮライン（Ｎは１以上）の符号化単位で符号化してデータ量を削減した後、送信メモリ部１１２に出力する。
【００６０】
送信メモリ部１１２は、圧縮部１１０から受け取ったデータを一時的に蓄積する。また送信メモリ部１１２は、ネットワーク環境に応じてルーティング情報を管理し、他の端末へのデータ転送を制御するルーティング機能を有してもよい。また、送信メモリ部１１２を後述する受信メモリ部１５４と統合し、送信データだけでなく受信データの蓄積を行うようにしてもよい。
【００６１】
送受信制御部１３０は、ＴＤＭＡ（Ｔｉｍｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）方式やＣＳＭＡ（Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）方式でのＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）層の制御を行う。また、送受信制御部１３０は、キャリアではなくプリアンブルの相関からパケットを識別するＰＳＭＡ（Ｐｒｅａｍｂｌｅ  Ｓｅｎｓｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）に基づくＭＡＣ層の制御を行ってもよい。
【００６２】
送信データ生成部１１４は、送受信制御部１３０の要求に基づいて、送信メモリ部１１２に蓄積されているデータを読み出して送信パケットを生成する。例えば、ＩＰプロトコルに基づく通信を行う場合には、送信データ生成部１１４は、送信メモリ部１１２から読み出した符号化済みの画像データを含むＩＰパケットを生成する。
【００６３】
物理層制御部１３２は、送受信制御部１３０または送信データ生成部１１４からの制御に基づいて物理層を制御する。物理層Ｔｘ１１６は、物理層制御部１３２の要求に基づいて動作を開始し、送信データ生成部１１４から供給された通信パケットをスイッチ部１４０に出力する。
【００６４】
スイッチ部１４０は、データの送信と受信とを切り替える機能を有し、物理層Ｔｘ１１６から通信パケットが供給されてきた場合、通信パケットをアンテナ部１４２を介して送信する。また、アンテナ部１４２を介して通信パケットが受信された場合、受信パケットを物理層Ｒｘ１５０に供給する。
【００６５】
物理層Ｒｘ１５０は、物理層制御部１３２の要求に基づいて動作を開始し、受信パケットを受信データ分離部１５２に供給する。
【００６６】
受信データ分離部１５２は、物理層Ｒｘ１５０から供給された受信パケットを解析し、画像アプリ管理部１０２に受け渡すべき画像データ及び制御データを分離して受信メモリ部１５４へ出力する。例えば、ＩＰプロトコルに基づく通信を行う場合には、受信データ分離部１５２は、受信パケットに含まれる宛先ＩＰアドレス及び宛先ポート番号を参照し、画像データ等を受信メモリ部１５４へ出力することができる。なお、受信データ分離部１５２は、他の端末へのデータ転送を制御するルーティング機能を有していてもよい。
【００６７】
受信メモリ部１５４は、受信データ分離部１５２から出力されるデータを一時的に蓄積し、及び復号を開始すべき時点を判断して復号の対象となるデータを復号部１５６へ出力する。なお、受信メモリ部１５４の詳細な構成については、後にさらに詳しく説明する。
【００６８】
復号部１５６は、受信メモリ部１５４から出力されるデータを１フィールド内のＮライン（Ｎは１以上）の単位で復号した後、画像アプリ管理部１０２へ出力する。
【００６９】
ここまで、本実施形態に係る通信装置１００の構成について図１を用いて説明を行った。ここで、ピクチャベースのコーデックに基づく送受信システムでは、厳密な同期制御を行う代わりに、復号部にフレーム予測やフィールド予測などのアルゴリズムを実装するのが一般的である。フレーム予測とは、例えばフレーム間の差分データのみを符号化することにより、画像データの高い圧縮効率を実現しようとするものである。しかしながら、ラインベース・コーデックにおいて、これらアルゴリズムを実装すると、低遅延のメリットが減殺される。そこで、本実施形態に係る通信装置１００では、以下に説明する復号開始時の処理によって、画像データの受信の際の同期を厳密に制御する。
【００７０】
図２は、受信メモリ部１５４のより詳細な構成を示すブロック図である。図２を参照すると、受信メモリ部１５４は、ヘッダ検出部１７０、蓄積制御部１７２、蓄積部１７４、復号開始指示部１７６、及び時間観測部１７８を備える。
【００７１】
ヘッダ検出部１７０は、受信データ分離部１５２から、１フィールド内のＮライン（Ｎは１以上）に相当する符号化単位で符号化された画像データを受信し、受信した画像データのヘッダを検出する。そして、ヘッダ検出部１７０は、検出したヘッダからピクチャの先頭、及び各データがどのピクチャのどのライン（またはラインブロック）に該当するかを認識し、認識した情報を制御情報として蓄積制御部１７２及び復号開始指示部１７６へ出力する。これら制御情報は、例えば後述する復号開始指示部１７６において、画像データの復号開始時点を決定するために用いられる。
【００７２】
図３は、本実施形態において通信装置１００が受信する可能性のある通信データの一例としての、ＩＰパケットの構成を示している。
【００７３】
図３では、１つのＩＰパケットの内部構成が図３（Ａ）〜図３（Ｄ）の４段階に分けて示されている。図３（Ａ）を参照すると、ＩＰパケットは、ＩＰヘッダ及びＩＰデータから構成される。ＩＰヘッダには、例えば宛先ＩＰアドレスなどのＩＰプロトコルに基づく通信経路の制御に関する制御情報などが含まれる。
【００７４】
ＩＰデータは、さらにＵＤＰヘッダ及びＵＤＰデータから構成される（図３（Ｂ））。ＵＤＰは、リアルタイム性が重視される動画または音声データの配信時などに一般的に使用される、ＯＳＩ参照モデルのトランスポート層のプロトコルである。ＵＤＰヘッダには、例えばアプリケーション識別情報である宛先ポート番号などが含まれる。
【００７５】
ＵＤＰデータは、さらにＲＴＰヘッダ及びＲＴＰデータから構成される（図３（Ｃ））。ＲＴＰヘッダには、例えばシーケンス番号などのデータストリームのリアルタイム性を保証するための制御情報が含まれる。
【００７６】
本実施形態において、ＲＴＰデータは、画像データのヘッダ（以下、画像ヘッダという。）及びラインベース・コーデックに基づいて圧縮された画像本体である符号化データから構成される（図３（Ｄ））。画像ヘッダには、例えばピクチャ番号やラインブロック番号（１ライン単位で符号化を行う場合にはライン番号）、サブバンド番号などを含むことができる。なお、画像ヘッダは、ピクチャごとに付与されるピクチャヘッダと、ラインブロックごとに付与されるラインブロックヘッダにさらに分けて構成されてもよい。
【００７７】
図２に示したヘッダ検出部１７０は、このような画像ヘッダを検出し、画像ヘッダに含まれる制御情報を抽出する。例えば、ヘッダ検出部１７０は、ピクチャ番号からピクチャの先頭位置を認識することができる。また、ヘッダ検出部１７０は、同様にラインブロック番号から各データがピクチャ内のどのラインブロックに該当するかを認識することができる。
【００７８】
蓄積制御部１７２は、ヘッダ検出部１７０から出力される各画像データの画像上の位置（即ち、ピクチャ内のどのライン（またはラインブロック）に該当するか）に応じて、蓄積部１７４への画像データの蓄積を制御する。
【００７９】
蓄積部１７４は、蓄積制御部１７２からの制御を受けて、受信した画像データを一時的に蓄積する。蓄積部１７４において、画像データは、典型的にはヘッダ検出部１７０によって認識された画像上の位置にそれぞれ対応して割当てられた所定の記憶領域に蓄積される。
【００８０】
復号開始指示部１７６は、ヘッダ検出部１７０から出力されるピクチャの先頭を認識したことを示す制御情報に基づいて画像データの復号開始時点を決定する。そして、復号開始指示部１７６は、復号開始時点まで待機した後に、復号部１５６に対して符号化単位（即ちラインまたはラインブロックの単位）での蓄積部１７４からの画像データの読み出しと復号開始を指示する。なお、復号開始時点までの待機は、時間観測部１７８に時間を観測させることにより行う。
【００８１】
ここで、本実施形態では、ピクチャの先頭が認識された時点から予め設定された一定の時間が経過した後の時点を、復号開始時点とする。例えば、復号化単位ごとのデータ量の変動や通信経路のジッタの影響等による遅延を吸収できる時間を一定の時間として設定するのが好適である。
【００８２】
時間観測部１７８は、復号開始指示部１７６からの制御を受けて、復号開始時点まで待機するための時間を計測する。時間観測部１７８は、典型的にはタイマーとして実装することができる。
【００８３】
次に、このように構成された通信装置１００における同期処理の流れを図４及び図５を用いて説明する。
【００８４】
通信装置１００における画像データの同期処理は、ピクチャごとの復号開始時点の判定処理と、符号化単位（ラインまたはラインブロックの単位）での復号指示処理に分けられる。図４は、このうちピクチャごとの復号開始時点の判定処理の流れを示したフローチャートである。
【００８５】
図４を参照すると、まず通信部１０４において受信された通信データの中から、所定の符号化単位で符号化された画像データが、受信データ分離部１５２によって分離、取得される（Ｓ１１０４）。
【００８６】
その後、ヘッダ検出部１７０は、受信データ分離部１５２によって取得された画像データからヘッダを検出し、ピクチャの先頭を認識すると、制御情報を出力してピクチャの先頭を認識したことを復号開始指示部１７６へ通知する（Ｓ１１０８）。また、ヘッダ検出部１７０は、さらに各データがどのピクチャのどのライン（またはラインブロック）に該当するかを識別し、蓄積制御部１７２を介して画像データを蓄積部１７４に蓄積させる。
【００８７】
復号開始指示部１７６は、ピクチャの先頭が認識されたことを示す制御情報を受け取ると、時間観測部１７８に時間観測の開始を要求し、復号開始時点の到来を待受ける（Ｓ１１１２）。
【００８８】
その後、復号開始時点に到達したと判定されると（Ｓ１１１６）、処理は復号化単位での復号処理に移る（Ｓ１１２０）。復号化単位での復号処理については、図５を用いてさらに詳しく述べる。復号化単位での復号処理は、ピクチャ内の全てのラインの処理が終了するまで繰り返される（Ｓ１１２４）。そして、全てのラインの処理が終了した時点で、本フローチャートは終了する。
【００８９】
図５は、本実施形態における符号化単位、即ちラインまたはラインブロック単位での復号指示処理の流れを示したフローチャートである。
【００９０】
図５を参照すると、まず復号開始時点を判定した復号開始指示部１７６から復号部１５６へ復号開始の指示が行われ、蓄積部１７４から復号部１５６へ復号対象となる画像データが転送される（Ｓ１２０４）。
【００９１】
そして、画像データの転送と共に、復号開始指示部１７６によって符号化単位での許容復号時間が計測される（Ｓ１２０８）。ここで、符号化単位での許容復号時間とは、１つの符号化単位の画像データを表示するために費やすことのできる時間を意味する。一例として、１０８０／６０ｐ（画面サイズ２２００ｘ１１２５、６０ｆｐｓのプログレッシブ方式）の映像を復号する場合、１ラインの表示に費やせる時間は、ブランク時間を考慮すると約１４．８［μｓ］、ブランク時間を考慮しないと約１５．４［μｓ］となる。そして、符号化単位がＮライン分のラインブロックであった場合には、符号化単位での許容復号時間は、前述の１ラインの表示に費やせる時間のＮ倍となる。
【００９２】
その後、符号化単位での処理時間が終了するまでに蓄積部１７４から復号部１５６への画像データの転送が終了するかどうかが監視される（Ｓ１２１２）。ここで符号化単位での処理時間の終了よりも早く画像データの転送が終了した場合には、即ち想定されるよりも少ない画像データしか受信されていなかった場合は、処理はＳ１２２８に移動する。
【００９３】
Ｓ１２２８では、復号の対象となる画像データの受信が通信の遅延などの原因により完了していないことが考えられる。このとき、復号の対象となる画像データの受信完了を待つと同期タイミングがずれて画像の表示が遅延するため、復号開始指示部１７６は、当該画像データの受信完了を待つことなくダミーデータを当該ライン（またはラインブロック）へ挿入する。ここで挿入されるダミーデータとしては、例えば１ピクチャ前（またはそれ以前）の同一ライン（またはラインブロック）の画像データを用いることができる。しかしながら、ダミーデータはかかる例に限定されず、固定の画像データや、動き保証などにより予測したデータなど、任意のデータであってよい。
【００９４】
一方、画像データの転送が終了する前に符号化単位での許容復号時間が終了すると（Ｓ１２１６）、そのとき蓄積部１７４に復号対象の画像データが残っているかどうかが判定される（Ｓ１２２０）。そして、画像データが残っていない場合には、復号化単位での復号処理は終了する。これに対し、Ｓ１２２０において画像データが残っている場合には、残っている画像データが削除され（Ｓ１２２４）、その後復号化単位での復号処理は終了する。
【００９５】
なお、Ｓ１２１６において、１つの符号化単位での処理時間が終了した際に、時間計測用のカウンタを一時停止またはリセットすることなく連続的に動作させながら、次の復号化単位での復号指示を行うのが好適である。そうすることにより、例えばラインブロックごとの符号化単位での復号タイミングがばらつくことなく復号処理が行われる。
【００９６】
また、その代わりに、時間計測用のカウンタとは別に通信装置１００内に時間制御部（図示せず）を設け、例えばＳ１２０８において、符号化単位ごとの処理開始、終了のタイミングを当該時間制御部から受信メモリ部１５４または復号部１５６へ通知させてもよい。
【００９７】
ここまで、図１〜図５を用いて本発明の第１の実施形態について説明を行った。本実施形態では、ヘッダ検出部１７０がピクチャの先頭を認識したことを示す制御情報を出力し、復号開始指示部１７６は、当該制御情報の出力の後予め設定された一定の時間が経過した時点を、前記復号開始時点として決定する。そして、復号開始指示部１７６は、復号開始時点まで待機した後、順次前記符号化単位ごとに許容復号時間を計測し、許容復号時間が経過するごとに符号化単位での復号開始を復号部１５６に指示する。
【００９８】
かかる構成によれば、画像データの受信及び復号の制御に使用できる時間がピクチャベースのコーデックと比較して短いラインベース・コーデックにおいても、安定して同期された状態で画像データの復号化単位での復号を行うことができる。
【００９９】
また、復号開始指示部１７６は、符号化単位で復号させる対象の画像データの受信が完了していない場合には、受信が完了していない画像データの代わりにダミーデータを挿入する。そうすることにより、復号対象の画像データの受信完了待ちによる同期タイミングのずれの発生を防ぐことができる。
【０１００】
このとき、ダミーデータとして、復号させる対象の画像データと同一のラインまたはラインブロックの、１ピクチャ以上前の画像データを用いてもよい。そうすることにより、ダミーデータの挿入による画質の劣化を利用者に感知させることなく、ダミーデータを含む画像を表示することができる。
【０１０１】
また、復号開始指示部１７６は、符号化単位での許容復号時間が終了した時点で復号させる対象の画像データが残っている場合には、復号させる対象の画像データを削除させる。そうすることにより、一時的なデータ量の増大によって特定のラインまたはラインブロックの復号が終了しない場合でも、後続のラインまたはラインブロックの復号に影響を与えることなく、安定して同期された状態で復号を行うことができる。
【０１０２】
なお、本実施形態において、通信装置１００を無線通信端末として説明したが、通信装置１００は無線通信端末に限定されない。通信装置１００は、任意の有線通信または無線通信によって相互に接続される通信装置または情報処理装置などであってよい。
【０１０３】
また、蓄積部１７４を画像上の位置にそれぞれ対応して割り当てられた所定の記憶領域として説明したが、共有する記憶領域において画像位置を判断できるヘッダ情報を持たせることで、記憶領域を画像上の位置ごとに固定させなくてもよい。
【０１０４】
また、本実施形態ではピクチャの先頭を認識して復号開始タイミングを判断することとしているが、現在どの符号化単位のデータを処理しているかを識別できる情報を用意し、ピクチャの先頭ではなく途中位置から復号開始タイミングを判断してもよい。例えば、図３に示したラインブロック番号によって現在どの符号化単位のデータかを識別できる。
【０１０５】
また、送受信するデータフォーマットとして、ＩＰ、ＵＤＰ、ＲＴＰを用いる場合について説明したが、本実施形態において扱うことのできるフォーマットはかかる例に限定されない。例えば、ＵＤＰの代わりにＴＣＰを用いてもよい。さらに、独自に定義したフォーマットに置き換え、または任意のフォーマットを削除した上で送受信してもよい。
【０１０６】
〔２〕第２の実施形態
第１の実施形態では、通信装置１００において、ピクチャの先頭が認識された時点から予め設定される一定時間が経過した後に、当該ピクチャ内のライン（またはラインブロック）ごとの復号が開始される。
【０１０７】
ここで、一般的に送受信装置間での通信におけるデータレートは一時的に固定される一方、符号化処理の結果として得られる符号化単位ごとのデータ量は、符号化方式に依存し、データ内容によって変化する。また、送受信装置間の通信環境の変動によって、送信側でデータの送信待ちも発生する。そのため、各画像データについて符号化処理が終了して送受信処理が開始するまでの待ち時間には、ばらつきが生じる場合がある。
【０１０８】
そこで、以下に説明する第２の実施形態では、さらに復号が開始される時点を、データ送信側の遅延状況に応じて調整する。
【０１０９】
図６は、第２の実施形態に係る通信装置２００の構成を示すブロック図である。図６を参照すると、通信装置２００は、画像アプリ管理部２０２、圧縮部２１０、送信メモリ部２１２、通信部２０４、計時部２０６、受信メモリ部２５４、及び復号部２５６を備える。さらに、通信部２０４は、送信データ生成部２１４、物理層Ｔｘ２１６、送受信制御部２３０、物理層制御部２３２、スイッチ部２４０、アンテナ部２４２、物理層Ｒｘ２５０、及び受信データ分離部２５２を備える。
【０１１０】
画像アプリ管理部２０２、圧縮部２１０、及び復号部２５６は、図１を用いて説明した第１の実施形態に係る通信装置１００の画像アプリ管理部１０２、圧縮部１１０、及び復号部１５６とそれぞれ同様の機能を有する。
【０１１１】
計時部２０６は、典型的には通信装置２００内の時間情報を保持するタイマーとして実装され、例えば送信メモリ部２１２や送信データ生成部２１４からの要求に応じて時間情報を出力する。
【０１１２】
送信メモリ部２１２は、第１の実施形態に係る送信メモリ部１１２の機能を有する他、圧縮部２１０から出力されるラインベース・コーデックにより符号化された画像データのヘッダに、計時部２０６から取得した時間情報をタイムスタンプとして挿入する。ここで挿入されるタイムスタンプは、画像データの符号化時点に対応するタイムスタンプであり、これを画像用タイムスタンプとする。例えば、画像用タイムスタンプは、図３（Ｄ）の画像ヘッダ内に挿入されてもよい。
【０１１３】
また、送信データ生成部２１４は、第１の実施形態に係る送信データ生成部１１４の機能を有する他、生成した通信データを物理層Ｔｘに出力する前に、通信データのヘッダに、計時部２０６から取得した時間情報をタイムスタンプとして挿入する。ここで挿入されるタイムスタンプは、通信データの送信時点に対応するタイムスタンプであり、これを伝送用タイムスタンプとする。例えば、伝送用タイムスタンプは、図３（Ｃ）のＲＴＰヘッダ内に挿入されてもよい。
【０１１４】
物理層Ｔｘ２１６、送受信制御部２３０、物理層制御部２３２、スイッチ部２４０、アンテナ部２４２、及び物理層Ｒｘ２５０は、図１を用いて説明した通信装置１００の物理層Ｔｘ１１６、送受信制御部１３０、物理層制御部１３２、スイッチ部１４０、アンテナ部１４２、及び物理層Ｒｘ１５０とそれぞれ同様の機能を有する。
【０１１５】
受信データ分離部２５２は、第１の実施形態に係る受信データ分離部１５２の機能を有する他、受信した通信データのヘッダ（以下、通信ヘッダという。）を検出して伝送用タイムスタンプを取得し、受信メモリ部２５４へ出力する。
【０１１６】
受信メモリ部２５４は、第１の実施形態に係る受信メモリ部１５４の機能を有する他、受信した画像データのヘッダを検出して画像用タイムスタンプを取得する。そして、受信メモリ部２５４は、受信データ分離部２５２から出力された伝送用タイムスタンプと画像用タイムスタンプの差分を計算し、画像データの復号開始時点を調整する。
【０１１７】
図７は、受信データ分離部２５２及び受信メモリ部２５４のより詳細な構成を示すブロック図である。図７を参照すると、受信データ分離部２５２は、分離部２５３及び通信ヘッダ検出部２７１を有する。また、受信メモリ部２５４は、画像ヘッダ検出部２７０、蓄積制御部２７２、蓄積部２７４、復号開始指示部２７６、及び時間観測部２７８を備える。
【０１１８】
分離部２５３は、物理層Ｒｘ２５０から通信データとして供給された受信パケットを解析し、画像アプリ管理部２０２で必要な画像データ及び制御データ等を分離して受信メモリ部２５４へ出力する。
【０１１９】
通信ヘッダ検出部２７１は、受信データに含まれる通信ヘッダから送信元装置の送信データ生成部２１４によって挿入された伝送用タイムスタンプを検出し、復号開始指示部２７６へ出力する。なお、実際のデータの送受信に際して送信装置と受信装置は異なる装置となるが、ここでは説明の便宜上、送信処理に係る処理ブロックと受信処理に係る処理ブロックに共に図６及び図７に示した各ブロックの符号を付して説明している。
【０１２０】
画像ヘッダ検出部２７０は、第１の実施形態に係るヘッダ検出部１７０の機能を有する他、送信装置の送信メモリ部２１２によって画像データのヘッダに挿入された画像用タイムスタンプを検出し、復号開始指示部２７６へ出力する。
【０１２１】
蓄積制御部２７２及び蓄積部２７４は、図２を用いて説明した通信装置１００の蓄積制御部１７２及び蓄積部１７４とそれぞれ同様の機能を有する。
【０１２２】
復号開始指示部２７６は、通信ヘッダ検出部２７１から出力された伝送用タイムスタンプと画像ヘッダ検出部２７０から出力された画像用タイムスタンプの時間差を計算し、計算された時間差を用いて復号開始時点までの待ち時間を調整する。前述したように、伝送用タイムスタンプとは、画像データの送信時点に対応するタイムスタンプである。また、画像用タイムスタンプとは、画像データの符号化時点に対応するタイムスタンプである。復号開始時点までの待ち時間Ｔは、伝送用タイムスタンプｔ１及び画像用タイムスタンプｔ２を用いて、次式のように計算される。
【０１２３】
【数１】
0004525795.tif 000002
【０１２４】
ここで、Ｔｃは、第１の実施形態と同様に予め設定される固定の時間である。Ｔｃは、復号化単位ごとのデータ量の変動や通信経路のジッタの影響、ハードウェア遅延、またはメモリ遅延等による遅延を吸収できる時間として与えられる。
【０１２５】
復号開始指示部２７６は、このようにして復号開始時点までの待ち時間Ｔを決定すると、時間観測部２７８に時間Ｔを計時させ、復号開始時点の到来を判定する。そして、復号開始時点が到来すると、復号開始指示部２７６は、第１の実施形態で説明したように、符号化単位（ラインまたはラインブロックの単位）で順次、復号部２５６に対して蓄積部２７４からの画像データの読み出しと復号を指示する。
【０１２６】
次に、このように構成された通信装置２００における、画像データの送信処理及び受信処理の流れを、図８及び図９を用いて説明する。
【０１２７】
図８は、通信装置２００における画像データの送信処理の流れを示したフローチャートである。
【０１２８】
図８を参照すると、まず圧縮部２１０によって画像データが１フィールド内のＮライン（Ｎは１以上）の符号化単位で符号化され、送信メモリ部２１２に出力される（Ｓ２００４）。
【０１２９】
そして、送信メモリ部２１２は、計時部２０６から時間情報を取得し、取得した時間情報を符号化後の画像データのヘッダへ画像用タイムスタンプとして挿入する（Ｓ２００８）。その後、通信経路及び送信処理の進行状況に応じて、画像データは送信メモリ部２１２に蓄積される（Ｓ２０１２）。
【０１３０】
そして、送信タイミングが到来すると、画像データが送信メモリ部２１２から送信データ生成部２１４へ出力され、画像データを含む通信データの生成が開始される（Ｓ２０１６）。このとき、送信データ生成部２１４は、計時部２０６から時間情報を取得し、取得した時間情報を通信データのヘッダへ伝送用タイムスタンプとして挿入する（Ｓ２０２０）。その後、通信データは物理層Ｔｘ２１６を介して送信される（Ｓ２０２４）。
【０１３１】
次に、図９は、通信装置２００における画像データの受信処理の流れを示したフローチャートである。
【０１３２】
図９を参照すると、まず物理層Ｒｘ２５０において受信された通信データの中から、前述の符号化単位で符号化された画像データが分離部２５３によって分離、取得される（Ｓ２１０４）。
【０１３３】
さらに、通信ヘッダ検出部２７１によって、受信された通信データの通信ヘッダが検出され、伝送用タイムスタンプが取得される（Ｓ２１０８）。ここで取得された伝送用タイムスタンプは、復号開始指示部２７６へ出力される。
【０１３４】
その後、画像ヘッダ検出部２７０により、分離部２５３から出力された画像データの中から画像ヘッダが検出され、画像用タイムスタンプが取得される（Ｓ２１１２）。ここで取得された画像用タイムスタンプは、復号開始指示部２７６へ出力される。また、このとき画像ヘッダ検出部２７０は、さらに各データがどのピクチャのどのライン（またはラインブロック）に該当するかを認識し、認識した情報を蓄積制御部２７２に出力して画像データを蓄積部２７４に蓄積させる。
【０１３５】
復号開始指示部２７６は、伝送用タイムスタンプ及び画像用タイムスタンプを受け取ると、前述の式（１）に従って、復号開始時点までの待ち時間Ｔを算出する（Ｓ２１１６）。そして、復号開始指示部２７６は、時間観測部２７８に待ち時間Ｔまでの時間の観測開始を要求し、復号開始時点の到来を待受ける（Ｓ２１２０）。
【０１３６】
その後、復号開始時点に到達したと判定されると（Ｓ２１２０）、処理は復号化単位での復号処理に移る（Ｓ２１２４）。ここでの復号化単位の復号処理は、図５を用いて説明した第１の実施形態に係る復号化単位の復号処理と同様の処理である。
【０１３７】
そして、復号化単位での復号処理は、ピクチャ内の全てのラインの処理が終了するまで繰り返され（Ｓ２１２８）、全てのラインの処理が終了した時点で受信処理は終了する。
【０１３８】
ここまで、図６〜図９を用いて本発明の第２の実施形態について説明を行った。本実施形態では、通信ヘッダからデータ送信時点に対応する伝送用タイムスタンプを検出する通信ヘッダ検出部２７１、及び画像ヘッダから符号化時点に対応する画像用タイムスタンプを検出する画像ヘッダ検出部２７０を含んでヘッダ検出部が構成される。そして、復号開始指示部２７６は、これら２つのヘッダ検出部から出力される通信用タイムスタンプ及び画像用タイムスタンプの時間差に応じて、復号開始時点を調整する。
【０１３９】
かかる構成によれば、符号化単位ごとのデータ量の変化や送受信装置間の通信環境の変動によって送信側でデータの送信待ちが発生した場合にも、画像データの受信タイミングのばらつきを吸収し、安定して同期された状態で画像データの復号を行うことができる。
【０１４０】
なお、第１の実施形態と同様、本実施形態においても、通信装置２００は、無線通信装置に限定されない。通信装置２００は、例えば任意の有線通信または無線通信によって相互に接続される通信装置または情報処理装置などであってよい。
【０１４１】
また、図７では通信ヘッダ検出部２７１を受信データ分離部２５２に、画像ヘッダ検出部２７０を受信メモリ部２５４に配置する例を示したが、通信装置２００の構成はかかる例に限定されない。例えば、通信ヘッダ検出部２７１を受信メモリ部２５４内に配置してもよい。
【０１４２】
また、伝送用タイムスタンプと画像用タイムスタンプのロールアップ周期が異なる場合には、例えば画像ヘッダ検出部２７０または通信ヘッダ検出部２７１において、タイムスタンプのビット幅を補正する処理を行ってもよい。
【０１４３】
また、事前に送信側で伝送用タイムスタンプｔ１と画像用タイムスタンプｔ２との間の時間差を演算し、得られた時間差情報をヘッダに挿入してもよい。そうすることにより、ヘッダ領域を削減し、及び受信側（復号側）における演算処理の処理量を削減することができる。
【０１４４】
〔３〕第３の実施形態
第１及び第２の実施形態では、通信装置１００または通信装置２００において、ピクチャの先頭を認識した後に所定の復号開始時点から当該ピクチャ内のライン（またはラインブロック）ごとの復号が開始される。即ち、ライン（またはラインブロック）での復号開始時点は、送信側の送信処理がいつ開始されるかに依存する。このとき、送受信装置が１対１で構成されている場合には問題は生じない。しかしながら、受信装置に対して送信装置が複数存在した場合には、受信側で複数の画像データの管理または統合をする際に、画像データ間での同期が合わない状況が生じる場合もある。そこで、以下に説明する本発明の第３の実施形態では、さらに受信側から送信側へ画像データの送信開始時点を通知して画像データの送受信を行う。
【０１４５】
図１０は、本発明の第３の実施形態に係る通信システム３０を概念的に描いた模式図である。図１０を参照すると、通信システム３０は、送信装置１００ａ、１００ｂ、及び受信装置３００、を含む。
【０１４６】
送信装置１００ａ及び１００ｂは、それぞれ被写体を撮影し、一連の画像データを生成して受信装置３００へ送信する装置である。図１０において、送信装置１００ａ及び１００ｂの一例としてビデオカメラを示しているが、送信装置１００ａ及び１００ｂはビデオカメラに限られない。例えば送信装置１００ａ及び１００ｂは、動画撮影機能を有するデジタルスチルカメラ、ＰＣ、携帯電話またはゲーム機器などであってもよい。
【０１４７】
受信装置３００は、通信システム３０において、画像データの送受信タイミングを決定するマスタとしての役割を果たす装置である。図１０において、受信装置３００の一例としてＰＣを示しているが、受信装置３００はＰＣに限られない。例えば、受信装置３００は、ビデオレコーダなどの業務用若しくは家庭用映像処理装置、通信装置または任意の情報処理装置などであってよい。
【０１４８】
図１０において、受信装置３００と送信装置１００ａ及び１００ｂとの間は、例えばＩＥＥＥ８０２．１１ａ、ｂ、ｇ、ｎ、ｓなどの標準仕様に基づく無線通信によって接続される。しかしながら、受信装置３００と送信装置１００ａ及び１００ｂとの間の通信を、無線通信ではなく任意の有線通信により行ってもよい。
【０１４９】
本明細書においては、これ以降、受信装置３００と送信装置１００ａとの間の画像データの送受信について説明する。受信装置３００と送信装置１００ｂとの間の画像データの送受信についても、以下の説明と同様に行われる。
【０１５０】
図１１は、第３の実施形態に係る送信装置１００ａの構成を示すブロック図である。図１１を参照すると、送信装置１００ａは、画像アプリ管理部３０３、圧縮部１１０、送信メモリ部１１２、及び通信部１０４を備える。
【０１５１】
画像アプリ管理部３０３は、送信装置１００ａが撮影した画像データの伝送要求をアプリケーションから受け、前述の経路制御等を行うと共に、受信装置３００との間で画像データの送信タイミングの調整を行う。より具体的には、画像アプリ管理部３０３は、後述する受信装置３００の同期制御部３９０から送信される送信開始指示信号を受け取り、指定された送信開始時刻に画像データを圧縮部１１０へ出力する。
【０１５２】
圧縮部１１０、送信メモリ部１１２、及び通信部１０４は、送信開始時刻において画像アプリ管理部３０３から供給される画像データに対し、第１の実施形態に関連して説明した符号化単位での一連の画像データの送信処理を実行する。
【０１５３】
図１２は、第３の実施形態に係る受信装置３００の構成を示すブロック図である。図１２を参照すると、受信装置３００は、画像アプリ管理部３０２、圧縮部３１０、送信メモリ部３１２、通信部３０４、受信メモリ部３５４、復号部３５６、及び同期制御部３９０を備える。
【０１５４】
このうち、画像アプリ管理部３０２、圧縮部３１０、送信メモリ部３１２、通信部３０４、及び復号部３５６は、第１の実施形態に係る画像アプリ管理部１０２、圧縮部１１０、送信メモリ部１１２、通信部１０４、及び復号部１５６とそれぞれ同様の機能を有する。
【０１５５】
受信メモリ部３５４は、図２を用いて説明した受信メモリ部１５４と同様の構成を有し、受信した画像データを一時的に蓄積した後、所定の復号開始時点で復号部３５６へ画像データを出力する。但し、本実施形態では、第１の実施形態と異なり、受信メモリ部３５４の復号開始指示部１７６は、同期制御部３９０から取得した復号開始時刻を画像データの復号開始時点として決定する。
【０１５６】
同期制御部３９０は、通信システム３０内の装置間の画像データの送受信タイミングを制御するタイミングコントローラの役割を果たす。同期制御部３９０は、画像アプリ管理部３０２と同様、典型的にはアプリケーション層の処理として実装される。
【０１５７】
同期制御部３９０による画像データの送受信タイミングの調整は、画像アプリ管理部３０２からの指示、または送信装置１００ａからの同期要求信号の受信などをきっかけとして開始される。そして、同期制御部３９０は、送信装置１００ａに向けて画像データの送信開始時刻を指定する送信開始指示信号を送信し、及び受信メモリ部３５４に対する復号開始時刻の指定を行う。
【０１５８】
このとき、送信装置１００ａへ送信される画像データの送信開始時刻は、受信メモリ部３５４に対して指定される復号開始時刻から、復号化単位ごとのデータ量の変動や通信経路のジッタなどの通信環境の変動により生じる遅延、ハードウェア遅延、またはメモリ遅延等を吸収するための時間を差し引いた時刻とする。
【０１５９】
なお、図１１及び図１２では、説明の分かり易さのために、送信開始指示信号は画像アプリ管理部３０３と同期制御部３９０の間で直接やり取りされるように示しているが、送信開始指示信号は、実際には通信部１０４及び３０４を介して送受信される。
【０１６０】
次に、本実施形態に係る送信装置１００ａによる画像データの送信処理、及び受信装置３００による受信処理の流れについて、図１３及び図１４を用いて説明する。
【０１６１】
図１３は、送信装置１００ａにおける画像データの送信処理の流れを示したフローチャートである。
【０１６２】
図１３を参照すると、まず受信装置３００から送信された送信開始指示信号が、画像アプリ管理部３０３によって受信される（Ｓ３００４）。画像アプリ管理部３０３は、送信開始指示信号に含まれる送信開始時刻を取得する。
【０１６３】
そして、画像アプリ管理部３０３は、送信開始時刻の到来まで待機し（Ｓ３００８）、送信開始時刻が到来すると画像データを圧縮部１１０へ出力する。圧縮部１１０は、出力された画像データを１フィールド内のＮライン（Ｎは１以上）の符号化単位で符号化し、送信メモリ部１１２へ出力する（Ｓ３０１２）。その後、通信経路及び送信処理の進行状況に応じて、画像データは送信メモリ部１１２に蓄積される（Ｓ３０１６）。
【０１６４】
その後、送信タイミングが到来すると、画像データは送信メモリ部１１２から通信部１０４へ出力され、画像データを含む通信データの生成が開始される（Ｓ３０２０）。そして、通信データは受信装置３００へ向けて送信される（Ｓ３０２４）。
【０１６５】
図１４は、受信装置３００における画像データの受信処理の流れを示したフローチャートである。
【０１６６】
図１４を参照すると、まず同期制御部３９０から受信メモリ部３５４に対して、復号開始時刻の指定が行われる（Ｓ３１０４）。ここでの復号開始時刻の指定は、例えば記憶部の所定のアドレスへの復号開始時刻の書き込み、または受信メモリ部３５４に対する信号の出力などにより行うことができる。また、このとき同期制御部３９０から送信装置１００ａへの送信開始指示信号の送信も行われる。
【０１６７】
その後、受信メモリ部３５４において、復号開始時刻までの時間を観測するためのタイマー起動が要求される（Ｓ３１０８）。
【０１６８】
さらに、通信部３０４を介して送信装置１００ａから受信された画像データが、順次受信メモリ部３５４に受け渡される（Ｓ３１１２）。ここで受け渡された画像データは、復号開始時刻まで蓄積される。
【０１６９】
そして、Ｓ３１０４において指定された復号開始時刻に到達すると（Ｓ３１１６）、その時点で送受信対象の画像データの受信が終了しているかどうかが判定される（Ｓ３１２０）。ここで、送受信対象の画像データを検出できない場合には、処理はＳ３１０４に戻り、当該画像データの送受信タイミングの再調整が行われる。
【０１７０】
一方、Ｓ３１１６において、送受信対象の画像データが検出された場合には、当該画像データに対して復号化単位の復号処理が行われる（Ｓ３１２４）。ここでの復号化単位の復号処理は、図５を用いて説明した第１の実施形態に係る復号化単位の復号処理と同様の処理である。
【０１７１】
そして、復号化単位での復号処理は、ピクチャ内の全てのラインの処理が終了するまで繰り返され（Ｓ３１２８）、全てのラインの処理が終了した時点で受信処理は終了する。
【０１７２】
ここまで、図１０〜図１４を用いて本発明の第３の実施形態について説明を行った。本実施形態では、受信装置３００は、画像データの送信開始時刻を指定する信号を送信装置１００ａまたは１００ｂへ送信する同期制御部３９０を備える。
【０１７３】
かかる構成によれば、受信装置に対して送信装置が複数存在する通信システム３０において、受信側で複数の画像データの管理または統合をする際に、受信装置３００がタイミングコントローラの役割を果たし、画像データ間での同期を合わせることができる。
【０１７４】
また、同期制御部３９０は、通信環境の変動を吸収するための時間間隔を前述の送信開始時刻との間に有する復号開始時刻を受信メモリ部３５４内の復号開始指示部に対して指定する。そして、受信メモリ部３５４内の復号開始指示部は、指定された復号開始時刻に基づいて復号開始時点を決定し、画像データの復号化単位での復号開始の指示を行う。そうすることにより、送信装置間で同期を合わせて送信された画像データについて、通信環境の変動などの影響を吸収しながら、安定して同期された状態で復号を行うことができる。
【０１７５】
なお、ここまで説明した第１〜第３の実施形態に共通し、ラインベース・コーデックとして前述のラインベース・ウェーブレット変換を用いる場合には、ラインブロック単位ではなくラインブロックのサブバンド単位で通信パケットを生成することができる。その場合には、受信メモリ部１５４、２５４または３５４において、例えば画像ヘッダから取得されるラインブロック番号及びサブバンド番号に対応する記憶領域を確保し、周波数成分に分解された画像データをラインブロックのサブバンド単位で蓄積してもよい。
【０１７６】
このとき、例えばラインブロック単位で復号を行う際に、伝送エラーなどによってサブバンド（またはその一部）の欠落が生じた場合には、ラインブロック内の当該サブバンド以降にダミーデータを挿入し、次のラインブロックからは通常の復号を行ってもよい。
【０１７７】
また、本明細書において説明した第１〜第３の実施形態に係る一連の処理をハードウェアで実現するかソフトウェアで実現するかは問わない。一連の処理をソフトウェアで実行させる場合には、ソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれたコンピュータ、または例えば図１８に示した汎用コンピュータなどを用いて実行される。
【０１７８】
図１８において、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）９０２は、汎用コンピュータの動作全般を制御する。ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）９０４には、一連の処理の一部または全部を記述したプログラムまたはデータが格納される。ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）９０６には、ＣＰＵ９０２が演算処理に用いるプログラムやデータなどが一時的に記憶される。
【０１７９】
ＣＰＵ９０２、ＲＯＭ９０４、及びＲＡＭ９０６は、バス９０８を介して相互に接続される。バス９０８にはさらに、入出力インタフェース９１０が接続される。
【０１８０】
入出力インタフェース９１０は、ＣＰＵ９０２、ＲＯＭ９０４、及びＲＡＭ９０６と、入力部９１２、出力部９１４、記憶部９１６、通信部９１８、及びドライブ９２０とを接続するためのインタフェースである。
【０１８１】
入力部９１２は、例えばボタン、スイッチ、レバー、マウスやキーボードなどの入力装置を介して、利用者からの指示や情報入力を受け付ける。出力部９１４は、例えばＣＲＴ（Ｃａｔｈｏｄｅ  Ｒａｙ  Ｔｕｂｅ）、液晶ディスプレイ、ＯＬＥＤ（Ｏｒｇａｎｉｃ  Ｌｉｇｈｔ  Ｅｍｉｔｔｉｎｇ  Ｄｉｏｄｅ）などの表示装置、またはスピーカーなどの音声出力装置を介して利用者に対して情報を出力する。
【０１８２】
記憶部９１６は、例えばハードディスクドライブまたはフラッシュメモリなどにより構成され、プログラム、プログラムデータ、画像データなどを記憶する。通信部９１８は、第１〜第３の実施形態に係る通信部１０４、２０４、または３０４などに相当し、任意のネットワークを介した通信処理を行う。ドライブ９２０は、必要に応じて汎用コンピュータに設けられ、例えばドライブ９２０にはリムーバブルメディア９２２が装着される。
【０１８３】
第１〜第３の実施形態に係る一連の処理をソフトウェアで実行する場合には、例えば図１８に示したＲＯＭ９０４、記憶部９１６またはリムーバブルメディア９２２に格納されたプログラムが、実行時にＲＡＭ９０６に読み込まれ、ＣＰＵ９０２によって実行される。
【０１８４】
以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【０１８５】
例えば、第１〜第３の実施形態における受信メモリ部を、復号部の後に配置してもよい。その場合、受信メモリ部の有する蓄積部は、復号前の画像データではなく、復号済みの画像データを復号化単位で蓄積する。そして、復号開始指示部は、例えば図５に示した手順に従い、画像データの復号ではなく復号済みの画像データの蓄積部から画像アプリ管理部への出力を指示する。
【０１８６】
また、第１〜第３の実施形態に係る受信処理（または復号処理）のうち、２種類以上の処理を切り替えながら実行してもよい。例えば、第１〜第３の実施形態に係る処理のうち実行すべき処理を切替えるための切替え情報をヘッダに持たせ、または事前に端末に設定させてもよい。そうした場合には、受信装置は、例えば画像データを受信するステップである図５のＳ１２０４、図９のＳ２１０４、または図１４のＳ３１１２において、前述の切替え情報をヘッダまたは事前の端末設定から取得することができる。そして、受信装置は、取得した切替え情報に基づいていずれか１つの処理を選択し、その後の処理を切り替えることができる。
【０１８７】
また、第１の実施形態及び第２の実施形態に関連して説明した通信装置１００または通信装置２００の各機能のうち、画像データの送信時の機能のみを実装した送信装置を構成してもよい。また、その代わりに、画像データの受信時の機能のみを実装した受信装置を構成してもよい。また、かかる送信装置及び受信装置を含む通信システムを構成してもよい。
【図面の簡単な説明】
【０１８８】
【図１】第１の実施形態に係る通信装置の構成を示すブロック図である。
【図２】第１の実施形態に係る受信メモリ部の詳細な構成を示すブロック図である。
【図３】通信データの一例としてのＩＰパケットの構成を示す説明図である。
【図４】第１の実施形態に係る復号開始時点の判定処理の流れを示すフローチャートである。
【図５】第１の実施形態に係る復号指示処理の流れを示したフローチャートである。
【図６】第２の実施形態に係る通信装置の構成を示すブロック図である。
【図７】第２の実施形態に係る受信データ分離部及び受信メモリ部の詳細な構成を示すブロック図である。
【図８】第２の実施形態に係る送信処理の流れを示したフローチャートである。
【図９】第２の実施形態に係る受信処理の流れを示したフローチャートである。
【図１０】第３の実施形態に係る通信システムを概念的に描いた模式図である。
【図１１】第３の実施形態に係る送信装置の構成を示すブロック図である。
【図１２】第３の実施形態に係る受信装置の構成を示すブロック図である。
【図１３】第３の実施形態に係る送信処理の流れを示したフローチャートである。
【図１４】第３の実施形態に係る受信処理の流れを示したフローチャートである。
【図１５】ウェーブレット変換を行う符号化器の構成例を示すブロック図である。
【図１６】２次元画像を帯域分割して得られる帯域成分の一例を示す説明図である。
【図１７】ラインベース・ウェーブレット変換による変換処理を概念的に示した模式図である。
【図１８】汎用コンピュータの構成例を示すブロック図である。
【符号の説明】
【０１８９】
１００、２００、３００  通信装置、受信装置
１７０                  ヘッダ検出部
１７４、２７４          蓄積部
１７６、２７６          復号開始指示部
１５６、２５６、３５６  復号部
２７１                  第１のヘッダ検出部
２７０                  第２のヘッダ検出部
３９０                  同期制御部
３０                    通信システム
【図１】
0004525795.tif 000003
【図２】
0004525795.tif 000004
【図３】
0004525795.tif 000005
【図４】
0004525795.tif 000006
【図５】
0004525795.tif 000007
【図６】
0004525795.tif 000008
【図７】
0004525795.tif 000009
【図８】
0004525795.tif 000010
【図９】
0004525795.tif 000011
【図１０】
0004525795.tif 000012
【図１１】
0004525795.tif 000013
【図１２】
0004525795.tif 000014
【図１３】
0004525795.tif 000015
【図１４】
0004525795.tif 000016
【図１５】
0004525795.tif 000017
【図１６】
0004525795.tif 000018
【図１７】
0004525795.tif 000019
【図１８】
0004525795.tif 000020