JP5162939B2 - 情報処理装置および方法、並びにプログラム - Google Patents

情報処理装置および方法、並びにプログラム Download PDF

Info

Publication number
JP5162939B2
JP5162939B2 JP2007094015A JP2007094015A JP5162939B2 JP 5162939 B2 JP5162939 B2 JP 5162939B2 JP 2007094015 A JP2007094015 A JP 2007094015A JP 2007094015 A JP2007094015 A JP 2007094015A JP 5162939 B2 JP5162939 B2 JP 5162939B2
Authority
JP
Japan
Prior art keywords
unit
data
precinct
packet
encoded data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007094015A
Other languages
English (en)
Other versions
JP2008252739A (ja
Inventor
星 砂原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2007094015A priority Critical patent/JP5162939B2/ja
Priority to TW97111513A priority patent/TWI414183B/zh
Priority to US12/301,682 priority patent/US8184636B2/en
Priority to CN2008800002777A priority patent/CN101543071B/zh
Priority to PCT/JP2008/056325 priority patent/WO2008120777A1/ja
Priority to EP08739439.1A priority patent/EP2134092B1/en
Priority to KR1020087029188A priority patent/KR101426097B1/ko
Priority to BRPI0803098-7A priority patent/BRPI0803098B1/pt
Publication of JP2008252739A publication Critical patent/JP2008252739A/ja
Application granted granted Critical
Publication of JP5162939B2 publication Critical patent/JP5162939B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
    • H04N21/4385Multiplex stream processing, e.g. multiplex stream decrypting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/63Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding using sub-band based transform, e.g. wavelets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2389Multiplex stream processing, e.g. multiplex stream encrypting

Description

本発明は、情報処理装置および方法、並びにプログラムに関し、特に、パケット送受信時における遅延を低減させることができるようにした情報処理装置および方法、並びにプログラムに関する。
従来、インターネット等を介して映像や音声のストリーミングが行われている。このときパケットロスや到着遅延等が生じると、データ品質劣化が起きる恐れがある。例えば、MPEG(Moving Picture Experts Group)やH.26x系の圧縮方式ように、フレーム間差分を取るエンコード方式の場合、パケットロスにより、あるフレームのデータが欠落すると、それ以降のフレームの画質に影響が出る、いわゆるエラーの伝搬が生じる。
また,MPEG方式では動き予測により圧縮率を高めているが、動き予測を行うとアルゴリズムが複雑になり、その処理時間はフレームサイズの2乗に比例して大きくなるため、原理的に数フレームの符号化遅延が発生する。双方向実時間通信を行う際には、許容遅延時間250msぎりぎりの遅延時間となり、無視できない大きさである。
これらに対して、JPEG(Joint Photographic Experts Group)2000に代表されるような、イントラフレームコーデックはフレーム間の差分情報を利用しないため、上述したような遅延は発生しない。しかしながら、フレーム単位での圧縮となるため、エンコード開始まで、最低でも1フレームは待つ必要がある。現在の一般的なシステムでは1秒間に30フレームであることが多いため、エンコード開始までに16ms程度の待ち時間が必要となる。
そこでこの遅延をさらに低減することが求められており、エンコードやデコード以外の部分における遅延の低減も必要になってきた。
処理遅延のひとつとして、RTP(Real-time Transport Protocol)パケット化とデパケット化を行うパケタイズ/デパケタイズ処理がある。従来、デパケタイズを行う際には、ある程度のパケットが溜るのを待ってから処理を開始するため、遅延が発生していた。パケットをためる理由としては、インターネットでは分割せずに送信することのできるパケットの最大サイズに制限が存在し、ある意味を持った一連のデータが、複数のパケットに分割して送信される。デパケタイザでも分割されたパケットが揃うまでバッファリングしてからデパケタイズをはじめるため、遅延が増大し、またバッファのためのリソースも必要となる。
つまり、符号化データの受信側の装置では、受信したパケットが、デパケタイズ処理部によりデパケタイズされ、抽出された符号化データがデコーダにより復号されるが、このとき、デパケタイズ処理とデコード処理の両方においてバッファが必要になり、バッファのメモリ容量が増大する恐れがあった。
これに対して、バッファのメモリ容量を低減させるために各種の方法が考えられてきた(例えば、特許文献1参照)。
特許文献1においては、中継装置が受信したパケットを誤り訂正のためにバッファメモリに蓄積すると同時に、誤り訂正演算ブロック全体のパケットが到着するのを待つことなく、下流側に向けて逐次送信し、パケットの消失が検出された場合、誤り訂正演算を行って回復させて、その回復させたパケットを先送りしたパケットに続く形式で送信する。
特開2005-12753号
しかしながら、上述した特許文献1に記載の方法の場合、誤り訂正を行うため、中継装置においてもバッファメモリが必要になる。すなわち、上述したようにバッファのメモリ容量が増大する恐れがあった。また、特許文献1に記載の方法の場合、中継装置がパケットの誤り訂正を行うとパケットの順序が変更されてしまう。従って、受信装置においてデパケタイズの際に並び替えを行う必要があり、デパケタイズ処理が複雑になり遅延時間が増大するだけでなく、デパケタイズ処理用のバッファも必要になる。受信装置においてパケット化されて伝送された符号化データのデコードを行う場合、そのデパケタイズ用のバッファとは別にデコード用のバッファも必要になるので、メモリ容量だけでなく遅延時間もさらに増大する恐れがあった。
本発明は、このような従来の実情に鑑みて提案されたものであり、デパケタイズ処理において不要な待機時間の発生を抑制し、処理を容易かつ高速に行うことができるようにし、データをパケット化して送受信する際に発生する遅延時間を低減させることができるようにするものである。
本発明の一側面は、画像データの符号化データであって、前記画像データを符号化する際に行われる前記画像データのウェーブレット変換において、最低域成分の1ライン分を生成するために必要な、他のサブバンドも含めたラインの集まりであるプレシンクトの符号化データを、複数の部分データに分割する分割部と、前記分割部により得られた各部分データを、それぞれパケット化するパケット化部と、前記パケット化部により生成された各パケットの内、前記プレシンクトの符号化データの先頭の部分データをペイロードとする先頭パケットに対して、先頭パケットであることを示し、デパケタイズの際に、パケットロス発生に対するデータ破棄の制御を前記プレシンクトの符号化データ毎に行うために、前記プレシンクトの符号化データの先頭であることを確認するために参照される先頭フラグを設定する先頭フラグ設定部と、前記パケット化部により生成された各パケットの内、前記プレシンクトの符号化データの終端の部分データをペイロードとする最終パケットに対して、最終パケットであることを示し、デパケタイズの際に、パケットロス発生に対するデータ破棄の制御を前記プレシンクトの符号化データ毎に行うために、前記プレシンクトの符号化データの終端であることを確認するために参照される最終フラグを設定する最終フラグ設定部とを備える情報処理装置である。
前記パケット化部は、前記プレシンクトの符号化データについて、符号化が失敗している場合、前記分割部により得られた各部分データを破棄し、ヘッダ情報のみでパケット化することができる。
前記パケット化部は、前記部分データをペイロードとし、前記プレシンクトの符号化データのヘッダ情報と、少なくとも一部が共通のヘッダ情報を付加することにより、前記部分データをパケット化することができる。
前記パケット化部は、前記プレシンクトの符号化データの符号化が失敗しているか否かを示すフラグを、前記ヘッダ情報に含めて前記部分データに付加することができる。
前記画像データを、前記プレシンクト毎に符号化する符号化部をさらに備え、前記分割部は、前記符号化部により得られた前記プレシンクトの符号化データを分割することができる。
本発明の一側面はまた、情報処理装置の情報処理方法であって、前記情報処理装置が、画像データの符号化データであって、前記画像データを符号化する際に行われる前記画像データのウェーブレット変換において、最低域成分の1ライン分を生成するために必要な、他のサブバンドも含めたラインの集まりであるプレシンクトの符号化データを、複数の部分データに分割し、得られた各部分データを、それぞれパケット化し、生成された各パケットの内、前記プレシンクトの符号化データの先頭の部分データをペイロードとする先頭パケットに対して、先頭パケットであることを示し、デパケタイズの際に、パケットロス発生に対するデータ破棄の制御を前記プレシンクトの符号化データ毎に行うために、前記プレシンクトの符号化データの先頭であることを確認するために参照される先頭フラグを設定し、生成された各パケットの内、前記プレシンクトの符号化データの終端の部分データをペイロードとする最終パケットに対して、最終パケットであることを示し、デパケタイズの際に、パケットロス発生に対するデータ破棄の制御を前記プレシンクトの符号化データ毎に行うために、前記プレシンクトの符号化データの終端であることを確認するために参照される最終フラグを設定する情報処理方法である。
本発明の一側面はさらに、コンピュータを、画像データの符号化データであって、前記画像データを符号化する際に行われる前記画像データのウェーブレット変換において、最低域成分の1ライン分を生成するために必要な、他のサブバンドも含めたラインの集まりであるプレシンクトの符号化データを、複数の部分データに分割する分割部と、前記分割部により得られた各部分データを、それぞれパケット化するパケット化部と、前記パケット化部により生成された各パケットの内、前記プレシンクトの符号化データの先頭の部分データをペイロードとする先頭パケットに対して、先頭パケットであることを示し、デパケタイズの際に、パケットロス発生に対するデータ破棄の制御を前記プレシンクトの符号化データ毎に行うために、前記プレシンクトの符号化データの先頭であることを確認するために参照される先頭フラグを設定する先頭フラグ設定部と、前記パケット化部により生成された各パケットの内、前記プレシンクトの符号化データの終端の部分データをペイロードとする最終パケットに対して、最終パケットであることを示し、デパケタイズの際に、パケットロス発生に対するデータ破棄の制御を前記プレシンクトの符号化データ毎に行うために、前記プレシンクトの符号化データの終端であることを確認するために参照される最終フラグを設定する最終フラグ設定部として機能させるためのプログラムである。
本発明の一側面においては、画像データの符号化データであって、画像データを符号化する際に行われる画像データのウェーブレット変換において、最低域成分の1ライン分を生成するために必要な、他のサブバンドも含めたラインの集まりであるプレシンクトの符号化データが、複数の部分データに分割され、得られた各部分データが、それぞれパケット化され、生成された各パケットの内、プレシンクトの符号化データの先頭の部分データをペイロードとする先頭パケットに対して、先頭パケットであることを示し、デパケタイズの際に、パケットロス発生に対するデータ破棄の制御をプレシンクトの符号化データ毎に行うために、プレシンクトの符号化データの先頭であることを確認するために参照される先頭フラグが設定され、生成された各パケットの内、プレシンクトの符号化データの終端の部分データをペイロードとする最終パケットに対して、最終パケットであることを示し、デパケタイズの際に、パケットロス発生に対するデータ破棄の制御をプレシンクトの符号化データ毎に行うために、プレシンクトの符号化データの終端であることを確認するために参照される最終フラグが設定される。
本発明によれば、パケットを受信し、そのパケットからデータを抽出することができる。特に、その際のデパケタイズ処理を容易かつ高速に行い、後段の処理開始までの遅延時間を低減させることができる。
以下、本発明の実施の形態について説明する。
図1は、本発明を適用した伝送システムの構成例を示すブロック図である。
図1において、伝送システム100は、撮像装置101が生成した画像データを送信装置102が圧縮符号化し、パケット化して送信し、回線110を介して伝送されるそのパケットを、受信装置103が受信してデパケタイズして復号し、表示装置104が得られた画像データの画像を表示するデータ伝送システムである。
撮像装置101は、CCD(Charge Coupled Device)やCMOS(Complementary Metal Oxide Semiconductor)等を利用した撮像素子を有し、被写体を撮像し、その撮像画像をデジタルデータの画像データに変換し、得られた画像データを送信装置102に供給する。
送信装置102は、符号化部121、パケタイズ処理部122、および送信部123を有する。送信装置102は、符号化部121において、撮像装置101より供給される画像データを所定の方法で符号化し、その符号化により得られた符号化データをパケタイズ処理部122においてパケット化し、生成されたパケットを送信部123より所定の通信方法で回線110に送出する。
回線110は、送信装置102と受信装置103を接続し、送信装置102より送出されるパケットを受信装置103に伝送する任意の伝送媒体である。
受信装置103は、受信部131、デパケタイズ処理部132、および復号部133を有する。受信装置103は、受信部131において、回線110を介して伝送されてきたパケットを受信し、デパケタイズ処理部132において、その受信したパケットから符号化データを抽出し、復号部133において、その抽出した符号化データを送信装置102の符号化部121に対応する復号方法で復号し、得られたベースバンドの画像データを表示装置104に出力する。
表示装置104は、ディスプレイを有し、受信装置103より供給された画像データの画像をそのディスプレイに表示する。
この図1の伝送システム100は、パケタイズ処理部122によるパケタイズ処理による遅延時間、および、デパケタイズ処理部132によるデパケタイズ処理による遅延時間を低減し、撮像装置101において撮像されてから、その画像が表示装置104に表示されるまでの遅延時間を低減させることができるシステムである。
図1の伝送システム100において、送信装置102が送信する画像データを提供する装置として撮像装置101が示されているが、画像データを提供することができる装置であればどのような装置であってもよい。また、受信装置103が受信した画像データを利用する装置として表示装置104が示されているが、画像データを利用することができる装置であればどのような装置であってもよい。
また、ここでは伝送されるデータとして画像データについてのみ説明するが、例えば、音声データ等、その他のデータが画像データとともに伝送されてもよい。
送信装置102が行うパケットの送信方法は、受信装置103に対してのみ送信するユニキャストであってもよいし、受信装置103を含む複数の装置に対して送信するマルチキャストであってもよいし、不特定多数の装置に対して送信するブロードキャストであってもよい。
回線110は、パケットを伝送可能なものであればどのような形態のものであってもよく、有線であってもよいし、無線であってもよいし、その両方を含むものであってもよい。また、図1において回線110は、1本の矢印により示されているが、専用または汎用の伝送ケーブルであってもよいし、例えばLAN(Local Area Network)やインターネット等のような、1つまたは複数の通信網を含むようにしてもよいし、何らかの通信中継装置を含むようにしてもよい。さらに、回線110の回線数(チャネル数)は何本であってもよい。
次に、図1に示される送信装置102および受信装置103の各部の詳細について説明する。
図2は、図1の送信装置102の符号化部121の内部の構成例を示すブロック図である。図2において、符号化部121は、ウェーブレット変換部150、途中計算用バッファ部151、係数並び替え用バッファ部152、係数並び替え部153、レート制御部154、およびエントロピ符号化部155を有する。
符号化部121に入力された画像データは、途中計算用バッファ部151に一時的に溜め込まれる。ウェーブレット変換部150は、途中計算用バッファ部151に溜め込まれた画像データに対してウェーブレット変換を施す。すなわち、ウェーブレット変換部150は、途中計算用バッファ部151から画像データを読み出して分析フィルタによりフィルタ処理を施して低域成分および高域成分の係数のデータを生成し、生成された係数データを途中計算用バッファ部151に格納する。ウェーブレット変換部150は、水平分析フィルタと垂直分析フィルタとを有し、画像データ群に対して、画面水平方向と画面垂直方向の両方について分析フィルタ処理を行う。ウェーブレット変換部150は、途中計算用バッファ部151に格納された低域成分の係数データを再度読み出し、読み出した係数データに対して分析フィルタによるフィルタ処理を施して、高域成分および低域成分の係数のデータをさらに生成する。生成された係数データは、途中計算用バッファ部151に格納される。
ウェーブレット変換部150は、この処理を繰り返して分解レベルが所定レベルに達したら、途中計算用バッファ部151から係数データを読み出し、読み出された係数データを係数並び替え用バッファ部152に書き込む。
係数並び替え部153は、係数並び替え用バッファ部152に書き込まれた係数データを所定の順序で読み出し、エントロピ符号化部155に供給する。エントロピ符号化部155は、供給された係数データを、例えばハフマン符号化や算術符号化といった所定のエントロピ符号化方式で符号化する。
エントロピ符号化部155は、レート制御部154と連動的に動作し、出力される圧縮符号化データのビットレートが略一定値となるように制御される。すなわち、レート制御部154は、エントロピ符号化部155からの符号化データ情報に基づき、エントロピ符号化部155により圧縮符号化されたデータのビットレートが目標値に達した時点あるいは目標値に達する直前でエントロピ符号化部155による符号化処理を終了するように制御する制御信号を、エントロピ符号化部155に対して供給する。エントロピ符号化部155は、レート制御部154から供給される制御信号に応じて符号化処理が終了した時点で、符号化データを出力する。
なお、エントロピ符号化部155が、係数並び替え部153から読み出された係数データに対して、最初に量子化を行い、得られた量子化係数に対してハフマン符号化や算術符号化等の情報源符号化処理を施すようにすれば、さらに圧縮効果の向上を期待することができる。この量子化の方法としてはどのようなものを用いても良く、例えば、一般的な手段、つまり、以下の式(1)に示されるような、係数データWを量子化ステップサイズΔで除算する手法を用いれば良い。
量子化係数=W/Δ ・・・(1)
この時の量子化ステップサイズΔは、例えばレート制御部154において算出される。
エントロピ符号化部155は、符号化により得られた符号化データをパケタイズ処理部122に供給する。
次に、図2のウェーブレット変換部150で行われる処理について、より詳細に説明する。先ず、ウェーブレット変換について、概略的に説明する。画像データに対するウェーブレット変換では、図3に概略的に示されるように、画像データを空間周波数の高い帯域と低い帯域とに分割する処理を、分割の結果得られる空間周波数の低い帯域のデータに対して再帰的に繰り返す。こうして、空間周波数の低い帯域のデータをより小さな領域に追い込んでいくことで、効率的な圧縮符号化を可能とする。
なお、図3は、画像データの最低域成分領域に対する低域成分の領域Lおよび高域成分の領域Hへの分割処理を3回、繰り返し、分割の階層の総数を示す分割レベル=3とした場合の例である。図3において、"L"および"H"は、それぞれ低域成分および高域成分を表し、"L"および"H"の順序は、前側が横方向に分割した結果の帯域を示し、後側が縦方向に分割した結果の帯域を示す。また、"L"および"H"の前の数字は、その領域の階層を示しており、低域成分の階層ほど小さい値で表されている。
また、図3の例から分かるように、画面の右下の領域から左上の領域にかけて段階的に処理がなされ、低域成分が追い込まれていく。すなわち、図3の例では、画面の右下の領域が最も低域成分の少ない(高域成分が最も多く含まれる)領域3HHとされる、画面が4分割された左上の領域は、さらに4分割され、この4分割された領域のうち左上の領域がさらに4分割される。最も左上隅の領域は、最も低域成分を多く含む領域0LLとされる。
低域成分に対して繰り返し変換および分割を行うのは、画像のエネルギが低域成分に集中しているためである。このことは、図4Aに一例が示される分割レベル=1の状態から、図4Bに一例が示される分割レベル=3の状態のように分割レベルを進めていくに従って、図4Bに示されるようにしてサブバンドが形成されていくことからも、理解される。例えば、図3におけるウェーブレット変換の分割レベルは3であり、この結果、10個のサブバンドが形成されている。
ウェーブレット変換部150は、通常、低域フィルタと高域フィルタとから構成されるフィルタバンクを用いて、上述のような処理を行う。なお、デジタルフィルタは、通常、複数タップ長のインパルス応答すなわちフィルタ係数を持っているため、フィルタ処理を行えるだけの入力画像データまたは係数データを予めバッファリングしておく必要がある。また、ウェーブレット変換を多段にわたって行う場合も同様に、前段で生成したウェーブレット変換係数を、フィルタ処理が行える数だけバッファリングしておく必要がある。
このウェーブレット変換の具体的な例として、5×3フィルタを用いた方法について説明する。この5×3フィルタを用いた方法は、JPEG2000規格でも採用されており、少ないフィルタタップ数でウェーブレット変換を行うことができる点で、優れた方法である。
5×3フィルタのインパルス応答(Z変換表現)は、次の式(2)および式(3)に示すように、低域フィルタH0(z)と、高域フィルタH1(z)とから構成される。式(2)および式(3)から、低域フィルタH0(z)は、5タップで、高域フィルタH1(z)は、3タップであることが分かる。
0(z)=(−1+2z-1+6z-2+2z-3−z-4)/8 ・・・(2)
1(z)=(−1+2z-1−z-2)/2 ・・・(3)
これら式(2)および式(3)によれば、低域成分および高域成分の係数を、直接的に算出することができる。ここで、リフティング(Lifting)技術を用いることで、フィルタ処理の計算を減らすことができる。
次に、このウェーブレット変換方法について、さらに具体的に説明する。図5は、5×3フィルタのリフティングによるフィルタ処理を、分解レベル=2まで実行した例を示している。なお、図5において、図の左側に分析フィルタとして示される部分は、ウェーブレット変換部150のフィルタである。また、図の右側に合成フィルタとして示される部分は、後述する復号装置におけるウェーブレット逆変換部のフィルタである。
なお、以下の説明では、例えば表示デバイスなどにおいて画面の左上隅の画素を先頭として、画素が画面の左端から右端に向けて走査されて1ラインが構成され、ライン毎の走査が画面の上端から下端に向けて行われて1画面が構成されるものとする。
図5において、左端列は、原画像データのライン上の対応する位置にある画素データが縦方向に並べられて示されている。すなわち、ウェーブレット変換部150におけるフィルタ処理は、垂直フィルタを用いて画面上を画素が縦に走査されて行われる。左端から1列目乃至3列目が分割レベル=1のフィルタ処理を示し、4列目乃至6列目が分割レベル=2のフィルタ処理を示す。左端から2列目は、左端の原画像データの画素に基づく高域成分出力、左端から3列目は、原画像データおよび高域成分出力に基づく低域成分出力を示す。分割レベル=2のフィルタ処理は、左端から4列目乃至6列目に示されるように、分割レベル=1のフィルタ処理の出力に対して処理がなされる。
分解レベル=1のフィルタ処理において、第1段階のフィルタ処理として、原画像データの画素に基づき高域成分の係数データが算出され、第2段階のフィルタ処理として、第1段階のフィルタ処理で算出された高域成分の係数データと、原画像データの画素とに基づき低域成分の係数データが算出される。分解レベル=1の一例のフィルタ処理を、図5における左側(分析フィルタ側)の第1列目乃至第3列目に示す。算出された高域成分の係数データは、図2の係数並び替え用バッファ部152に格納される。また、算出された低域成分の係数データは、図2の途中計算用バッファ部151に格納される。
図5においては、係数並び替え用バッファ部152は、一点鎖線で囲まれた部分として示し、途中計算用バッファ部151は、点線で囲まれた部分として示す。
途中計算用バッファ部151に保持された分解レベル=1のフィルタ処理の結果に基づき、分解レベル=2のフィルタ処理が行われる。分解レベル=2のフィルタ処理では、分解レベル=1のフィルタ処理において低域成分の係数として算出された係数データを、低域成分および高域成分を含んだ係数データと見做して、分解レベル=1と同様のフィルタ処理を行う。分解レベル=2のフィルタ処理により算出された、高域成分の係数データおよび低域成分の係数データは、係数並び替え用バッファ部152に格納される。
ウェーブレット変換部150では、上述したようなフィルタ処理を、画面の水平方向および垂直方向にそれぞれ行う。例えば、先ず、分解レベル=1のフィルタ処理を水平方向に行い、生成された高域成分および低域成分の係数データを途中計算用バッファ部151に格納する。次に、途中計算用バッファ部151に格納された係数データに対して、垂直方向に分解レベル=1のフィルタ処理を行う。この分解レベル=1の水平および垂直方向の処理により、高域成分をさらに高域成分および低域成分に分解した係数データのそれぞれによる領域HHおよび領域HLと、低域成分をさらに高域成分および低域成分に分解した係数データのそれぞれによる領域LHおよび領域LLとの4領域が形成される。
そして、分解レベル=2では、水平方向および垂直方向のそれぞれについて、分解レベル=1で生成された低域成分の係数データに対してフィルタ処理が行われる。すなわち、分解レベル=2では、分解レベル=1で分割されて形成された領域LLがさらに4分割され、領域LL内にさらに領域HH、領域HL、領域LHおよび領域LLが形成される。
ウェーブレット変換部150は、ウェーブレット変換によるフィルタ処理を、画面の縦方向について、数ライン毎の処理に分割して、複数回に分けて段階的に行うようにしている。図5の例では、画面上の第1ラインからの処理になる1回目の処理は、7ラインについてフィルタ処理を行い、8ライン目からの処理になる2回目以降の処理は、4ライン毎にフィルタ処理を行っている。このライン数は、高域成分と低域成分とに2分解した後に、1ライン分の最低域成分が生成されるために必要なライン数に基づく。
なお、以下において、この最低域成分の1ライン分(最低域成分のサブバンドの1ライン分の係数データ)を生成するために必要な、他のサブバンドも含めたラインの集まりを、プレシンクト(またはラインブロック)と称する。ここでラインとは、ウェーブレット変換前の画像データに対応するピクチャ若しくはフィールド内、または各サブバンド内において形成される1行分の画素データ若しくは係数データのことを示す。すなわち、プレシンクト(ラインブロック)とは、ウェーブレット変換前の元の画像データにおける、ウェーブレット変換後の最低域成分のサブバンド1ライン分の係数データを生成するために必要なライン数分の画素データ群、または、その画素データ群をウェーブレット変換して得られる各サブバンドの係数データ群のことを示す。
図5によれば、分解レベル=2のフィルタ処理結果で得られる係数C5は、係数C4および途中計算用バッファ部151に格納された係数Caに基づき算出され、係数C4は、途中計算用バッファ部151に格納された係数Ca、係数Cbおよび係数Ccに基づき算出される。さらに、係数Ccは、係数並び替え用バッファ部152に格納される係数C2および係数C3、並びに、第5ラインの画素データに基づき算出される。また、係数C3は、第5ライン乃至第7ラインの画素データに基づき算出される。このように、分割レベル=2における低域成分の係数C5を得るためには、第1ライン乃至第7ラインの画素データが必要とされる。
これに対して、2回目以降のフィルタ処理においては、前回までのフィルタ処理で既に算出され係数並び替え用バッファ部152に格納されている係数データを用いることができるので、必要なライン数が少なくて済む。
すなわち、図5によれば、分解レベル=2のフィルタ処理結果で得られる低域成分の係数のうち、係数C5の次の係数である係数C9は、係数C4および係数C8、並びに、途中計算用バッファ部151に格納された係数Ccに基づき算出される。係数C4は、上述した1回目のフィルタ処理により既に算出され、係数並び替え用バッファ部152に格納されている。同様に、係数Ccは、上述の1回目のフィルタ処理により既に算出され、途中計算用バッファ部151に格納されている。したがって、この2回目のフィルタ処理においては、係数C8を算出するためのフィルタ処理のみが、新たになされることになる。この新たなフィルタ処理は、第8ライン乃至第11ラインがさらに用いられてなされる。
このように、2回目以降のフィルタ処理は、前回までのフィルタ処理により算出され途中計算用バッファ部151および係数並び替え用バッファ部152に格納されたデータを用いることができるので、それぞれ4ライン毎の処理で済むことになる。
なお、画面上のライン数が符号化のライン数と合致しない場合は、原画像データのラインを所定の方法で複製してライン数を符号化のライン数と合わせて、フィルタ処理を行う。
このように、最低域成分1ライン分の係数データが得られるだけのフィルタ処理を段階的に、画面全体のラインに対して複数回に分けて(プレシンクト単位で)行うことで、符号化データを伝送した際に低遅延で復号画像を得ることを可能としている。
ウェーブレット変換を行うためには、ウェーブレット変換そのものを実行するために用いられる第1のバッファと、所定の分割レベルまで処理を実行する間に生成される係数を格納するための第2のバッファとが必要とされる。第1のバッファは、途中計算用バッファ部151に対応し、図5においては点線で囲まれて示されている。また、第2のバッファは、係数並び替え用バッファ部152に対応し、図5においては一点鎖線に囲まれて示されている。第2のバッファに格納された係数は、復号の際に用いられるため、後段のエントロピ符号化処理の対象とされる。
次に、図2の係数並び替え部153の処理について説明する。上述したように、ウェーブレット変換部150で算出された係数データは、係数並び替え用バッファ部152に格納され、係数並び替え部153により順序を並び替えられて読み出され、コーディングユニット単位でエントロピ符号化部155に送出される。
既に説明したように、ウェーブレット変換においては、高域成分側から低域成分側へと係数が生成されていく。図5の例では、1回目において、原画像の画素データにより、分解レベル=1のフィルタ処理で、高域成分の係数C1、係数C2および係数C3が順次生成される。そして、分解レベル=1のフィルタ処理で得られた低域成分の係数データに対して分解レベル=2のフィルタ処理を行い、低域成分の係数C4および係数C5が順次生成される。すなわち、第1回目では、係数C1、係数C2、係数C3、係数C4、係数C5の順に、係数データが生成される。この係数データの生成順は、ウェーブレット変換の原理上、必ずこの順序(高域から低域の順)になる。
これに対して、復号側では、低遅延で即座に復号を行うためには低域成分から画像の生成および出力を行う必要がある。そのため、符号化側で生成された係数データを最低域成分側から高域成分側に向けて並び替えて復号側に供給することが望ましい。
図5の例を用いて、より具体的に説明する。図5の右側は、逆ウェーブレット変換を行う合成フィルタ側を示す。復号側の、出力画像データの第1ライン目を含む1回目の合成処理(逆ウェーブレット変換処理)は、符号化側の1回目のフィルタ処理で生成された最低域成分の係数C4および係数C5と、係数C1とを用いて行われる。
すなわち、1回目の合成処理においては、係数C5、係数C4、係数C1の順に符号化側から復号側に係数データを供給し、復号側では、分解レベル=2に対応する合成処理である合成レベル=2の処理で、係数C5および係数C4に対して合成処理を行って係数Cfを生成し、バッファに格納する。そして、分解レベル=1に対応する合成処理である合成レベル=1の処理で、この係数Cfと係数C1に対して合成処理を行って、第1ラインを出力する。
このように、第1回目の合成処理においては、符号化側で係数C1、係数C2、係数C3、係数C4、係数C5の順に生成され係数並び替え用バッファ部152に格納された係数データが、係数C5、係数C4、係数C1、・・・の順に並び替えられて復号側に供給される。
なお、図5の右側に示す合成フィルタ側では、符号化側から供給される係数について、括弧内に符号化側での係数の番号を記し、括弧外に合成フィルタのライン順を記す。例えば係数C1(5)は、図5の左側の分析フィルタ側では係数C5であって、合成フィルタ側では第1ライン目であることを示す。
符号化側の2回目以降のフィルタ処理で生成された係数データによる復号側の合成処理は、前回の合成処理の際に合成あるいは符号化側から供給された係数データを用いて行うことができる。図5の例では、符号化側の2回目のフィルタ処理で生成された低域成分の係数C8および係数C9を用いて行う、復号側の2回目の合成処理は、符号化側の1回目のフィルタ処理で生成された係数C2および係数C3がさらに必要とされ、第2ライン乃至第5ラインが復号される。
すなわち、2回目の合成処理においては、係数C9、係数C8、係数C2、係数C3の順に符号化側から復号側に係数データを供給する。復号側では、合成レベル=2の処理において、係数C8および係数C9と、1回目の合成処理の際に符号化側から供給された係数C4とを用いて係数Cgを生成し、バッファに格納する。この係数Cgと、上述の係数C4と、1回目の合成処理により生成されバッファに格納された係数Cfとを用いて係数Chを生成し、バッファに格納する。
そして、合成レベル=1の処理において、合成レベル=2の処理で生成されバッファに格納された係数Cgおよび係数Chと、符号化側から供給された係数C2(合成フィルタでは係数C6(2)と示されている)および係数C3(合成フィルタでは係数C7(3)と示されている)とを用いて合成処理が行われ、第2ライン乃至第5ラインが復号される。
このように、第2回目の合成処理においては、符号化側で係数C2、係数C3、(係数C4、係数C5)、係数C6、係数C7、係数C8、係数C9の順に生成された係数データが、係数C9、係数C8、係数C2、係数C3、・・・の順に並び替えられて復号側に供給される。
3回目以降の合成処理においても、同様にして、係数並び替え用バッファ部152に格納された係数データが所定の順序に並び替えられて復号部に供給され、4ラインずつ、ラインが復号される。
なお、符号化側において画面の下端のラインを含むフィルタ処理(以下、最後の回と呼ぶ)に対応する復号側の合成処理では、それまでの処理で生成されバッファに格納された係数データを全て出力することになるため、出力ライン数が多くなる。図5の例では、最後の回に8ラインが出力される。
なお、係数並び替え部153による係数データの並び替え処理は、例えば、係数並び替え用バッファ部152に格納された係数データを読み出す際の読み出しアドレスを、所定の順序に設定することでなされる。
図6を用いて、上述までの処理をより具体的に説明する。図6は、5×3フィルタを用いて、分解レベル=2までウェーブレット変換によるフィルタ処理を施した例である。ウェーブレット変換部150において、図6Aに一例が示されるように、入力画像データの第1ラインから第7ラインに対して1回目のフィルタ処理が水平および垂直方向にそれぞれ行われる(図6AのIn−1)。
1回目のフィルタ処理の分解レベル=1の処理において、係数C1、係数C2、および係数C3の3ライン分の係数データが生成され、図6Bに一例が示されるように、分解レベル=1で形成される領域HH、領域HLおよび領域LHのそれぞれに配置される(図6BのWT−1)。
また、分解レベル=1で形成される領域LLは、分解レベル=2による水平および垂直方向のフィルタ処理でさらに4分割される。分解レベル=2で生成される係数C5および係数C4は、分解レベル=1による領域LL内において、領域LLに係数C5による1ラインが配置され、領域HH、領域HLおよび領域LHのそれぞれに、係数C4による1ラインが配置される。
ウェーブレット変換部150による2回目以降のフィルタ処理では、4ライン毎にフィルタ処理が行われ(図6AのIn−2・・・)、分解レベル=1で2ラインずつの係数データが生成され(図6BのWT−2)、分解レベル=2で1ラインずつの係数データが生成される。
図5の2回目の例では、分解レベル=1のフィルタ処理で係数C6および係数C7の2ライン分の係数データが生成され、図6Bに一例が示されるように、分解レベル1で形成される領域HH、領域HLおよび領域LHの、1回目のフィルタ処理で生成された係数データの次から配置される。同様に、分解レベル=1による領域LL内において、分解レベル=2のフィルタ処理で生成された1ライン分の係数C9が領域LLに配置され、1ライン分の係数C8が領域HH、領域HLおよび領域LHにそれぞれ配置される。
図6Bのようにウェーブレット変換されたデータを復号した際には、図6Cに一例が示されるように、符号化側の第1ライン乃至第7ラインによる1回目のフィルタ処理に対して、復号側の1回目の合成処理による第1ラインが出力される(図6CのOut−1)。以降、符号化側の2回目から最後の回の前までのフィルタ処理に対して、復号側で4ラインずつが出力される(図6CのOut−2・・・)。そして、符号化側の最後の回のフィルタ処理に対して、復号側で8ラインが出力される。
ウェーブレット変換部150で高域成分側から低域成分側へと生成された係数データは、係数並び替え用バッファ部152に順次格納される。係数並び替え部153は、上述した係数データの並び替えが可能となるまで係数並び替え用バッファ部152に係数データが蓄積されると、係数並び替え用バッファ部152から合成処理に必要な順に並び替えて係数データを読み出す。読み出された係数データは、エントロピ符号化部155に順次、供給される。
以上のようにプレシンクト単位で符号化された画像データ(符号化データ)は、パケタイズ処理部122に供給される。その際、エントロピ符号化部155は、プレシンクト単位で、その画像データに関する情報をヘッダ情報(プレシンクトヘッダ)としてパケタイズ処理部122に供給する。図7にそのプレシンクトヘッダの構成例を示す。
図7に示されるように、プレシンクトヘッダ171は、4ワード(32×4ビット)分のデータよりなり、PID、AT、AID、FT、CF、IF、プレシンクトタイムスタンプ、量子化係数、およびプレシンクトコード長等の情報を含む。
PID(Precinct ID)は、ピクチャの先頭から数えたプレシンクトの番号を示す12ビットの情報である。AT(Align Unit Type)は、プレシンクト内に構成されるアラインユニットの属性を示す4ビットの情報である。アラインユニットは、プレシンクト内の符号化データが、例えば符号化単位等、所定のデータ単位で分割されたものである。つまり、プレシンクトは1つまたは複数のアラインユニットにより構成される。AID(Align Unit ID)は、プレシンクトの先頭から数えたアラインユニットの番号を示す5ビットの情報である。FT(Field Type)は、ピクチャがプログレッシブであるか、または、インタレースのどちらのフィールドであるかを示す2ビットのフラグ情報である。CF(Component Flag)は、輝度成分Y、色差成分Cb、および色差成分Crのコンポーネントの内、複数のコンポーネントをひとつのアラインユニットやプレシンクトにまとめたことを示す3ビットの情報である。
IF(Incomplete Flag)は、何らかの理由で符号化に失敗したアラインユニットまたはプレシンクトであることを示す1ビットのフラグ情報である。この失敗の範囲は、PID、AT、およびAIDが示すペイロードに限定される。
プレシンクトタイムスタンプ(Precint Time Stamp)は、そのプレシンクトのタイムスタンプの下位32ビットを示す情報である。量子化係数(QP Y or C)は、そのプレシンクトの、輝度成分Yまたは色差成分Cの量子化の際に使用された量子化係数の値を示す16ビットの情報である。プレシンクトコード長(Precinct Code Length Y or C)は、そのプレシンクトの、輝度成分Yまたは色差成分Cの符号化データのデータ長を示す26ビットの情報である。
また、エントロピ符号化部155は、ピクチャ単位で、その画像データに関する情報をヘッダ情報(ピクチャヘッダ)としてパケタイズ処理部122に供給する。図8にそのピクチャヘッダの構成例を示す。
図8に示されるように、ピクチャヘッダ172は、26ワード(32×26ビット)分のデータよりなり、PI、w、CEF、CBD、DL、WF、PDI、SF、FR、AR、DBSZ、フルタイムスタンプ、V0スタートポジション、SD、Hスタートポジション、VF、V合計サイズ、TSD、H合計サイズ、PXCS、Vサイズ、VSD、Hサイズ、BRT、CTS、およびWTm等の情報を含む。
PI(Profile Indication)は、プロファイルの指定を行う5ビットの情報である。wは、重み付け係数のカスタム値を設定するためのテーブル情報であるウェイティングテーブルをパケットに含めるか否かを示す1ビットのフラグ情報である。CEF(Color Extension Flag)は、カラー情報の拡張ヘッダを使用するか否かを示す1ビットのフラグ情報である。CBD(Component Bit Depth)は、コンポーネントのビット深度を示す5ビットの情報である。予め指定された値から「8」を引いた値が格納される。DL(DWT Level)は、ウェーブレット変換の分割数(分割レベル)を示す3ビットの情報である。WF(Wavelet Filter)は、ウェーブレット変換において使用されたフィルタの種類を示す2ビットの情報である。PDI(Picture Discontinuity Indication)は、タイムスタンプの連続性を示す1ビットの情報である。SF(Sampling Format)は、色差のサンプリング法を示す2ビットの情報である。
FR(Frame Rate)は、フレームレートを示す1ビットの情報である。AR(Aspect Ratio)は、画素アスペクト比を示す6ビットの情報である。DBSZ(Decoder Buffer Size)は、デコーダでのプレシンクトバッファサイズを示す4ビットの情報である。フルタイムスタンプ(FTS(Full Time Stamp))は、フルサイズのタイムスタンプを示す46ビットの情報である。
V0スタートポジション(FFVS(First Field Vertical Start))は、先頭フィールドの垂直方向有効画素開始位置を示す13ビットの情報である。SD(Start Diff)は、FFVSと第2フィールドとの差分を示す2ビットの情報である。Hスタートポジション(HS(Horizontal Start))は、水平方向の有効画素開始位置を示す13ビットの情報である。VF(Video Format)は、圧縮信号の映像フォーマットを示す4ビットの情報である。
V合計サイズ(FFVTS(First Field Vertical Total Size))は、先頭フィールドのブランクを含めた総画素数を示す13ビットの情報である。TSD(Total Size Diff)は、FFVTSと第2フィールドとの差分を示す2ビットの情報である。H合計サイズ(HTS(Horizontal Total Size))は、水平方向のブランクを含めた総画素数を示す13ビットの情報である。PXCS(Pixel Clock Scale)は、クロックの倍率を示す3ビットの情報である。
Vサイズ(FFVVS(First Field Vertical Valid Size))は、先頭フィールドの垂直方向有効画素サイズを示す13ビットの情報である。VSD(Valid Size Diff)は、FFVVSと第2フィールドとの差分を示す2ビットの情報である。Hサイズ(HVS(Horizontal Valid Size))は、水平方向の有効画素サイズを示す13ビットの情報である。BRT(B Value Reset Timing)は、B値のリセットタイミングを示す2ビットの情報である。
CTS(Custom Table Size)は、カスタムテーブルのサイズを示す16ビットの情報である。指定値の数だけ後続のカスタム値が存在し、そのサイズはCTS×2バイトである。WTm(Weighting Table m)は、m番目のウェイティングテーブルを示す16×mビットの情報である。
なお、実際には、図9に示されるように、符号化部121からパケタイズ処理部122へは、データ以外にも、属性情報やVALID情報等が供給される。属性情報は、供給するデータが、ヘッダであるか画像データであるかを示したり、輝度成分のデータであるか色差成分のデータであるかを示したりする情報である。VALID情報は、データの読み取りタイミングを通知する情報である。
パケタイズ処理部122は、所定のデータ単位(プレシンクト)毎に供給される符号化データに対して、そのデータのサイズと、別途指定されるパケットサイズに基づいて、パケタイズ処理を行う。
図10は、図1のパケタイズ処理部122の内部の構成例を示すブロック図である。
図10においてパケタイズ処理部122は、データ取得部201、RTP(Real-time Transport Protocol)ヘッダ作成部202、共通ヘッダ作成部203、拡張ヘッダ作成部204、ピクチャ情報作成部205、フラグ確認部206、サイズ確認部207、フラグメント処理部208、パケット化部209、および出力部210を有する。
データ取得部201は、符号化部121より供給される符号化データやパケット等を、そのデータともに供給される属性情報やVALID情報等に基づいて取得する。例えば、プレシンクトヘッダ171を取得すると、データ取得部201は、それを、RTPヘッダ作成部202、共通ヘッダ作成部203、拡張ヘッダ作成部、フラグ確認部206、およびサイズ確認部207に供給する。また、例えば、ピクチャヘッダ172を取得すると、データ取得部201は、それをピクチャ情報作成部205に供給する。さらに、例えば、符号化データを取得すると、データ取得部201は、それをフラグメント処理部208に供給する。
RTPヘッダ作成部202は、データ取得部201がプレシンクトヘッダを取得すると、その取得されたプレシンクトヘッダに基づいて、RTPパケットのヘッダであるRTPヘッダを作成する。RTPヘッダの詳細については後述する。RTPヘッダ作成部202は、作成したRTPヘッダをパケット化部209に供給し、処理終了を共通ヘッダ作成部203に通知する。
RTPヘッダ作成部202より通知を受けると、共通ヘッダ作成部203は、データ取得部201が取得したプレシンクトヘッダ171に基づいて、そのプレシンクトより作成される各パケットに付加される共通のヘッダである共通ヘッダを作成する。共通ヘッダにはそのプレシンクトに関する基本的な情報が含まれる。共通ヘッダの詳細については後述する。共通ヘッダ作成部203は、作成した共通ヘッダをパケット化部209に供給し、処理終了を拡張ヘッダ作成部204に通知する。
共通ヘッダ作成部203より通知を受けると、拡張ヘッダ作成部204は、データ取得部201が取得したプレシンクトヘッダ171に基づいて、そのプレシンクトに関する、共通ヘッダには含まれない情報を必要に応じて付与する拡張ヘッダの情報を作成する。この拡張ヘッダの作成により、送信者は柔軟かつ効率的なヘッダ作成が可能になる。拡張ヘッダの情報の内容は任意であるが、例えば、量子化係数に関する情報や、サイズに関する情報等がある。拡張ヘッダの詳細については後述する。拡張ヘッダ作成部204は、作成した拡張ヘッダをパケット化部209に供給し、処理終了をピクチャ情報作成部205に通知する。
拡張ヘッダ作成部204より通知を受け、さらに、データ取得部201がピクチャヘッダ172を取得すると、ピクチャ情報作成部205は、そのピクチャヘッダ172に基づいて、そのピクチャに関する情報を含むピクチャ情報を作成する。このピクチャ情報の詳細については後述する。ピクチャ情報作成部205は、作成したピクチャ情報をパケット化部209に供給し、そのピクチャ情報を拡張ヘッダに挿入させ、処理終了をフラグ確認部206に通知する。なお、データ取得部201がピクチャヘッダ172を取得しない場合、ピクチャ情報作成部205は、ピクチャ情報を作成せずに、処理終了をフラグ確認部206に通知する。
ピクチャ情報作成部205より通知を受けると、フラグ確認部206は、データ取得部201が取得したプレシンクトヘッダ171に含まれるIFを参照し、そのフラグの値に応じて、パケットに符号化データを含めるか否かを判定する。例えば、「IF=1」である場合、フラグ確認部206は、そのプレシンクトのデータの符号化は失敗したと判定し、データ取得部201に、その復号不可能な符号化データを破棄させる(取得しない)ようにし、さらに、パケット化部209を制御し、ヘッダ情報のみで(ペイロードを含めないように)パケット化させる。また、例えば、「IF=0」である場合、フラグ確認部206は、そのプレシンクトの符号化は成功したと判定し、パケット化部209にペイロードを含めてパケット化させるようにし、処理終了をサイズ確認部207に通知する。
フラグ確認部206より通知を受けると、サイズ確認部207は、データ取得部201が取得したプレシンクトヘッダに含まれるプレシンクトコード長に基づいて、プレシンクトのデータサイズが、予め別途設定されているパケットサイズ(1つのパケットに含まれるペイロードのデータサイズの最大値)より大きいか否かを確認する。例えば、パケットサイズよりプレシンクトのデータサイズの方が大きい場合、サイズ確認部207は、フラグメント処理部208を制御し、データ取得部201が取得する符号化データをパケットサイズ毎に分割させる。逆に、例えば、パケットサイズよりプレシンクトのデータサイズの方が大きくない場合、サイズ確認部207は、フラグメント処理部208を制御し、データ取得部201が取得する符号化データを分割させないようにする。
フラグメント処理部208は、サイズ確認部207に制御されて、プレシンクトのデータサイズがパケットサイズより大きい場合、データ取得部201が取得する符号化データを、パケットサイズ毎に分割してパケット化部209に供給する。つまり、この場合、フラグメント処理部208は、データ取得部201がヘッダ部分も考慮した1パケットサイズ分の符号化データを取得する度に、その1パケットサイズ分の符号化データを1つのペイロードとしてパケット化部209に供給する。
逆に、プレシンクトのデータサイズがパケットサイズより大きくない場合、フラグメント処理部208は、サイズ確認部207に制御されて、データ取得部201が取得する符号化データを、そのままパケット化部209に供給する。つまり、この場合、フラグメント処理部208は、データ取得部201が取得する1プレシンクト分の符号化データを1つのペイロードとしてパケット化部209に供給する。
パケット化部209は、各部より供給されるヘッダ情報を用いてフラグメント処理部208より供給されるペイロードをパケット化する。例えば、1プレシンクトの符号化データがフラグメント処理部208により複数のペイロードに分割される場合、パケット化部209は、各ペイロードに対して、それぞれ必要なヘッダ情報を付加し、それぞれをパケット化する。また、例えば、フラグメント処理部208が符号化データを分割しない場合、パケット化部209は、フラグメント処理部208より供給された1つのペイロードに対して必要なヘッダ情報を付加しパケット化する。さらに、例えば、フラグ確認部206が、ペイロードをパケットに含めないように指示する場合、パケット化部209は、その指示に基づいてヘッダ情報のみでパケット化を行う。
また、パケット化部209は、生成した各パケットの共通ヘッダに含まれるSFFやM等のフラグ情報の値を適宜設定する。SFF(Start Fragment Flag)は、そのパケットがプレシンクトの先頭部分を含むパケット(先頭パケット)であるか否かを示すフラグ情報であり、M(Marker)は、プレシンクトの終端部分を含むパケット(最終パケット)であるか否かを示すフラグ情報である。これらのフラグ情報は、デパケタイズ処理部132によるデパケタイズ処理時に参照される。
例えば、フラグメント処理部208が符号化データを分割する場合、パケット化部209は、1プレシンクトの符号化データが分割されて生成されたペイロード群の内、先頭のペイロードのパケットのSFFを1に設定し、最後のペイロードのパケットのMを1に設定する。
また、例えば、フラグメント処理部208が符号化データを分割しない場合、パケット化部209は、生成された1つのパケットのSFFおよびMのそれぞれを1に設定する。
このようにSFFやM等のフラグ情報を設定することにより、デパケタイズ処理部132は、このフラグ情報を参照するだけで容易に、そのパケットがプレシンクトの先頭パケットであるか、最終パケットであるか、またはそれ以外のパケットであるかを把握することができる。これにより、デパケタイズ処理部132は、後述するように待機時間を低減させることができ、デパケタイズ処理の遅延時間を低減させることができる。
パケット化部209は、生成したパケットを出力部210に供給する。
出力部210は、パケット化部209より供給されるRTPパケットを、送信部123(図1)に供給し、受信装置103(図1)に送信させる。
上述したように符号化部121は、図11に示されるように、1ピクチャ(フレームまたはフィールド)を、複数のプレシンクトに分割し、そのプレシンクト毎に符号化を行う。
パケタイズ処理部122は、図12に示されるように、1つのプレシンクトの符号化データを所定のパケットサイズ毎に分割してパケット化する。プレシンクトのデータサイズがパケットサイズより大きくなければ、生成されるパケットは1つとなる。図12の例においては1つのプレシンクトの符号化データから5つのパケットが生成されている。
画像データの伝送フォーマットの一例について以下に示す。
図13は、RTPヘッダ作成部202が作成する、RTPパケットのヘッダ情報であるRTPヘッダの構成を示している。RTPヘッダ221には、バージョン番号(V)、パディング(P)、拡張ヘッダ(X)の有無、送信元数(Counter)(CC)、マーカ情報(marker bit)(M)、ペイロードタイプ(Payload type)(PT)、シーケンス番号、タイムスタンプ、および同期ソース(送信元)識別子(SSRC(Synchronization Source Identifier))の各フィールドが設けられている。
バージョン番号(V)は、RTPのバージョン番号を示す2ビットの情報である。パディング(P)は、1ビットのフラグ情報であり、その値が「1」のとき、ペイロードの最後にパディング・オクテット(埋め込みデータ)が1つ以上付加されていることを示す。拡張ヘッダ(X)の有無は、1ビットのフラグ情報であり、その値が「1」のとき、固定長ヘッダの他に拡張ヘッダが付加されている(ヘッダ拡張がある)ことを示す。送信元数(CC)は、CSRCの識別子の数を示す4ビットの情報であり、例えば、多地点電話会議のように、複数のデータ源のデータを1つのRTPパケット化したときの、個々のデータ源の識別子の数を示す。
マーカ情報(M)は、1ビットのフラグ情報であり、例えば、ペイロードにおける任意のイベント等を示す。このマーカ情報(M)の利用方法は、例えば、ペイロードタイプ(PT)等において設定される。ペイロードタイプ(PT)は、そのパケットで運ぶペイロードの形式を指定する7ビットの情報である。
シーケンス番号は、RTPデータパケットの順序を示す16ビットの番号情報であり、初期値はランダムに設定され、その後に続くパケットにおいては値が「1」ずつ増える。このシーケンス番号は、伝送される符号化データ(画像データ)全体を通してのパケットの順序を示す。
タイムスタンプは、RTPパケットの最初のバイトのサンプリング時刻を示す32ビットの情報である。サンプリングクロックは、ペイロードのデータプロファイルによって決まる。例えば、音声信号の標本化周波数を8kHzとすると、タイムスタンプの値は125μsec毎に「1」増えるので、RTPデータパケットが20msecのデータとすると、タイムスタンプの値はパケットごとに160ずつ増える。なお、初期値はランダムに設定される。
同期ソース(送信元)識別子(SSRC)は、このパケットの送信元を示す32ビットの識別子である。この情報はランダムに生成される。トランスポートアドレスが変わると、このSSRC識別子も更新される。
共通ヘッダ作成部203、拡張ヘッダ作成部204、およびピクチャ情報作成部205はRTPヘッダに続くペイロードヘッダに含まれる各種情報を生成する。図14にペイロードヘッダの構成例を示す。図14に示されるように、ペイロードヘッダは、共通ヘッダ231、量子化パラメータ情報232、サイズ情報233、フォーマット情報234、ピクチャ情報235、およびカラー情報236により構成され、ペイロード237の前に付加される。
共通ヘッダ231は、共通ヘッダ作成部203により作成されるプレシンクトに関する基本的な情報を含むヘッダ情報である。この共通ヘッダ231は必須のヘッダであり、全パケットに付加される。
量子化パラメータ情報232は、拡張ヘッダ作成部204により作成される拡張ヘッダであり、量子化係数に関する情報を含む。サイズ情報233は、拡張ヘッダ作成部204により作成される拡張ヘッダであり、データサイズに関する情報を含む。フォーマット情報234は、拡張ヘッダ作成部204により作成される拡張ヘッダであり、データのフォーマットに関する情報を含む。ピクチャ情報235は、ピクチャ情報作成部205により作成される拡張ヘッダであり、元画像(つまり、符号化され、パケット化されて伝送される画像データ)に関する情報を含む。カラー情報236は、拡張ヘッダ作成部204により作成される拡張ヘッダであり、画像データの色に関する情報を含む。
量子化パラメータ情報232、フォーマット情報234、ピクチャ情報235、およびカラー情報236は、プレシンクトの先頭のパケット(フラグメントを行わない場合のパケットも含む)に拡張ヘッダとして付加される。サイズ情報233は、拡張ヘッダとして任意のパケットに付加される。
つまり、全てのパケットにサイズ情報を付加する場合、プレシンクトの先頭のパケットには、共通ヘッダ231乃至ペイロード237の全てが含まれる。これに対して、プレシンクトの先頭のパケット以外のパケットには、共通ヘッダ231とサイズ情報233とペイロード237のみが含まれる。
各情報の詳細について説明する。
図15は、共通ヘッダ231の構成例を示す図である。図15に示されるように、共通ヘッダ231は、PID、AT、AID、SFF、M、TSF、NF、FT、CF、IF、X、およびTS等の情報を含む。つまり、共通ヘッダ231の第1ワード(上から1段目)と第2ワード(上から2段目)は、符号化部121より供給されるプレシンクトヘッダ171の第1ワード(Word0)と第2ワード(Word1)をそのまま利用して作成されており、第1ワードの空きフィールド(Reserved)であった4ビットに、SFF、M、TSF、およびNFを追加したものである。
SFF(Start Fragment Flag)は、PID、AT、およびAIDが示すペイロードの先頭であるか否かを示す1ビットのフラグ情報である。つまり、このパケットがプレシンクトの先頭のパケット(先頭パケット)である場合、このSFFの値が「1」に設定され、それ以外の場合、「0」に設定される。
M(Marker)は、PID、AT、およびAIDが示すペイロードの終端部分を含むか否かを示す1ビットのフラグ情報である。つまり、このパケットがプレシンクト若しくはアラインユニットの終端部分を含むパケット(最終パケット)である場合、このMの値が「1」に設定され、それ以外の場合、「0」に設定される。
TSF(Time Stamp Flag)は、共通ヘッダにタイムスタンプを含むか否かを示す1ビットのフラグ情報である。つまり、このTSFの値が「1」の場合、共通ヘッダ231の第2ワードには、プレシンクトヘッダ171の第2ワード(Word1)が付加されている。
NF(Next Flag)は、後続ペイロードの存在を示す1ビットのフラグ情報である。つまり、このパケットに複数のプレシンクト若しくはアラインユニットのペイロードが付加されていて、かつ、このヘッダがパケット中の最後のプレシンクト若しくはアラインユニットではない場合、このNFの値が「1」に設定される。
TS(Time Stamp)は、このパケットのペイロードが属するプレシンクトのタイムスタンプの下位32ビットを示す情報であり、プレシンクトヘッダ171の第2ワード(Word1)に対応する。
なお、図15に示される第3ワード(上から3段目)は、共通ヘッダ231に連続して付与される拡張ヘッダを示している。
図16は、拡張ヘッダに含まれる量子化パラメータ情報232の構成例を示す図である。図16に示されるように、量子化パラメータ情報232は、ET、QP、およびX等の情報を含む情報である。拡張ヘッダ作成部204は、符号化部121より供給されるプレシンクトヘッダ171の第3ワード(Word2)を利用して、この量子化パラメータ情報232を作成する。
ET(Extension Type)は、拡張ヘッダの内容を示す5ビットの情報である。この量子化パラメータ情報232使用時の場合の指定値は任意であるが、例えば「00011」である。QP(Quantize Parameter)は、量子化係数の値を示す16ビットの情報である。X(Extension)は、拡張ヘッダを使用するか否かを示すフラグである。
図17は、拡張ヘッダに含まれるサイズ情報233の構成例を示す図である。図17に示されるように、サイズ情報233は、ET、SS、およびX等の情報を含む情報である。拡張ヘッダ作成部204は、符号化部121より供給されるプレシンクトヘッダ171の第4ワード(Word3)を利用して、このサイズ情報233を作成する。
ET(Extension Type)は、拡張ヘッダの内容を示す5ビットの情報である。このサイズ情報233使用時の場合の指定値は任意であるが、例えば「00100」である。SS(Segment Size)は、セグメントのペイロードサイズをワード長で示す26ビットの情報である。X(Extension)は、拡張ヘッダを使用するか否かを示すフラグである。
図7、並びに、図15乃至図17に示されるように、符号化部121は、共通ヘッダ231や拡張ヘッダ(量子化パラメータ情報232やサイズ情報233)と同じフォーマットのプレシンクトヘッダ171を、パケタイズ処理部122に供給する。これにより、パケタイズ処理部122の共通ヘッダ作成部203および拡張ヘッダ作成部204は、容易かつ高速に共通ヘッダおよび拡張ヘッダを作成することができる。
図18は、拡張ヘッダに含まれるフォーマット情報234の構成例を示す図である。フォーマット情報234は、基本的に、図18Aに示されるように、ET、FTI、およびX等の情報を含む。拡張ヘッダ作成部204は、例えば符号化部121より供給される情報を利用して、このフォーマット情報234を作成する。
ET(Extension Type)は、拡張ヘッダの内容を示す5ビットの情報である。このフォーマット情報234使用時の場合の指定値は任意であるが、例えば「00101」である。FTI(Format Type Identifier)は、どのフォーマットタイプに関する情報が記述されているかを示す情報である。この値は任意であるが、例えば、ベイヤ情報が記述されている場合、値「00001」が設定される。X(Extension)は、拡張ヘッダを使用するか否かを示すフラグである。
図18Bに、ベイヤ情報が記述されている場合の、フォーマット情報234の構成例を示す。この場合、フォーマット情報234には、ET、FTI、およびXの他に、MT、SMT、BLF、VLOF、SSF、EVF、DC、BL、RBL、RVLO、DSS、NSS、およびEV等の情報が含まれる。
MT(Mosaic Type)は、ペイロードのモザイクタイプを示す4ビットの情報である。SMT(Start Mosaic Type)は、フレーム左上の最初の画素情報を示す4ビットの女王である。BLF(Black Level Flag)は、黒レベル情報の存在を示す1ビットのフラグ情報である。VLOF(Vertical Line Offset Flag)は、縦筋補正情報の存在を示す1ビットのフラグ情報である。SSF(Shutter Speed Flag)は、シャッタースピード情報の存在を示す1ビットのフラグ情報である。EVF(EV Flag)は、EV情報の存在を示す1ビットのフラグ情報である。DC(Defect Correction)は、欠陥補正を行うか否かを示す1ビットのフラグ情報である。
BL(Black Level)は、黒レベル値を示す32ビットのフラグ情報である。RBL(Revised Black Level)は、黒レベル補正オフセット値を示す32ビットの情報である。BLとRBLは、BLFの値が「1」の場合のみ存在する。
RVLO(Revised Vertical Line Offset)は、縦筋補正オフセット値を示す32ビットの情報である。RVLOは、VLOFの値が「1」の場合のみ存在する。
DSSは、シャッタースピード分子(APEX単位)を示す32ビットの情報である。NSSは、シャッタースピード分母(APEX単位)を示す32ビットの情報である。DSSとNSSは、SSFの値が「1」の場合のみ存在する。
EVは、EV値を示す32ビットの情報である。EVは、EVFの値が「1」の場合のみ存在する。
図19は、拡張ヘッダに含まれるピクチャ情報235の構成例を示す図である。図19に示されるように、ピクチャ情報235は、ET、PI、CEF、CBD、DL、WF、PDI、SF、FR、AR、DBSZ、FTS、FFVS、SD、HS、VF、FFVTS、TSD、HTS、PXCS、FFVVS、VSD、HVS、BRT、WCF、X、CTS、およびWTm等の情報を含む。ピクチャ情報作成部205は、符号化部121より供給されるピクチャヘッダ172を利用して、このピクチャ情報235を作成する。
つまり、ピクチャ情報235は、符号化部121より供給されるピクチャヘッダ172の、第1ワード(Word0)の空きフィールド(Reserved)にETを追加し、第6ワード(Word5)の空きフィールド(Reserved)にWCFとXを追加したものである。
ET(Extension Type)は、拡張ヘッダの内容を示す5ビットの情報である。このピクチャ情報235使用時の場合の指定値は任意であるが、例えば「00010」である。WCF(Waighting Custom Flag)は、重み付け係数のカスタム値を使用するかを示す1ビットのフラグ情報である。このWCFの値が「1」のときのみCTSが存在する。X(Extension)は、拡張ヘッダをこのヘッダに続けて使用するか否かを示すフラグである。
図8、および図19に示されるように、符号化部121は、ピクチャ情報235と同じフォーマットのピクチャヘッダ172を、パケタイズ処理部122に供給する。これにより、パケタイズ処理部122のピクチャ情報作成部205は、容易かつ高速にピクチャ情報235を作成することができる。
図20は、拡張ヘッダに含まれるカラー情報236の構成例を示す図である。図20に示されるように、カラー情報236は、ETやX等の情報を含む。拡張ヘッダ作成部204は、符号化部121より供給される情報等を利用して、このカラー情報236を作成する。
ET(Extension Type)は、拡張ヘッダの内容を示す5ビットの情報である。X(Extension)は、拡張ヘッダを使用するか否かを示すフラグである。
パケタイズ処理部122は、以上のようにプレシンクト毎の符号化データをパケット化し、送信部123に供給する。送信部123は、そのパケットを順次、回線110を介して受信装置103に送信する。
以上のようなフォーマットで送信部123より送出されたパケットは、回線110を介して受信装置103の受信部131に供給される。受信部131は、そのパケットを受信すると、それをデパケタイズ処理部132に供給する。
図21は、デパケタイズ処理部132の内部の構成例を示すブロック図である。図21に示されるように、デパケタイズ処理部132は、例えば、パケット取得部251、ヘッダ情報解析部252、制御モード遷移部253、制御部254、ヘッダ供給部255、データ供給部256、エラー通知部257、および制御信号供給部258を有する。
パケット取得部251は、受信部131より供給されるパケットを取得する。そのとき、パケット取得部251は、RTPペイロードヘッダまで情報を取得すると、その取得を続けながら、既に取得した情報を順次、ヘッダ情報解析部252に供給する。つまり、パケット取得部251は、ペイロードの取得が完了する前に、ヘッダ情報をヘッダ情報解析部252に供給する。また、パケット取得部251は、ヘッダ情報はヘッダ供給部255にも供給し、ペイロードはデータ供給部256にも供給する。
ヘッダ情報解析部252は、パケット取得部251が取得したRTPパケットのヘッダ情報、つまり、RTPヘッダやペイロードヘッダの情報を解析し、その解析結果を制御モード遷移部253や制御部254に供給する。
制御モード遷移部253は、ヘッダ情報解析部252より供給されるヘッダ情報の解析結果に基づいて制御部254の動作モードを制御し、必要に応じて遷移させる。
制御部254は、制御モード遷移部253により制御されて遷移した制御モードで、ヘッダ情報解析部252より供給される解析結果に基づいて、ヘッダ供給部255、データ供給部256、エラー通知部257、および制御信号供給部258の動作を制御する。
ヘッダ供給部255は、制御部254に制御されて、パケット取得部251より供給されるペイロードヘッダに含まれる各種情報を抽出し、プレシンクトヘッダ171やピクチャヘッダ172を復元し、復号部133に供給する。データ供給部256は、制御部254に制御されて、パケット取得部251より供給されるペイロードデータを復号部133に供給する。エラー通知部257は、制御部254に制御されて、パケットロスの発生等のエラーを復号部133に通知する。制御信号供給部258は、制御部254に制御されて、ヘッダやデータ以外の各種制御情報を復号部133に供給する。
制御部254の制御モードには、図22に示されるように、スタートモード301、スタンバイモード302、プロセッシングモード303、およびロスモード304の4つのモードがある。制御モード遷移部253は、ヘッダ情報解析部252によるヘッダ情報の解析結果に基づいて、RTPパケットの受信状況を把握し、その状況に応じて制御部254の制御モードを、最適なモードに遷移させる。
スタートモード301は、符号化データ全体の最初のパケットを処理するためのモードである。デパケタイズ処理開始時、制御部254は、このスタートモード301に設定される。スタンバイモード302は、プレシンクトの先頭のパケットを処理するためのモードである。プレシンクトの最後のパケットが処理された後、制御部254は、このスタンバイモード302に設定される。プロセッシングモード303は、パケットロスが発生していない通常時、プレシンクトの先頭以外の各パケットを処理するためのモードである。パケットロスが発生していないとき、プレシンクトの先頭以外の各パケットに対して、制御部254は、このプロセッシングモード303に設定される。ロスモード304は、パケットロス等のエラーが発生したときに、そのプレシンクトの残りのパケットを処理するためのモードである。パケットロスが発生した場合、制御部254は、このロスモード304に設定される。
各モードにおけるデパケタイズ処理部132の動作の詳細については後述する。
なお、実際には、図23に示されるように、デパケタイズ処理部132から復号部133へは、データ以外にも、スタート情報、エンド情報、VALID情報、属性情報、およびエラー通知等が供給される。
スタート情報は、プレシンクト若しくはアラインユニットの先頭パケットのペイロードを示す情報であり、デパケタイズ処理部132が、プレシンクト若しくはアラインユニットの先頭パケットのペイロードを復号部133に供給するとき、このスタート情報に値「1」が設定される。エンド情報は、プレシンクト若しくはアラインユニットの最終パケットのペイロードを示す情報であり、デパケタイズ処理部132が、プレシンクト若しくはアラインユニットの最終パケットのペイロードを復号部133に供給するとき、このエンド情報に値「1」が設定される。
属性情報は、供給するデータが、ヘッダであるか画像データであるかを示したり、輝度成分のデータであるか色差成分のデータであるかを示したりする情報である。VALID情報は、データの読み取りタイミングを通知する情報である。エラー通知は、パケットロス等のエラーの発生を復号部133に通知する情報である。
図24は、図1の復号部133の内部の構成例を示すブロック図である。図24に示されるように、復号部133は、制御情報取得部351、復号制御部352、復号処理実行部353、ヘッダ取得部354、データ取得部355、エラー通知取得部356、および破棄処理部357を有する。
制御情報取得部351は、デパケタイズ処理部132より、スタート情報、エンド情報、VALID情報、および属性情報等の制御情報を取得し、その制御情報を復号制御部352に供給する。復号制御部352は、その制御情報に基づいて、所定のタイミングで復号処理実行部353に復号処理を開始させる。
復号処理実行部353は、デパケタイズ処理部132より供給され、ヘッダ取得部354により取得されたヘッダ情報に基づいて、データ取得部355により取得された符号化データの復号処理を行う。復号処理実行部353は、図24に示されるように、バッファ部361、エントロピ復号部362、およびウェーブレット逆変換部363を有する。バッファ部361は、データ取得部355より供給される符号化データを一時的に保持し、必要に応じてその符号化データをエントロピ復号部362に供給する。また、バッファ部361は、エントロピ復号部362より供給される、符号化データの復号結果である係数データを一時的に保持し、必要に応じてその係数データをウェーブレット逆変換部363に供給する。
エントロピ復号部362は、復号制御部352に制御されて、バッファ部361に保持されている符号化データを読み出して、符号化部121のエントロピ符号化部155に対応する方法でエントロピ復号し、係数データを生成する。なお、エントロピ符号化部155において、量子化を行う場合、エントロピ復号部362は、エントロピ復号処理を行った後、得られる係数データに対して逆量子化処理も行う。エントロピ復号部362は、得られた係数データをバッファ部361に供給して蓄積させる。
ウェーブレット逆変換部363は、所定のタイミングでバッファ部361に蓄積された係数データを読み出し、符号化部121のウェーブレット変換部150に対応する方法でウェーブレット逆変換処理を行い、得られたベースバンドの画像データを出力画像データとして、表示装置104に出力する。
ヘッダ取得部354は、デパケタイズ処理部132より供給されるプレシンクトヘッダやピクチャヘッダ等のヘッダ情報を取得し、それをバッファ部361に供給して保持させる。データ取得部355は、デパケタイズ処理部132より供給されるペイロードデータを取得し、それをバッファ部361に供給して保持させる。
エラー通知取得部356は、デパケタイズ処理部132より供給される、受信処理においてパケットのロスが発生したこと等を通知するエラー通知を取得し、それを破棄処理部357に供給する。破棄処理部357は、エラー通知を取得すると、復号処理実行部353のバッファ部361に蓄積されている符号化データを破棄させる。つまり、破棄処理部357は、パケットの受信処理においてパケットのロスが発生した場合(シーケンス番号に基づいてパケットロスの発生が確認された場合)、そのパケットロスが発生した現在のプレシンクトに対する正常なエントロピ復号処理が実行不可能であるので、バッファ部361に蓄積されている、パケットロスが発生した現在のプレシンクトの符号化データを全て破棄する。
次に、各部の実行する処理の流れについて説明する。最初に、送信装置102の符号化部121により実行される符号化処理の流れの例を図25のフローチャートを参照して説明する。
符号化処理が開始されると、ウェーブレット変換部150は、ステップS1において、処理対象プレシンクトの番号Aを初期設定にする。通常の場合、番号Aは「1」に設定される。設定が終了すると、ウェーブレット変換部150は、ステップS2において、最低域サブバンドにおいて上からA番目の1ラインを生成するのに必要なライン数(すなわち、1プレシンクト)の画像データを取得し、その画像データに対して、ステップS3において画面垂直方向に並ぶ画像データに対して分析フィルタリングを行う垂直分析フィルタリング処理を行い、ステップS4において画面水平方向に並ぶ画像データに対して分析フィルタリング処理を行う水平分析フィルタリング処理を行う。
ステップS5においてウェーブレット変換部150は、分析フィルタリング処理を最終レベルまで行ったか否かを判定し、分解レベルが最終レベルに達していないと判定した場合、処理をステップS3に戻し、現在の分解レベルに対して、ステップS3およびステップS4の分析フィルタリング処理を繰り返す。
ステップS5において、分析フィルタリング処理が最終レベルまで行われたと判定した場合、ウェーブレット変換部150は、処理をステップS6に進める。
ステップS6において、係数並び替え部153は、プレシンクトA(ピクチャ(フレームまたはフィールド)の上からA番目のプレシンクト)の係数を低域から高域の順番に並び替える。エントロピ符号化部155は、ステップS7において、その係数に対してライン毎にエントロピ符号化する。
エントロピ符号化が終了すると、エントロピ符号化部155は、まず、ステップS8においてプレシンクトヘッダ171(図7)を送出し、ステップS9において、現在の処理対象のプレシンクトがピクチャの先頭のプレシンクト(つまり、A=1)であるか否かを判定する。ピクチャの先頭であると判定された場合、処理はステップS10に進み、エントロピ符号化部155は、ピクチャヘッダ172(図8)を送出する。ステップS10の処理が終了すると、処理はステップS11に進む。また、ステップS9において、現在の処理対象のプレシンクトがピクチャの先頭のプレシンクトでないと判定された場合、ステップS10の処理は省略され、処理はステップS11に進む。
エントロピ符号化部155は、ステップS11において、ヘッダ情報に続いてプレシンクトAの符号化データを外部に送出する。
ウェーブレット変換部150は、ステップS12において番号Aの値を「1」インクリメントして次のプレシンクトを処理対象とし、ステップS13において、処理対象のピクチャについて、未処理の画像入力ラインが存在するか否かを判定し、存在すると判定した場合、処理をステップS2に戻し、新たな処理対象のプレシンクトに対してそれ以降の処理を繰り返す。
以上のようにステップS2乃至ステップS13の処理が繰り返し実行され、各プレシンクトが符号化される。そして、ステップS13において、未処理の画像入力ラインが存在しないと判定した場合、ウェーブレット変換部150は、そのピクチャに対する符号化処理を終了する。次のピクチャに対しては新たに符号化処理が開始される。
従来のウェーブレット変換の方法の場合、まず、水平分析フィルタリング処理をピクチャ全体に対して行い、次に垂直分析フィルタリング処理をそのピクチャ全体に対して行う。そして得られた低域成分全体に対して同様の水平分析フィルタリング処理と垂直分析フィルタリング処理を順に行う。以上のように、分解レベルが最終レベルに達するまで、分析フィルタリング処理が再帰的に繰り返される。従って、各分析フィルタリング処理の結果をバッファに保持させる必要があるが、その際、バッファは、ピクチャ全体、若しくは、その時点の分解レベルの低域成分全体のフィルタリング結果を保持する必要があり、多大なメモリ容量を必要とすることになる(保持するデータ量が多い)。
また、この場合、ピクチャ内において全てのウェーブレット変換が終了するまで、後段の係数並び替えやエントロピ符号化を行うことができず、遅延時間が増大する。
これに対して、符号化部121のウェーブレット変換部150の場合、上述したようにプレシンクト単位で垂直分析フィルタリング処理および水平分析フィルタリング処理を最終レベルまで連続して行うので、従来の方法と比較して、一度に(同時期に)保持する(バッファリングする)必要のあるデータの量が少なく、用意すべきバッファのメモリ量を大幅に低減させることができる。また、最終レベルまで分析フィルタリング処理が行われることにより、後段の係数並び替えやエントロピ符号化等の処理も行うことができる(つまり、係数並び替えやエントロピ符号化をプレシンクト単位で行うことができる)。従って、従来の方法と比較して遅延時間を大幅に低減させることができる。
また、エントロピ符号化部155は、符号化データとともに、プレシンクト毎にプレシンクトヘッダ171を、ピクチャ毎にピクチャヘッダ172をパケタイズ処理部122に供給するので、パケタイズ処理部122は、容易にヘッダ情報を生成することができる。また、このプレシンクトヘッダ171およびピクチャヘッダ172のフォーマットは、パケタイズ処理部122がパケットに付加するペイロードヘッダのフォーマットと同様であるので、パケタイズ処理部122は、さらに容易にヘッダ情報を生成することができる。
さらに、エントロピ符号化部155は、何らかの理由で符号化に失敗した場合、プレシンクトヘッダ171のIFを立てることにより、そのプレシンクトまたはアラインユニットが、符号化に失敗したプレシンクトまたはアラインユニットであることを示す。このIFを参照することによりパケタイズ処理部122は、復号できない不要なデータをパケット化して受信装置103に送信することを容易に抑制することができる。
次に、パケタイズ処理部122によるパケタイズ処理の流れの例を、図26のフローチャートを参照して説明する。
ステップS31において、パケタイズ処理部122のデータ取得部201は、プレシンクトヘッダ171を取得したか否かを判定し、取得したと判定するまで待機する。符号化部121より供給されたプレシンクトヘッダ171を取得したと判定された場合、処理はステップS32に進む。
ステップS32において、RTPヘッダ作成部202は、RTPヘッダ221を作成する。ステップS33において、共通ヘッダ作成部203は、プレシンクトヘッダ171に基づいて、共通ヘッダ231を作成する。このとき、共通ヘッダ作成部203は、プレシンクトヘッダ171の第1ワード(Word0)に、SFF、M、TSF、およびNFのフィールドを追加する。
ステップS34において、拡張ヘッダ作成部204は、プレシンクトヘッダ171に基づいて、量子化パラメータ情報232、サイズ情報233、フォーマット情報234、およびカラー情報236等の拡張ヘッダを作成する。
ステップS35において、ピクチャ情報作成部205は、ピクチャヘッダ172を取得したか否かを判定する。ピクチャヘッダ172を取得したと判定された場合、処理はステップS36に進む。ステップS36において、ピクチャ情報作成部205は、ピクチャヘッダ172を参照し、wの値が「1」であるか否かを判定し、wの値が「1」であると判定した場合、ステップS37においてウェイティングテーブル(WTm)もパケット化するようにピクチャ情報に含める。ステップS37の処理が終了すると、処理はステップS39に進む。
また、ステップS36において、wの値が「0」であると判定した場合、ピクチャ情報作成部205は、ステップS38において、ウェイティングテーブル(WTm)をピクチャ情報より削除する。ステップS38の処理が終了すると、処理はステップS39に進む。
さらに、ステップS35において、ピクチャヘッダを取得していないと判定された場合、処理は、ステップS39に進む。
ステップS39において、フラグ確認部206は、プレシンクトヘッダ171のIFの値が0であるか否かを判定する。プレシンクトヘッダ171のIFの値が0であると判定された場合、処理はステップS40に進む。
ステップS40において、サイズ確認部207は、プレシンクトのデータサイズがパケットのペイロードの最大サイズ(パケットサイズ)より大きいか否かを判定する。
プレシンクトのサイズがパケットサイズより大きいと判定された場合、処理はステップS41に進む。ステップS41において、フラグメント処理部208は、1プレシンクトの符号化データをパケットサイズ毎に分割し、互いに異なるペイロードとする。ステップS41の処理が終了すると、処理はステップS43に進む。
また、ステップS40において、プレシンクトのデータサイズがパケットサイズより大きくないと判定された場合、フラグメント処理部208は、符号化データの分割を行わない。つまり、この場合、ステップS41の処理は省略され、処理はステップS43に進む。
さらに、ステップS39において、「IF=0」と判定された場合、処理はステップS42に進む。ステップS42において、データ取得部201は、フラグ確認部206に制御されて、供給される符号化データを破棄する。ステップS42の処理が終了すると、処理はステップS43に進む。
パケット化部209は、ステップS43において、各ペイロードやヘッダ情報を用いてRTPパケットを生成し、ステップS44において、各パケットのSFFおよびM等のフラグ情報を設定する。
以上のように各フラグ情報が設定されると、出力部210は、そのRTPパケットを、送信部123に出力する。
ステップS45において、データ取得部201は、全てのプレシンクトを処理したか否かを判定する。未処理のプレシンクトが存在すると判定された場合、処理はステップS31に戻り、それ以降の処理が繰り返される。また、ステップS45において全てのプレシンクトを処理したと判定された場合、パケタイズ処理は終了する。
以上のように、パケタイズ処理部122は、符号化部121より供給されるヘッダ情報に基づいて容易に共通ヘッダや拡張ヘッダを生成することができる。
また、上述したように、ステップS36乃至ステップS38において、ピクチャ情報作成部205は、プレシンクトヘッダ171のwの値に基づいてウェイティングテーブルの付加を容易かつ高速に制御することができる。つまり、ピクチャ情報作成部205は、プレシンクトヘッダ171のwの値を確認するだけで、ウェイティングテーブルを必要なときのみ適切に付加することができる。これにより、送信装置102より受信装置103に転送されるデータ量の不要な増大や、それに伴う各部の不要な負荷の増大を抑制することができる。
さらに、上述したように、ステップS39においてプレシンクトヘッダ171のIFの値が「1」である場合、フラグ確認部206は、ステップS42においてデータ取得部201を制御して、符号化データを取得させないようにし、パケットにペイロードを付加させないようにする。つまり、この場合、パケタイズ処理部122より出力されるRTPパケットにはヘッダ情報のみが含まれ、ペイロードは含まれない。このようにすることにより、パケタイズ処理部122は、符号化部121より供給されるプレシンクトヘッダ171を参照するだけで、容易かつ高速に復号できない不要なデータの送信を低減させることができ、送信部123、回線110、および受信装置103等の不要な負荷の増大を抑制することができる。
また、上述したようにステップS40において、サイズ確認部207は、プレシンクトヘッダ171に基づいてプレシンクトのサイズがパケットサイズより大きいか否かを判定することができるので、パケタイズ処理部122は、1プレシンクトの符号化データを、蓄積することなく、容易かつ高速にフラグメントするか否かを判定することができる。
さらに、パケット化部209は、ステップS44において、プレシンクトの先頭パケットについては、共通ヘッダ231のSFFのフラグを立て、プレシンクトの最終パケットについては、共通ヘッダ231のMのフラグを立てる。このようなフラグを立てることにより、受信装置103のデパケタイズ処理部132は、ヘッダ情報を参照するだけで容易に、プレシンクトの先頭とプレシンクトの終端を識別することができる。これによりデパケタイズ処理部132は、後述するようにデパケタイズ処理を高速かつ容易に行うことができる。
さらに、このとき、共通ヘッダ231のIFのフラグが立てられていることにより、受信装置103のデパケタイズ処理部132は、ヘッダ情報を参照するだけで容易に、パケットにペイロードが含まれていないことを識別することができる。これによりデパケタイズ処理部132は、後述するようにデパケタイズ処理を高速かつ容易に行うことができる。
次に、パケットを受信する受信装置103のデパケタイズ処理部132が実行する処理について説明する。上述したようにデパケタイズ処理部132は、4つの制御モードでデパケタイズ処理を行う。デパケタイズ処理を開始する際、デパケタイズ処理部132は、スタートモード301に設定される。
最初に、そのスタートモード301のデパケタイズ処理部132により実行されるスタートモード処理の流れの例を図27のフローチャートを参照して説明する。
ステップS61において、パケット取得部251は、パケットを取得したか否かを判定し、受信部131を介してパケットを取得したと判定するまで待機する。パケットを取得したと判定された場合、処理はステップS62に進む。ステップS62において、ヘッダ情報解析部252は、パケットのヘッダ情報を取得し、「PID=0」、「CF=4」、かつ「SFF=1」であるか否かを判定する。つまり、ヘッダ情報解析部252は、複数のコンポーネントを1つにまとめた、ピクチャの先頭のプレシンクトの最初のパケットであるか否かを判定する。「PID=0」、「CF=4」、かつ「SFF=1」ではないと判定された場合、処理はステップS61に戻りそれ以降の処理が繰り返される。つまり、「PID=0」、「CF=4」、かつ「SFF=1」であると判定されるまで、ステップS61およびステップS62の処理が繰り返され、「PID=0」、「CF=4」、かつ「SFF=1」であると判定されると、処理はステップS63に進む。
ステップS63において、制御部254は、後述するように各モードで実行される、プレシンクトの先頭のパケットに対するデパケタイズ処理であるモード共通処理を実行する。モード共通処理の詳細については後述する。モード共通処理が終了すると、制御モードは他のモードに遷移するので、スタートモード処理は終了する。
以上のように、スタートモードにおいて、制御部254は、共通ヘッダ231のSFFの値を参照するだけで、ピクチャの先頭のプレシンクトの先頭パケットを容易に検出することができる。また、制御部254は、そのピクチャの先頭のプレシンクトの先頭パケットを検出することにより、その時点でモード共通処理を開始し、そのプレシンクトからペイロードの抽出を開始することができる。つまり、制御部254は、プレシンクトの最終パケットを確認することなく、新規のプレシンクトを把握することができるので、ペイロードの抽出の開始タイミングをより早くすることができ、遅延時間を低減させることができる。
次に、図27のステップS63において実行されるモード共通処理の流れの例を図28のフローチャートを参照して説明する。このモード共通処理は、後述するように、他のモードにおいても実行される処理であり、デパケタイズ処理部132が、1つ前のプレシンクトの最終パケットが確認されていないが、新しいプレシンクトの先頭パケットを確認した場合に、そのプレシンクトに対するデパケタイズ処理を行うものである。
従って、このモード共通処理は、パケット取得部251がパケットを既に取得している状態で開始される。
モード共通処理が開始されると、ステップS82において、ヘッダ情報解析部252は、共通ヘッダ231を参照し、「IF=0」であるか否かを判定する。「IF=1」であると判定された場合、処理はステップS83に進む。
「IF=1」であると判定された場合、制御部254は、ステップS83において、ヘッダ供給部255およびデータ供給部256を制御して、パケットのヘッダ部分のみを復号部133に転送させる。IF=1の場合、基本的にそのパケットにペイロードは含まれていない。仮に含まれているとしても復号不可能であるので、制御部254は、データ供給部256を制御してそのペイロードの転送を禁止する。
ステップS83の処理が終了すると、制御モード遷移部253は、ステップS84において、制御モードを、次のプレシンクトの先頭パケットを待ち受けるスタンバイモードへ遷移する。スタンバイモードの処理については後述する。制御モードが遷移されるとモード共通処理は終了する。
ステップS82において、「IF=0」であると判定された場合、処理は、ステップS85に進む。この場合、ペイロードの符号化データは正常に符号化されたデータである。ステップS85において、ヘッダ供給部255は、制御部254に制御されて、プレシンクトヘッダ4ワード分を、復号部133に転送する。
ステップS86において、ヘッダ情報解析部252は、共通ヘッダ231を参照し、「PID=0」かつ「CF=4」であるか否かを判定する。「PID=0」かつ「CF=4」であると判定された場合、処理は、ステップS87進む。ステップS87において、ヘッダ情報解析部252は、共通ヘッダ231を参照し、「w=1」であるか否かを判定する。「w=1」であると判定された場合、処理はステップS88に進み、ヘッダ供給部255は、制御部254に制御されて、ピクチャヘッダ172を、ウェイティングテーブルも含めるように26ワード分復号部133に転送する。ステップS88の処理が終了すると、処理はステップS90に進む。
また、ステップS87において、「w=1」でないと判定された場合、処理はステップS89に進み、ヘッダ供給部255は、制御部254に制御されて、ピクチャヘッダ172を、ウェイティングテーブルも含めないように6ワード分のみ復号部133に転送する。ステップS89の処理が終了すると、処理はステップS90に進む。
また、ステップS86において、「PID=0」かつ「CF=4」であると判定された場合、ピクチャの先頭のプレシンクトではないので、ヘッダ供給部255は、制御部254に制御されて、ピクチャヘッダ172を復号部133に転送しない。従って、この場合、処理はステップS90に進む。
ステップS90において、データ供給部256は、制御部254に制御されて、パケットの残りのペイロード、つまり符号化データを復号部133に転送する。ステップS91において、ヘッダ情報解析部252は、共通ヘッダ231を参照し、「M=1」であるか否かを判定する。「M=1」であり、処理対象のパケットがプレシンクトの最終パケットであると判定された場合、処理はステップS92に進み、制御部254は、制御モード遷移部253に制御されて、制御モードをスタンバイモードへ遷移する。つまり、今回最終パケットの処理が終了したので、制御モードは、次のプレシンクトの先頭パケットを待ち受けるスタンバイモードへ遷移される。制御モードが遷移されるとモード共通処理は終了する。
また、ステップS91において、「M=1」でなく、処理対象のパケットがプレシンクトの最終パケットでないと判定された場合、処理はステップS93に進み、制御部254は、制御モード遷移部253に制御されて、制御モードをプロセッシングモードへ遷移する。つまり、今回最終パケットでないパケットの転送処理が正常に終了したので、制御モードは、同じプレシンクトの後続のパケットを待ち受けるプロセッシングモードへ遷移される。制御モードが遷移されるとモード共通処理は終了する。このモード共通処理が図27のステップS63において実行されたのであれば、モード共通処理終了により、処理は図27のステップS63に戻り、スタートモード処理が終了される。
以上のように、デパケタイズ処理部132は、SFFやMの値に基づいて、プレシンクトの先頭パケットや最終パケットを容易に識別することができる。また、Mにより最終パケットを識別することができるので、デパケタイズ処理部132は、容易にプレシンクト毎にモードを適宜遷移させることができる。これにより、デパケタイズ処理部132は、各プレシンクトに対して適切にデパケタイズ処理を行うことができる。さらに、SFFにより先頭パケットを識別することができるので、デパケタイズ処理部132は、最終パケットを確認しなくてもプレシンクトの更新を把握することができる。つまり、例えば、パケットロスが発生した場合、つまり、取得したパケットのシーケンス番号が前回取得したパケットのシーケンス番号と連続していない場合であっても、デパケタイズ処理部132は、そのパケットが新たなプレシンクトの先頭パケットであるならば、次のプレシンクトを待たずに、その新たなプレシンクトのパケットからペイロードの抽出を開始することができる。つまり、デパケタイズ処理部132は、不要な待機時間を低減させることができる。もちろん、スタートモードだけでなく、プロセッシングモードやロスモードにおいてモード共通処理を実行する場合も、デパケタイズ処理部132は、待機時間を短縮することができるので、遅延時間の短縮を実現することができる。
また、ステップS83のように、デパケタイズ処理部132は、共通ヘッダ231を参照するだけで、容易に、復号不可能な不要なペイロードを復号部133に供給することを抑制することができる。これにより復号部133の復号処理の負荷を軽減させることができる。なお、ヘッダ情報は、復号処理に利用可能であるので、制御部254は、ヘッダ情報のみを転送させる。
次に、スタンバイモード処理の流れの例を図29のフローチャートを参照して説明する。このスタンバイモード処理は、次のプレシンクトの先頭パケットを待ち受けるモードの処理であり、制御モード遷移部253により制御モードがスタンバイモードに遷移されると、開始される。
スタンバイモード処理が開始されると、パケット取得部251は、ステップS111において、パケットを受信したか否かを判定し、受信したと判定するまで待機する。受信部131よりパケットが供給され、パケットを受信したと判定された場合、処理はステップS112に進む。
ステップS112において、ヘッダ情報解析部252は、RTPヘッダ221を参照し、シーケンス番号が前回受信したパケットと連続するか否かを判定する。シーケンス番号が前回受信したパケットと連続していない場合、パケットの受信に失敗している(パケットロスが発生している)ことを示す。シーケンス番号が前回受信したパケットと連続しており、パケットロスが発生していないと判定された場合、処理はステップS113に進む。
ステップS113乃至ステップS122の各処理は、図28を参照して説明したモード共通処理のステップS82およびステップS83、ステップS85乃至ステップS91、並びに、ステップS93の各処理と同様に実行される。
つまり、ステップS113の処理はステップS82に対応し、ステップS114の処理はステップS83に対応する。ただし、スタンバイモード処理の場合、既にスタンバイモードであるので、図28のステップS84に対応する処理は省略され、ステップS111に処理が進められる(図28においてスタンバイモードに遷移し、スタンバイモード処理が開始されるのと同等である)。
また、ステップS115乃至ステップS121は、それぞれ、図28のステップS85乃至ステップS91に対応する。ただし、スタンバイモード処理の場合、既にスタンバイモードであるので、ステップS121において「M=1」であると判定された場合、図28のステップS92に対応する処理は省略され、ステップS111に処理が進められる(図28においてスタンバイモードに遷移し、スタンバイモード処理が開始されるのと同等である)。
なお、ステップS121において、「M=1」でないと判定された場合、処理はステップS122に進む。このステップS122の処理は、図28のステップS93の処理に対応し、制御モード遷移部253が制御モードをプロセッシングモードに遷移させると、スタンバイモード処理は終了される。
また、ステップS112において、シーケンス番号が前回受信したパケットと連続しておらず、パケットロスが発生したと判定された場合、処理はステップS123に進む。
ステップS123において、ヘッダ情報解析部252は、共通ヘッダ231を参照し、「SFF=1」であるか否かを判定する。「SFF=1」であると判定された場合、処理はステップS113に戻り、それ以降の処理を繰り返す。復号処理はプレシンクト単位で行われるので、プレシンクト内においてパケットロスが発生していなければ、そのプレシンクトは復号可能である。つまり、「SFF=1」である場合、現在処理対象のパケットが属するプレシンクトではなく、過去のプレシンクトにおいてパケットロスが発生したことを示している。その上、スタンバイモードの場合、その過去のプレシンクトの符号化データの、復号部133による蓄積は終了している。従って、パケットロスが発生しても、新たに取得したパケットが新たなプレシンクトの先頭パケットであるならば、そのパケットロスは無視され、処理はステップS113に戻される。
ステップS123において、「SFF=1」でないと判定された場合、処理はステップS124に進む。この場合、パケットロスは、処理対象のパケットと同じプレシンクト内において発生している。従って、そのプレシンクトは復号することができないので、ペイロードの転送は中止される。つまり、ステップS124において、データ供給部256は、制御部254に制御されて、受信したパケットを、復号部133に転送せずに破棄する。
上述したように、スタンバイモードであるので、過去のプレシンクトの符号化データの、復号部133による蓄積は終了しており、新たなプレシンクトの符号化データはまだ蓄積されていない。従って、この場合、復号部133はデータを破棄する必要がないので、デパケタイズ処理部132は、復号部133にエラーを通知する必要は無い。
ステップS125において、制御部254は、制御モード遷移部253に制御されて、制御モードを、エラーが発生したプレシンクトにおいて次のプレシンクトのパケットを取得するまで待機するモードであるロスモードに遷移する。制御モードがロスモードに遷移されると、スタンバイモード処理は終了される。
以上のように、スタンバイモードにおいてデパケタイズ処理部132は、SFFやMの値に基づいて、プレシンクトの先頭パケットや最終パケットを容易に識別することができる。また、Mにより最終パケットを識別することができるので、デパケタイズ処理部132は、容易にプレシンクト毎にモードを適宜遷移させることができる。これにより、デパケタイズ処理部132は、各プレシンクトに対して適切にデパケタイズ処理を行うことができる。さらに、SFFにより先頭パケットを識別することができるので、デパケタイズ処理部132は、最終パケットを確認しなくてもプレシンクトの更新を把握することができる。つまり、例えば、パケットロスが発生した場合、つまり、取得したパケットのシーケンス番号が前回取得したパケットのシーケンス番号と連続していない場合であっても、デパケタイズ処理部132は、そのパケットが新たなプレシンクトの先頭パケットであるならば、次のプレシンクトを待たずに、その新たなプレシンクトのパケットからペイロードの抽出を開始することができる。つまり、デパケタイズ処理部132は、不要な待機時間を低減させることができる。
次に、プロセッシングモード処理の流れの例を図30のフローチャートを参照して説明する。このプロセッシングモード処理は、同じプレシンクトの後続のパケットを待ち受けるモードの処理であり、制御モード遷移部253により制御モードがプロセッシングモードに遷移されると、開始される。
プロセッシングモード処理が開始されると、パケット取得部251は、ステップS141において、パケットを受信したか否かを判定し、受信したと判定するまで待機する。受信部131よりパケットが供給され、パケットを受信したと判定された場合、処理はステップS142に進む。
ステップS142において、ヘッダ情報解析部252は、RTPヘッダ221を参照し、シーケンス番号が前回受信したパケットと連続するか否かを判定する。シーケンス番号が前回受信したパケットと連続しており、パケットロスが発生していないと判定された場合、処理はステップS143に進む。
ステップS143において、ヘッダ供給部255は、制御部254に制御されて、パケットより共通ヘッダ231を削除する。ステップS144において、データ供給部256は、制御部254に制御されて、残りのペイロードデータを復号部133へ転送する。ステップS145において、ヘッダ情報解析部252は、共通ヘッダ231を参照し、「M=1」であるか否かを判定し、「M=1」ではなくプレシンクトの最終パケットでないと判定された場合、同じプレシンクトに後続のパケットが存在するので、処理はステップS141に戻り、それ以降の処理が繰り返される。
つまり、ステップS141乃至ステップS145の処理が繰り返されながら、プレシンクトの各パケットよりペイロードが抽出されて復号部133に転送される。
ステップS145において、「M=1」であり、処理対象のパケットがプレシンクトの最終パケットであると判定された場合、処理はステップS146に進み、制御部254は、制御モード遷移部253に制御されて、制御モードをスタンバイモードに遷移する。制御モードがスタンバイモードに遷移されるとプロセッシングモード処理は終了される。
また、ステップS142において、シーケンス番号が前回受信したパケットと連続しておらず、パケットロスが発生したと判定された場合、処理はステップS147に進む。
この場合、そのプレシンクトのデータを復号部133において蓄積中であるので、ステップS147において、エラー通知部257は、制御部254に制御されて、転送エラーを復号部133に通知する。
エラー通知が終了すると、ヘッダ情報解析部252は、ステップS148において、共通ヘッダ231を参照し、「SFF=1」であるか否かを判定する。「SFF=1」であると判定された場合、処理はステップS149に進む。ステップS149において、制御部254は、図28のフローチャートを参照して説明したモード共通処理を実行する。この場合、モード共通処理が終了すると、処理は図30のステップS149に戻り、プロセッシングモード処理が終了される。
また、ステップS148において、「SFF=1」でないと判定された場合、処理はステップS150に進み、データ供給部256は、制御部254に制御されて受信したパケットを破棄する。ステップS151において、制御部254は、制御モード遷移部253に制御されて、制御モードをロスモードに遷移する。制御モードがロスモードに遷移されるとプロセッシングモード処理は終了される。
以上のように、プロセッシングモードにおいてデパケタイズ処理部132は、SFFやMの値に基づいて、プレシンクトの先頭パケットや最終パケットを容易に識別することができる。また、Mにより最終パケットを識別することができるので、デパケタイズ処理部132は、容易にプレシンクト毎にモードを適宜遷移させることができる。これにより、デパケタイズ処理部132は、各プレシンクトに対して適切にデパケタイズ処理を行うことができる。さらに、SFFにより先頭パケットを識別することができるので、デパケタイズ処理部132は、最終パケットを確認しなくてもプレシンクトの更新を把握することができる。
例えば、パケットロスが発生していない場合、デパケタイズ処理部132は、順次供給される各パケットよりペイロードを抽出し、Mの値に基づいて最終パケットを確認し、そのプレシンクトに対する処理が終了したと判定した場合、スタンバイモードに遷移する。パケットロスが発生した場合、デパケタイズ処理部132は、復号部133にエラーを通知し、先頭パケットで無ければそのパケットを破棄し、次のプレシンクトのパケットを確認するまで待機するようにロスモードに遷移する。ただし、「SFF=1」であるとき、つまり、パケットロスを確認したときに取得したパケットが新たなプレシンクトの先頭パケットであれば、デパケタイズ処理部132は、モード共通処理を実行することにより、スタンバイモードやロスモードに遷移することなく、つまり、新たなプレシンクトのパケットを待たずに、そのプレシンクトからペイロード抽出を開始することができるので、ペイロード抽出の開始タイミングをより早くすることができ、遅延時間を低減させることができる。
次に、図31のフローチャートを参照してロスモード処理の流れの例を説明する。このロスモード処理は、同じプレシンクトにおいてパケットロスが発生したときに次のプレシンクトのパケットを受信するまで待機するモードの処理であり、制御モード遷移部253により制御モードがロスモードに遷移されると、開始される。
ロスモード処理が開始されると、パケット取得部251は、ステップS171において、パケットを受信したか否かを判定し、受信したと判定するまで待機する。受信部131よりパケットが供給され、パケットを受信したと判定された場合、処理はステップS172に進む。
ステップS172において、ヘッダ情報解析部252は、共通ヘッダ231を参照し、「SFF=1」であるか否かを判定する。「SFF=1」でなく、プレシンクトの先頭パケットでないと判定された場合、処理はステップS173に進み、ヘッダ情報解析部252は、今度は、「M=1」であるか否かを判定する。「M=1」でない、つまりプレシンクトの最終パケットで無いと判定された場合、処理は、ステップS171に戻りそれ以降の処理が繰り返される。
ステップS173において、「M=1」であると判定された場合、処理はステップS174に進み、制御部254は、制御モード遷移部253に制御されて制御モードをスタンバイモードに遷移する。制御モードがスタンバイモードに遷移されるとロスモード処理は終了される。
また、ステップS172において、「SFF=1」であると判定された場合、制御部254は、図28のフローチャートを参照して説明したモード共通処理を実行する。この場合、モード共通処理が終了すると、処理は図31のステップS175に戻り、ロスモード処理が終了される。
つまり、ロスモードにおいても、デパケタイズ処理部132は、SFFやMの値に基づいて、プレシンクトの先頭パケットや最終パケットを容易に識別することができる。また、Mにより最終パケットを識別することができるので、デパケタイズ処理部132は、容易にプレシンクト毎にモードを適宜遷移させることができる。これにより、デパケタイズ処理部132は、各プレシンクトに対して適切にデパケタイズ処理を行うことができる。さらに、SFFにより先頭パケットを識別することができるので、デパケタイズ処理部132は、最終パケットを確認しなくてもプレシンクトの更新を把握することができる。
ロスモードの場合、デパケタイズ処理部132は、パケットを取得しながら、基本的に待機し、Mの値に基づいて最終パケットを検出した場合、スタンバイモードに遷移し、次のプレシンクトの先頭パケットの取得に備える。また、SFFの値に基づいて先頭パケットを検出した場合、デパケタイズ処理部132は、モード共通処理を実行することによって、そのプレシンクトからペイロードの抽出を開始する。
このようにすることにより、デパケタイズ処理部132は、ペイロードの抽出の開始タイミングをより早くすることができ、遅延時間を低減させることができる。
以上のように、状況に応じて制御モードを切り替えながらデパケタイズ処理を行うことにより、デパケタイズ処理部132は、デパケタイズ用のバッファを設けて、プレシンクト毎にパケットを蓄積しなくても、供給されるパケットのヘッダ情報に基づいて順次適切に処理を行うことができ、容易かつ高速にデパケタイズ処理を行うことができる。また、パケットロスが発生した場合、デパケタイズ処理部132は、必要に応じてエラー通知を行うので復号部133は、不要な復号処理の実行を抑制し、復号処理の負荷を軽減させることができる。
さらに、IFの値により、デパケタイズ処理部132は、容易に、復号不可能な不要なペイロードを復号部133に供給することを抑制することができる。これにより復号部133の復号処理の負荷を軽減させることができる。
復号部133は、以上のようなデパケタイズ処理部132の処理に対応して、デパケタイズ処理部132より供給される符号化データの復号処理を行う。そのために、復号部133は、復号処理の実行を制御する復号制御処理を実行する。図32のフローチャートを参照して、復号制御処理の流れの例を説明する。この符号化制御処理は、符号化データの供給が開始されてから終了するまでの間実行される。
ステップS191において、データ取得部355は、デパケタイズ処理部132より供給される符号化データを取得する。ステップS192において、バッファ部361は、その符号化データを蓄積する。ステップS193において、制御情報取得部351は、制御情報を取得する。ステップS194において、復号制御部352は、制御情報取得部351が取得した制御情報に基づいて、データ取得部355が取得したデータがプレシンクトの先頭パケットのペイロードであるか否かを判定する。プレシンクトの先頭パケットのペイロードであると判定された場合、処理はステップS195に進む。ステップS195において、復号制御部352は、制御情報取得部351が取得した制御情報に基づいて、データ取得部355に取得されバッファ部361に蓄積されたデータが連続しているか否かを判定する。パケットロスが発生しておらず、データ取得部355に取得されバッファ部361に蓄積されたデータが連続していると判定された場合、処理は、ステップS191に戻り、次の符号化データに対して、ステップS191以降の処理が繰り返される。
また、ステップS195において、パケットロスが発生し、データが連続していないと判定された場合、処理はステップS196に進む。ステップS196において、復号制御部352は、エントロピ復号部362を制御し、補完処理を開始させる。エントロピ復号部362は、プレシンクト単位で復号処理を行うが、プレシンクトのデータが欠落した場合、他のプレシンクトのデータ等を用いて補完処理を行う。
従って、復号制御部352は、前回取得したパケットと連続していない先頭パケットを取得した場合、エントロピ復号部362を制御し、その1つ前のプレシンクトに対して補完処理を実行させる。補完処理が終了すると、処理はステップS197に進む。
ステップS197において、復号制御部352は、復号制御処理を終了するか否かを判定し、終了しないと判定された場合、処理はステップS191に戻り、それ以降の処理が繰り返される。また、ステップS197において、復号制御処理を終了すると判定された場合、復号制御処理が終了される。
また、ステップS194において、データ取得部355が取得したデータがプレシンクトの先頭パケットのペイロードでないと判定された場合、処理はステップS198に進み、復号制御部352は、データ取得部355が取得したデータがプレシンクトの最終パケットのペイロードであるか否かを判定する。プレシンクトの最終パケットのペイロードであると判定された場合、処理はステップS199に進み、復号制御部352は、エントロピ復号部362を制御して、バッファ部361に蓄積されている符号化データに対して、復号処理を開始させる。ステップS199の処理が終了されると、処理はステップS197に戻る。
また、ステップS198において、データ取得部355が取得したデータがプレシンクトの最終パケットのペイロードでないと判定された場合、処理はステップS197に戻る。
次に、図33のステップS199において開始される復号処理の流れの例を図35のフローチャートを参照して説明する。この復号処理は、図34の復号制御処理により制御され、プレシンクト単位で実行される。
復号処理が開始されると、エントロピ復号部362は、ステップS211において、バッファ部361に蓄積されている符号化データを取得し、ステップS212において、ライン毎に符号化データをエントロピ復号する。ステップS213において、バッファ部361は、その復号されて得られた係数データを保持する。ステップS214においてウェーブレット逆変換部363は、バッファ部361に1プレシンクト分の係数データが蓄積されたか否かを判定し、蓄積されていないと判定した場合、処理をステップS211に戻し、それ以降の処理を実行させ、バッファ部361に1プレシンクト分の係数データが蓄積されるまで待機する。
ステップS214においてバッファ部361に1プレシンクト分の係数データが蓄積されたと判定した場合、ウェーブレット逆変換部363は、処理をステップS215に進め、バッファ部361に保持されている係数データを1プレシンクト分読み出す。
そしてその読み出した係数データに対して、ウェーブレット逆変換部363は、ステップS216において、画面垂直方向に並ぶ係数データに対して合成フィルタリング処理を行う垂直合成フィルタリング処理を行い、ステップS217において、画面水平方向に並ぶ係数データに対して合成フィルタリング処理を行う水平合成フィルタリング処理を行い、ステップS218において、合成フィルタリング処理がレベル1(分解レベルの値が「1」のレベル)まで終了したか否か、すなわち、ウェーブレット変換前の状態まで逆変換したか否かを判定し、レベル1まで達していないと判定した場合、処理をステップS216に戻し、ステップS216およびステップS217のフィルタリング処理を繰り返す。
ステップS218において、レベル1まで逆変換処理が終了したと判定した場合、ウェーブレット逆変換部363は、処理をステップS219に進め、逆変換処理により得られた画像データを外部に出力する。
ステップS220において、エントロピ復号部362は、復号処理を終了するか否かを判定し、復号処理を終了しないと判定した場合、処理をステップS211に戻し、それ以降の処理を繰り返す。また、ステップS220において、プレシンクトが終了するなどして復号処理を終了すると判定した場合、エントロピ復号部362は、復号処理を終了する。
従来のウェーブレット逆変換の方法の場合、処理対象の分解レベルの全係数に対して、まず、画面水平方向に水平合成フィルタリング処理を行い、次に画面垂直方向に垂直合成フィルタリング処理を行っていた。つまり、各合成フィルタリング処理の度に、その合成フィルタリング処理の結果をバッファに保持させる必要があるが、その際、バッファは、その時点の分解レベルの合成フィルタリング結果と、次の分解レベルの全係数を保持する必要があり、多大なメモリ容量を必要とすることになる(保持するデータ量が多い)。
また、この場合、ピクチャ(インタレース方式の場合フィールド)内において全てのウェーブレット逆変換が終了するまで画像データ出力が行われないので、入力から出力までの遅延時間が増大する。
これに対して、復号部133のウェーブレット逆変換部363の場合、上述したようにプレシンクト単位で垂直合成フィルタリング処理および水平合成フィルタリング処理をレベル1まで連続して行うので、従来の方法と比較して、一度に(同時期に)バッファリングする必要のあるデータの量が少なく、用意すべきバッファのメモリ量を大幅に低減させることができる。また、レベル1まで合成フィルタリング処理(ウェーブレット逆変換処理)が行われることにより、ピクチャ内の全画像データが得られる前に(プレシンクト単位で)画像データを順次出力させることができ、従来の方法と比較して遅延時間を大幅に低減させることができる。
次に、復号部133において、図32の復号制御処理と並行して行われる、デパケタイズ処理部132からのエラー通知に対する処理であるエラー通知対応処理の流れの例を図34のフローチャートを参照して説明する。
図34において、エラー通知処理が開始されると、エラー通知取得部356は、ステップS241において、デパケタイズ処理部132よりエラー通知を取得したか否かを判定する。エラー通知を取得したと判定されるまで処理は待機する。ステップS241においてエラー通知を取得したと判定された場合、処理はステップS242に進む。ステップS242において、破棄処理部357は、バッファ部361に現在受信途中のプレシンクト(パケットロスが発生した最新のプレシンクトに属する符号化データ)が存在するか否かを判定する。
現在受信途中であるプレシンクトがバッファ部361に存在すると判定された場合、処理は、ステップS243に進む。ステップS243において、破棄処理部357は、バッファ部361に蓄積されている受信中のスライスを破棄する。ステップS243の処理が終了すると、処理は、ステップS244に進む。また、ステップS242において、現在受信途中であるスライスがバッファ部361に存在しないと判定された場合、ステップS243の処理は省略され、処理はステップS244に進む。
ステップS244において、破棄処理部357は、エラー通知対応処理を終了するか否かを判定する。デパケタイズ処理は続いており、エラー通知対応処理も終了しないと判定された場合、処理はステップS241に戻り、それ以降の処理を繰り返す。また、ステップS244において、エラー通知対応処理を終了すると判定された場合、エラー通知対応処理は終了される。
以上のように、復号部133は、デパケタイズ処理部132からのエラー通知に応じて、パケットロスが発生したスライスの符号化データを破棄するので、不要な復号処理を行わないようにすることができる。このように適切な復号処理を行うことができるので、復号部133は、復号処理を容易かつ高速に行うことができ、復号処理の負荷を低減し、回路規模やコストを低減させることができる。
デパケタイズ処理部132により行われるエラー通知の様子の例を図35に示す。
図35において、デパケタイズ処理部132と復号部133は、6本の信号線で接続されているものとする。デパケタイズ処理部132は、受信したパケット1からRTPヘッダなどを削除して抽出した符号化データ(Data1)を復号部133に供給する。このとき、この符号化データ(Data1)が新たなスライスの先頭であった場合、デパケタイズ処理部132の制御信号供給部258は、制御部254に制御されてスタート情報(START)を通知する。
次に届いたパケットがパケット5であった場合、パケットロスがあったと判断される。このとき、復号部133にはプレシンクトの一部であるData1が既に伝送されているため、デパケタイズ処理部132のエラー通知部257は、制御部254に制御されてエラー通知を行う。また、パケット5は「SFF=1」であったため、デパケタイズ処理部132の制御信号供給部258は、制御部254に制御されて、スタート情報(START)を通知する。
なお、以上においては、パケタイズ処理部122は、プレシンクトのデータサイズがパケットサイズより大きい場合、データを分割して複数のパケットを生成し、そうでない場合、1つのパケットを生成するように説明したが、プレシンクトのデータサイズがパケットサイズに比べて小さい場合、複数のプレシンクトのデータを1つのパケットとするようにしてもよい。
その場合、ペイロードヘッダの構成は、例えば、図36に示されるように、ヘッダ情報およびペイロードが順次並べられる。図36の例の場合、1つ目のプレシンクトのデータである共通ヘッダ231乃至ペイロード237の後に、2つ目のプレシンクトのデータであるセグメント情報431、量子化パラメータ情報432、サイズ情報433、フォーマット情報434、ピクチャ情報435、カラー情報436、及びペイロード437が構成され、その後には、3つ目以降のプレシンクトのデータが並ぶ。
セグメント情報431は、2つ目のプレシンクトに対する共通ヘッダであり、図37に示されるように、基本的に共通ヘッダ231と同様の情報が含まれる。つまり、セグメント情報431は、プレシンクトヘッダ171に基づいて作成される。なお、自分自身よりも後に他のプレシンクトのデータが存在する場合、共通ヘッダ231(セグメント情報431も同様)において、NFの値が「1」に設定される。
この場合のパケタイズ処理の流れの例を図38のフローチャートを参照して説明する。
図38に示されるように、この場合のパケタイズ処理も基本的に図26を参照して説明した場合と同様に実行される。ステップS301乃至ステップS312の各処理は、図26のステップS31乃至ステップS42の各処理と同様に実行され、ステップS315乃至ステップS317の各処理は、図26のステップS43乃至ステップS45の各処理と同様に実行される。
ただし、ステップS310において、プレシンクトのサイズがパケットサイズより大きく無いと判定された場合、パケタイズ処理部122のサイズ確認部207は、同じパケットに新たなペイロードを追加可能であるか否かを判定する。パケットサイズに余裕があり、ペイロード追加可能と判定された場合、処理はステップS314に進み、データ取得部201は、プレシンクトヘッダを取得したか否かを判定し、取得したと判定するまで待機する。プレシンクトヘッダを取得したと判定した場合、処理はステップS303に戻り、パケットに追加するプレシンクトに対してそれ以降の処理が繰り返される。つまり、ステップS303乃至ステップS310、並びに、ステップS313およびステップS314のループ処理が繰り返されることにより、符号化データの合計のデータサイズがパケットサイズより大きくなるまで、同じパケットにプレシンクトが順次追加される。
なお、ステップS313において、パケットにペイロード追加不可能であると判定された場合、処理は、ステップS313に戻り、それ以降の処理が実行される。つまりこの場合、1つのプレシンクトの符号化データで1つのパケットが生成される。
以上のようにパケタイズ処理を行うことにより、1つのパケットに複数のプレシンクトのデータを含めることができる。
以上のような図1に示される伝送システム100の各部により実行される各種処理は、例えば、図39に示されるように、適宜、並列的に実行される。
図39は、図1に示される伝送システム100の各部により実行される処理の各要素の並列動作の例を概略的に示す図である。この図39は、上述した図6と対応するものである。画像データの入力In−1(図39A)に対して、ウェーブレット変換部150(図2)で1回目のウェーブレット変換WT−1が施される(図39B)。図5を参照し説明したように、この1回目のウェーブレット変換WT−1は、最初の3ラインが入力された時点で開始され、係数C1が生成される。すなわち、画像データIn−1の入力からウェーブレット変換WT−1が開始されるまで、3ライン分の遅延が生じる。
生成された係数データは、係数並び替え用バッファ部152(図2)に格納される。以降、入力された画像データに対してウェーブレット変換が施され、1回目の処理が終了すると、そのまま2回目のウェーブレット変換WT−2に処理が移行する。
2回目のウェーブレット変換WT−2のための画像データIn−2の入力と、当該2回目のウェーブレット変換WT−2の処理と並列的に、係数並び替え部153(図2)により3個の、係数C1、係数C4、および係数C5の並び替えOrd−1が実行される(図39C)。
なお、ウェーブレット変換WT−1の終了から並び替えOrd−1が開始されるまでの遅延は、例えば、並び替え処理を係数並び替え部153に指示する制御信号の伝達に伴う遅延や、制御信号に対する係数並び替え部153の処理開始に要する遅延、プログラム処理に要する遅延といった、装置やシステム構成に基づく遅延であって、符号化処理における本質的な遅延ではない。
係数データは、並び替えが終了した順に係数並び替え用バッファ部152から読み出され、エントロピ符号化部155(図2)に供給され、エントロピ符号化EC−1が行われる(図39D)。このエントロピ符号化EC−1は、3個の、係数C1、係数C4、および係数C5の、全ての並び替えの終了を待たずに開始することができる。例えば、最初に出力される係数C5による1ラインの並び替えが終了した時点で、当該係数C5に対するエントロピ符号化を開始することができる。この場合、並び替えOrd−1の処理開始からエントロピ符号化EC−1の処理開始までの遅延は、1ライン分となる。
エントロピ符号化部155によるエントロピ符号化EC−1が終了した符号化データは、所定の信号処理が施された後、回線110を介して受信装置103に伝送される(図39E)。このとき、符号化データは、パケット化されて伝送される。
送信装置102の符号化部121に対して、1回目の処理による7ライン分の画像データ入力に続けて、画面上の下端のラインまで画像データが順次、入力される。符号化部121では、画像データの入力In−n(nは2以上)に伴い、上述したようにして、4ライン毎にウェーブレット変換WT−n、並び替えOrd−nおよびエントロピ符号化EC−nを行う。符号化部121における最後の回の処理に対する並び替えOrdおよびエントロピ符号化ECは、6ラインに対して行われる。これらの処理は、符号化部121において、図39A乃至図39Dに例示されるように、並列的に行われる。
符号化部121によるエントロピ符号化EC−1により符号化された符号化データのパケットは、受信装置103に伝送され、デパケタイズ処理等が施された後、復号部133に供給される。復号部133のエントロピ復号部362は、供給された、エントロピ符号化EC−1により符号化された符号化データに対して、順次、エントロピ符号の復号iEC−1を行い、係数データを復元する(図39F)。復元された係数データは、順次、バッファ部361に格納される。ウェーブレット逆変換部363は、バッファ部361にウェーブレット逆変換が行えるだけ係数データが格納されたら、バッファ部361から係数データを読み出して、読み出された係数データを用いてウェーブレット逆変換iWT−1を行う(図39G)。
図5を参照して説明したように、ウェーブレット逆変換部363によるウェーブレット逆変換iWT−1は、係数C4および係数C5がバッファ部361に格納された時点で開始することができる。したがって、エントロピ復号部362による復号iEC−1が開始されてからウェーブレット逆変換部363によるウェーブレット逆変換iWT−1が開始されるまでの遅延は、2ライン分となる。
ウェーブレット逆変換部363において、1回目のウェーブレット変換による3ライン分のウェーブレット逆変換iWT−1が終了すると、ウェーブレット逆変換iWT−1で生成された画像データの出力Out−1が行われる(図39H)。出力Out−1では、図5および図6を用いて説明したように、第1ライン目の画像データが出力される。
復号部133に対して、符号化部121における1回目の処理による3ライン分の符号化された係数データの入力に続けて、エントロピ符号化EC−n(nは2以上)により符号化された係数データが順次、入力される。復号部133では、入力された係数データに対して、上述したようにして、4ライン毎にエントロピ復号iEC−nおよびウェーブレット逆変換iWT−nを行い、ウェーブレット逆変換iWT−nにより復元された画像データの出力Out−nを順次、行う。符号化部121の最後の回に対応するエントロピ復号iECおよびウェーブレット逆変換iWTは、6ラインに対して行われ、出力Outは、8ラインが出力される。これらの処理は、復号部133において、図39F乃至図39Hに例示されるように、並列的に行われる。
上述のようにして、画面上部から下部の方向に順番に、符号化部121および復号部133における各処理を並列的に行うことで、画像圧縮処理および画像復号処理をより低遅延で行うことが可能となる。
図39を参照して、5×3フィルタを用いて分解レベル=2までウェーブレット変換を行った場合の、画像入力から画像出力までの遅延時間を計算してみる。第1ライン目の画像データが符号化部121に入力されてから、この第1ライン目の画像データが復号部133から出力されるまでの遅延時間は、下記の各要素の総和となる。なお、ここでは、伝送路における遅延や、装置各部の実際の処理タイミングに伴う遅延などの、システムの構成により異なる遅延は、除外している。
(1)最初のライン入力から7ライン分のウェーブレット変換WT−1が終了するまでの遅延D_WT
(2)3ライン分の計数並び替えOrd−1に伴う時間D_Ord
(3)3ライン分のエントロピ符号化EC−1に伴う時間D_EC
(4)3ライン分のエントロピ復号iEC−1に伴う時間D_iEC
(5)3ライン分のウェーブレット逆変換iWT−1に伴う時間D_iWT
図39を参照して、上述の各要素による遅延の計算を試みる。(1)の遅延D_WTは、10ライン分の時間である。(2)の時間D_Ord、(3)の時間D_EC、(4)の時間D_iEC、および(5)の時間D_iWTは、それぞれ3ライン分の時間である。また、符号化部121において、並び替えOrd−1が開始されてから1ライン後には、エントロピ符号化EC−1を開始することができる。同様に、復号部133において、エントロピ復号iEC−1が開始されてから2ライン後には、ウェーブレット逆変換iWT−1を開始することができる。また、エントロピ復号iEC−1は、エントロピ符号化EC−1で1ライン分の符号化が終了した時点で処理を開始することができる。
したがって、この図39の例では、符号化部121に第1ライン目の画像データが入力されてから、復号部133から当該第1ライン目の画像データが出力されるまでの遅延時間は、10+1+1+2+3=17ライン分となる。
遅延時間について、より具体的な例を挙げて考察する。入力される画像データがHDTV(High Definition Television)のインタレースビデオ信号の場合、例えば1920画素×1080ラインの解像度で1フレームが構成され、1フィールドは、1920画素×540ラインとなる。したがって、フレーム周波数を30Hzとした場合、1フィールドの540ラインが16.67msec(=1sec/60フィールド)の時間に、符号化部121に入力されることになる。
したがって、7ライン分の画像データの入力に伴う遅延時間は、0.216msec(=16.67msec×7/540ライン)であり、例えば1フィールドの更新時間に対して非常に短い時間となる。また、上述した(1)の遅延D_WT、(2)の時間D_Ord、(3)の時間D_EC、(4)の時間D_iEC、および(5)の時間D_iWTの総和についても、処理対象のライン数が少ないため、遅延時間が非常に短縮される。各処理を行う要素をハードウェア化すれば、処理時間をさらに短縮することも可能である。
ここで、SFFおよびMのフラグ情報について説明する。
上述したように伝送システム100においては、遅延時間の増大に対する許容度が低く、少しでも効率よくデータを伝送し、効率よく必要な処理を行うことが求められる。
従来においても、所定のデータ単位で符号化や復号を行うシステムは存在する。図1の伝送システム100のように、符号化データをパケット化して伝送する場合、そのデータ単位の符号化データを複数に分割してそれぞれをパケット化して伝送するものもある。ただし、従来のシステムの場合、遅延時間に対する許容度は大きいので、デパケタイズ処理では、そのデータ単位分のパケットを蓄積し、データ単位毎にデパケタイズ処理が行われる。このようにすることにより、データ単位分揃った符号化データのみを復号部に供給し復号させることができる。
しかしながら、この方法では、デパケタイズ処理部においても符号化部においてもバッファリングする必要が生じるので、遅延時間の低減が求められる伝送システム100においては望ましくない。
そこで、デパケタイズ処理部132は、上述したように、伝送される符号化データが各部においてその供給順に処理が可能であることを利用して、受信したパケットよりペイロードデータを順次抽出し、蓄積せずに復号部133に供給する。復号部133は、順次供給される符号化データをプレシンクト分蓄積する毎に復号処理を開始する。これにより、符号化データのバッファリングの回数を低減させることができるので、伝送システム100は、遅延時間をより短縮させることができる。
SFFおよびMは、プレシンクトの先頭または終端を示すフラグ情報であり、デパケタイズ処理部132は、このフラグ情報に基づいてプレシンクトの先頭や終端を検出することができ、その旨を復号部133に通知することができる。復号部133は、そのデパケタイズ処理部132からの通知に基づいて、プレシンクトの切れ目を把握し、復号処理をプレシンクト単位で開始することができる。
これだけであればプレシンクトの終端を示すMだけでも十分である。仮に、プレシンクトを複数に分割したパケットと分割していないパケットが混在するのであれば、分割したことを示すフラグ情報があれば、それらのパケットの識別は可能である。
しかしながら、実際には受信部131がパケットの受信に失敗する(ロスする)ことも考えられる。このようにパケットロスが発生した場合、デパケタイズ処理部132は、パケットのバッファリングを行わないため、通常時と処理を変える必要がある。例えば、パケットロスが発生すると、伝送システム100の場合、そのパケットを送信装置102に再送させる時間が確保できないので、そのプレシンクトの符号化データは揃わないことになる。つまり、パケットロスの発生により復号部133は、そのプレシンクトに対する復号処理を実行することができなくなる。
従って、例えばプレシンクトの途中のパケットでロスが発生した場合、復号部133には、そのプレシンクトのそれまでの符号化データが蓄積されていることも考えられる。このような場合、デパケタイズ処理部132は、復号部133にパケットロスの発生を通知し、その蓄積している、ロスされたパケットの符号化データと同じプレシンクトの符号化データを破棄させる。これにより、復号部133は、そのプレシンクトに対して不要な復号処理(失敗する復号処理)の実行を回避することができ、負荷を軽減させることができる。
また、一度パケットロスが発生すると、そのプレシンクトのそれ以降の符号化データは不要になる。従って、デパケタイズ処理部132は、次以降のプレシンクトになるまで、パケットを取得しても、符号化データを復号部133に供給しない。そして新たなプレシンクトのパケットを取得すると、デパケタイズ処理部132は、符号化データの供給を再開する。
このようにデパケタイズ処理部132は、その状況に応じて、制御モードを変更し、適宜適切な処理を行う。そのために、デパケタイズ処理部132は、SFFやMを参照し、プレシンクトの先頭や終端を検出する。このとき、終端を示すMしかないと、プレシンクトの終端を検出するまで、デパケタイズ処理部132は、プレシンクトが変わったと判定することができなくなる。例えば、プレシンクトの最終パケットをロスした場合、デパケタイズ処理部132は、さらに次の新たなプレシンクトを待たなければならなくなり、遅延時間が増大してしまうだけでなく、復号部133において復号処理を行うことができず、復元された画像の画質が劣化する恐れがある。
これに対して、SFFの値を参照し、先頭パケットを検出することにより、デパケタイズ処理部132は、復号部133へのデータを再開させる等、不要な待機時間を低減させるだけでなく、例えば、復号部133に符号化データだけでなくヘッダ情報も供給したり、パケットロスの発生を復号部133に通知するエラー通知を省略したり、パケットロスが発生しても復号部133への符号化データの供給を継続させたりするなど、先頭パケットに対してのみ例外的な処理を行うこともできる。
このようにSFFおよびMのフラグ情報によりデパケタイズ処理部132は適切に処理を行うことができ、遅延時間をより短縮させることができる。
また、デパケタイズ処理部132は、このSFFやMに基づいて、供給する符号化データがプレシンクトの先頭であることや終端であることを復号部133に通知したりする。これにより、復号部133は、プレシンクトの先頭と終端を容易に把握することができるので、例えば、プレシンクトの終端が供給されたのであれば、復号処理を開始することができるし、連続していない新たなプレシンクトの先頭が供給されたのであれば、その前のロスしたプレシンクトに対して補完処理を行うことができる。つまり、復号部133は、デパケタイズ処理部132からの通知に基づいて、このような制御を容易かつ高速に行うことができる。
以上のように、SFFやMは、単にデパケタイズ処理や復号処理の開始タイミングを通知するためのフラグ情報ではなく、デパケタイズ処理部132および復号部133に、符号化データを復号して出力するまでの遅延時間をより短縮させるように、適切なタイミングで適切な処理を選択させ実行させるようにするためのフラグ情報である。
ところで、図2においては、係数の並び替えをウェーブレット変換の直後(エントロピ符号化の前)に行うように説明したが、符号化データが低域から高域の順に復号部133のウェーブレット逆変換部363に供給されればよく(つまり、低域のサブバンドに属する係数データを符号化して得られる符号化データから、高域のサブバンドに属する係数データを符号化して得られる符号化データの順に供給されればよく)、並び替えのタイミングは、ウェーブレット変換の直後以外であってもよい。
例えば、エントロピ符号化によって得られる符号化データの順序を並び替えるようにしてもよい。図40は、その場合の符号化部の構成例を示すブロック図である。
図40の場合、符号化部500は、図2の符号化部121の場合と同様に、ウェーブレット変換部150、途中計算用バッファ部151、エントロピ符号化部155、およびレート制御部154を有するが、図2の係数並び替え用バッファ部152および係数並び替え部153の代わりに、符号並び替え用バッファ部501および符号並び替え部502を有する。
符号並び替え用バッファ部501は、エントロピ符号化部155において符号化された符号化データの出力順を並び替えるためのバッファであり、符号並び替え部502は、その符号並び替え用バッファ部501に蓄積される符号化データを所定の順に読み出すことにより、符号化データの出力順の並び替えを行う。
つまり、図40の場合、ウェーブレット変換部150より出力されるウェーブレット係数は、エントロピ符号化部155に供給されて符号化される。その符号化により得られた各符号化データが、順次、符号並び替え用バッファ部501に供給され、並び替えのために一時的に蓄積される。
符号並び替え部502は、符号並び替え用バッファ部501に書き込まれた符号化データを、所望の順序で読み出し、符号化部500の外部に出力する。
図40の例の場合、エントロピ符号化部155は、ウェーブレット変換部150による出力順に、各係数データの符号化を行い、得られた符号化データを符号並び替え用バッファ部501に書き込む。つまり、符号並び替え用バッファ部501には、符号化データが、ウェーブレット変換部150によるウェーブレット係数の出力順に対応する順序で格納される。通常の場合、1つのプレシンクトに属する係数データ同士を比較すると、ウェーブレット変換部150は、より高域のサブバンドに属する係数データほど先に出力し、より低域のサブバンドに属する係数データほど後に出力する。つまり、符号並び替え用バッファ部501には、各符号化データが、高域のサブバンドに属する係数データをエントロピ符号化して得られた符号化データから、低域のサブバンドに属する係数データをエントロピ符号化して得られた符号化データに向かう順に記憶される。
これに対して、符号並び替え部502は、この順序とは独立して、任意の順序でその符号並び替え用バッファ部501に蓄積された各符号化データを読み出すことにより、符号データの並び替えを行う。
例えば、符号並び替え部502は、低域のサブバンドに属する係数データを符号化して得られた符号化データほど優先的に読み出し、最後に、最も高域のサブバンドに属する係数データを符号化して得られた符号化データを読み出す。このように、符号化データを低域から高域に向かって読み出すことにより、符号並び替え部502は、復号部133が、取得した順で各符号化データを復号することができるようにし、復号部133による復号処理おいて生じる遅延時間を低減させるようにすることができる。
符号並び替え部502は、符号並び替え用バッファ部501に蓄積されている符号化データを読み出し、それを符号化部500の外部に出力する。
なお、図40に示される符号化部500で符号化され出力されたデータは、図24を用いて既に説明した復号部133により、図2の符号化部121より出力される符号化データの場合と同様に復号することができる。
また、並び替えの処理を行うタイミングは、上述した以外であってもよい。例えば、図41において一例が示されるように、符号化部において行うようにしてもよいし、図42において一例が示されるように、復号部において行うようにしてもよい。
ウェーブレット変換で生成された係数データを並び替える処理では、係数並び替え用バッファの記憶容量として比較的大容量が必要となると共に、係数並び替えの処理自体にも、高い処理能力が要求される。この場合でも、符号化装置の処理能力がある程度以上高い場合には何ら問題は生じない。
ここで、携帯電話端末やPDA(Personal Digital Assistant)といった所謂モバイル端末などの、比較的処理能力の低い機器に符号化装置が搭載される場合について考える。例えば、近年では、携帯電話端末に対して撮像機能を付加した製品が広く普及している(カメラ機能付き携帯電話端末と呼ぶ)。このようなカメラ機能付き携帯電話端末で撮像された画像データをウェーブレット変換およびエントロピ符号化により圧縮符号化し、無線あるいは有線通信を介して伝送することが考えられる。
このような例えばモバイル端末は、CPU(Central Processing Unit)の処理能力も限られ、また、メモリ容量にもある程度の上限がある。そのため、上述したような係数並び替えに伴う処理の負荷などは、無視できない問題となる。
そこで、図42に一例が示されるように、並び替え処理を復号部に組み入れることで、符号化部の負荷が軽くなり、符号化部をモバイル端末などの比較的処理能力が低い機器に搭載することが可能となる。
図43は、その場合の符号化部の一例の構成を示すブロック図である。なお、この図43において、上述の図2と共通する部分には同一の符号を付して、詳細な説明を省略する。
この図43に示される符号化部510の構成は、上述の図2で示した符号化部121の構成に対して係数並び替え部153および係数並び替え用バッファ部152を除去した構成となっている。すなわち、符号化部510は、符号化部121と同様の、ウェーブレット変換部150、途中計算用バッファ部151、レート制御部154、およびエントロピ符号化部155を有している。
入力された画像データは、途中計算用バッファ部151に一時的に溜め込まれる。ウェーブレット変換部150は、途中計算用バッファ部151に溜め込まれた画像データに対してウェーブレット変換を施し、生成された係数データを、係数データの生成順に順次、エントロピ符号化部155に供給する。すなわち、エントロピ符号化部155に対して、ウェーブレット変換の順序に従い高域成分から低域成分の順に、生成された係数データが供給される。エントロピ符号化部155は、供給された係数に対して、レート制御部154により出力データのビットレートを制御されながらエントロピ符号化を施す。エントロピ符号化部155から、ウェーブレット変換により生成された係数データがエントロピ符号化された符号化データが出力される。
図44は、この符号化部510に対応する復号装置の一例の構成を示すブロック図である。なお、この図44において、上述の図24と共通する部分には同一の符号を付し、詳細な説明を省略する。
図44に示されるように、この場合の復号部520は、図24の復号部133と同様に、制御情報取得部351、復号制御部352、復号処理実行部353、ヘッダ取得部354、データ取得部355、エラー通知取得部356、および破棄処理部357を有するが、復号処理実行部353は、さらに、係数並び替え用バッファ部521を有する。
図43で説明した符号化部510のエントロピ符号化部155から出力された符号化データは、図44の復号部520においてバッファ部361を介してエントロピ復号部362に供給され、エントロピ符号を復号され係数データとされる。この係数データは、バッファ部361を介して係数並び替え用バッファ部521に格納される。ウェーブレット逆変換部363は、係数並び替え用バッファ部521に係数データの並び替えが可能となるまで係数データが蓄積されると、係数並び替え用バッファ部521に格納された係数データを、低域成分から高域成分の順に並び替えて読み出し、読み出された順に係数データを用いてウェーブレット逆変換処理を行う。5×3フィルタを用いる場合は、上述の図42で示したようになる。
すなわち、ウェーブレット逆変換部363は、例えば1フレームの先頭からの処理であれば、係数並び替え用バッファ部521にエントロピ符号の復号がなされた係数C1、係数C4、および係数C5が格納された時点で、係数並び替え用バッファ部521から係数データを読み出し、ウェーブレット逆変換処理を行う。ウェーブレット逆変換部363でウェーブレット逆変換を施されたデータは、順次、出力画像データとして出力される。
なお、この場合でも、図39を用いて既に説明したように、符号化部510における各要素の処理と、伝送路に対する符号化データの伝送と、復号部520における各要素の処理とが並列的に実行される。
以上のように、本発明は、多様な形態に適用することができ、容易に多様な用途に応用することができる(すなわち汎用性が高い)ことも大きな効果である。
上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータ、または、複数の装置よりなる情報処理システムの情報処理装置などに、プログラム記録媒体からインストールされる。
図45は、上述した一連の処理をプログラムにより実行する情報処理システムの構成の例を示すブロック図である。
図45に示されるように、情報処理システム800は、情報処理装置801、その情報処理装置801とPCIバス802によって接続された、記憶装置803、複数台のビデオテープレコーダ(VTR)であるVTR804-1乃至VTR804-S、ユーザがこれらに対する操作入力を行うためのマウス805、キーボード806、並びに操作コントローラ807により構成されるシステムであり、インストールされたプログラムによって、上述したような画像符号化処理や画像復号処理等を行うシステムである。
例えば情報処理システム800の情報処理装置801は、RAID(Redundant Arrays of Independent Disks)でなる大容量の記憶装置803に記憶されている動画コンテンツを符号化して得られた符号化データを記憶装置803に記憶させたり、記憶装置803に記憶されている符号化データを復号して得られた復号画像データ(動画コンテンツ)を記憶装置803に記憶させたり、符号化データや復号画像データをVTR804-1乃至VTR804-Sを介してビデオテープに記録したりすることができる。また、情報処理装置801は、VTR804-1乃至VTR804-Sに装着されたビデオテープに記録された動画コンテンツを記憶装置803に取り込み得るようにもなされている。その際、情報処理装置801が、動画コンテンツを符号化するようにしてもよい。
情報処理装置801は、マイクロプロセッサ901、GPU(Graphics Processing Unit)902、XDR(Extreme Data Rate)-RAM903、サウスブリッジ904、HDD(Hard Disk Drive)905、USBインタフェース(USB I/F)906、およびサウンド入出力コーデック907を有している。
GPU902は専用のバス911を介してマイクロプロセッサ901に接続される。XDR-RAM903は専用のバス912を介してマイクロプロセッサ901に接続される。サウスブリッジ904は、専用のバスを介してマイクロプロセッサ901のI/Oコントローラ944に接続される。このサウスブリッジ904には、HDD905、USBインタフェース906、および、サウンド入出力コーデック907も接続されている。このサウンド入出力コーデック907にはスピーカ921が接続されている。また、GPU902にはディスプレイ922が接続されている。
またサウスブリッジ904には、さらに、PCIバス802を介して、マウス805、キーボード806、VTR804-1乃至VTR804-S、記憶装置803、並びに、操作コントローラ807が接続されている。
マウス805およびキーボード806は、ユーザの操作入力を受け、PCIバス802およびサウスブリッジ904を介して、ユーザの操作入力の内容を示す信号を、マイクロプロセッサ901に供給する。記憶装置803およびVTR804-1乃至VTR804-Sは、所定のデータを記録または再生できるようになされている。
PCIバス802にはさらに、必要に応じてドライブ808が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア811が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じてHDD905にインストールされる。
マイクロプロセッサ901は、OS(Operating System)等の基本プログラムを実行する汎用のメインCPUコア941と、メインCPUコア941に内部バス945を介して接続された複数(この場合8個)のRISC(Reduced Instruction Set Computer)タイプの信号処理プロセッサである、サブCPUコア942-1乃至サブCPUコア942-8と、例えば256[MByte]の容量を持つXDR-RAM903に対するメモリコントロールを行うメモリコントローラ943と、サウスブリッジ904との間でデータの入出力を管理するI/O(In/Out)コントローラ944とが1チップに集積されたマルチコア構成でなり、例えば動作周波数4[GHz]を実現している。
このマイクロプロセッサ901は、起動時、HDD905に格納された制御プログラムに基づき、HDD905に格納されている必要なアプリケーションプログラムを読み出してXDR-RAM903に展開し、この後このアプリケーションプログラム及びオペレータ操作に基づいて必要な制御処理を実行する。
また、マイクロプロセッサ901は、ソフトウェアを実行することにより、例えば、上述した符号化処理や復号処理を実現し、エンコードの結果得られた符号化ストリームを、サウスブリッジ904を介して、HDD905に供給して記憶させたり、デコードした結果得られる動画像コンテンツの再生映像を、GPU902へデータ転送して、ディスプレイ922に表示させたりすることができる。
マイクロプロセッサ901内の各CPUコアの使用方法は任意であるが、例えば、メインCPUコア941が、画像符号化処理や画像復号処理の制御に関する処理を行い、8個のサブCPUコア942-1乃至サブCPUコア942-8に、ウェーブレット変換、係数並び替え、エントロピ符号化、エントロピ復号、ウェーブレット逆変換、量子化、および逆量子化等の各処理を、例えば図39を参照して説明したように同時並列的に実行させるようにしてもよい。その際、メインCPUコア941が、8個のサブCPUコア942-1乃至サブCPUコア942-8のそれぞれに対してプレシンクト単位で処理を割り振るようにすれば、符号化処理や復号処理が、図39を参照して説明した場合と同様にプレシンクト単位で同時並列的に実行される。つまり、符号化処理や復号処理の効率を向上させ、処理全体の遅延時間を短縮させ、さらに、負荷、処理時間、および、処理に必要なメモリ容量を低減させることができる。もちろん、これ以外の方法で各処理を行うようにしてもよい。
例えば、マイクロプロセッサ901の8個のサブCPUコア942-1乃至サブCPUコア942-8のうちの一部がエンコード処理を、他の部分がデコード処理を、同時並列的に実行するようにすることも可能である。
また、例えば、PCIバス802に、独立したエンコーダまたはデコーダ、もしくは、コーデック処理装置が接続されている場合、マイクロプロセッサ901の8個のサブCPUコア942-1乃至サブCPUコア942-8が、サウスブリッジ904およびPCIバス802を介して、これらの装置が実行する処理を制御するようにしてもよい。さらに、これらの装置が複数接続されている場合、または、これらの装置が複数のデコーダまたはエンコーダを含んでいる場合、マイクロプロセッサ901の8個のサブCPUコア942-1乃至サブCPUコア942-8は、複数のデコーダまたはエンコーダが実行する処理を、分担して制御するようにしてもよい。
このときメインCPUコア941は、8個のサブCPUコア942-1乃至サブCPUコア942-8の動作を管理し、各サブCPUコアに対して処理を割り当てたり、処理結果を引き取ったりする。さらに、メインCPUコア941は、これらのサブCPUコアが行う以外の処理も行う。例えば、メインCPUコア941は、サウスブリッジ904を介してマウス805、キーボード806、または、操作コントローラ807から供給された命令を受け付け、命令に応じた種々の処理を実行する。
GPU902は、ディスプレイ922に表示する動画コンテンツの再生映像を動かすときのテクスチャの張り込みなどに関する最終的なレンダリング処理に加えて、動画コンテンツの再生映像及び静止画コンテンツの静止画像をディスプレイ922に一度に複数表示するときの座標変換計算処理や、動画コンテンツの再生映像及び静止画コンテンツの静止画像に対する拡大・縮小処理等を行う機能を司り、マイクロプロセッサ901の処理負担を軽減させるようになされている。
GPU902は、マイクロプロセッサ901の制御のもとに、供給された動画コンテンツの映像データや静止画コンテンツの画像データに対して所定の信号処理を施し、その結果得られた映像データや画像データをディスプレイ922へ送出して、画像信号をディスプレイ922へ表示させる。
ところで、マイクロプロセッサ901における8個のサブCPUコア942-1乃至サブCPUコア942-8で同時並列的にデコードされた複数の動画コンテンツにおける再生映像は、バス911を介してGPU902へデータ転送されるが、このときの転送速度は、例えば、最大30[Gbyte/sec]であり、特殊効果の施された複雑な再生映像であっても高速かつ滑らかに表示し得るようになされている。
また、マイクロプロセッサ901は、動画コンテンツの映像データ及び音声データのうち音声データに対して音声ミキシング処理を施し、その結果得られた編集音声データを、サウスブリッジ904およびサウンド入出力コーデック907を介して、スピーカ921へ送出することにより、音声信号に基づく音声をスピーカ921から出力させることもできる。
上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、ネットワークや記録媒体からインストールされる。
この記録媒体は、例えば、図45に示されるように、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク(フレキシブルディスクを含む)、光ディスク(CD-ROM,DVDを含む)、光磁気ディスク(MDを含む)、もしくは半導体メモリなどよりなるリムーバブルメディア811により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているHDD905や記憶装置803等で構成される。もちろん、記録媒体は、ROMやフラッシュメモリ等の半導体メモリであってもよい。
以上においては、マイクロプロセッサ901内に8個のサブCPUコアが構成されるように説明したが、これに限らず、サブCPUコアの数は任意である。また、マイクロプロセッサ901が、メインCPUコアとサブCPUコアのような複数のコアにより構成されていなくてもよく、シングルコア(1つのコア)により構成されるCPUを用いるようにしてもよい。また、マイクロプロセッサ901の代わりに複数のCPUを用いるようにしてもよいし、複数の情報処理装置を用いる(すなわち、本発明の処理を実行するプログラムを、互いに連携して動作する複数の装置において実行する)ようにしてもよい。
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
また、本明細書において、システムとは、複数のデバイス(装置)により構成される装置全体を表すものである。
なお、以上において、1つの装置として説明した構成を分割し、複数の装置として構成するようにしてもよい。逆に、以上において複数の装置として説明した構成をまとめて1つの装置として構成されるようにしてもよい。また、各装置の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置の構成の一部を他の装置の構成に含めるようにしてもよい。
以上説明したこの発明は、パケタイズ処理およびデパケタイズ処理を容易かつ高速に行うものであり、画像を圧縮符号化して伝送し、伝送先で圧縮符号を復号して出力するような装置またはシステムであれば、様々なものに適用することができる。この発明は、特に、画像の圧縮符号化から復号および出力までの遅延が短いことが要求されるような装置またはシステムに用いて好適である。
例えば、この発明は、ビデオカメラで撮影された映像を見ながらマジックハンドを操作して治療行為を行うような、医用遠隔医療診断の用途に用いて好適である。また、この発明は、放送局内などにおける、画像を符号化して伝送し、復号して表示または記録するようなシステムに用いて好適である。
さらに、実況中継される映像の配信を行うシステム、教育現場において生徒と教師との間でインタラクティブな通信を可能としたシステムなどに、この発明を適用することができる。
さらにまた、カメラ機能付き携帯電話端末といった、撮像機能を有するモバイル端末で撮影された画像データの送信や、テレビジョン会議システム、監視カメラおよび監視カメラで撮影された映像を記録するレコーダによるシステムなどに、この発明を適用することができる。
本発明を適用した伝送システムの構成例を示すブロック図である。 図1の符号化部の構成例を示すブロック図である。 ウェーブレット変換について概略的に説明するための略線図である。 ウェーブレット変換について概略的に説明するための略線図である。 5×3フィルタのリフティングによるフィルタリングを分解レベル=2まで実行した例を示す略線図である。 この発明によるウェーブレット変換およびウェーブレット逆変換の流れを概略的に示す略線図である。 プレシンクトヘッダの構成例を示す図である。 ピクチャヘッダの構成例を示す図である。 符号化部とパケタイズ処理部との間で授受される情報の例を示す図である。 図1のパケタイズ処理部の詳細な構成例を示すブロック図である。 プレシンクトの例を説明するための模式図である。 パケットの作成例を説明するための模式図である。 RTPヘッダの構成例を説明するための模式図である。 RTPペイロードヘッダの構成例を説明するための模式図である。 共通ヘッダの構成例を示す図である。 量子化パラメータ情報の構成例を示す図である。 サイズ情報の構成例を示す図である。 フォーマット情報の構成例を示す図である。 ピクチャ情報の構成例を示す図である。 カラー情報の構成例を示す図である。 図1のデパケタイズ処理部の詳細な構成例を示すブロック図である。 制御モードの遷移の様子の例を示す図である。 デパケタイズ処理部と復号部との間で授受される情報の例を示す図である。 図1の復号部の詳細な構成例を示すブロック図である。 符号化処理の流れの例を説明するためのフローチャートである。 パケタイズ処理の流れの例を説明するためのフローチャートである。 スタートモード処理の流れの例を説明するためのフローチャートである。 モード共通処理の流れの例を説明するためのフローチャートである。 スタンバイモード処理の流れの例を説明するためのフローチャートである。 プロセッシングモード処理の流れの例を説明するためのフローチャートである。 ロスモード処理の流れの例を説明するためのフローチャートである。 復号制御処理の流れの例を説明するためのフローチャートである。 復号処理の流れの例を説明するためのフローチャートである。 エラー通知対応処理の流れの例を説明するためのフローチャートである。 エラー通知対応の様子の例を説明する模式図である。 RTPペイロードヘッダの他の構成例を示す図である。 セグメント情報の構成例を示す図である。 パケタイズ処理の流れの、他の例を説明するためのフローチャートである。 送信装置および受信装置の各要素が行う並列動作の様子の例を概略的に示す略線図である。 図1の符号化部の他の構成例を示すブロック図である。 ウェーブレット係数の並び替え処理を符号化部側で行う場合の処理の流れを説明するための略線図である。 ウェーブレット係数の並び替え処理を復号部側で行う場合の処理の流れを説明するための略線図である。 図1の符号化部の、さらに他の構成例を示すブロック図である。 図43の符号化部に対応する復号部の構成例を示すブロック図である。 本発明を適用した情報処理システムの構成例を示す図である。
符号の説明
100 伝送システム, 102 送信装置, 103 受信装置, 110 回線, 132 デパケタイズ処理部, 133 復号部, 202 RTPヘッダ作成部, 203 共通ヘッダ作成部, 204 拡張ヘッダ作成部, 205 ピクチャ情報作成部, 206 フラグ確認部, 207 サイズ確認部, 208 フラグメント処理部, 209 パケット化部, 252 ヘッダ情報解析部, 253 制御モード遷移部, 254 制御部, 255 ヘッダ供給部, 256 データ供給部, 257 エラー通知部, 258 制御信号供給部, 351 制御情報取得部, 352 復号制御部, 353 復号処理実行部, 354 ヘッダ取得部, 355 データ取得部, 356 エラー通知取得部, 357 破棄処理部

Claims (7)

  1. 画像データの符号化データであって、前記画像データを符号化する際に行われる前記画像データのウェーブレット変換において、最低域成分の1ライン分を生成するために必要な、他のサブバンドも含めたラインの集まりであるプレシンクトの符号化データを、複数の部分データに分割する分割部と、
    前記分割部により得られた各部分データを、それぞれパケット化するパケット化部と、
    前記パケット化部により生成された各パケットの内、前記プレシンクトの符号化データの先頭の部分データをペイロードとする先頭パケットに対して、先頭パケットであることを示し、デパケタイズの際に、パケットロス発生に対するデータ破棄の制御を前記プレシンクトの符号化データ毎に行うために、前記プレシンクトの符号化データの先頭であることを確認するために参照される先頭フラグを設定する先頭フラグ設定部と、
    前記パケット化部により生成された各パケットの内、前記プレシンクトの符号化データの終端の部分データをペイロードとする最終パケットに対して、最終パケットであることを示し、デパケタイズの際に、パケットロス発生に対するデータ破棄の制御を前記プレシンクトの符号化データ毎に行うために、前記プレシンクトの符号化データの終端であることを確認するために参照される最終フラグを設定する最終フラグ設定部と
    を備える情報処理装置。
  2. 前記パケット化部は、前記プレシンクトの符号化データについて、符号化が失敗している場合、前記分割部により得られた各部分データを破棄し、ヘッダ情報のみでパケット化する
    請求項1に記載の情報処理装置。
  3. 前記パケット化部は、前記部分データをペイロードとし、前記プレシンクトの符号化データのヘッダ情報と、少なくとも一部が共通のヘッダ情報を付加することにより、前記部分データをパケット化する
    請求項1に記載の情報処理装置。
  4. 前記パケット化部は、前記プレシンクトの符号化データの符号化が失敗しているか否かを示すフラグを、前記ヘッダ情報に含めて前記部分データに付加する
    請求項3に記載の情報処理装置。
  5. 前記画像データを、前記プレシンクト毎に符号化する符号化部をさらに備え、
    前記分割部は、前記符号化部により得られた前記プレシンクトの符号化データを分割する
    請求項1に記載の情報処理装置。
  6. 情報処理装置の情報処理方法であって、
    前記情報処理装置が、
    画像データの符号化データであって、前記画像データを符号化する際に行われる前記画像データのウェーブレット変換において、最低域成分の1ライン分を生成するために必要な、他のサブバンドも含めたラインの集まりであるプレシンクトの符号化データを、複数の部分データに分割し、
    得られた各部分データを、それぞれパケット化し、
    生成された各パケットの内、前記プレシンクトの符号化データの先頭の部分データをペイロードとする先頭パケットに対して、先頭パケットであることを示し、デパケタイズの際に、パケットロス発生に対するデータ破棄の制御を前記プレシンクトの符号化データ毎に行うために、前記プレシンクトの符号化データの先頭であることを確認するために参照される先頭フラグを設定し、
    生成された各パケットの内、前記プレシンクトの符号化データの終端の部分データをペイロードとする最終パケットに対して、最終パケットであることを示し、デパケタイズの際に、パケットロス発生に対するデータ破棄の制御を前記プレシンクトの符号化データ毎に行うために、前記プレシンクトの符号化データの終端であることを確認するために参照される最終フラグを設定する
    情報処理方法。
  7. コンピュータを、
    画像データの符号化データであって、前記画像データを符号化する際に行われる前記画像データのウェーブレット変換において、最低域成分の1ライン分を生成するために必要な、他のサブバンドも含めたラインの集まりであるプレシンクトの符号化データを、複数の部分データに分割する分割部と、
    前記分割部により得られた各部分データを、それぞれパケット化するパケット化部と、
    前記パケット化部により生成された各パケットの内、前記プレシンクトの符号化データの先頭の部分データをペイロードとする先頭パケットに対して、先頭パケットであることを示し、デパケタイズの際に、パケットロス発生に対するデータ破棄の制御を前記プレシンクトの符号化データ毎に行うために、前記プレシンクトの符号化データの先頭であることを確認するために参照される先頭フラグを設定する先頭フラグ設定部と、
    前記パケット化部により生成された各パケットの内、前記プレシンクトの符号化データの終端の部分データをペイロードとする最終パケットに対して、最終パケットであることを示し、デパケタイズの際に、パケットロス発生に対するデータ破棄の制御を前記プレシンクトの符号化データ毎に行うために、前記プレシンクトの符号化データの終端であることを確認するために参照される最終フラグを設定する最終フラグ設定部と
    して機能させるためのプログラム。
JP2007094015A 2007-03-30 2007-03-30 情報処理装置および方法、並びにプログラム Expired - Fee Related JP5162939B2 (ja)

Priority Applications (8)

Application Number Priority Date Filing Date Title
JP2007094015A JP5162939B2 (ja) 2007-03-30 2007-03-30 情報処理装置および方法、並びにプログラム
TW97111513A TWI414183B (zh) 2007-03-30 2008-03-28 Information processing apparatus and method and non-temporary computer-readable recording medium
CN2008800002777A CN101543071B (zh) 2007-03-30 2008-03-31 信息处理设备和信息处理方法
PCT/JP2008/056325 WO2008120777A1 (ja) 2007-03-30 2008-03-31 情報処理装置および方法、並びにプログラム
US12/301,682 US8184636B2 (en) 2007-03-30 2008-03-31 Information processing device and method, and computer readable medium for packetizing and depacketizing data
EP08739439.1A EP2134092B1 (en) 2007-03-30 2008-03-31 Information processing apparatus and method, and program
KR1020087029188A KR101426097B1 (ko) 2007-03-30 2008-03-31 정보 처리 장치 및 방법과, 프로그램
BRPI0803098-7A BRPI0803098B1 (pt) 2007-03-30 2008-03-31 Dispositivos e métodos de processamento de informação, e, mídias de armazenamento legível por computador

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007094015A JP5162939B2 (ja) 2007-03-30 2007-03-30 情報処理装置および方法、並びにプログラム

Publications (2)

Publication Number Publication Date
JP2008252739A JP2008252739A (ja) 2008-10-16
JP5162939B2 true JP5162939B2 (ja) 2013-03-13

Family

ID=39808357

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007094015A Expired - Fee Related JP5162939B2 (ja) 2007-03-30 2007-03-30 情報処理装置および方法、並びにプログラム

Country Status (8)

Country Link
US (1) US8184636B2 (ja)
EP (1) EP2134092B1 (ja)
JP (1) JP5162939B2 (ja)
KR (1) KR101426097B1 (ja)
CN (1) CN101543071B (ja)
BR (1) BRPI0803098B1 (ja)
TW (1) TWI414183B (ja)
WO (1) WO2008120777A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10075566B2 (en) 2014-08-06 2018-09-11 Samsung Electronics Co., Ltd. Packet transmitter, interface device and computing system including the same

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI384882B (zh) * 2009-07-28 2013-02-01 Mstar Semiconductor Inc 封包順序回復控制器及其方法
US9411810B2 (en) * 2009-08-27 2016-08-09 International Business Machines Corporation Method and apparatus for identifying data inconsistency in a dispersed storage network
JP5263621B2 (ja) * 2009-09-24 2013-08-14 ソニー株式会社 画像処理装置および方法
KR101079697B1 (ko) 2009-10-05 2011-11-03 주식회사 글로벌미디어테크 범용 그래픽 처리장치의 병렬 프로세서를 이용한 고속 영상 처리 방법
JP2011147050A (ja) * 2010-01-18 2011-07-28 Sony Corp 画像処理装置および方法
JP5515758B2 (ja) * 2010-01-18 2014-06-11 ソニー株式会社 画像処理装置および方法
JP5123340B2 (ja) * 2010-02-23 2013-01-23 日本電信電話株式会社 映像データ送信装置,映像データ送信方法および映像データ送信プログラム
US8970750B2 (en) 2010-11-12 2015-03-03 Sony Corporation Image outputting apparatus, image outputting method, image processing apparatus, image processing method, program, data structure and imaging apparatus
JP2012138851A (ja) * 2010-12-27 2012-07-19 Toshiba Corp 画像送信装置および方法、画像受信装置および方法
FR2972588A1 (fr) 2011-03-07 2012-09-14 France Telecom Procede de codage et decodage d'images, dispositif de codage et decodage et programmes d'ordinateur correspondants
FR2977111A1 (fr) * 2011-06-24 2012-12-28 France Telecom Procede de codage et decodage d'images, dispositif de codage et decodage et programmes d'ordinateur correspondants
JP2013051607A (ja) * 2011-08-31 2013-03-14 Canon Inc データ処理装置、方法および制御プログラム
JP5994367B2 (ja) * 2012-04-27 2016-09-21 富士通株式会社 動画像符号化装置、動画像符号化方法
JP2014070993A (ja) * 2012-09-28 2014-04-21 Japan Radio Co Ltd 衛星測位受信装置
JP6098114B2 (ja) 2012-10-26 2017-03-22 アイコム株式会社 中継装置および通信システム
KR102053689B1 (ko) * 2013-01-14 2019-12-09 삼성전자 주식회사 카메라의 영상 데이터 압축 방법 및 이를 지원하는 단말기
CN104486633B (zh) * 2014-11-11 2019-01-18 三星电子(中国)研发中心 视频错误掩藏方法及装置
CA2977201C (en) 2015-03-04 2024-02-20 Sony Corporation Transmission device, transmission method, reception device, and reception method
US10187640B2 (en) * 2015-09-01 2019-01-22 Mediatek Inc. Method of hard-limited packet size for video encoding
WO2019159268A1 (ja) * 2018-02-15 2019-08-22 三菱電機株式会社 情報分析装置、情報分析方法、及び情報分析プログラム
JP2020022087A (ja) * 2018-08-01 2020-02-06 日本放送協会 映像/パケット変換装置、パケット/映像変換装置、及びプログラム
KR101967260B1 (ko) * 2018-11-05 2019-04-09 (주)이엠텍아이엔씨 컴퓨터의 상태에 따라 모니터의 절전을 행하는 방법 및 이를 활용한 에너지 절감형 모니터를 갖는 컴퓨터 시스템
KR101967259B1 (ko) * 2018-11-05 2019-04-09 (주)이엠텍아이엔씨 컴퓨터의 상태에 따라 모니터의 밝기를 제어하는 방법 및 이를 활용한 에너지 절감형 컴퓨터 시스템
MX2022008445A (es) * 2020-01-13 2022-10-18 Lg Electronics Inc Metodo y aparato de inter prediccion en sistema de codificacion de imagenes/video.

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05153550A (ja) 1991-12-02 1993-06-18 Matsushita Electric Ind Co Ltd 映像信号の記録装置および再生装置
JPH06292179A (ja) 1993-04-01 1994-10-18 Matsushita Electric Ind Co Ltd 直交変換符号化装置および直交変換復号化装置
JPH0818979A (ja) * 1994-06-27 1996-01-19 Canon Inc 画像処理装置
GB2295936B (en) 1994-12-05 1997-02-05 Microsoft Corp Progressive image transmission using discrete wavelet transforms
JP3213222B2 (ja) 1995-11-02 2001-10-02 株式会社リコー 符号化方法
JP3213582B2 (ja) 1997-05-29 2001-10-02 シャープ株式会社 画像符号化装置及び画像復号装置
US6707948B1 (en) 1997-11-17 2004-03-16 The Regents Of The University Of California Image compression for memory-constrained decoders
JP2000059781A (ja) 1998-08-07 2000-02-25 Ricoh Co Ltd ウェーブレット変換装置
US6970604B1 (en) * 1998-10-05 2005-11-29 Media Tek Inc. Apparatus and method for forming a coding unit
US6339658B1 (en) * 1999-03-09 2002-01-15 Rockwell Science Center, Llc Error resilient still image packetization method and packet structure
JP2000333163A (ja) * 1999-05-24 2000-11-30 Sony Corp 復号装置及び方法、符号化装置及び方法、画像処理システム、画像処理方法
JP4097108B2 (ja) 1999-07-06 2008-06-11 株式会社リコー ウェーブレット変換装置及び符号化復号化装置
JP3609389B2 (ja) * 1999-09-30 2005-01-12 富士通株式会社 プロトコル変換装置、通信装置、通信プログラム記憶媒体、および通信システム
EP1189447A3 (en) 2000-09-19 2004-11-17 Matsushita Electric Industrial Co., Ltd. Image signal transmitter
JP2002359853A (ja) 2001-03-26 2002-12-13 Sony Corp 画像処理装置、画像処理方法、画像処理プログラムおよび記録媒体
US7136485B2 (en) * 2001-05-04 2006-11-14 Hewlett-Packard Development Company, L.P. Packetizing devices for scalable data streaming
US6865374B2 (en) * 2001-09-18 2005-03-08 Koninklijke Philips Electronics N.V. Video recovery system and method
JP4549610B2 (ja) 2001-11-08 2010-09-22 ソニー株式会社 通信システム、通信方法、送信装置および方法、受信装置および方法、並びにプログラム
JP3931642B2 (ja) * 2001-11-27 2007-06-20 日本電気株式会社 ストリーム配信システム、ストリーム送信装置、及び、中継装置
US7557929B2 (en) * 2001-12-18 2009-07-07 Massachusetts Institute Of Technology Systems and methods for phase measurements
US7194630B2 (en) * 2002-02-27 2007-03-20 Canon Kabushiki Kaisha Information processing apparatus, information processing system, information processing method, storage medium and program
JP2003283839A (ja) * 2002-03-19 2003-10-03 Sanyo Electric Co Ltd 画像変換方法および装置
JP3743384B2 (ja) * 2002-04-19 2006-02-08 ソニー株式会社 画像符号化装置及び方法、並びに画像復号装置及び方法
US7483575B2 (en) 2002-10-25 2009-01-27 Sony Corporation Picture encoding apparatus and method, program and recording medium
JP4449400B2 (ja) 2002-10-25 2010-04-14 ソニー株式会社 画像符号化装置及び方法、並びにプログラム及び記録媒体
AU2003290807A1 (en) * 2002-11-15 2004-06-15 The Arizona Board Of Regents On Behalf Of The University Of Arizona Methods for decoding corrupt jpeg2000 codestreams
SG111978A1 (en) * 2002-11-20 2005-06-29 Victor Company Of Japan An mpeg-4 live unicast video streaming system in wireless network with end-to-end bitrate-based congestion control
JP3880050B2 (ja) 2002-12-16 2007-02-14 梶原工業株式会社 調理装置
JP3701956B2 (ja) 2003-05-29 2005-10-05 日本電信電話株式会社 パケット中継装置及びその方法と、パケット受信装置及びその方法と、パケット中継プログラム及びそのプログラムを記録した記録媒体と、パケット受信プログラム及びそのプログラムを記録した記録媒体
EP1494456A1 (en) * 2003-07-01 2005-01-05 Deutsche Thomson-Brandt GmbH Method for run-length encoding of a bitmap data stream
US7715480B2 (en) * 2003-10-17 2010-05-11 Mitsubishi Electric Research Laboratories, Inc. Video encoding with motion-selective wavelet transform
JP2005167515A (ja) 2003-12-01 2005-06-23 Matsushita Electric Ind Co Ltd ストリーミングデータ通信システム、ストリーミングデータ通信装置及びストリーミングデータ配信方法
JP4716949B2 (ja) * 2005-09-02 2011-07-06 株式会社リコー 画像処理装置および画像処理方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10075566B2 (en) 2014-08-06 2018-09-11 Samsung Electronics Co., Ltd. Packet transmitter, interface device and computing system including the same

Also Published As

Publication number Publication date
KR20090126176A (ko) 2009-12-08
BRPI0803098B1 (pt) 2020-03-24
CN101543071B (zh) 2013-05-08
CN101543071A (zh) 2009-09-23
TWI414183B (zh) 2013-11-01
BRPI0803098A2 (pt) 2011-08-30
EP2134092B1 (en) 2019-10-23
EP2134092A1 (en) 2009-12-16
US20090201949A1 (en) 2009-08-13
KR101426097B1 (ko) 2014-08-01
TW200906195A (en) 2009-02-01
WO2008120777A1 (ja) 2008-10-09
EP2134092A4 (en) 2011-08-31
JP2008252739A (ja) 2008-10-16
US8184636B2 (en) 2012-05-22

Similar Documents

Publication Publication Date Title
JP5162939B2 (ja) 情報処理装置および方法、並びにプログラム
JP5527588B2 (ja) 情報処理装置および方法
KR101377021B1 (ko) 부호화 장치 및 방법, 복호 장치 및 방법, 및 전송 시스템
JP4488027B2 (ja) 情報処理装置および方法、並びに、情報処理システム
US20080063078A1 (en) Apparatus and Method of Information Processing, Program, and Recording Medium
JPWO2008093698A1 (ja) 情報処理装置および方法
CN1717935A (zh) 根据请求进行ⅰ图像插入
JP5515758B2 (ja) 画像処理装置および方法
JP5527603B2 (ja) 情報処理装置および情報処理方法
US9665422B2 (en) Information processing apparatus and method, and, program
WO2013154025A1 (ja) 情報処理装置および方法、並びに、プログラム
CN110731083A (zh) 视频编码系统和方法中的编码块位流结构和语法
JP7338992B2 (ja) 送信装置、受信装置、及びプログラム
JP2006115001A (ja) 映像送信装置および映像受信装置
JP2007329747A (ja) 画像処理装置、画像処理方法、及びそれを用いた監視システム
JP2004056234A (ja) 画像符号化装置および画像符号化方法
JP2011078068A (ja) 映像伝送方式
KR20020088633A (ko) 동영상 전송장치 및 부호화 방법
KR20090113171A (ko) 정보 처리 장치 및 방법

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100305

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120313

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120507

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20120712

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20121012

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20121023

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20121120

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20121203

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151228

Year of fee payment: 3

R151 Written notification of patent or utility model registration

Ref document number: 5162939

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151228

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees