(57)【要約】【課題】JPEG2000のデータをインターネットを介して伝送するとき、消失したデータを補完する。【解決手段】  JPEG2000用RTPペイロードのフォーマットにpriorityを配置し、そこにパケットに含まれるコードストリームの重要度を表す値を格納する。typeは、JPEG2000コードストリームのペイロードタイプを表す。mh_idは、JPEG2000コードストリームのメインヘッダの識別子であり、メインヘッダの変化の有無を表す。mh_lengthは、メインヘッダの長さを表す。fragment offsetは、パケットにおける画像の先頭からのオフセットバイト数が格納される。【選択図】図１
2006067570.tif 000002
【特許請求の範囲】
【請求項１】
連続した画像フレームがそれぞれ符号化されている符号化データをパケット化して送信する送信装置と、前記送信装置から送信されるパケットを受信する受信装置から構成される通信システムにおいて、
前記送信装置は、
連続した前記画像フレームの符号化パラメータの変化を検出する検出手段と、
前記符号化データをパケット化するとともに、前記検出手段によって符号化パラメータの変化が検出された場合、変化した符号化パラメータを含むメインヘッダもパケット化するパケット化手段と、
前記パケット化手段によって生成されたパケットを、ネットワークを介して送信する送信手段とを含み、
前記受信装置は、
受信された前記パケットに含まれる、符号化パラメータを含むメインヘッダを保持する保持手段と、
受信された前記パケットに含まれる符号化データのうち、対応するメインヘッダが受信されていないものを検知する検知手段と、
前記検知手段によって検知された前記符号化データに対し、前記保持手段によって保持されている前記メインヘッダを用いてメインヘッダを補完する補完手段とを含む
ことを特徴とする通信システム。
【請求項２】
連続した画像フレームがそれぞれ符号化されている符号化データをパケット化して送信する送信装置と、前記送信装置から送信されるパケットを受信する受信装置から構成される通信システムの通信方法において、
送信装置による、連続した前記画像フレームの符号化パラメータの変化を検出する検出ステップと、
送信装置による、前記符号化データをパケット化するとともに、前記検出ステップの処理で符号化パラメータの変化が検出された場合、変化した符号化パラメータを含むメインヘッダもパケット化するパケット化ステップと、
送信装置による、前記パケット化ステップの処理で生成されたパケットを、ネットワークを介して送信する送信ステップと、
受信装置による、受信された前記パケットに含まれる、符号化パラメータを含むメインヘッダを保持する保持ステップと、
受信装置による、受信された前記パケットに含まれる符号化データのうち、対応するメインヘッダが受信されていないものを検知する検知ステップと、
受信装置による、前記検知ステップの処理で検知された前記符号化データに対し、前記保持ステップの処理で保持されている前記メインヘッダを用いてメインヘッダを補完する補完ステップと
を含むことを特徴とする通信方法。
【請求項３】
連続した画像フレームがそれぞれ符号化されている符号化データをパケット化して送信する送信装置において、
連続した前記画像フレームの符号化パラメータの変化を検出する検出手段と、
前記符号化データをパケット化するとともに、前記検出手段によって符号化パラメータの変化が検出された場合、変化した符号化パラメータを含むメインヘッダもパケット化するパケット化手段と、
前記パケット化手段によって生成されたパケットを、ネットワークを介して送信する送信手段と
を含むことを特徴とする送信装置。
【請求項４】
前記パケット化手段は、各パケットに対して対応するメインヘッダを示すメインヘッダ識別子を記述し、前記検出手段によって符号化パラメータの変化が検出されない場合、前のパケットに記述したメインヘッダ識別子と同一のメインヘッダ識別子を記述し、前記検出手段によって符号化パラメータの変化が検出された場合、前のパケットに記述したメインヘッダ識別子と異なるメインヘッダ識別子を記述する
ことを特徴とする請求項３に記載の送信装置。
【請求項５】
前記パケット化手段は、前記検出手段によって符号化パラメータの変化が検出された場合、それ以降の所定の数の画像フレームにそれぞれ対応するメインヘッダもパケット化する
ことを特徴とする請求項４に記載の送信装置。
【請求項６】
前記検出手段は、連続した前記画像フレームの前記符号化パラメータを含む前記メインヘッダの変化も検出し、
前記検出手段によって前記メインヘッダの変化が検出されない場合、前記メインヘッダを送信するか否かを選択する選択手段を
さらに含むことを特徴とする請求項３に記載の送信装置。
【請求項７】
前記パケット化手段は、前記選択手段によって前記メインヘッダを送信しないことが選択された場合、前記メインヘッダの代わりに圧縮メインヘッダをパケット化する
ことを特徴とする請求項６に記載の送信装置。
【請求項８】
前記パケット化手段は、前記検出手段によって検出された前記メインヘッダの変化が軽微な場合、前記圧縮メインヘッダとして、変化のあった部分だけをパケット化する
ことを特徴とする請求項７に記載の送信装置。
【請求項９】
連続した画像フレームがそれぞれ符号化されている符号化データをパケット化して送信する送信装置の送信方法において、
連続した前記画像フレームの符号化パラメータの変化を検出する検出ステップと、
前記符号化データをパケット化するとともに、前記検出ステップの処理で符号化パラメータの変化が検出された場合、変化した符号化パラメータを含むメインヘッダもパケット化するパケット化ステップと、
前記パケット化ステップの処理で生成されたパケットを、ネットワークを介して送信する送信ステップと
を含むことを特徴とする送信方法。
【請求項１０】
前記パケット化ステップは、各パケットに対して対応するメインヘッダを示すメインヘッダ識別子を記述し、前記検出ステップの処理で符号化パラメータの変化が検出されない場合、前のパケットに記述したメインヘッダ識別子と同一のメインヘッダ識別子を記述し、前記検出ステップの処理で符号化パラメータの変化が検出された場合、前のパケットに記述したメインヘッダ識別子と異なるメインヘッダ識別子を記述する
ことを特徴とする請求項９に記載の送信方法。
【請求項１１】
前記パケット化ステップは、前記検出ステップの処理で符号化パラメータの変化が検出された場合、それ以降の所定の数の画像フレームにそれぞれ対応するメインヘッダもパケット化する
ことを特徴とする請求項９に記載の送信方法。
【請求項１２】
前記検出ステップは、連続した前記画像フレームの前記符号化パラメータを含む前記メインヘッダの変化も検出し、
前記検出ステップの処理で前記メインヘッダの変化が検出されない場合、前記メインヘッダを送信するか否かを選択する選択ステップを
さらに含むことを特徴とする請求項９に記載の送信方法。
【請求項１３】
前記パケット化ステップは、前記選択ステップの処理で前記メインヘッダを送信しないことが選択された場合、前記メインヘッダの代わりに圧縮メインヘッダをパケット化する
ことを特徴とする請求項１２に記載の送信方法。
【請求項１４】
前記パケット化ステップは、前記検出ステップの処理で検出された前記メインヘッダの変化が軽微な場合、前記圧縮メインヘッダとして、変化のあった部分だけをパケット化する
ことを特徴とする請求項１３に記載の送信方法。
【請求項１５】
連続した画像フレームがそれぞれ符号化されている符号化データをパケット化して送信するためのプログラムであって、
連続した前記画像フレームの符号化パラメータの変化を検出する検出ステップと、
前記符号化データをパケット化するとともに、前記検出ステップの処理で符号化パラメータの変化が検出された場合、変化した符号化パラメータを含むメインヘッダもパケット化するパケット化ステップと、
前記パケット化ステップの処理で生成されたパケットを、ネットワークを介して送信する送信ステップと
を含む処理をコンピュータに実行させることを特徴とするプログラム。
【請求項１６】
連続した画像フレームがそれぞれ符号化されている符号化データを含むパケットを受信する受信装置において、
受信された前記パケットに含まれる、符号化パラメータを含むメインヘッダを保持する保持手段と、
受信された前記パケットに含まれる符号化データのうち、対応するメインヘッダが受信されていないものを検知する検知手段と、
前記検知手段によって検知された前記符号化データに対し、前記保持手段によって保持されている前記メインヘッダを用いてメインヘッダを補完する補完手段と
を含むことを特徴とする受信装置。
【請求項１７】
前記補完手段は、前記保持手段によって保持されている前記メインヘッダのうち、前記検知手段によって検知された前記符号化データが含まれていたパケットに記述されているメインヘッダ識別子に対応するものを用いて、前記検知手段によって検知された前記符号化データに対してメインヘッダを補完する
ことを特徴とする請求項１６に記載の受信装置。
【請求項１８】
前記補完手段は、前記検知手段によって検知された前記符号化データが含まれていた前記パケットに記述されているメインヘッダ長に基づいて前記メインヘッダを補完する
ことを特徴とする請求項１６に記載の受信装置。
【請求項１９】
前記補完手段は、前記検知手段によって検知された前記符号化データが含まれていた前記パケットに記述されていた前記パケットの状態を示すフラグに基づいて前記メインヘッダを補完する
ことを特徴とする請求項１６に記載の受信装置。
【請求項２０】
前記符号化データは、JPEG(Joint Photographic Expert Group)2000のデータであり、
前記パケットは、RTP(Realtime Transport Protocol)に基づくRTPパケットであり、
前記パケットには、前記JPEG2000のデータを複数の前記RTPパケットに分割したときの先頭からのオフセットを示す情報が含まれ、
前記JPEG2000のデータは、パケットロスを考慮したデータ分割がなされており、
前記パケットロスを考慮したデータ分割は、前記JPEG2000のデータを意味のあるデータ単位に分割し、完全なデータ単位だけで前記RTPパケットを構成すること、または不完全なデータ単位で前記RTPパケットを構成する場合には、その不完全な単位のみだけで前記RTPパケットを構成することであり、
前記意味のあるデータ単位とは、前記JPEG2000のメインヘッダ、タイルパートヘッダ、データ部全体、または個々のJPEG2000パケットであり、
前記RTPパケットには、前記データ単位でパケット化したときに、どのデータ単位がパケット化されているのかを示すパケットタイプが記述されている
ことを特徴とする請求項１６に記載の受信装置。
【請求項２１】
連続した画像フレームがそれぞれ符号化されている符号化データを含むパケットを受信する受信装置の受信方法において、
受信された前記パケットに含まれる、符号化パラメータを含むメインヘッダを保持する保持ステップと、
受信された前記パケットに含まれる符号化データのうち、対応するメインヘッダが受信されていないものを検知する検知ステップと、
前記検知ステップの処理で検知された前記符号化データに対し、前記保持ステップの処理で保持されている前記メインヘッダを用いてメインヘッダを補完する補完ステップと
を含むことを特徴とする受信方法。
【請求項２２】
前記補完ステップは、前記保持ステップの処理で保持されている前記メインヘッダのうち、前記検知ステップの処理で検知された前記符号化データが含まれていたパケットに記述されているメインヘッダ識別子に対応するものを用いて、前記検知ステップの処理で検知された前記符号化データに対してメインヘッダを補完する
ことを特徴とする請求項２１に記載の受信方法。
【請求項２３】
前記補完ステップは、前記検知ステップの処理で検知された前記符号化データが含まれていた前記パケットに記述されているメインヘッダ長に基づいて前記メインヘッダを補完する
ことを特徴とする請求項２１に記載の受信方法。
【請求項２４】
前記補完ステップは、前記検知ステップの処理で検知された前記符号化データが含まれていた前記パケットに記述されていた前記パケットの状態を示すフラグに基づいて前記メインヘッダを補完する
ことを特徴とする請求項２１に記載の受信方法。
【請求項２５】
前記符号化データは、JPEG2000のデータであり、
前記パケットは、RTPに基づくRTPパケットであり、
前記パケットには、前記JPEG2000のデータを複数の前記RTPパケットに分割したときの先頭からのオフセットを示す情報が含まれ、
前記JPEG2000のデータは、パケットロスを考慮したデータ分割がなされており、
前記パケットロスを考慮したデータ分割は、前記JPEG2000のデータを意味のあるデータ単位に分割し、完全なデータ単位だけで前記RTPパケットを構成すること、または不完全なデータ単位で前記RTPパケットを構成する場合には、その不完全な単位のみだけで前記RTPパケットを構成することであり、
前記意味のあるデータ単位とは、前記JPEG2000のメインヘッダ、タイルパートヘッダ、データ部全体、または個々のJPEG2000パケットであり、
前記RTPパケットには、前記データ単位でパケット化したときに、どのデータ単位がパケット化されているのかを示すパケットタイプが記述されている
ことを特徴とする請求項２１に記載の受信方法。
【請求項２６】
連続した画像フレームがそれぞれ符号化されている符号化データを含むパケットを受信するためのプログラムであって、
受信された前記パケットに含まれる、符号化パラメータを含むメインヘッダを保持する保持ステップと、
受信された前記パケットに含まれる符号化データのうち、対応するメインヘッダが受信されていないものを検知する検知ステップと、
前記検知ステップの処理で検知された前記符号化データに対し、前記保持ステップの処理で保持されている前記メインヘッダを用いてメインヘッダを補完する補完ステップと
を含む処理をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システム、通信方法、送信装置および方法、受信装置および方法、並びにプログラムに関し、特に、JPEG2000のデータを、インターネットを介して伝送できるようにした通信システム、通信方法、送信装置および方法、受信装置および方法、並びにプログラムに関する。
【背景技術】
【０００２】
インターネットを介して動画などのデータをストリーミング伝送する場合に問題となるのは、パケットロスや到着遅延によるデータ品質劣化である。MPEG（Moving Picture Experts Group）やH.26x系のようなフレーム間差分を取るエンコード方式の場合、パケットロスにより、あるフレームのデータが欠落すると、それ以降のフレームの画質に影響が出る、いわゆるエラーの伝搬が生じる。また、MPEG方式では、動き予測により圧縮率を高めているが、動き予測を行うとアルゴリズムが複雑になり、その処理時間はフレームサイズの２乗に比例して大きくなるため、原理的に数フレームの符号化遅延が発生する。双方向実時間通信を行う際には、許容遅延時間250msぎりぎりの遅延時間となり、無視できない大きさである。
【０００３】
一方、Motion JPEG2000は、JPEG（Joint Photographic Expert Group）の後継となる静止画圧縮アルゴリズムJPEG2000を連続的に再生することで動画として扱おうというものであり、ISOで標準化されたJPEG2000規格のpart3にそのファイルフォーマットが定義されている。Motion JPEG2000は、フレーム間差分を取らない動画像フォーマットであるため、前述したような問題は発生しない。また、Motion JPEG2000の基礎となるJPEG2000は、ウェーブレット変換とエントロピー符号化により圧縮率を高めているため、フレーム間差分を取らない動画像フォーマットという点で同じMotion JPEGやDVよりも高圧縮かつ高画質である。また、JPEG2000には、様々なエラー耐性が図られており、インターネットのようなパケットロスが発生する環境では、フレーム間差分をとらないMotion JPEG2000のような動画像フォーマットが適していると考えられる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、JPEG2000を使ってストリーミングを行おうとした場合、その伝送フォーマットが存在しないという問題がある。JPEG2000のpart3で定義されているMotion JPEG2000は、保存形式すなわちファイルフォーマットのみである。インターネット上での実時間メディアの転送にはRTP（Realtime Transport Protocol）が使われることが多いが、各種メディアをRTPで運ぶためのフォーマットを検討しているIETFでも、JPEG2000用のRTPフォーマットは規定されていない。
【０００５】
本発明はこのような状況に鑑みてなされたものであり、JEPG2000のデータを、インターネットを介して伝送するとき、消失したデータを補完できるようにするものである。
【課題を解決するための手段】
【０００６】
請求項１に記載の通信システムは、送信装置が、連続した画像フレームの符号化パラメータの変化を検出する検出手段と、符号化データをパケット化するとともに、検出手段によって符号化パラメータの変化が検出された場合、変化した符号化パラメータを含むメインヘッダもパケット化するパケット化手段と、パケット化手段によって生成されたパケットを、ネットワークを介して送信する送信手段とを含み、受信装置が、受信されたパケットに含まれる、符号化パラメータを含むメインヘッダを保持する保持手段と、受信されたパケットに含まれる符号化データのうち、対応するメインヘッダが受信されていないものを検知する検知手段と、検知手段によって検知された符号化データに対し、保持手段によって保持されているメインヘッダを用いてメインヘッダを補完する補完手段とを含む
ことを特徴とする。
【０００７】
請求項２に記載の通信方法は、送信装置による、連続した画像フレームの符号化パラメータの変化を検出する検出ステップと、送信装置による、符号化データをパケット化するとともに、検出ステップの処理で符号化パラメータの変化が検出された場合、変化した符号化パラメータを含むメインヘッダもパケット化するパケット化ステップと、送信装置による、パケット化ステップの処理で生成されたパケットを、ネットワークを介して送信する送信ステップと、受信装置による、受信されたパケットに含まれる、符号化パラメータを含むメインヘッダを保持する保持ステップと、受信装置による、受信されたパケットに含まれる符号化データのうち、対応するメインヘッダが受信されていないものを検知する検知ステップと、受信装置による、検知ステップの処理で検知された符号化データに対し、保持ステップの処理で保持されているメインヘッダを用いてメインヘッダを補完する補完ステップとを含むことを特徴とする。
【０００８】
本発明の通信システムおよび通信方法においては、送信装置により、連続した画像フレームの符号化パラメータの変化が検出され、符号化パラメータの変化が検出された場合、変化した符号化パラメータを含むメインヘッダもパケット化され、生成されたパケットがネットワークを介して送信される。そして、受信装置により、受信されたパケットに含まれる、符号化パラメータを含むメインヘッダが保持され、受信されたパケットに含まれる符号化データのうち、対応するメインヘッダが受信されていないものが検知され、検知された符号化データに対し、保持されているメインヘッダを用いてメインヘッダが補完される。
【０００９】
請求項３に記載の送信装置は、連続した画像フレームの符号化パラメータの変化を検出する検出手段と、符号化データをパケット化するとともに、検出手段によって符号化パラメータの変化が検出された場合、変化した符号化パラメータを含むメインヘッダもパケット化するパケット化手段と、パケット化手段によって生成されたパケットを、ネットワークを介して送信する送信手段とを含むことを特徴とする。
【００１０】
前記パケット化手段は、各パケットに対して対応するメインヘッダを示すメインヘッダ識別子を記述し、検出手段によって符号化パラメータの変化が検出されない場合、前のパケットに記述したメインヘッダ識別子と同一のメインヘッダ識別子を記述し、検出手段によって符号化パラメータの変化が検出された場合、前のパケットに記述したメインヘッダ識別子と異なるメインヘッダ識別子を記述するようにすることができる。
【００１１】
前記パケット化手段は、検出手段によって符号化パラメータの変化が検出された場合、それ以降の所定の数の画像フレームにそれぞれ対応するメインヘッダもパケット化するようにすることができる。
【００１２】
請求項６に記載の送信装置は、前記検出手段が連続した画像フレームの符号化パラメータを含むメインヘッダの変化も検出するようにすることができ、検出手段によってメインヘッダの変化が検出されない場合、メインヘッダを送信するか否かを選択する選択手段をさらに含むことができる。
【００１３】
前記パケット化手段は、選択手段によってメインヘッダを送信しないことが選択された場合、メインヘッダの代わりに圧縮メインヘッダをパケット化するようにすることができる。
【００１４】
前記パケット化手段は、検出手段によって検出されたメインヘッダの変化が軽微な場合、圧縮メインヘッダとして、変化のあった部分だけをパケット化するようにすることができる。
【００１５】
請求項９に記載の送信方法は、連続した画像フレームの符号化パラメータの変化を検出する検出ステップと、符号化データをパケット化するとともに、検出ステップの処理で符号化パラメータの変化が検出された場合、変化した符号化パラメータを含むメインヘッダもパケット化するパケット化ステップと、パケット化ステップの処理で生成されたパケットを、ネットワークを介して送信する送信ステップとを含むことを特徴とする。
【００１６】
前記パケット化ステップは、各パケットに対して対応するメインヘッダを示すメインヘッダ識別子を記述し、検出ステップの処理で符号化パラメータの変化が検出されない場合、前のパケットに記述したメインヘッダ識別子と同一のメインヘッダ識別子を記述し、検出ステップの処理で符号化パラメータの変化が検出された場合、前のパケットに記述したメインヘッダ識別子と異なるメインヘッダ識別子を記述するようにすることができる。
【００１７】
前記パケット化ステップは、検出ステップの処理で符号化パラメータの変化が検出された場合、それ以降の所定の数の画像フレームにそれぞれ対応するメインヘッダもパケット化するようにすることができる。
【００１８】
請求項１２に記載の通信方法は、前記検出ステップが、連続した画像フレームの符号化パラメータを含むメインヘッダの変化も検出するようにすることができ、検出ステップの処理でメインヘッダの変化が検出されない場合、メインヘッダを送信するか否かを選択する選択ステップをさらに含むことができる。
【００１９】
前記パケット化ステップは、選択ステップの処理でメインヘッダを送信しないことが選択された場合、メインヘッダの代わりに圧縮メインヘッダをパケット化するようにすることができる。
【００２０】
前記パケット化ステップは、検出ステップの処理で検出されたメインヘッダの変化が軽微な場合、圧縮メインヘッダとして、変化のあった部分だけをパケット化するようにすることができる。
【００２１】
請求項１５に記載のプログラムは、連続した画像フレームの符号化パラメータの変化を検出する検出ステップと、符号化データをパケット化するとともに、検出ステップの処理で符号化パラメータの変化が検出された場合、変化した符号化パラメータを含むメインヘッダもパケット化するパケット化ステップと、パケット化ステップの処理で生成されたパケットを、ネットワークを介して送信する送信ステップとを含む処理をコンピュータに実行させることを特徴とする。
【００２２】
本発明の送信装置および方法、並びにプログラムおいては、連続した画像フレームの符号化パラメータの変化が検出され、符号化パラメータの変化が検出された場合、変化した符号化パラメータを含むメインヘッダもパケット化され、生成されたパケットがネットワークを介して送信される。
【００２３】
請求項１６に記載の受信装置は、受信されたパケットに含まれる、符号化パラメータを含むメインヘッダを保持する保持手段と、受信されたパケットに含まれる符号化データのうち、対応するメインヘッダが受信されていないものを検知する検知手段と、検知手段によって検知された符号化データに対し、保持手段によって保持されているメインヘッダを用いてメインヘッダを補完する補完手段とを含むことを特徴とする。
【００２４】
前記補完手段は、保持手段によって保持されているメインヘッダのうち、検知手段によって検知された符号化データが含まれていたパケットに記述されているメインヘッダ識別子に対応するものを用いて、検知手段によって検知された符号化データに対してメインヘッダを補完するようにすることができる。
【００２５】
前記補完手段は、検知手段によって検知された符号化データが含まれていたパケットに記述されているメインヘッダ長に基づいてメインヘッダを補完するようにすることができる。
【００２６】
前記補完手段は、検知手段によって検知された符号化データが含まれていたパケットに記述されていたパケットの状態を示すフラグに基づいてメインヘッダを補完するようにすることができる。
【００２７】
前記符号化データは、JPEG2000のデータであり、前記パケットは、RTPに基づくRTPパケットであり、前記パケットには、JPEG2000のデータを複数のRTPパケットに分割したときの先頭からのオフセットを示す情報が含まれ、前記JPEG2000のデータは、パケットロスを考慮したデータ分割がなされており、前記パケットロスを考慮したデータ分割は、JPEG2000のデータを意味のあるデータ単位に分割し、完全なデータ単位だけでRTPパケットを構成すること、または不完全なデータ単位でRTPパケットを構成する場合には、その不完全な単位のみだけでRTPパケットを構成することであり、前記意味のあるデータ単位とは、JPEG2000のメインヘッダ、タイルパートヘッダ、データ部全体、または個々のJPEG2000パケットであり、前記RTPパケットには、データ単位でパケット化したときに、どのデータ単位がパケット化されているのかを示すパケットタイプが記述されているようにすることができる。
【００２８】
請求項２１に記載の受信方法は、受信されたパケットに含まれる、符号化パラメータを含むメインヘッダを保持する保持ステップと、受信されたパケットに含まれる符号化データのうち、対応するメインヘッダが受信されていないものを検知する検知ステップと、検知ステップの処理で検知された符号化データに対し、保持ステップの処理で保持されているメインヘッダを用いてメインヘッダを補完する補完ステップとを含むことを特徴とする。
【００２９】
前記補完ステップは、保持ステップの処理で保持されているメインヘッダのうち、検知ステップの処理で検知された符号化データが含まれていたパケットに記述されているメインヘッダ識別子に対応するものを用いて、検知ステップの処理で検知された符号化データに対してメインヘッダを補完するようにすることができる。
【００３０】
前記補完ステップは、検知ステップの処理で検知された符号化データが含まれていたパケットに記述されているメインヘッダ長に基づいてメインヘッダを補完するようにすることができる。
【００３１】
前記補完ステップは、検知ステップの処理で検知された符号化データが含まれていたパケットに記述されていたパケットの状態を示すフラグに基づいてメインヘッダを補完するようにすることができる。
【００３２】
前記符号化データは、JPEG2000のデータであり、前記パケットは、RTPに基づくRTPパケットであり、前記パケットには、JPEG2000のデータを複数のRTPパケットに分割したときの先頭からのオフセットを示す情報が含まれ、前記JPEG2000のデータは、パケットロスを考慮したデータ分割がなされており、前記パケットロスを考慮したデータ分割は、JPEG2000のデータを意味のあるデータ単位に分割し、完全なデータ単位だけでRTPパケットを構成すること、または不完全なデータ単位でRTPパケットを構成する場合には、その不完全な単位のみだけでRTPパケットを構成することであり、前記意味のあるデータ単位とは、JPEG2000のメインヘッダ、タイルパートヘッダ、データ部全体、または個々のJPEG2000パケットであり、前記RTPパケットには、データ単位でパケット化したときに、どのデータ単位がパケット化されているのかを示すパケットタイプが記述されているようにすることができる。
【００３３】
請求項２６に記載のプログラムは、受信されたパケットに含まれる、符号化パラメータを含むメインヘッダを保持する保持ステップと、受信されたパケットに含まれる符号化データのうち、対応するメインヘッダが受信されていないものを検知する検知ステップと、検知ステップの処理で検知された符号化データに対し、保持ステップの処理で保持されているメインヘッダを用いてメインヘッダを補完する補完ステップとを含む処理をコンピュータに実行させることを特徴とする。
【００３４】
本発明の受信装置および方法、並びにプログラムおいては、受信されたパケットに含まれる、符号化パラメータを含むメインヘッダが保持され、受信されたパケットに含まれる符号化データのうち、対応するメインヘッダが受信されていないものが検知され、検知された符号化データに対し、保持されているメインヘッダを用いてメインヘッダが補完される。
【発明の効果】
【００３５】
本発明によれば、JPEG2000に代表されるデータを、インターネットを介して伝送するとき、消失したデータを補完することが可能となる。
【発明を実施するための最良の形態】
【００３６】
本発明は、JPEG2000ビデオストリームをRTPパケットで運ぶ際に必要となるペイロード情報およびその処理方法についての解決策を与える。
【００３７】
１．  考えるべきこと
まず、JPEG2000ビデオストリームをインターネットで伝送するために以下を考慮する必要がある。
【００３８】
（１）  インターネットではパケットロスは当然のように生じるので、パケットロスを考慮する。具体的には、一部のパケットがロスしたために、JPEG2000画像フレーム全体に影響が生じないように、あるいは生じ難いようにする。そのためには、JPEG2000画像をRTPパケットに分割する際のパケット化を工夫する。
【００３９】
（２）  同様に、JPEG2000メインヘッダの情報のロス対策も必要である。JPEG2000のメインヘッダには圧縮パラメータ(ウェーブレット分割数、カラーコンポーネント数、レイヤ数、量子化テーブルなどの情報)が記述されており、メインヘッダを正しく受信できないとデコード処理に影響が生じてしまい、最悪の場合、全くデコードできないことになる。
【００４０】
（３）  パケットロスを抑止するため対処方法として、TCPで行われているような再送処理が考えられる。しかしながら、実時間性を要求されるアプリケーションでJPEG2000ビデオストリームを用いる場合には、再送が間に合わないことがあるので、再送を前提としない伝送方法を採用することにする。
【００４１】
（４）  JPEG2000では、画像データは階層的に符号化されており、受信端末の能力やネットワーク帯域に応じたスケーラブルな通信が可能になる。JPEG2000ビデオストリームをRTPパケット化したときに、このような階層的な情報を埋め込めるようにする。
【００４２】
１．ペイロードヘッダとしての情報
上記を考慮したJPEG2000ビデオストリームをパケット化するときに、図１のようなペイロードヘッダを付ける。以下、図１に示すペイロードヘッダを第１のフォーマットを記述する。ペイロードヘッダは、８ビットのtypeフィールド、８ビットのpriorityフィールド、４ビットのmh_idフィールド、１２ビットのmh_lengthフィールド、３２ビットのfragment offsetフィールドから構成される。以下、各フィールドについて説明する。
【００４３】
２．１  typeフィールド
パケットが運ぶJPEG2000コードストリームのペイロードタイプを表す。JPEG2000は、メインヘッダ、タイルパートヘッダなど複数のデータ単位から構成されるので、パケット化したときに、パケット内にどのようなデータ単位が含まれているかを簡単に識別できるようにする。データ単位については、後述する。
【００４４】
２．２  priorityフィールド
当該パケットに含まれるコードストリームの重要度を表す値が入る。JPEG2000では、画像データは階層的に符号化されているため、例えばウェーブレットの低域のデータの方が、高域のデータよりも重要度が高い。さらに、JPEG2000の階層符号化では、階層の種類は、ウェーブレットのレベルによる解像度的階層、量子化レベルによる画質的階層、色数による色調階層など様々な階層が存在するので、重要度の付け方はアプリケーションによって異なる。
【００４５】
そこで、階層情報と重要度の対応表は動的に作成し、通信開始時あるいは通信途中に、画像通信とは別の制御チャネルを用いて転送する。送信側は、決められた対応表にしたがって、階層情報に応じた値をpriorityフィールドに挿入する。図２にウェーブレット３階層、量子化レベル５階層の場合の階層情報と重要度の対応表の例を示す。
【００４６】
２．３  mh_idフィールド
これは、JPEG2000コードストリームのメインヘッダの識別子であり、メインヘッダの変化あり／なしを識別するために用いる。mh_idの値そのものに意味はなく、直前の画像フレームと当該パケットが属する画像フレームのメインヘッダに記述されている符号化パラメータが同じか違うかを判断するために使われる。
【００４７】
２．４  mh_lengthフィールド
これは、JPEG2000コードストリームのメインヘッダの長さを示す。
【００４８】
２．５  fragment offsetフィールド
ここには、当該パケットにおける画像先頭からのオフセットバイト数が入る。インターリーブなどを用いて、JPEG2000コードストリームの順番にRTPパケットを送信しない場合にも、fragment offsetの値を見ることでJPEG2000コードストリームのリアセンブルが容易になる。
【００４９】
３．  パケット化
JPEG2000コードストリームをRTPパケットに分割する方法について説明する。基本的な考えは、JPEG2000コードストリームを幾つかのコード単位に分け、完全な状態のコード単位(すなわちコード単位の全て)と、不完全な状態のコード単位(すなわちコード単位の一部)を同じRTPパケットにしないことである。
【００５０】
また、２．２で述べたようにJPEG2000コードストリームの階層データからRTPパケットを構成する場合、異なる重要度を持つ階層データが同一のRTPパケットに入らないようにしている。コード単位としては、例えばメインヘッダ、タイルパートヘッダなどが１つのコード単位となる。コード単位の取り方によって幾つかのパケット化方法がある。
【００５１】
３．１  メインヘッダ、タイルパートヘッダ、符号化データを単位としてパケット化する方法
メインヘッダ（Main Header）、タイルパートヘッダ（Tile-part Header）、符号化データ（JP2 Data）を１つのコード単位として考えてパケット化する方法である。この場合の代表的なパケット分割パターンは、図３のように、メインヘッダ、タイルパートヘッダを完全なデータ単位として各々独立したRTPパケットにし、符号化データを不完全なデータ単位として複数のRTPパケットに分割する手法である。
【００５２】
なお、図３に示されるように、RTPパケットの先頭にはRTPヘッダ（RTP Header）が配置され、その次に、JPEG2000用RTPペイロードヘッダ（PL Header）が配置される。このJPEG2000用RTPペイロードヘッダが、図１に示される構成を有することになる。JP2 Dataは、JPEG2000符号データである。
【００５３】
メインヘッダ長、タイルパートヘッダ長が小さい場合には、メインヘッダとタイルパートヘッダを１つのRTPパケットにまとめた図４のような分割パターンも考えられる。さらに、符号化データ長も短い場合には、メインヘッダ、タイルパートヘッダ、符号化データが１つのRTPパケットに収めるパターンも考えられる。
【００５４】
なお、符号化データを１つのコード単位として扱うと、符号化データの区切りが明確でないため、階層化データごとにRTPパケットを構成できないが、RTPパケットへの分割処理が簡単になるという利点がある。
【００５５】
３．２  メインヘッダ、タイルパートヘッダ、JP2パケットを単位としてパケット化する方法
メインヘッダ、タイルパートヘッダを１つのコード単位することは３．１と同様であるが、符号化データをJP2パケット単位とすることで、より柔軟性に富んだパケット化が可能になるという利点がある。JP2パケットは、JPEG2000画像の要素単位であり、デコード処理はJP2パケット単位で行われる。したがって、JP2パケットをコード単位とすることで、階層的な配信が可能になる。この場合、階層情報に応じた重要度をRTPペイロードヘッダに挿入するために、異なる重要度を持つ階層が同じRTPパケットにならないようにRTPパケットを構成しなければならない。
【００５６】
３．３  符号化パラメータに変化あったときのみメインヘッダを送る方法
メインヘッダのロス対策の詳細については後述するが、そのロス対策の基本的な考えは、JPEG2000を用いたビデオストリームでは、画像毎に符号化パラメータが変わることは少ないだろうという予測に基づいている。符号化パラメータに変化がなければ、メインヘッダがロスしたときに、正しく受信した同じメインヘッダで補完を行なうことで受信データのデコードを可能にしている。この考えをさらに進めて、符号化パラメータに変化があったときのみ、メインヘッダを付けて送る方法を提案する。この場合は、３．１や３．２で述べたケースで単純にメインヘッダのRTPパケットを送らないことで実現できる。
【００５７】
送信したメインヘッダがパケットロスを起こした場合の対処方法として、符号化パラメータに変化があった場合には、変化のあった画像フレームから引続きＮ個の画像フレームについてはメインヘッダを付けて送信することでエラー耐性を上げるという方法を取る。これによりランダムエラーだけでなく、バースト的なエラーにも対処できるようになる。Ｎの値は、固定的に割り当てたり、RTCP（RealTime Control Protocol）のReceiver Report(RR)で報告されるエラー率あるいはアプリケーションが独自に拡張・定義したエラー報告を元に動的に決定したりする方法が考えられる。
【００５８】
３．４  圧縮メインヘッダを使ったパケット化
メインヘッダに記述されているのは、符号化パラメータだけではなく、代表的なものであれば、画像に対するコメント(補足情報、メタ情報)なども記述されている。このコメントはJPEG2000の規格では、使用者が自由に使ってよいことになっている。代表的な使い方として考えられるのは、画像をキャプチャした正確な日時、撮影したカメラ情報(シリアル番号など)、撮影地点(緯度・経度・標高)などの情報をいれることである。これらの情報をメインヘッダのコメント部にいれた場合、圧縮パラメータに変化がなくても、これらの情報は画像フレーム毎に内容が異なることになる。
【００５９】
３．３で述べた方法のように符号化パラメータに変化があった場合だけメインヘッダを送るようにすると、これらの情報が失われてしまう。そこで、３．３で述べた方法の拡張として、メインヘッダにおいて変化のあった部分だけを圧縮メインヘッダとして付加して送る方法が考えられる。
【００６０】
４．  メインヘッダのロス検知と補完方法
図１で示した mh_idとmh_lengthは、JPEG2000画像のメインヘッダのロス検知および補完を目的としたフィールドである。JPEG2000ではメインヘッダの情報が失われると、全くデコードできなくなるため、メインヘッダの損失を最小限に抑えることが高品質なビデオストリームを実現するために重要である。
【００６１】
送信ノードは、まず、mh_idに任意の値を設定して最初の画像フレームを送信する。後続の画像フレームを送る場合、直前の画像フレームのメインヘッダの符号化パラメータと比較し、変化がなければ、mh_idの値に同じ値をいれてパケットを送信する。もし、符号化パラメータが異なっている場合には、mh_idの値を１つ増やしてパケット化する。mh_idフィールドは４ビットであるので、mh_idを１５から１つ増やす場合、次のパケットには mh_id=１をセットする。
【００６２】
送信ノードによっては、処理負荷の関係上、メインヘッダの符号化パラメータ比較が困難な場合がある。そのような場合には、送信ノードは、mh_idに０をセットしてパケット化する。mh_id=０は、メインヘッダのロス検知および補完を行わない(行うために使用してはいけない)ことを示す値であるので、符号化パラメータの比較を行う場合には、必ず０以外の値をmh_idにセットしなければならない。
【００６３】
mh_lengthは、メインヘッダの長さを表わし、受信側で、RTPパケットからメインヘッダを容易に分離できるようにするために使われる。
【００６４】
図５にメインヘッダ補完の概略を示す。受信ノードは受信したフレームにメインヘッダがないことを検知すると、保存しておいたmh_idとフレームのmh_idを比較して、同じ値なら保存しておいたメインヘッダで補完を行う。
【００６５】
図６にメインヘッダ保存用の構造体を、図７に正しく受信できたメインヘッダを保存するアルゴリズムを、図８にメインヘッダのロス検知および補完アルゴリズムについて示す。
【００６６】
５．  priorityについて
図１に示したフォーマットにおいて、priorityフィールドは、RTPパケットの重要度を埋め込むためのフィールドである。たとえば、空間解像度に応じた階層配信を行う場合、ウェーブレットの低域部分ほど重要なデータということができる、低域のデータを含むパケットに高いpriority値を付けることが考えられる。
【００６７】
図９に示すように、ウェーブレット３段階、レイヤ５段階に階層符号化されたJPEG2000画像の場合、図２に示すようなプライオリティマッピングテーブルを定義することができる。プライオリティマッピングテーブルは、セッション開始時あるいは通信途中でプライオリティ対応に変更のあったときに、RTSPやSIP（Session Initiation Protocol）などのシグナリングを用いて、あるいは何らかの方法で、送信ノードと受信ノードで同期を取るようにする。
【００６８】
パケット送出においては、送信ノードではプライオリティの高い順にパケットを送出する。受信側では受信したパケットのpriorityフィールドを見て、priority値＝３を受信しているがpriority値＝４を受信していないと認識した場合、送信ノードに直ちに再送要求を出したり、あるいは重要部分がロスしたのでデコードすることは無意味(画質が期待できないため)であると判断してフレームスキップを行ったりするなどの処理を取ることが考えられる。
【００６９】
本発明では、符号化パラメータに変化があっても、なくても、データの伝送が可能である。また、メインヘッダを送るか否かを選択する場合、次の方法を採用することができる。
【００７０】
（１）  送信ノードの起動時に、「変化があったときのみ送る」、「変化があった部分だけを圧縮メインヘッダとして送る」、または「変化がなくても送る」の設定をする。
【００７１】
（２）  ネットワークのパケットロス状況(これは、受信ノードから送信ノードへ受信状況を報告するRTCPの RR(Receiver Report;受信報告メッセージ)を見ることで分かる)を見て、パケットロスが第１の閾値を越えた場合、「変化があったときのみ送る」、さらにロスが多くなり第２の閾値を越えた場合、「変化があった部分だけを圧縮メインヘッダとして送る」というように、動的に切り替える。
【００７２】
この場合、受信側では、どのような送り方をされても、送られて来たRTPパケットから、メインヘッダが送られているか否かを判断できる必要がある。このため、以下のようなアルゴリズムを採用することができる。
【００７３】
そして、この場合、メインヘッダは各JPEG2000フレームの先頭部分にあること、JPEG2000動画をRTPパケットに分割して送信するとき、既存のRTPの枠組の中で、どのRTPパケットからフレームが変わったかを検知できること、および、図１で示すfragment offsetは、JPEG2000画像フレームの先頭からのオフセットバイトを表していること、が前提となる。
【００７４】
アルゴリズム
画像フレームの先頭のRTPパケットの fragment offset を見て、
(1-1)  fragment offset が 0 で始まっていれば、
メインヘッダが送信されている。
(1-2)  fragment offset が 0 ではじまっていない場合は、
メインヘッダが送信されていないことが分かる。
fragment offset と mh_length を比べて、
(1-2-1)fragment offset == mh_length ならば、
メインヘッダ全部が省略されていることが分かる(「３．３  メインヘッダを送らない場合」に該当する)。
(1-2-2)  fragment offset < mh_length であれば、
メインヘッダの一部だけが送られたと分かる(「３．４  圧縮メインヘッダを使ったパケット化」に該当する)。
保存しておいたメインヘッダの送られて来た部分だけを置き換えて、デコードに使う。
【００７５】
JPEG2000は、１つの大きな画像から様々な解像度の画像を簡単に取り出すことができる。すなわち、JPEG2000の圧縮形式は、規格的に階層的符号化が行なわれており、階層毎にユニット化(JP2パケット)されている。低解像度の画像にする場合は、低解像度のJP2パケットだけを抜き出せばよい。他の画像圧縮形式では、階層的符号化が行なわれていないので、一度デコードして再エンコードしなければならず、かなりの送信オーバヘッドになる。
【００７６】
この機能を利用すると、狭帯域ネットワーク(低速ネットワーク)に画像を伝送する場合には、小さな解像度を抜き出して送ることができる。
【００７７】
解像度を低くすることでデータ量自体は減るが、メインヘッダのサイズは変わらない。そのため、低解像度であればあるほど、全体に対するメインヘッダの占める割合が大きくなる。
【００７８】
そのような場合、メインヘッダを送らないようにしてデータ伝送効率をあげ、ネットワークの使用帯域を減らすことができる。
【００７９】
また、メインヘッダのデータ量を減らした分だけ、誤り訂正符号を付加する、あるいは画像の低域部分(ＳＤサイズの場合、メインヘッダとほぼ同サイズ)を重複して送るなど、パケットロス耐性をあげることができる。
【００８０】
６．  ところで、図１に示したペイロードヘッダの第１のフォーマットの代わりに、図１０に示すペイロードヘッダの第２のフォーマットを用いることができる。ペイロードヘッダの第２のフォーマットは、第１のフォーマットにおける８ビットのパケットタイプを簡素化するために、必要な情報だけをE、MHF、TH flagの各フラグとして用意した。また、Tile numberを定義した。
【００８１】
Ｘフィールド
１ビットのエクステンションフラグのフィールドであり、JEPG2000のオプショナルペイロードヘッダの場合、１がセットされる。
【００８２】
Ｅフィールド
１ビットのイネーブルフラグのフィールドであり、"intelligent packetization"の場合、１がセットされる。
【００８３】
MHF(MF_flag)フィールド
３ビットのメインヘッダフラグのフィールドであり、当該メインヘッダがRTPパケットに含まれる場合、３ビットのうちの先頭の１ビットの１がセットされる。
【００８４】
TH flagフィールド
４ビットで示す値のうち、０，１，１５の３種類の値に対して定義が成されている。当該RTPパケットにタイルパートが１つだけ含まれる場合、０がセットされる。当該RTPパケットに複数のタイルパートが含まれる場合、１がセットされる。当該RTPパケットにタイルパートが含まれない場合、１５(0xFF)がセットされる。
【００８５】
Tile numberフィールド
当該RTPパケットに含まれるタイルパートの数がセットされる。
【００８６】
ペイロードヘッダの第１のフォーマットの代わりに第２のフォーマットを用いることの利点としては、複数のタイルパートを１つのRTPパケットにパケタイズできるようにしたので、全方位映像配信などタイル分割されたJPEG200ストリームから、必要なタイルだけを簡単に取り出すことが可能となることである。
【００８７】
７．  図１０に示したペイロードヘッダの第２のフォーマットに対応する、JPEG2000コードストリームのRTPパケットへの分割方法について説明する。
【００８８】
ペイロードヘッダの第１のフォーマットに対応する分割方法では、複数のタイルパートを１つのRTPパケットに入れることを禁止していた。JPEG2000コードストリームは、メインヘッダと複数のタイルから構成されるが、タイルサイズが小さいと各タイルパートは小さくなる。タイルパートが小さい場合、パケットを小分けにすることになるため、ヘッダ（ＩP/UDP/RTPヘッダ）のオーバヘッドが大きくなり、転送効率が悪くなる。そこで、ペイロードヘッダの第２のフォーマットに対応する分割方法では、複数のタイルパートを１つのRTPパケットに入れることができるようにした。この場合、上述したように、RTPペイロードヘッダのTH flagフィールドに１をセットし、Tile numberフィールドに当該RTPパケットに含まれるタイルパートの数をセットする。
【００８９】
図１１は、JPEG2000コードストリームの構造とRTPパケットの関係を示している。分割されたJPEG2000コードストリームには、JPEG2000用RTPペイロードヘッダ、RTPペイロードヘッダ、TRP共通ヘッダが付加されてネットワークに送信される。
【００９０】
図１２Ａは、タイルサイズが大きい場合の分割方法を示している。図１２Ｂは、タイルサイズが小さくて、かつ、RTPパケットにタイツパートを１つだけ入れる分割方法（ペイロードヘッダの第１のフォーマットに対応する分割方法）を示している。図１２Ｃは、タイルサイズが小さくて、かつ、RTPパケットに複数のタイツパートを入れる分割方法（ペイロードヘッダの第２のフォーマットに対応する分割方法）を示している。
【００９１】
図１３は、RTPパケット化の４種類の方法を示す図である。CASE１は、ペイロードヘッダの第２のフォーマットに対応する分割方法を示している。
【００９２】
８．  次に、ペイロードヘッダの第２のフォーマットにおけるpriorityに対応する通信ついて説明する。５．で述べたペイロードヘッダの第１のフォーマットにおけるpriorityに対応する通信では、送信ノードと受信ノードの間であらかじめ何らかの方法で接続し、プライオリティマッピングテーブルの同期をとっていた。この場合、送信ノードと受信ノードの間でプライオリティマッピングテーブルを同期させなければ、priority fieldを使えない。マルチキャスト環境のように、送信ノードと受信ノードの組み合わせが多数ある場合、このようなプライオリティマッピングテーブルの同期をとることはセッション制御のオーバヘッドが大きく、現実的ではない。
【００９３】
そこで、ペイロードヘッダの第２のフォーマットにおけるpriorityに対応する通信では、送信ノードと受信ノードの間であらかじめプライオリティマッピングテーブルの同期をとる必要がないように、図１４に示すように、default priorityが定義されている。送信ノードは、JP2パケットのシーケンス番号に１を加算した値を、priority値として使用する。JP2パケットのシーケンス番号とは、文献「ISO/IEC JTC1/SC29: ISO/IEC 15444-1 的nformation technology  JPEG 2000 image coding system  Part 1: Core coding system   December 2000.」のAnnex A.8.1のSOPマーカの定義で示されているものであり、JP2パケットの順番を表すものである。シーケンス番号に１を加算する理由は、JP2パケットのシーケンス番号は０から始まるが、priority値＝０はヘッダ（メインヘッダあるいはタイルパートヘッダ）用の値として用い、JP2パケットのpriority値を１から始めるためである。
【００９４】
JPEG2000をRTPで運ぶためのフォーマットを定義することにより、インターネットでのJPEG2000を用いたあらゆる通信アプリケーションに採用されて普及していくことが予想される。
【００９５】
エラー対策を念頭においたパケットフォーマットになっているため、インターネットのようなパケットロスが頻繁に発生する環境において、この送信方法は有効に機能すると思われる。特に、今後普及が予想される携帯端末においては、無線通信が主体であり、無線通信ではパケットロスはさらに頻繁に発生する。パケットロスに強いJPEG2000通信フォーマットは、これらの携帯端末に実装され、高画質な動画像サービスを提供することが可能になる。
【００９６】
JPEG2000動画は、フルイントラフレームの動画フォーマットなので、編集や加工が容易であるため、放送システムを中心に普及していくと思われる。そうなると、当然の要求として、JPEG2000動画を放送に使うことが予想され、JPEG2000 RTPフォーマットは放送システムでも広く使われると予想される。
【００９７】
ところで、上述した一連の処理は、例えば、図１５に示されるようなパーソナルコンピュータにより構成される通信制御装置により実行される。
【００９８】
図１５において、CPU（Central Processing Unit）２１は、ROM（Read Only Memory）２２に記憶されているプログラム、または記憶部２８からRAM（Random Access Memory）２３にロードされたプログラムに従って各種の処理を実行する。RAM２３にはまた、CPU２１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【００９９】
CPU２１、ROM２２、およびRAM２３は、バス２４を介して相互に接続されている。このバス２４にはまた、入出力インタフェース２５も接続されている。
【０１００】
入出力インタフェース２５には、キーボード、マウスなどよりなる入力部２６、CRT(Cathode Ray Tube)、LCD(Liquid Crystal display)などよりなるディスプレイ、並びにスピーカなどよりなる出力部２７、ハードディスクなどより構成される記憶部２８、モデム、ターミナルアダプタなどより構成される通信部２９が接続されている。通信部２９は、インターネットを含むネットワークを介しての通信処理を行う。
【０１０１】
入出力インタフェース２５にはまた、必要に応じてドライブ３０が接続され、磁気ディスク４１、光ディスク４２、光磁気ディスク４３、或いは半導体メモリ４４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部２８にインストールされる。
【０１０２】
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【０１０３】
この記録媒体は、図１５に示されるように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク４１（フロッピディスクを含む）、光ディスク４２（CD-ROM(Compact Disk-Read Only Memory)、DVD(Digital Versatile Disk)を含む）、光磁気ディスク４３（ＭＤ（Mini-Disk）を含む）、もしくは半導体メモリ４４などよりなるパッケージメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM２２や、記憶部２８に含まれるハードディスクなどで構成される。
【０１０４】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１０５】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０１０６】
なお、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
【図面の簡単な説明】
【０１０７】
【図１】JPEG2000用RTPペイロードの第１のフォーマットを示す図である。
【図２】プライオリティマッピングテーブルを示す図である。
【図３】パケット化の方法を示す図である。
【図４】パケット化の他の方法を示す図である。
【図５】メインヘッダの補完を説明する図である。
【図６】メインヘッダ保存用構造体を示す図である。
【図７】メインヘッダの保存アルゴリズムを示す図である。
【図８】メインヘッダのロス検知および補完アルゴリズムを示す図である。
【図９】ウェーブレット３段階とレイヤ５段階の階層符号化を説明する図である。
【図１０】JPEG2000用RTPペイロードの第２のフォーマットを示す図である。
【図１１】JPEG2000コードストリームの構造とRTPパケットの関係を示す図である。
【図１２】タイルサイズの対応した分割方法を説明するための図である。
【図１３】RTPパケット化の４種類の方法を示す図である。
【図１４】予め定義されているdefault priorityを説明するための図である。
【図１５】パーソナルコンピュータの構成例を示すブロック図である。
【符号の説明】
【０１０８】
２１  CPU，  ２２  ROM，  ２３  RAM，  ２６  入力部，  ２７  出力部，
２８  記憶部，  ２９  通信部
【図１】
2006067570.tif 000003
【図２】
2006067570.tif 000004
【図３】
2006067570.tif 000005
【図４】
2006067570.tif 000006
【図５】
2006067570.tif 000007
【図６】
2006067570.tif 000008
【図７】
2006067570.tif 000009
【図８】
2006067570.tif 000010
【図９】
2006067570.tif 000011
【図１０】
2006067570.tif 000012
【図１１】
2006067570.tif 000013
【図１２】
2006067570.tif 000014
【図１３】
2006067570.tif 000015
【図１４】
2006067570.tif 000016
【図１５】
2006067570.tif 000017