JP4356023B2 - 送信装置および方法、受信装置および方法、並びにプログラム - Google Patents

Description

本発明は、送信装置および方法、受信装置および方法、並びにプログラムに関し、特に、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に代表されるデータを、インターネットを介して伝送するとき、消失したデータを補完することが可能となる。

本発明は、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， ２６ 入力部， ２７ 出力部，
２８ 記憶部， ２９ 通信部

Claims (13)

1. 連続した画像フレームがそれぞれ符号化されている符号化データをパケット化して送信する送信装置において、
   連続した前記画像フレームの符号化パラメータの変化を検出する検出手段と、
   前記符号化データをパケット化するとともに、前記検出手段によって符号化パラメータの変化が検出された場合、変化した符号化パラメータを含むメインヘッダもパケット化するパケット化手段と、
   前記パケット化手段によって生成されたパケットを、ネットワークを介して送信する送信手段と
   を含み、
   前記パケット化手段は、各パケットに対して対応するメインヘッダを示すメインヘッダ識別子を記述し、
   前記検出手段によって符号化パラメータの変化が検出されない場合、前のパケットに記述したメインヘッダ識別子と同一のメインヘッダ識別子を記述し、
   前記検出手段によって符号化パラメータの変化が検出された場合、前のパケットに記述したメインヘッダ識別子と異なるメインヘッダ識別子を記述する
   送信装置。
2. 前記パケット化手段は、前記検出手段によって符号化パラメータの変化が検出された場合、それ以降の所定の数の画像フレームにそれぞれ対応するメインヘッダもパケット化する
   請求項１に記載の送信装置。
3. 前記検出手段は、連続した前記画像フレームの前記符号化パラメータの変化も検出し、
   前記検出手段による、連続した前記画像フレームの前記符号化パラメータの変化の検出結果に対応して、前記メインヘッダを送信するか否かを選択する選択手段を
   さらに含む請求項１に記載の送信装置。
4. 前記パケット化手段は、前記ネットワークのパケットロス状況に対応し、前記メインヘッダの代わりに圧縮メインヘッダをパケット化する
   請求項１に記載の送信装置。
5. 前記パケット化手段は、前記ネットワークのパケットロス状況に対応し、前記メインヘッダの代わりの前記圧縮メインヘッダとして、連続した前記画像フレームの前記符号化パラメータの変化のあった部分だけをパケット化する
   請求項４に記載の送信装置。
6. 連続した画像フレームがそれぞれ符号化されている符号化データをパケット化して送信する送信装置の送信方法において、
   連続した前記画像フレームの符号化パラメータの変化を検出する検出ステップと、
   前記符号化データをパケット化するとともに、前記検出ステップの処理で符号化パラメータの変化が検出された場合、変化した符号化パラメータを含むメインヘッダもパケット化するパケット化ステップと、
   前記パケット化ステップの処理で生成されたパケットを、ネットワークを介して送信する送信ステップと
   を含み、
   前記パケット化ステップは、各パケットに対して対応するメインヘッダを示すメインヘッダ識別子を記述し、
   前記検出ステップの処理で符号化パラメータの変化が検出されない場合、前のパケットに記述したメインヘッダ識別子と同一のメインヘッダ識別子を記述し、
   前記検出ステップの処理で符号化パラメータの変化が検出された場合、前のパケットに記述したメインヘッダ識別子と異なるメインヘッダ識別子を記述する
   送信方法。
7. 連続した画像フレームがそれぞれ符号化されている符号化データをパケット化して送信する送信装置の制御用のプログラムであって、
   連続した前記画像フレームの符号化パラメータの変化を検出する検出ステップと、
   前記符号化データをパケット化するとともに、前記検出ステップの処理で符号化パラメータの変化が検出された場合、変化した符号化パラメータを含むメインヘッダもパケット化するパケット化ステップと、
   前記パケット化ステップの処理で生成されたパケットを、ネットワークを介して送信する送信ステップと
   を含み、
   前記パケット化ステップは、各パケットに対して対応するメインヘッダを示すメインヘッダ識別子を記述し、
   前記検出ステップの処理で符号化パラメータの変化が検出されない場合、前のパケットに記述したメインヘッダ識別子と同一のメインヘッダ識別子を記述し、
   前記検出ステップの処理で符号化パラメータの変化が検出された場合、前のパケットに記述したメインヘッダ識別子と異なるメインヘッダ識別子を記述する
   処理を送信装置のコンピュータに実行させるプログラム。
