(57)【特許請求の範囲】
【請求項１】
フレーム間予測を行って圧縮された圧縮動画像信号のデコード装置において、
上記圧縮動画像信号を動き補償を施す前の複数画素のブロックレベルへデコードしたデータに対してブロック単位で圧縮を行うブロック圧縮手段と、
当該ブロック圧縮手段によって圧縮されてメモリに書き込まれる圧縮データを読み出して上記ブロック単位で伸張するブロック伸張手段とを有してなり、
実際の表示又は動き補償演算の際に必要とされる上記圧縮データを上記メモリから読み出して伸張し、上記実際の表示又は動き補償演算のために使用することを特徴とする圧縮動画像信号のデコード装置。
【請求項２】
予測フレームをリファレンスとして使用してフレームの動き補償を行った結果のデータをブロック単位で保持するブロック保持手段と、
上記ブロック保持手段に保持された上記ブロックをリファレンスとして動き補償を行う動き補償手段とを備え、
予測フレームの動き補償演算の実行の後、ブロック単位での圧縮を行い、上記メモリに書き込むことを特徴とする請求項１記載の圧縮動画信号のデコード装置。
【請求項３】
両方向予測されたフレームについては、ブロック単位で圧縮することなく、実際の表示の時刻においてブロック単位で伸張されたリファレンスフレームとの動き補償演算を行って表示に使用することを特徴とする請求項２記載の圧縮動画像信号のデコード装置。
【請求項４】
フレーム間予測を行って圧縮された圧縮動画像信号のデコード装置において、
上記圧縮動画像信号を動き補償を施す前の複数画素のブロックレベルへデコードしたデータに対してブロック単位で可変長符号を用いて圧縮を行うブロック圧縮手段と、
当該ブロック圧縮手段によって圧縮されてメモリに書き込まれる圧縮データのブロック単位でのアドレス情報を保持するブロックアドレス保持手段と、
上記メモリ内の圧縮データを読み出して上記ブロック単位で伸張するブロック伸張手段とを有してなり、
実際の表示又は動き補償演算の際に、上記ブロックアドレス保持手段を参照し、参照結果から必要とされる上記圧縮データを上記メモリから読み出して伸張し、上記実際の表示又は動き補償演算のために使用することを特徴とする圧縮動画像信号のデコード装置。
【請求項５】
予測フレームをリファレンスとして使用してフレームの動き補償を行った結果のデータをブロック単位で保持するブロック保持手段と、
上記ブロック保持手段に保持された上記ブロックをリファレンスとして動き補償を行う動き補償手段とを備え、
予測フレームの動き補償演算の実行の後、ブロック単位での圧縮を行い、上記メモリに書き込むことを特徴とする請求項４記載の圧縮動画信号のデコード装置。
【請求項６】
両方向予測されたフレームについては、ブロック単位で圧縮することなく、実際の表示の時刻においてブロック単位で伸張されたリファレンスフレームとの動き補償演算を行って表示に使用することを特徴とする請求項５記載の圧縮動画像信号のデコード装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、２次元の画像圧縮、特にいわゆるＭＰＥＧのようにフレーム間での予測を利用する圧縮方式による圧縮符号化（エンコード）が施された圧縮動画像信号を伸張復号化するデコード装置に関する。
【０００２】
【従来の技術】
動画像圧縮の国際規格であるいわゆるＭＰＥＧのビデオ（以下簡単のためＭＰＥＧと呼ぶ）の圧縮においては、３つのタイプのフレーム（ピクチャ）が存在する。Ｉ−ピクチャは、イントラピクチャと呼ばれ、このフレームにはフレーム間予測は行われず、圧縮処理はこのフレーム内で閉じて実行される。このためＩ−ピクチャは他のフレームのデータを必要とすることなくデコードすることが可能である。一方、Ｐ−ピクチャとＢ−ピクチャはフレーム間予測を行うフレームであり、Ｐ−ピクチャはこのフレームより前のＩ−ピクチャまたはＰ−ピクチャより前方予測を行うものである。Ｂ−ピクチャは、当該フレームの前のＩ−ピクチャあるいはＰ−ピクチャからの前方予測に加え、このフレームより後のフレームからの後方予測も行う。すなわち、このＢ−ピクチャの場合は、前方予測、後方予測、両方向予測の何れかが行われる。なお、ＭＰＥＧとは、国際標準化機構／国際電機標準会議  合同技術委員会１／専門部会 ２９（ISO/IEC JTC1/SC29(International Organization for Stan-dardization/International Electrotechnical Commission, Joint Technical Commitee 1/Sub Commitee 29：）の蓄積用動画像符号化の検討組織の略称であり、ＭＰＥＧ１標準としてＩＳＯ１１１７２が、ＭＰＥＧ２標準としてＩＳＯ１３８１８がある。これらの国際標準において、システム多重化の項目でＩＳＯ１１１７２−１及びＩＳＯ１３８１８−１が、映像符号化の項目でＩＳＯ１１１７２−２及びＩＳＯ１３８１８−２が、音声符号化の項目でＩＳＯ１１１７２−３及びＩＳＯ１３８１８−３が、それぞれ標準化されている。
【０００３】
図９には、これら３種類のフレームでの依存関係の例を示す。
【０００４】
この図９において、Ｉ１、Ｂ２、Ｂ３、Ｐ４は表示順に並んだフレーム（ピクチャ）を表しており、左から右に付随した番号順に表示が行われる。図中の”Ｉ”はＩ−ピクチャを、”Ｐ”はＰ−ピクチャを、”Ｂ”はＢ−ピクチャを表し、図中の矢印は予測の方向を表している。Ｉ１は表示番号１のＩ−ピクチャであり、当該フレームのデコードはこのフレーム内で閉じて行われる。Ｐ４は表示番号４のＰ−ピクチャで、このフレームのデコードのためにはＩ１のフレームのデコード結果を動きベクター（Ｍｏｔｉｏｎ  Ｖｅｃｔｏｒ：動きベクトル）によって読み出し、演算を行う必要がある。Ｂ２は両方向予測を行う表示番号２のＢ−ピクチャで、Ｉ１のフレームのデコード結果とＰ４のフレームのデコード結果により、フレーム間予測の演算（すなわち動き補償演算）を行って、画像を復元する。
【０００５】
図１０は、各フレームのデコードのために必要なデータについて、時間軸を元に表している。
【０００６】
この図１０において、Ｉ１のフレームのデータは当該Ｉ１自身のフレームのデコードのためだけではなく、Ｂ２、Ｂ３、Ｐ４の各フレームでの動き補償（Ｍｏｔｉｏｎ  Ｃｏｍｐｅｎｓａｔｉｏｎ：ＭＣ）の処理でも必要となる。Ｂ２、Ｂ３などのＢ−ピクチャのデコードのためには、それら自身のデータに加え、Ｐ４のフレームのデータも必要となる。Ｐ−ピクチャであるＰ４のフレームは、図に示すようにＢ２、Ｂ３、Ｐ４、Ｂ５、Ｂ６のフレームのデコード処理で必要となる。これらＢ−ピクチャのデコードの際に必要となるＩ−ピクチャやＰ−ピクチャのデコードは、当該Ｂ−ピクチャのデコードが行われる時刻より前に実行され、また、当該Ｂ−ピクチャのデコードの間中、保持されていなければならない。この図１０より明らかなようにＢ−ピクチャも含めると、一時に、最大３フレーム分のデータの保持が必要となる。これらのフレーム用のバッファメモリは、大きなメモリ領域を必要とし、通常、これらは外部メモリとしてデコーダに付随して使用される。
【０００７】
図１１には、実際のＭＰＥＧデコーダでの処理の時間関係の例を示している。
【０００８】
この図１１において、上段の指示符号Ｔ１にて示す時間はデコードのタイミングで、下段の指示符号Ｔ２にて表す時間は表示のタイミングである。この例ではデコードと表示の時間のずれがＩ−ピクチャで１．５フレーム（図中Ｔ３にて示す時間）、Ｂ−ピクチャで０．５フレーム（図中Ｔ４にて示す時間）の遅れがあるものを例として示した。図中のＡ５にて示す矢印は、デコードのフレームと表示のフレームの対応を示したものである。前記図１０からも明らかなように、図１１のＩ１のフレームのデコード結果は、Ｉ１のフレームの表示のタイミングだけではなく、Ｐ４、Ｂ２、Ｂ３のフレームのデコードのタイミングでも必要であり、この期間、Ｉ１のフレームのデコード結果を保持しておく必要がある。Ｐ４のフレームは、当該Ｐ４のフレームの表示のタイミングとＢ２、Ｂ３、Ｐ７、Ｂ５などのフレームのデコード処理でも必要で、この期間保持される。Ｂ−ピクチャに関しては、１フレームをバッファリングする方式と、その一部のみを保持する方式があるが、どちらも大きなメモリ領域を必要とする。
【０００９】
図１２には、従来のＭＰＥＧデコーダの構成例を示す。
【００１０】
この図１２において、ＭＰＥＧのビットストリームが端子６を介してＭＰＥＧデコーダ７に入力されると、先ずデマルチプレクサ８でオーディオ、ビデオなどのビットストリームに分解され、信号線９、バス１０、信号線１１を経てメモリインターフェース回路１２により、一旦外付けのメモリ１３の領域１４に書き込まれる。ここで信号線１５は、デコーダ７とメモリ１３間のデーターバス、アドレス信号線などを表している。なお、図１２ではオーディオなどの処理を行う構成については省略している。
【００１１】
上記外付けメモリ１３の領域１４から読み出されたビデオのビットストリームは、メモリインターフェース回路１２、信号線１１、バス１０、信号線１６を経てビデオデコーダ１７に入力される。
【００１２】
ビデオデコーダ１７にはその主な構成要素として、ヘッダの解析と可変長符号のデコードを行うヘッダ／ＶＬＤ回路１８、逆量子化（ＩＱ）器１９、逆コサイン変換（ＩＤＣＴ）器２０、動き補償を行う動き補償（ＭＣ）器２１などがある。
【００１３】
動き補償器２１には、動きベクターによって読み出されたリファレンス画像が信号線２２を介して入力され、当該動き補償器２１にて再構成された出力画像は信号線２３、バス１０、信号線１１、メモリインターフェース回路１２を経て外付けメモリ１３内の領域に書き込まれる。例えばデコードされたＩ−ピクチャ、Ｐ−ピクチャ、およびＢ−ピクチャの各画像は、外付けメモリ１３のそれぞれ指定された領域２４、２５、２６に書き込まれる。これらの領域の大きさはそれぞれ１フレーム分必要であり、外付けメモリ１３のサイズはかなり大きなものが必要となる。なお、Ｉ−ピクチャのための領域２４は、Ｐ−ピクチャのためにも利用される。
【００１４】
外付けメモリ１３内のＩ−ピクチャのデータは、前記図１１に示した表示タイミングで読み出され、信号線２７を経て表示用のディスプレイ回路２８へ送られ、画像データとして端子２９から出力される。また、この外付けメモリ１３内のＩ−ピクチャのデータは、図１１のタイミングでＢ−ピクチャあるいはＰ−ピクチャのデコードのためにも読み出される。Ｐ−ピクチャのデータも同様に表示のため、Ｂ−ピクチャのデコードのために読み出される。Ｂ−ピクチャに関しては、本例では１フレーム分の領域を確保したものを示したが、ここからは表示のタイミングで読み出しが行われる。
【００１５】
【発明が解決しようとする課題】
上述したＭＰＥＧでは、各種のデータ圧縮技術の組み合わせにより、高品質、高圧縮率の画像圧縮を実現している。そのなかで、フレーム間の予測は最も重要な技術の一つである。フレーム間予測方式では、動きベクターにより、現在デコード中のブロックに最も近いブロックを前フレームあるいは後フレームから切り出し、これらの差分を計算し、この結果を圧縮するというものだが、このフレーム間予測により圧縮されたビットストリームのデコードのためには、本質的に前にデコードされたフレームデータの保持が必要となり、必要なメモリ容量が増大する。
【００１６】
すなわち前記従来の構成例においては、デコードされた画像データを少なくとも３フレーム分蓄える必要があり、大きな領域の外付けメモリ１３が必要となる。例えば、ＭＰＥＧにおけるメインレベル（Ｍａｉｎ  Ｌｅｖｅｌ（ＭＬ））のデコーダでは、１６Ｍビット程度の外付けメモリ１３が必要となり、またチップへのインテグレーションの際に大きなチップ面積が必要で、大幅なコストアップとなる。さらに大きな画像サイズであるハイレベル（Ｈｉｇｈ  Ｌｅｖｅｌ（ＨＬ））のデコーダでは、フレームサイズが４〜６倍となり、必要となるメモリサイズも格段に大きくなる。このハイレベル（ＨＬ）のデコーダを外付けメモリ１３で実現する際には、デコーダ７と外付けメモリ１３との間のバスのバンド幅が問題になる。また、チップ上にインテグレーションする場合には、そのサイズが大きく、実現は難しい。
【００１７】
そこで、本発明はこのような状況に鑑みてなされたものであり、メモリ容量の増大を防ぎ、また、チップへのインテグレーションの際のチップ面積の増大とコスト上昇を抑え、バスのバンド幅をも削減できる、圧縮動画像信号のデコード装置を提供することを目的とする。
【００１８】
【課題を解決するための手段】
本発明の圧縮動画像信号のデコード装置は、フレーム間予測を行って圧縮された圧縮動画像信号のデコード装置において、上記圧縮動画像信号を動き補償を施す前の複数画素のブロックレベルへデコードしたデータに対してブロック単位で圧縮を行うブロック圧縮手段と、当該ブロック圧縮手段によって圧縮されてメモリに書き込まれる圧縮データを読み出して上記ブロック単位で伸張するブロック伸張手段とを有してなり、実際の表示又は動き補償演算の際に必要とされる上記圧縮データを上記メモリから読み出して伸張し、上記実際の表示又は動き補償演算のために使用することにより、上述した課題を解決する。
また、本発明の圧縮動画像信号のデコード装置は、フレーム間予測を行って圧縮された圧縮動画像信号のデコード装置において、上記圧縮動画像信号を動き補償を施す前の複数画素のブロックレベルへデコードしたデータに対してブロック単位で可変長符号を用いて圧縮を行うブロック圧縮手段と、当該ブロック圧縮手段によって圧縮されてメモリに書き込まれる圧縮データのブロック単位でのアドレス情報を保持するブロックアドレス保持手段と、上記メモリ内の圧縮データを読み出して上記ブロック単位で伸張するブロック伸張手段とを有してなり、実際の表示又は動き補償演算の際に、上記ブロックアドレス保持手段を参照し、参照結果から必要とされる上記圧縮データを上記メモリから読み出して伸張し、上記実際の表示又は動き補償演算のために使用することにより、上述した課題を解決する。
【００１９】
すなわち本発明によれば、後に使用するデコードされたデータを再度他の方法で圧縮し、必要なときに伸張するようにしたことにより、必要となるメモリの削減を実現するようにしている。言い換えれば、メモリに蓄えるべきフレームデータを一旦圧縮し、後に必要となった際に読み出して、表示や演算に使用するようにしているため、フレームデータの保持のためのメモリサイズが大幅に削減され、チップ上へのメモリのインテグレーションも可能となり、また、高画素数化の場合であってもメモリサイズの増加を行うことなく実現可能となっている。
【００２０】
【発明の実施の形態】
以下、本発明の好ましい実施の形態について、図面を参照しながら説明する。
【００２１】
先ず、本発明実施の形態の具体的内容の説明を行う前に、本発明の基本的な構成及び動作原理の説明を行う。
【００２２】
本発明のデコード装置は、動画像圧縮の国際規格であるＭＰＥＧ等のように、フレーム間予測による圧縮方式にて処理された圧縮動画像信号をデコードするシステムであり、デコードされたフレームデータを保持するためのメモリサイズを削減することを可能にするものである。
【００２３】
すなわち、本発明のデコード装置は、ＭＰＥＧ等のデコードの際に、ＭＰＥＧ等のアルゴリズムに基づいて一旦デコードされたデータを再び別のアルゴリズムで圧縮してメモリに蓄えておき、その後の動き補償演算等のデコードの動作或いは表示の動作において、これらのデータが必要となったタイミングで、これらの別のアルゴリズムで圧縮されて保持されているデータを読み出して伸張してから、上記動き補償や表示のために使用するようにしている。このように、本発明の構成では、ＭＰＥＧのデコードされた結果をそのままメモリに保持するのではなく、当該デコードされたデータに対して後段の処理に適した圧縮を施して保持しておくことで、メモリの保持すべきデータの量の削減を行い、メモリサイズの削減を実現する。また、上記別のアルゴリズムで圧縮されたデータを保持するメモリは、外付けメモリ、チップ上のメモリの何れであってもよい。
【００２４】
より詳細に説明すると、ＭＰＥＧでの圧縮においては、フレーム間予測により、フレーム間のデータが依存しあっている。また１フレーム内でも、スライス（Ｓｌｉｃｅ）レベルではその独立性がある程度保たれているが、これより細かなマクロブロック（Ｍａｃｒｏｂｌｏｃｋ）レベルあるいはブロック（Ｂｌｏｃｋ）レベルではこれらの間にデータの依存関係があり、独立したものではない。例えば、ＤＣ成分のブロック間の差分処理などにより、スライス内のあるマクロブロック／ブロックの処理のためにはスライスの先頭からの処理が必要となるなど、局所的な圧縮アルゴリズムとは言い難い。
【００２５】
ＭＰＥＧのデコードを行う際に、フレームデータとして蓄えられたデータは、表示のためと動き補償のために読み出される。表示の際には、ラスタースキャンすなわち水平方向に１ラインづつの読み出しが行われ、一方、動き補償の際には、動きベクターに従ってブロック単位でランダムな読み出しが必要となる。
【００２６】
上記動き補償のための読み出しにおいて、外付けメモリに保持された圧縮されたデータに局所的でない依存性があると、必要となるデータの伸張の際、大量のデータの読み出しと長いステップのデコード動作とが必要となり、したがって、動作スピードや読み出しデータ量の観点からも、この圧縮は局所的であることが望ましい。
【００２７】
図１には、動き補償（Ｍｏｔｉｏｎ  Ｃｏｍｐｅｎｓａｔｉｏｎ：ＭＣ）のために必要なブロックデータについて説明するための図を示している。基本となるＭＰＥＧの８×８画素のブロックを指示符号３０に、動き補償のために必要となる１７×１７画素のブロックの読み出し領域を指示符号３１に示している。動き補償のためのブロック３１の領域は動きベクターの値によって任意に変わるため、８×８のブロック３０とは独立した位置からの読み出しが必要となる。また、半画素単位でのデータが必要なため、マクロブロックのサイズ１６×１６画素より水平、垂直とも１画素づつ大きなブロックの読み出しが必要となる。このようなデータを獲得するに当たり、局所的でない圧縮が行われると、大きな領域のデータの確保とそのデコード、そして必要なデータの切り出しが必要となり、効率ではない。
【００２８】
本発明では、８×８画素のブロック内で閉じた圧縮方式をベースにしている。しかしながら、本発明の適用はこのような８×８画素のブロック単位での圧縮に限るものではなく、局所的なアルゴリズムであれば使用可能である。圧縮という観点からいえば局所性と演算効率は相反するもので、システムでの効率を考えて選択される。
【００２９】
本発明で使用される圧縮アルゴリズムの要求仕様をまとめると、以下の（１）〜（４）のようになる。
【００３０】
（１）局所性
・フレーム内処理であること。
【００３１】
・ブロック単位で閉じた圧縮アルゴリズムであること。
【００３２】
（２）圧縮率
・２〜６倍程度の低圧縮率で充分。
【００３３】
（３）低演算量
・圧縮伸張の計算量が少ないこと。複数個の圧縮、伸張装置を必要とするため。
【００３４】
（４）可逆性
・必ずしも必要ない。システムの画質の要求レベルによる。
【００３５】
どのような圧縮アルゴリズムを使用するかは、システムの要求レベルや実現方法に依存する。コサイン変換と可変長符号の組み合わせなどや、より簡単なアダマール変換などの適用が可能である。現在までの種々の圧縮アルゴリズムが提案、実用化されており、これらの中から、あるいはこれらを組み合わせて適切なアルゴリズムが選択される。
【００３６】
次に、本発明の実施の形態の形態の具体的な内容の説明を行う。
【００３７】
なお、本実施の形態の説明においては、ＭＰＥＧを例に取り上げているが、本発明はＭＰＥＧに限るものではなく、同様の考えを持つ他のいかなる圧縮方式にも適応できるものである。すなわち、フレーム間予測方式のように、一旦デコードされたデータを後で再度使用するような各種の圧縮方式に適用できるものである。また、本実施の形態の説明では、簡単のため、フレーム単位での表示及び処理であるプログレッシブ方式を中心に説明し、インターレースの場合については簡単に触れたのみとなっているが、インターレースでは単にフィールドでのデータの保存、処理が必要となるのみである。さらに、同一フレーム内のフィールドでの表示時間のずれを補正するには、圧縮された形でのデータの保持か、表示の際にフィールドデータの処理を行うのみである。
【００３８】
本発明の第１の実施の形態のデコード装置の概略構成を図２に示す。
【００３９】
この図２において、端子３２に供給されたＭＰＥＧビデオのビットストリーム３２は、先ずプリデコーダ３３でＭＰＥＧのアルゴリズムに準じたデコード処理が行われる。このときどこまでデコードが行われるかは、システムによって、あるいはその後の圧縮アルゴリズムに依存するが、８×８画素のブロック単位での閉じた圧縮が可能なレベルまではデコードされる。図２の例では、Ｐ−ピクチャおよびＢ−ピクチャについては動き補償の前までのデコード処理とし、後段で動き補償の演算が行われる例を示した。
【００４０】
プリデコーダ３３でのデコード処理の結果は、上記ＭＰＥＧのアルゴリズムとは異なるアルゴリズムを用いたブロック単位での圧縮を行うブロック圧縮器３４によって圧縮され、信号線３５とバス３６及び信号線４４を経由してメモリ３７に書き込まれる。このとき、Ｐ−ピクチャやＢ−ピクチャでの動きベクターなどの情報は、パラメータとして圧縮ストリームに挿入される。なお、この段階での圧縮に可変長符号が使用された際には、ブロック境界が固定ではないのでブロックアドレステーブル３８にそのブロックのデータの先頭アドレス、長さなどが信号線４３を通して記録される。
【００４１】
上記メモリ３７への記憶が行われた後に、必要なブロックアドレスのデータの場所を探す際には、ブロック検索エンジン３９を使用してブロックアドレステーブル３８の検索を行い、そのブロックの先頭アドレスを獲得してから上記メモリ３７からの読み出しが実行される。
【００４２】
メモリ３７には、この第１の実施の形態の例ではＩ／Ｐ−ピクチャ用バッファ４０、Ｐ−ピクチャ用バッファ４１、Ｂ−ピクチャ用バッファ４２が存在する。これらは信号線４４を通してバス３６に接続されており、データの読み書きが行われる。
【００４３】
上述したように、ブロック圧縮器３４でブロック圧縮が行われた後のＩ−ピクチャ、Ｐ−ピクチャおよびＢ−ピクチャの圧縮データは、それぞれメモリ３７内の対応する場所に書き込まれる。
【００４４】
ここで、Ｉ−ピクチャの表示の際には、上記メモリ３７に保存されているＩ−ピクチャの圧縮データが読み出され、信号線４４とバス４４及び信号線４７を通してブロック伸張器４８に送られ、上記ブロック圧縮器３４での圧縮アルゴリズムに対応する伸張処理が行われる。このブロック伸張器４８にて伸張されたＩ−ピクチャのデータは、信号線５２を通ってセレクタ５８に送られて選択され、さらに信号線６１を通してラインバッファ６２に送られる。本発明の例では、８×８のブロックを圧縮の基本単位としているため、ブロック伸張器４８で伸張されたＩ−ピクチャの８×８の画素データがラインバッファ６２に蓄えられる。このラインバッファ６２からは、上記蓄えられた画素データがラスタスキャン順に読み出されて信号線６３を介してディスプレイ化６４に送られる。このディスプレイ回路６４では、上記供給されたデータから表示用のビデオ信号を生成し、このビデオ信号が端子６５から出力される。
【００４５】
一方、Ｐ−ピクチャのデコードの際には、上記メモリ３７のＰ−ピクチャ用バッファ４１あるいはＩ／Ｐピクチャ用バッファ４０から、Ｐ−ピクチャの圧縮データが読み出され、先ずブロック伸張器４８に送られてブロック伸張処理される。また、このとき動きベクターも復元され、当該Ｐーピクチャのデコードに使用されるリファレンスフレームとして必要なＩ−ピクチャ（Ｐ−ピクチャの場合もある）の圧縮データも、上記メモリ３７から読み出される。次いで、上記復元された動きベクターの値から、上記リファレンスフレーム内の必要なブロック番号が選択され、ブロック検索エンジン３９によってブロックアドレステーブル３８から対応するブロックのメモリ３７上でのアドレスを得る。このアドレスにより、上記必要なブロックの圧縮データが上記メモリ３７から読み出され、信号線４９を通してブロック伸張器５０に送られてブロックの復元が行われる。このブロック伸張器５０にて復元されたデータは信号線５４に送られ、その後動き補償演算に必要なデータのみがセレクタ５６にて選択されて動き補償演算器５７に送られる。ここでは半画素単位の補間演算などが行われ、ブロック伸張器４８にて伸張されて信号線５２を通ったデータとの加算が行われ、動き補償演算によりデコードが完了する。この結果は、セレクタ５８、信号線６１を通してラインバッファ６２に送られ、さらにディスプレイ回路６４に送られて表示用のビデオ信号になされる。また、当該Ｐ−ピクチャの画像データは、この段階でブロック圧縮器５９にて再度ＭＰＥＧとは異なるアルゴリズムによってブロック単位で圧縮された後、メモリ３７に蓄えられる。この動き補償された後に再度圧縮されたＰ−ピクチャは、その後のフレームのデコードの際に読み出し及び伸張されて前方予測のリファレンスフレームとして使用されることになる。
【００４６】
Ｂ−ピクチャのデコードの際には、両方向のフレーム予測が行われる場合があるため、上記Ｐ−ピクチャのデコードよりも複雑となり、さらにもう１回動き補償演算（すなわち２回の動き補償演算）を行う必要がある。上記メモリ３７のＢ−ピクチャ用バッファ４２から読み出された圧縮データは、信号線４４とバス３６及び信号線４５を通してブロック伸張器４６に送られてブロック伸張される。また、このときも動きベクターが取り出され、先ず先行しているＩ−ピクチャ（Ｐ−ピクチャのこともある。ただしＰ−ピクチャのときには当該Ｐ−ピクチャのブロックの動き補償演算が行われている必要がある。詳細は図４のところで説明を行う。）をリファレンスフレームとした前方予測の処理が行われる。また、上記動きベクターによって指定されたリファレンスフレームのブロックのアドレスを、上述したＰ−ピクチャの場合と同様にしてブロック検索エンジン３９とブロックアドレステーブル３８によって獲得し、これによって必要なブロックデータの読み出しを行い、さらにブロック伸張器５０で伸張する。その後、この中から必要なデータを選んでＰ−ピクチャの場合と同様に動き補償演算器５７で動き補償演算（第１回目の動き補償演算）を行い、得られたデータをブロックバッファ６０に保存する。また、第１回目の動き補償演算後のデータは、ブロック圧縮器５９にて再度圧縮し、メモリ３７に保存してその後のフレームのデコードの際にリファレンスフレームとして使用される。後方予測演算の時には、上記ブロックバッファ６０からブロックデータが読み出され、信号線５５及びセレクタ５３を通って動き補償器５７に送られると共に、この動き補償器５７には上記メモリ３７からは後方用の動きベクターによる前述同様の処理によって必要な圧縮データが読み出され、さらにブロック伸張器５０にて伸張されたブロックデータも供給される。動き補償器５７では、上記ブロックバッファ６０からのブロックデータと上記ブロック伸張器５０からのブロックデータとの間で動き補償演算を行う。この動き補償演算の結果は、ラインバッファ６２以降の構成に送られ、前述同様の表示用のビデオ信号が生成される。
【００４７】
また、Ｂ−ピクチャのリファレンスフレームがＰ−ピクチャであった場合にはさら１ステップの演算（第２回目の動き補償演算）が必要となる。すなわち、本実施の形態では、前述したようにプリデコード後に動き補償の演算を行っていないため、リファレンスフレームとなるＰ−ピクチャは完全な画像データではなく、リファレンスフレームとして使用する前に動き補償の処理を行う必要がある。この動作は、上記のＰ−ピクチャでの処理と同様であり、この動き補償演算後のＰ−ピクチャのブロックデータを使用してＢ−ピクチャでの動き補償演算を行うものとなる。つまり、このとき既に表示が行われたＰ−ピクチャの動き補償後の画像データは、前述したようにブロック圧縮器５９にてブロック圧縮されてメモリ３７内に保持されているので、このＰ−ピクチャの圧縮データを読み出して伸張し、前方予測の際のリファレンスフレームとして使用する。
【００４８】
なお、本実施の形態では、クロマ成分、フィールド予測の場合、デュアルプライム（Ｄｕａｌ  Ｐｒｉｍｅ）の場合などの説明を省略したが、前述同様の動作、システムでこれらの処理も実現することは容易である。また、本実施の形態におけるインターレースの際のように、同一フレーム内の異なるフィールドで表示時間にずれがある場合には、マクロブロック単位でデコードされた後のブロック圧縮をフィールド単位のブロックとして実行する。表示の際にはこれら２つのフィールドを別々に読み出し、動き補償の演算もフィールド単位での処理として実行する。また、図２においてブロック圧縮器、ブロック伸張器などが複数個設けられているが、これらのハードウェアを共用にすることも可能である。
【００４９】
図３には、図２の実施の形態の構成における処理のタイミングについて示している。図中指示符号Ｔ６６はプリデコード及び圧縮のタイミングを、指示符号Ｔ６７はＩ／Ｐ−ピクチャの伸張のタイミングを、指示符号Ｔ６８はＰ−ピクチャのブロック伸張を、指示符号Ｔ６９はＢ−ピクチャのブロック伸張のタイミングをそれぞれ表している。また、指示符号Ｔ７０は表示のタイミングを示している。図中Ｉ１、Ｐ４などとあるのは処理されるフレームを示す。Ｉ−ピクチャはその表示の２フレーム前にプリデコードとブロック圧縮が行われる。Ｉ−ピクチャ表示時にはＩ−ピクチャのデータのみがブロック伸張され、表示される。続くＢ−ピクチャの表示タイミングでは、Ｂ−ピクチャのブロック伸張とともに、動き補償のためのリファレンスフレームとしてＩ−ピクチャ／Ｐ−ピクチャのブロック伸張と動き補償演算が行われ、さらに表示される。Ｐ−ピクチャの表示タイミングでは、Ｐ−ピクチャのブロック伸張とともに、動き補償のためのリファレンスフレームとしてＩ−ピクチャ（Ｐ−ピクチャ）のブロック伸張演算が行われる。また、このＰ−ピクチャの表示の際には同時に、動き補償されたＰ−ピクチャの再度のブロック圧縮も行われる（図には表示なし）。
【００５０】
図４には、動き補償演算時の依存関係を示す。図４の（ａ）はＰ−ピクチャの場合を示し、当該Ｐ−ピクチャのデコードのためにはＩ−ピクチャ又はＰ−ピクチャのリファレンスフレーム内の動きベクターに対応したブロックの読み出しとブロック伸張が行われる。図４の（ｂ）はＢ−ピクチャの場合を示し、Ｉ−ピクチャをリファレンスフレームとする場合には図４の（ａ）と同様な動作となるが、Ｐ−ピクチャをリファレンスフレームとする際には２ステップの処理（２回の動き補償演算）が必要となる。すなわち、動きベクターによって指定されたＰ−ピクチャのブロックのデータは未だ動き補償の演算が行われていないため、このＰ−ピクチャの動き補償のためのリファレンスフレーム（Ｉ−ピクチャあるいは動き補償演算のなされたＰ−ピクチャ）を使って、事前に演算しておく必要がある。このようにして先に復元されたＰ−ピクチャのデータを使用してＢ−ピクチャの動き補償演算が行われる。
【００５１】
図５は本発明の第２の実施の形態の構成を示す。なお、この図５の構成において、図２と同じ指示符号にて示す各構成要素は基本的には図２のものと同様な機能である。また、この第２の実施の形態では、Ｂ−ピクチャに関しての処理を表示タイミングに合わせて行うようにしており、Ｂ−ピクチャの圧縮とメモリ３７での保持は行わない（Ｂ−ピクチャをブロック圧縮することなく動き補償演算をして表示を行う）例を挙げている。
【００５２】
この図５において、プリデコーダ３３からの出力は２つあり、信号線７１からのＩ−ピクチャおよびＰ−ピクチャのデータは、前記第１の実施の形態と同様にブロック圧縮器３４にて圧縮され、前記ブロックのアドレステーブルの作成とともにメモリ３７に書き込まれる。一方、信号線７２からのＢ−ピクチャのデータは、圧縮されることなく動き補償演算器５７に送られる。
【００５３】
このように、当該第２の実施の形態では、Ｉ−ピクチャおよびＰ−ピクチャのデコード処理の流れは前記図２の場合と同様であるが、Ｂ−ピクチャに関しては、圧縮とメモリ３７への保持を行うことなく、即座に動き補償演算が行われ、表示される。すなわち、プリデコーダ３３から信号線７２を通ったデータは、動き補償演算器５７に送られ、前方、後方のリファレンスフレームとの処理が図２と同様に行われる。ただし、本実施の形態では、プリデコーダ３３からのデータがマクロブロック単位となっているため、動き補償の演算、バッファリングなどはマクロブロック単位となる。また、この第２の実施の形態では、Ｂ−ピクチャ用の中間バッファであるブロックバッファ７３はマクロブロックのサイズに対応しており、表示用のラインバッファ６２もマクロブロックの大きさを持つ。さらに、本実施の形態では、Ｂ−ピクチャの圧縮とメモリ３７への書き込みを行わないため、メモリ３７にはＢ−ピクチャ用の領域はない。ただし、これはプログレッシブ方式の場合に係わるもので、インターレース方式の場合には表示ために第２フィールドの画像データを１フィールド期間保持する必要がある。ブロック圧縮器５９で圧縮され、メモリ３７に蓄えられたデータは、１フィールド後にメモリ３７から読み出されて、ブロック伸張され、表示にされる。この他、ディスプレイ回路６４に１フィールド分のメモリ領域を持ってデータを遅らせることも可能である。
【００５４】
図６は、第２の実施の形態での処理と表示のタイミングを前記図３に準じて示したものである。本例では、Ｉ−ピクチャのプリデコード、ブロック圧縮は、表示の１フレーム前に実行しており、Ｂ−ピクチャは表示のタイミングでプリデコードと同時に動き補償の演算が行われる。
【００５５】
図７には、本発明の第３の実施の形態の構成を示す。この第３の実施の形態の構成は、第２の実施の形態同様にＢ−ピクチャをブロック圧縮することなく動き補償演算及び表示し、Ｐ−ピクチャについては当該Ｐ−ピクチャのプリデコード後に動き補償演算を行い、その後にブロック圧縮を行ってＰ−ピクチャのデータをメモリ３７に蓄えるというものであり、Ｐ−ピクチャをリファレンスとして使用する際に図４の（ｂ）に示したように再度Ｐ−ピクチャのリファレンスを読み出し、Ｐ−ピクチャの動き補償演算を行ってから、Ｐ−ピクチャをリファレンスに使用するという２ステップ（２回の動き補償演算）の動作が不要となり、ブロック伸張されたＰ−ピクチャのデータをそのまま動き補償の演算に使用できるものである。
【００５６】
この図７の構成において、図５と同じ指示符号にて示す各構成要素は基本的には図５のものと同様な機能である。ただし、プリデコーダ３３から信号線７２を通って動き補償器５７へ送られるデータは、Ｂ−ピクチャに加えて、Ｐ−ピクチャのデータも送られる。一方、信号線７１を介してブロック圧縮器３４へ送られるデータはＩ−ピクチャのデータのみとなり、このＩ−ピクチャのデータがブロック圧縮器３４にて圧縮され、メモリ３７に蓄えられる。
【００５７】
当該第３の実施の形態では、Ｐ−ピクチャについての２ステップの動き補償演算（２回の動き補償演算）のためのブロックバッファは不用であるため省かれているが、その代わり、動き補償演算器５７からの出力をブロック圧縮するためのブロック圧縮器７５が追加されている。Ｂ−ピクチャの処理は第２の実施の形態と同様に表示のタイミングで実行される。
【００５８】
すなわち、本実施の形態では、Ｐ−ピクチャのデータはプリデコーダ３３での処理後、動き補償演算器５７に送られる。ここで、Ｐ−ピクチャの動きベクターに基づいてメモリ３７から読み出されたＩ−ピクチャ（または動き補償後のＰ−ピクチャ）の圧縮データは、信号線４９を通してブロック伸張器５０で伸張された後、必要なデータが選択され、動き補償器５７にてＰ−ピクチャのデータとの動き補償演算が行われ、その後ブロック圧縮器７５により圧縮されてメモリ３７に書き込まれる。この動作と同時にＩ−ピクチャ（あるいはＰ−ピクチャ）の表示が行われる。このため、ブロック伸張器４８で伸張されたデータは、セレクタ５８、信号線６１を通してラインバッファ６２に送られ、ディスプレイ回路６４にて表示される。
【００５９】
また、この第３の実施の形態におけるＢ−ピクチャでの処理は、第２の実施の形態と同じである。すなわち、前方又は後方予測の演算がなされた中間結果を一旦ブロックバッファ７３に蓄え、その後もう一度動き補償の演算を行った後、表示のためにラインバッファ６２に送る。
【００６０】
図８には第３の実施の形態でのタイミングを前記図６に準じて示したものである。この第３の実施の形態では、Ｐ−ピクチャがブロック圧縮の前に動き補償演算されているため、Ｐ−ピクチャの表示のタイミングで動き補償を行う必要がなく、このタイミングで次のＰ−ピクチャの動き補償演算が行われる。
【００６１】
上述したように、本発明によれば、従来フレーム間予測を使用した画像圧縮システムのデコーダにおいて必要とされていた大きなフレームバッファメモリの大きさを格段に抑えることが可能となる。本発明での幾つかの実施の形態からも明らかなように本発明の実現にはさまざまな方法が考えられ、これらのうちどれを選択するかは要求されるシステムによって変更が可能であり、適切な方式を選択することが可能である。また、前述した別のアルゴリズムによる圧縮の効果はメモリの削減だけではなく、本発明の各実施の形態にみられるように、メモリとのデータの圧縮、伸張がバスを挟んで実行されるため、バス上のバンド幅が大きく削減されるという効果があり、高速のバスが不要となるという効果がある。
【００６２】
【発明の効果】
以上の説明で明らかなように、本発明の圧縮動画像信号のデコード装置においては、圧縮動画像信号をブロックレベルへデコード処理した後のデータに対してブロック単位で圧縮し、この圧縮されてメモリに書き込まれる圧縮データのブロック単位でのアドレス情報を保持し、当該メモリ内の圧縮データを読み出してブロック単位で伸張し、実際の表示の時刻及び動き補償演算の時刻において、必要とされる圧縮データをメモリから読み出して伸張し、実際の表示及び動き補償演算のために使用するようにしたことにより、メモリ容量の増大を防ぎ、また、チップへのインテグレーションの際のチップ面積の増大とコスト上昇を抑え、バスのバンド幅を削減可能となる。
【図面の簡単な説明】
【図１】動き補償のために必要なブロックデータの説明に用いる図である。
【図２】本発明の第１の実施の形態のデコード装置の概略構成を示すブロック回路図である。
【図３】第１の実施の形態の装置での動作のタイミング関係を示した図である。
【図４】第１の実施の形態の装置でのデータの依存関係の説明に用いる図である。
【図５】本発明の第２の実施の形態のデコード装置の概略構成を示すブロック回路図である。
【図６】第２の実施の形態の装置での動作のタイミング関係を示した図である。
【図７】本発明の第３の実施の形態のデコード装置の概略構成を示すブロック回路図である。
【図８】第３の実施の形態の装置での動作のタイミング関係を示した図である。
【図９】ＭＰＥＧでのピクチャータイプによる依存関係の説明に用いる図である。
【図１０】各フレームのデコードに必要なビットストリームのデータについての説明に用いる図である。
【図１１】従来のデコーダにおけるデコード動作と表示のタイミングについての説明に用いる図である。
【図１２】従来のＭＰＥＧデコーダの構成例を示すブロック回路図である。
【符号の説明】
３３  プリデコーダ、  ３４，５９  ブロック圧縮器、  ３７  メモリ、  ４０，４１，４２  メモリないの圧縮されたフレームデータの保持領域、  ３８  ブロックアドレステーブル、  ３９  ブロック検索エンジン、  ４６，４８，５０  ブロック伸張器、  ５３，５６，５８  セレクタ、  ５７  動き補償器、  ６０，７３  ブロックバッファ、  ６２  ラインバッファ、  ６４  ディスプレイ回路
【図１】
0004010024.tif 000002
【図２】
0004010024.tif 000003
【図３】
0004010024.tif 000004
【図４】
0004010024.tif 000005
【図５】
0004010024.tif 000006
【図６】
0004010024.tif 000007
【図７】
0004010024.tif 000008
【図８】
0004010024.tif 000009
【図９】
0004010024.tif 000010
【図１０】
0004010024.tif 000011
【図１１】
0004010024.tif 000012
【図１２】
0004010024.tif 000013