8. 連続した画像フレームがそれぞれ符号化されている符号化データを含むパケットを受信する受信装置において、
   受信された前記パケットに含まれる、符号化パラメータを含むメインヘッダを保持する保持手段と、
   受信された前記パケットに含まれる符号化データのうち、対応するメインヘッダが受信されていないものを検知する検知手段と、
   前記検知手段によって検知された前記符号化データに対応するメインヘッダを、前記保持手段によって保持されている前記メインヘッダを用いて補完する補完手段と
   を含み、
   受信された前記パケットには、対応するメインヘッダを示すメインヘッダ識別子が記述されており、記述されている前記メインヘッダ識別子は、
   連続した前記画像フレームの符号化パラメータが変化していない場合、前のパケットに記述されているメインヘッダ識別子と同一のものであり、
   連続した前記画像フレームの符号化パラメータが変化している場合、前のパケットに記述されているメインヘッダ識別子とは異なるものである
   受信装置。
9. 前記補完手段は、前記検知手段によって検知された前記符号化データに対応するメインヘッダを、前記保持手段によって保持されている前記メインヘッダのうち、前記検知手段によって検知された前記符号化データが含まれていたパケットに記述されているメインヘッダ識別子に対応するものを用いて補完する
   請求項８に記載の受信装置。
10. 前記補完手段は、前記検知手段によって検知された前記符号化データに対応するメインヘッダを、前記検知手段によって検知された前記符号化データが含まれていた前記パケットに記述されているメインヘッダ長に基づき、前記保持手段によって保持されている前記メインヘッダのうち、前記検知手段によって検知された前記符号化データが含まれていたパケットに記述されているメインヘッダ識別子に対応するものの全部または一部を用いて補完する
    請求項９に記載の受信装置。
11. 前記符号化データは、JPEG(Joint Photographic Expert Group)2000のデータであり、
    前記パケットは、RTP(Realtime Transport Protocol)に基づくRTPパケットであり、
    前記パケットには、前記JPEG2000のデータを複数の前記RTPパケットに分割したときの先頭からのオフセットを示す情報が含まれ、
    前記JPEG2000のデータは、パケットロスを考慮したデータ分割がなされており、
    前記パケットロスを考慮したデータ分割は、前記JPEG2000のデータを意味のあるデータ単位に分割し、完全なデータ単位だけで前記RTPパケットを構成すること、または不完全なデータ単位で前記RTPパケットを構成する場合には、その不完全な単位のみだけで前記RTPパケットを構成することであり、
    前記意味のあるデータ単位とは、前記JPEG2000のメインヘッダ、タイルパートヘッダ、データ部全体、または個々のJPEG2000パケットであり、
    前記RTPパケットには、前記データ単位でパケット化したときに、どのデータ単位がパケット化されているのかを示すパケットタイプが記述されている
    請求項８に記載の受信装置。
12. 連続した画像フレームがそれぞれ符号化されている符号化データを含むパケットを受信する受信装置の受信方法において、
    受信された前記パケットに含まれる、符号化パラメータを含むメインヘッダを保持する保持ステップと、
    受信された前記パケットに含まれる符号化データのうち、対応するメインヘッダが受信されていないものを検知する検知ステップと、
    前記検知ステップの処理で検知された前記符号化データに対応するメインヘッダを、前記保持ステップの処理で保持されている前記メインヘッダを用いて補完する補完ステップと
    を含み、
    受信された前記パケットには、対応するメインヘッダを示すメインヘッダ識別子が記述されており、記述されている前記メインヘッダ識別子は、
    連続した前記画像フレームの符号化パラメータが変化していない場合、前のパケットに記述されているメインヘッダ識別子と同一のものであり、
    連続した前記画像フレームの符号化パラメータが変化している場合、前のパケットに記述されているメインヘッダ識別子とは異なるものである
    受信方法。
13. 連続した画像フレームがそれぞれ符号化されている符号化データを含むパケットを受信する受信装置の制御用のプログラムであって、
    受信された前記パケットに含まれる、符号化パラメータを含むメインヘッダを保持する保持ステップと、
    受信された前記パケットに含まれる符号化データのうち、対応するメインヘッダが受信されていないものを検知する検知ステップと、
    前記検知ステップの処理で検知された前記符号化データに対応するメインヘッダを、前記保持ステップの処理で保持されている前記メインヘッダを用いて補完する補完ステップと
    を含み、
    受信された前記パケットには、対応するメインヘッダを示すメインヘッダ識別子が記述されており、記述されている前記メインヘッダ識別子は、
    連続した前記画像フレームの符号化パラメータが変化していない場合、前のパケットに記述されているメインヘッダ識別子と同一のものであり、
    連続した前記画像フレームの符号化パラメータが変化している場合、前のパケットに記述されているメインヘッダ識別子とは異なるものである
    処理を受信装置のコンピュータに実行させるプログラム。

Images