(57)【特許請求の範囲】
【請求項１】
圧縮された動画像データに対して、可変長符号化された圧縮動画像データの可変長符号を復号する処理と、前記可変長符号の復号処理に続いて実施される逆スキャン処理と、前記逆スキャン処理に続いて実施される逆ＡＣＤＣ（交流・直流成分）予測と、を実施するソフトウェア処理部と、
前記ソフトウェア処理部にて処理された動画像データを格納するデータ記憶部と、
前記データ記憶部からの動画像データに対して、動画像データの逆量子化及びそれ以降の伸張処理をハードウェアにより実施する複数の処理部を少なくとも含むハードウェア処理部と、
を有し、
前記ソフトウェア処理部は、前記ソフトウェア処理部にて処理された動画像を圧縮して、前記データ記憶部に記憶させるデータ圧縮部を含み、
前記ハードウェア処理部は、前記データ記憶部からの動画像データを伸張して、前記データ圧縮部での圧縮処理前に戻すデータ伸張部を含み、
前記データ記憶部は、所定ビット数を有し、その上位側ビットにより種類を識別できる複数種のパケットの記憶エリアを有し、
前記複数種のパケットの一つがゼロカウントデータパケットであり、
前記データ圧縮部は、画素配列上で連続するゼロデータの数をカウントし、連続するゼロデータを、ゼロデータのカウント値に圧縮処理し、前記ゼロデータのカウント値を前記ゼロカウントデータパケットの記憶エリアに格納し、
前記複数種のパケットの他の一つが圧縮データパケットであり、
前記データ圧縮部は、予め定められたビット数以下のビット数で表せる複数の動画像データを、同一の前記圧縮データパケットの記憶エリアに格納し、
前記複数種のパケットのさらに他の一つが非圧縮データパケットであり、
前記データ圧縮部は、予め定められたビット数を越えたビット数でしか表わすことができない動画像データを、前記非圧縮データパケットの記憶エリアに格納することを特徴とする圧縮動画像の伸張装置。
【請求項２】
請求項１において、
前記データ記憶部は、少なくとも１フレーム分の動画像データを記憶する記憶領域を有することを特徴とする圧縮動画像の伸張装置。
【請求項３】
請求項２において、
前記ソフトウェア処理部に入力される圧縮された前記動画像データは、８画素×８画素の１ブロック単位で離散コサイン変換されており、
前記１フレーム分の記憶領域には、前記１ブロックに対応する記憶領域毎に前記複数種のパケットが格納されていることを特徴とする圧縮動画像の伸張装置。
【請求項４】
請求項３において、
前記１ブロックに対応する記憶領域には、前記ソフトウェア処理部にて生成され、前記ハードウェア処理部での伸張処理に必要なコントロールデータを記憶するコントロールデータパケットが設けられていることを特徴とする圧縮動画像の伸張装置。
【請求項５】
請求項１乃至４のいずれかにおいて、
前記データ記憶部には、前記ハードウェア処理部にて伸張された少なくとも１フレーム分の動画像を記憶する表示用記憶領域がさらに設けられていることを特徴とする圧縮動画像の伸張装置。
【請求項６】
ホストＣＰＵと、
前記ホストＣＰＵに接続され、圧縮された動画像データをソフトウェアにて伸張処理するソフトウェア処理部を有する第１の集積回路と、
前記ホストＣＰＵに接続され、表示制御を行う第２の集積回路と、
前記第２の集積回路により表示制御される画像表示部と、
を有し、
前記第２の集積回路は、
前記ソフトウェア処理部にて処理された動画像データを格納するデータ記憶部と、
前記データ記憶部からの動画像データをハードウェアにて伸張処理するハードウェア処理部と、
を有し、
前記ソフトウェア処理部は、圧縮された動画像データに対して、可変長符号化された圧縮動画像データの可変長符号を復号する処理と、前記可変長符号の復号処理に続いて実施される逆スキャン処理と、前記逆スキャン処理に続いて実施される逆ＡＣＤＣ（交流・直流成分）予測と、を実施し、かつ、前記ハードウェア処理部は、前記ソフトウェア処理部にて伸張処理された動画像データの逆量子化及びそれ以降の処理を実施する複数の処理部を少なくとも含み、
前記ソフトウェア処理部は、前記ソフトウェア処理部にて処理された動画像を圧縮して、前記データ記憶部に記憶させるデータ圧縮部を含み、
前記ハードウェア処理部は、前記データ記憶部からの動画像データを伸張して、前記データ圧縮部での圧縮処理前に戻すデータ伸張部を含み、
前記データ記憶部は、所定ビット数を有し、その上位側ビットにより種類を識別できる複数種のパケットの記憶エリアを有し、
前記複数種のパケットの一つがゼロカウントデータパケットであり、
前記データ圧縮部は、画素配列上で連続するゼロデータの数をカウントし、連続するゼロデータを、ゼロデータのカウント値に圧縮処理し、前記ゼロデータのカウント値を前記ゼロカウントデータパケットの記憶エリアに格納し、
前記複数種のパケットの他の一つが圧縮データパケットであり、
前記データ圧縮部は、予め定められたビット数以下のビット数で表せる複数の動画像データを、同一の前記圧縮データパケットの記憶エリアに格納し、
前記複数種のパケットのさらに他の一つが非圧縮データパケットであり、
前記データ圧縮部は、予め定められたビット数を越えたビット数でしか表わすことができない動画像データを、前記非圧縮データパケットの記憶エリアに格納することを特徴とする画像表示装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ＭＰＥＧ（Motion Picture Coding Experts Group）等にて圧縮された動画像を伸張する伸張装置及びそれを用いた画像表示装置に関する。
【０００２】
【背景技術及び発明が解決しようとする課題】
従来のＭＰＥＧ４の圧縮（エンコード）／伸張（デコード）装置は、一連のエンコード／デコード処理を全てハードウェアまたは全てソフトウェアにより実施していた。
【０００３】
エンコード／デコードの全処理をハードウェアにて実施した場合、回路規模が必然的に大きくなり、ＩＣの小型化を阻害する。特に携帯電話機などの携帯機器では、機器の小型化への要請に応えられない。
【０００４】
一方、エンコード／デコードの全処理をソフトウェアにて実施した場合、ＣＰＵの負荷が増大してしまう。このため、ＣＰＵが他の処理に費やす時間に制約が生じ、機器が有するパフォーマンスを実現できなくなってしまう。また、ＣＰＵの稼動時間が増大するので消費電力も大きくなる。特に携帯電話機などの携帯機器では、バッテリーの消耗を抑えるための低消費電力化への要請に応えられない。
【０００５】
そこで、本発明の目的は、圧縮動画像の伸張処理を、ハードウェアとソフトウェアにてシェアし、しかも、ハードウェアとソフトウェアとの優位性を発揮できる処理別に役割分担させた圧縮動画像の伸張装置及びそれを用いた画像表示装置を提供することにある。
【０００６】
本発明の他の目的は、圧縮動画像の伸張処理を、ハードウェアとソフトウェアにて並列処理することができ、その際に必要なバッファ容量を低減することができる圧縮動画像の伸張装置及びそれを用いた画像表示装置を提供することにある。
【０００７】
【課題を解決するための手段】
本発明の一態様に係る圧縮動画像の伸張装置は、圧縮された動画像データをソフトウェアにて伸張処理するソフトウェア処理部と、前記ソフトウェア処理部にて処理された動画像データを格納するデータ記憶部と、前記データ記憶部からの動画像データをハードウェアにて伸張処理するハードウェア処理部とを有し、前記ソフトウェア処理部は、可変長符号化された圧縮動画像データの可変長符号を復号する処理を少なくとも実施し、かつ、前記ハードウェア処理部は、前記ソフトウェア処理部にて処理された動画像データの逆量子化及びそれ以降の処理を実施する複数の処理部を少なくとも含むことを特徴とする。
【０００８】
逆量子化される前の動画像データは、ゼロデータが圧倒的に多く、逆量子化された後のデータと比較すればデータの情報量の種類が圧倒的に少ない。しかも、可変長符号の復号処理の演算自体の負荷も少ない。よって、情報量が少なく演算負荷の軽い処理をソフトウェア処理部で処理しても、その処理の負荷は小さい。逆に、逆量子化以降の複数の処理の多くは、情報量が多い上に演算も複雑で、ソフトウェアで処理するには負荷が大きい。これらは負荷が重い処理ではあるが企画が決まっているため変更の必要性は乏しく、また、繰り返し処理が多いため、ハードウェア処理部での処理に適している。また、ソフトウェア処理部で処理されるデータ量が少ないので、ソフトウェア処理部からハードウェア処理部に伝送されるデータが少なく、伝送負荷も軽くなる。また、ソフトウェア処理部とハードウェア処理部との間には、バッファとして機能するデータ記憶部が介在するので、ソフトウェア処理とハードウェア処理とを並列的に処理することができる。さらに、ソフトウェア処理とハードウェア処理とを使い分けることで、装置の小型化と消費電力の低減の双方を実現できる。
【０００９】
本発明の一態様においては、前記ソフトウェア処理部は、前記データ記憶部に記憶される動画像データを圧縮するデータ圧縮部を含むことができる。一方、前記ハードウェア処理部は、前記データ記憶部からの動画像データを伸張するデータ伸張部を含むことができる。こうすると、データ記憶部の容量を小さくでき、装置を小型化できる。
【００１０】
本発明の一態様においては、前記データ圧縮部は、画素配列上で連続するゼロデータの数をカウントし、連続するゼロデータを、ゼロデータのカウント値に圧縮処理することができる。逆量子化前の動画像データは、特に高周波の交流成分にゼロデータが多く、効率よく圧縮できる。
【００１１】
本発明の一態様においては、前記データ記憶部は、所定ビット数を有し、その上位側ビットにより種類を識別できる複数種のパケットを有することができる。データ圧縮部は、この複数種のパケットを、圧縮・非圧縮の種類ごとに使い分ける。
【００１２】
この複数種のパケットの一つを、ゼロカウントデータパケットとすることができる。データ圧縮部は、上述したゼロデータのカウント値がゼロカウントデータパケットに格納する。
【００１３】
複数種のパケットの他の一つを、圧縮データパケットとすることができる。データ圧縮部は、予め定められたビット数以下のビット数で表せる複数の動画像データを、同一の前記圧縮データパケットに格納することで、データ圧縮するができる。
【００１４】
複数種のパケットのさらに他の一つを、非圧縮データパケットとすることができる。データ圧縮部は、予め定められたビット数を越えたビット数でしか表わすことができない動画像データを、非圧縮データパケットに格納する。逆量子化前の動画像データのうち、非圧縮データパケットに格納される動画像データは比較的少ないので、圧縮度が低下することはほとんどない。
【００１５】
本発明の一態様においては、前記データ記憶部は、少なくとも１フレーム分の動画像データを記憶する記憶領域を有することができる。なお、ソフトウェア処理部に入力される圧縮された動画像データは、８画素×８画素の１ブロック単位で離散コサイン変換されている。このため、前記１フレーム分の記憶領域には、前記１ブロックに対応する記憶領域毎に前記複数種のパケットが格納される。
【００１６】
本発明の一態様においては、前記１ブロックに対応する記憶領域には、前記ソフトウェア処理部にて生成されたコントロールデータを記憶するコントロールデータパケットをさらに設けることができる。これらのコントロールデータは、ハードウェア処理部での伸張処理に用いられる。
【００１７】
本発明の一態様においては、前記データ記憶部には、前記ハードウェア処理部にて伸張された少なくとも１フレーム分の動画像を記憶する表示用記憶領域をさらに設けることができる。好ましくは、少なくとも２フレーム分の表示用記憶領域を設けることができ、この場合動画像をより円滑に表示することができる。
【００１８】
本発明の一態様においては、前記ソフトウェア処理部は、前記可変長符号の復号処理に続いて実施される逆スキャン処理をさらに実施しても良い。加えて、前記ソフトウェア処理部は、前記逆スキャン処理に続いて実施される逆ＡＣＤＣ（交流・直流成分）予測を実施しても良い。
【００１９】
本発明の他の態様に係る画像表示装置は、ホストＣＰＵと、前記ホストＣＰＵに接続され、圧縮された動画像データをソフトウェアにて伸張処理するソフトウェア処理部を有する第１の集積回路と、前記ホストＣＰＵに接続され、表示制御を行う第２の集積回路と、前記第２の集積回路により表示制御される画像表示部とを有する。前記第２の集積回路は、前記ソフトウェア処理部にて処理された動画像データを格納するデータ記憶部と、前記データ記憶部からの動画像データをハードウェアにて伸張処理するハードウェア処理部とを有する。前記ソフトウェア処理部は、可変長符号化された圧縮動画像データの可変長符号を復号する処理を少なくとも実施する。前記ハードウェア処理部は、前記ソフトウェア処理部にて伸張処理された動画像データの逆量子化及びそれ以降の処理を実施する複数の処理部を少なくとも含む。
【００２０】
このように、上述した伸張装置を画像表示装置に搭載することで、伸張装置の作用・効果に加えて、ホストＣＰＵが第１，第２の集積回路間でデータ伝送する情報量が少ないので、ホストＣＰＵがデータ伝送に専有される時間を短縮できる。
【００２１】
【発明の実施の形態】
以下、本発明の一実施形態について、図面を参照して説明する。
【００２２】
（携帯電話機の概要）
図１は、本発明が適用される電子機器の一例である携帯電話機のブロック図である。図１において、この携帯電話機１０は、通信機能部２０と付加機能部３０とに大別される。通信機能部２０は、アンテナ２１にて送受信される信号（圧縮動画像を含む）を処理する公知の各種ブロックを有する。通信機能部２０の全ブロックの説明は省略するが、ベースバンドＬＳＩ（第１の集積回路）２２は、主として音声などを処理するプロセッサであり、携帯電話１０には必ず搭載されている。このベースバンドＬＳＩ２２には、ベースバンドエンジン（ＢＢＥ）やアプリーションプロセッサ等が搭載されている。これらのプロセッサ上のソフトウェアにより、図２（Ａ）に示すＭＰＥＧ４の圧縮（エンコード）処理のうち、可変長符号（ＶＬＣ：Variable Length Code）への符号化（Encode）、スキャン（Scan）、AＣＤＣ（交流・直流成分）予測及びレートコントロール（Rate Control）が実施されるようになっている。さらに、ベースバンドＬＳＩ２２に搭載されたプロセッサ上のソフトウェアにより、図２（Ｂ）に示すＭＰＥＧ４の伸張（デコード）処理のうち、可変長符号（ＶＬＣ）の復号（Decode）、逆スキャン（Reverse Scan）及び逆ＡＣＤＣ（交流・直流成分）予測が実施されるようになっている。ＭＰＥＧ４のデコード及びエンコードの他の処理については、付加機能部３０に設けられたハードウェアにて実施される。
【００２３】
付加機能部３０は、通信機能部２０のベースバンドＬＳＩ２１に接続されたホストＣＰＵ（中央演算ユニット）３１を有する。このホストＣＰＵ３１にはＬＣＤコントローラＬＳＩ（第２の集積回路）３２が接続されている。このＬＣＤコントローラＬＳＩ３２には、画像表示部としての液晶表示装置（ＬＣＤ）３３と、撮像部としてのＣＣＤカメラ３４とが接続されている。ＭＰＥＧ４のデコード及びエンコードのうちのハードウェア処理については、ＬＣＤコントローラＬＳＩ３２に設けられたハードウェアにて実施される。
【００２４】
（ＭＰＥＧ４のエンコード及びデコード）
ここで、図２（Ａ）及び図２（Ｂ）に示すＭＰＥＧ４のエンコード及びデコードの各処理について簡単に説明する。この処理の詳細については、例えば日本実業出版社の「JPEG&MPEG  図解でわかる画像圧縮技術」（越智宏、黒田英夫の共著）に説明されているので、本発明に関する処理についてのみ主として説明する。
【００２５】
図２（Ａ）に示す圧縮（エンコード）処理では、まず、連続する２枚の画像間の動き検出（ＭＥ：Motion Estimation）が実施される(ステップ１)。具体的には２枚の画像間の同一画素同士の差分を求める。２枚の画像での静止画領域では差分が０になるので、情報量を少なくでき、この静止画領域のゼロデータに加え、動画領域の差分（プラス・マイナス成分）が動き検出後の情報となる。
【００２６】
次に、離散コサイン変換（ＤＣＴ：Discrete Cosine Transform）が実施される（ステップ２）。この離散コサイン変換（ＤＣＴ）は、図３に示す８画素×８画素の１ブロック単位にて演算され、１ブロック毎にＤＣＴ係数を求めるものである。離散コサイン変換後のＤＣＴ係数は、１ブロック内の画像の濃淡変化を、全体の明るさ（ＤＣ成分）と空間周波数（ＡＣ成分）とで表わしたものである。図４は、８×８画素の１ブロック内のＤＣＴ係数の一例を示している（上述の図書の第１１６頁の図５−６を引用）。その左上隅のＤＣＴ係数がＤＣ成分を示し、それ以外のＤＣＴ係数がＡＣ成分を示す。なお、ＡＣ成分のうち、高周波成分を省略しても画像認識への影響が少ない。
【００２７】
次に、ＤＣＴ係数の量子化が行われる（ステップ３）。この量子化は、１ブロック内の各ＤＣＴ係数を、量子化テーブル中の対応する位置の量子化ステップ値で除算して、情報量を少なくするために実施される。例えば、図４のＤＣＴ係数を図５の量子化テーブルを用いて量子化した１ブロック内のＤＣＴ係数を図６に示す（上述の図書の第１１７頁の図５−９及び図５−１０を引用）。図６に示す通り、特に、高周波成分のＤＣＴ係数を量子化ステップ値で除算し、その小数点以下を四捨五入すると、ほとんどがゼロデータとなり、情報量が大幅に減少している。
【００２８】
このエンコード処理には、処理フレームと次フレームとの間で上述の動き検出（ＭＥ）を実施するために、帰還ルートが必要となる。この帰還ルートでは、図２（Ａ）に示すように、逆量子化（ｉＱ）、逆ＤＣＴ及び動き補償（ＭＣ：Motion Compensation）が実施される（ステップ４〜６）。なお、動き補償の詳細な動作については省略するが、この処理は図３に示す１６画素×１６画素の１マクロブロック単位で実施される。
【００２９】
上述したステップ１〜６の処理は、本実施形態のＬＣＤコントローラＬＳＩ３２に設けられたハードウェアにて実施される。
【００３０】
次に、図１のベースバンドＬＳＩ２２に搭載されたプロセッサ上のソフトウェアにより実施されるAＣＤＣ（交流・直流成分）予測、スキャン（Scan）、可変長符号（ＶＬＣ：Variable Length Code）への符号化（Encode）及びレートコントロール（Rate Control）について説明する。
【００３１】
図２（Ａ）のステップ７で実施されるAＣＤＣ（交流・直流成分）予測及びステップ８で実施されるスキャンは、共にステップ９の可変長符号の符号化に必要な処理である。なぜなら、ステップ９の可変長符号への符号化は、ＤＣ成分については隣接ブロック間での差分を符号化し、ＡＣ成分についてはブロック内を周波数が低い側から高い側に向けてスキャン（ジグザグスキャンとも称する）して符号化の順序を決める必要があるからである。
【００３２】
ステップ９の可変長符号への符号化とは、エントロピー符号化とも称され、符号化原理として、出現頻度の多いものは少ない符号で表すように符号化するものである。ステップ７，８での結果を利用して、ＤＣ成分について隣接ブロック間での差分を符号化し、ＡＣ成分についてはスキャンされた順番で低周波側から高周波側から順にＤＣＴ係数値を符号化する。
【００３３】
ここで、画像信号は、その画像の複雑さや動きの激しさによって情報の発生量が変動する。この変動を吸収し、一定の伝送速度で伝送するには符号発生量の制御が必要であり、これがステップ１０のレートコントロールである。レートコントロールのために通常バッファメモリが設けられ、そのバッファメモリがオーバフローしないように蓄積情報量を監視し、情報発生量を抑えるようにする。具体的には、ステップ３での量子化特性を粗くして、ＤＣＴ係数値を表すビット数を減らしている。
【００３４】
図２（Ｂ）は圧縮された動画像の伸張（デコード）処理を示し、このデコード処理は図２（Ａ）のエンコード処理を逆順でかつ逆処理することで達成される。なお、図２（Ｂ）中の「ポストフィルタ」とは、ブロックノイズを消去するためのフィルタである。このデコード処理でも、ＶＬＣ復号化（ステップ１）、逆スキャン（ステップ２）及び逆ＡＣＤＣ予測（ステップ３）がソフトウェア処理され、逆量子化以降の処理がハードウェア処理される（ステップ４〜８）。
【００３５】
（ＬＣＤコントローラＬＳＩの構成及び動作）
図７は、図１に示すＬＣＤコントローラＬＳＩ３２の機能ブロック図である。なお、図７は圧縮動画像のデコード処理部に関係するハードウェアを示している。このＬＣＤコントローラＬＳＩ３２は、図２（Ｂ）のステップ４〜８を実施するハードウェア処理部４０及びデータ記憶部５０を有する。また、このＬＣＤコントローラＬＳＩ３２は、ホストインターフェース６０を介してホストＣＰＵ３１に接続される。ベースバンドＬＳＩ２２内にはソフトウェア処理部７０が設けられる。このソフトウェア処理部７０は、図２（Ｂ）のステップ１〜３を実施する。このソフトウェア処理部７０もまた、ホストＣＰＵ３１に接続されている。
【００３６】
まず、ソフトウェア処理部７０について説明する。このソフトウェア処理部７０は、ハードウェアとしてＣＰＵ７１と画像処理プログラム格納部７２とを有する。ＣＰＵ７１は、格納部７２に格納された画像処理プログラムに従って、図１のアンテナ２１から入力された圧縮動画像に対して、図２（Ｂ）に示すステップ１〜３を実施する。ＣＰＵ７１はさらに、図２（Ｂ）のステップ３の処理済データを圧縮するデータ圧縮部７１Ａとして機能する。圧縮されたデータは、ホストＣＰＵ３１、ホストインターフェース６０を介して、ＬＣＤコントローラ３２内のデータ記憶部５０（例えばＳＲＡＭなど）に設けられた圧縮データ用記憶領域５１に格納される。
【００３７】
一方、ＬＣＤコントローラ３２内に設けられたハードウェア処理部４０は、圧縮データ用記憶領域５１からの圧縮データを伸張するデータ伸張部４１を有する。このハードウェア処理部４０には、図２（Ｂ）のステップ４〜７の各処理を実施するための処理部４２〜４５が設けられている。ポストフィルタ４５にてブロックノイズが除去された動画像データは、データ記憶部５０内の表示用記憶領域５２内に格納される。色情報変換処理部４６は、表示用記憶領域５２内に格納された画像情報に基づいて、図２（Ｂ）のステップ８のＹＵＶ／ＲＧＢ変換を実施する。処理部４６の出力は、ＬＣＤインターフェース４７を介してＬＣＤ３３に供給され、表示駆動に供される。なお、表示用記憶領域５２は、少なくとも１フレーム分の動画像を記憶する容量を有する。表示用記憶領域５２は、好ましくは２フレーム分の動画像を記憶する容量を有し、動画像をより円滑に表示できるようにしても良い。
【００３８】
ここで、本実施形態において、図２（Ｂ）のステップ１〜３をソフトウェア処理し、ステップ４〜８をハードウェア処理する理由は下記の通りである。まず、図２（Ｂ）のステップ４の逆量子化の前であれば、図６に示すように各ブロック内にはゼロデータが圧倒的に多く、逆量子化された後のデータ（図４）と比較すればデータの情報量の種類が圧倒的に少ない。しかも、ステップ１〜３の演算自体の負荷も少ないので、ステップ１〜３をソフトウェアで処理しても、その処理の負荷は小さくなる。逆に、図２（Ｂ）のステップ４の逆量子化やステップ５の逆ＤＣＴなどは、情報量が多い上に演算も複雑で、ソフトウェアで処理するには負荷が大きい。これらの逆量子化、逆ＤＣＴ、動き補償などは、負荷が重い処理ではあるが規格が決まっているため変更の必要性は乏しく、また、繰り返し処理が多いため、ハードウェアでの処理に適している。また、上述した通りソフトウェアで処理される逆量子化前のデータ量が少ないので、ソフトウェア処理部７０からホストＣＰＵ３１を経由してハードウェア処理部４０に伝送されるデータ量が少なく、ホストＣＰＵ３１の負担も軽い。
【００３９】
次に、ソフトウェア処理部７０とハードウェア処理部４０との間に設けられた圧縮データ用記憶領域５１について説明する。ソフトウェア処理部７０での処理は、動画像の複雑さや動きの激しさによって情報量が変動し、その情報量に応じて処理時間が変動する。その一方で、ハードウェア処理部４０での処理時間の変動はほとんどない。このようなソフトウェア処理部７０とハードウェア処理部４０とを効率よく並列駆動するには、両者間にバッファとして機能する圧縮データ用記憶領域５１が必要となる。このバッファは少なくとも１フレーム分必要であるが、図８に示すように複数、例えば第１，第２のフレームメモリ５１Ａ，５１Ｂを設けても良い。このようにすると、ハードウェア処理部４０は、ソフトウェア処理部７０での処理時間に制約されることがほとんどない。
【００４０】
本実施形態では、圧縮データ用記憶領域５１に記憶されるデータは、図２（Ｂ）のステップ１〜３にてソフトウェア処理されたデータ（以下、ＱＦデータと称する）を図７のデータ圧縮部７１Ａにてさらに圧縮したものである。よって、ホストＣＰＵ３１を介してソフトウェア処理部７０より圧縮データ用記憶領域５１に伝送される情報量はさらに少なくなり、ホストＣＰＵ３１をデータ伝送のために専有する時間が短くて済む。
【００４１】
（ソフトウェア処理部でのデータ圧縮とハードウェア処理部でのデータ伸張）まず、図７のデータ圧縮部７１Ａでのデータ圧縮動作について説明する。図９は、図７に示す圧縮データ用記憶領域５１での１フレーム分の記憶領域を示す。この１フレーム分の記憶領域は、前後のフレームエンドパケット間に配置され、かつ、図３に示す１ブロック毎に分割されている。各ブロックは、コントロールデータパケット１，２と多数のＱＦデータパケットから構成される。コントロールデータパケット１，２は、図２（Ｂ）のステップ１〜３の処理にて生成されたコントロールデータであって、ハードウェア処理部４０でのデコード処理に必要なコントロールデータを記憶している。
【００４２】
データ圧縮されるのは、図２（Ｂ）のステップ１〜３にて処理されたＱＦデータであり、図９のＱＦデータパケットに圧縮して格納される。このＱＦデータパケットには、例えば、図１０（Ａ）〜図１０（Ｃ）に示すゼロカウントパケット、７ビット圧縮データパケット、非圧縮データパケットの３種類がある。
【００４３】
図９に示すフレームエンドパケット、コントロールデータパケット及びＱＦデータパケットはいずれも、例えば１６ビットのデータ長を有する。図１０（Ａ）に示すゼロカウントパケットは、上位４ビットにゼロカウントパケットを示す識別データ「１００１」が格納され、残りの１２ビットにゼロカウント値が格納される。図１０（Ｂ）に示す７ビット圧縮データは、上位１ビット欄に７ビット圧縮データを示す識別データ「０」が格納され、次の７ビット欄に７ビット圧縮データが格納される。続くビット欄（下位８ビット目）はディスカードビット（Discard Bit）の符号欄であり、下位７ビットに格納される７ビットデータが、有効な圧縮データであれば「０」が、ダミーデータであれば「１」が格納される。このように、ＱＦデータが７ビット以下であれば、一つの７ビット圧縮データパケットに２個のＱＦデータが格納されて圧縮される。図１０（Ｃ）に示す非圧縮データパケットは、上位４ビット欄に非圧縮データパケットを示す識別データ「１０００」が格納され、続く１２ビット欄に非圧縮データが格納される。なお、７ビットの圧縮データ及び１２ビットの非圧縮データの各最上位ビットには、プラスまたはマイナスの符号を意味するビットが割り当てられる。
【００４４】
より具体的には、各種ＱＦデータを各パケットに格納する状況が図１１に示されている。図１１は、図３に示す１ブロック内のＱＦデータを１６進法の３桁で示したもの（プラス、マイナスの符号は省略）を、図１０（Ａ）〜図１０（Ｃ）の３種類のデータパケットに圧縮した状況を示している（１ブロック内の上位２ラインのデータ圧縮のみ図示）。なお、図１１中のＡ〜Ｆは、１０〜１５の数値にそれぞれ対応する。例えば、３桁の１６進法の最大値ＦＦＦとは、１５×１６２＋１５×１６１×１５×１６０＝４０９５を意味する。
【００４５】
ここで、１ブロック内の先頭アドレスにある１６進法の「０２５」とは１０進法の「３７」に相当する。これは、２進法では「０１００１０１」と７ビットで表現できる（最上位ビットである符号ビットは０とした。以下、同様）。よって、このデータは７ビット圧縮データパケットの下位７ビット欄に格納される。次のアドレスにある１６進法の「００１」とは１０進法の「１」に相当する。これは、２進法では「００００００１」と７ビットで表現できる。よって、このデータは７ビット圧縮データパケットの上位側の７ビット欄に格納される。次のアドレス以降は「０００」のゼロデータが６個連続している。よって、ゼロカウントデータパケットの最下位３ビットに０の連続数「６」を２進法で示す「１１０」が格納される。２ライン目にある１６進法の「０２Ｆ」及び「００３」は１０進法の「４７」及び「３」に相当する。これらも２進法の７ビット以下で表せるので、図１１に示す通り７ビット圧縮データパケットに格納される。次のアドレスには「０００」が１個のみ存在するので、そのゼロカウント値がゼロカウトンデータパケットに格納される。次のアドレスにある１６進法の「ＦＦＣ」及び「ＦＦＦ」は１０進法の「４０９２」及び「４０９５」に相当する。これは２進法の７ビット以下のデータでは表せない。よって、「ＦＦＣ」及び「ＦＦＦ」は非圧縮データパケットに格納される。次のアドレス以降は「０００」のゼロデータが３個連続している。よって、ゼロカウントデータパケットの最下位２ビットに０の連続数「３」を２進法で示す「１１」が格納される。以下、同様にしてＱＦデータが圧縮される。
【００４６】
図１２は、上述のＱＦデータの圧縮処理手順を示すフローチャートである。ＱＦデータ＝０であれば、（ステップ１での判断がＹＥＳ）、ゼロカウント値を一つカウントアップする。（ステップ２）。そのＱＦデータが最初のデータであればステップ３での判断はＮＯとなり、次のＱＦデータに移行する（ステップ１７）。すなわち、ＱＦデータ＝０であれば、そのゼロデータの連続が終了するまでカウントアップを繰り返すため、圧縮データ用記憶領域（ＳＲＡＭ）５１への書き込みは保留される。なお、０であるＱＦデータの一つ前のＱＦデータが７ビット以下である時には（ステップ３がＹＥＳ）、後述するステップ１０にて前回に生成した７ビット以下の圧縮データが、前回のＳＲＡＭアドレスの記憶領域に格納される。
【００４７】
今回のＱＦデータが０でなければ（ステップ１の判断がＮＯ）、前回までのゼロカウント値が０であるか否かが判断される（ステップ５）。前回までのゼロカウント値が０でなければ（ステップ５での判断がＹＥＳ）、前回のＱＦデータ＝０であることを意味し、かつ、今回初めてゼロデータの連続が終了したことを意味する。よって、今回のＳＲＡＭアドレスにゼロカウントデータを格納する（ステップ６）。さらに、ゼロカウント値を０にリセットし、かつアドレス値を一つカウントアップする（ステップ７）。
【００４８】
次に、ステップ８にて、今回のＱＦデータが７ビット以下で表せるか否かを判断する。ステップ８での判断がＹＥＳであれば、さらに、前回のＱＦデータが７ビット以下で表せるか否かを判断する（ステップ９）。ステップ９での判断がＮＯであれば、ステップ１０にて、今回のＱＦデータの圧縮データ（７ビットデータ）を生成する。このとき、ステップ１１にてＳＲＡＭアドレスを一つカウントダウンさせておけば、その後のステップ１６にてアドレスを一つカウントアップしても、前回のアドレスが維持される。その後、次のＱＦデータに移行される（ステップ１７）。なお、今回生成した圧縮データの書き込みは保留される。このように、７ビット以下の圧縮データは、ステップ１０で生成されるが、その圧縮データの格納は上述したステップ４の他、後述するステップ１２またはステップ１５のタイミングまで保留される。
【００４９】
ステップ９での判断がＹＥＳであれば、前回のステップ１０にて生成した圧縮データが、今回のＳＲＡＭアドレスの記憶領域に格納される。その後、ステップ１６にてＳＲＡＭアドレスがカウントアップされ、次のＱＦデータに移行する（ステップ１７）。
【００５０】
ステップ８での判断がＮＯであれば、前回のＱＦデータが７ビット以下であるか否かが判断される（ステップ１３）。ステップ１３での判断がＮＯであれば、そのＱＦデータを非圧縮データとして、今回のＳＲＡＭアドレスの記憶領域に格納する（ステップ１４）。ステップ１３での判断がＹＥＳであれば、前回のＳＲＡＭアドレスに、ステップ１０にて前回に生成した圧縮データを格納する（ステップ１５）。これにより、図１１に示すゼロカウントデータ、７ビット圧縮データまたは非圧縮データの格納が実現される。
【００５１】
図１３は、図７に示すハードウェア処理部４０に設けられたデータ伸張部４１でのデータ伸張動作を示している。
【００５２】
まず、図７に示すデータ記憶部（ＳＲＡＭ）５０の圧縮データ用記憶領域５１よりデータを取り込み（ステップ１）、ＳＲＡＭからのデータが７ビット圧縮データであるか否かが判断される（ステップ２）。ステップ２での判断がＹＥＳであれば、その７ビット圧縮データに基づいてＱＦデータを再生する（ステップ３）。次にそのパケット内のディスカードビットが０であれば（ステップ４での判断がＹＥＳ）、同一パケット内にもう一つの有効データが存在することを意味する。この場合には、そのもう一つの有効データに基づいてＱＦデータを再生する（ステップ５）。ステップ４での判断がＮＯの時、またはステップ５での処理が終了した時、次のＳＲＡＭデータに移行する（ステップ１０）。
【００５３】
ステップ２での判断がＮＯであれば、ＳＲＡＭからのデータが非圧縮データであるか否かが判断される（ステップ６）。ステップ６での判断がＹＥＳであれば、その非圧縮データに基づいてＱＦデータを再生する（ステップ７）。
【００５４】
ステップ６での判断がＮＯであれば、ＳＲＡＭからのデータがゼロカウントデータであるか否かが判断される（ステップ８）。ステップ８での判断がＹＥＳであれば、そのゼロカウント値と等しい数のＱＦデータ（＝０）を再生する（ステップ９）。ステップ８での判断がＮＯの時、またはステップ９での処理が終了した時、次のＳＲＡＭデータに移行する（ステップ１０）。
【００５５】
図７のデータ伸張部４１にて再生されたＱＦデータと、ＳＲＡＭ５０からのコントロールデータとに基づいて、次段以降の処理部４２〜４７にて、図２（Ｂ）に示すステップ４〜８の各処理が実施され、ＭＰＥＧ４方式にて圧縮された動画像がデコードされる。
【００５６】
なお、本実施形態では、図１に示すＣＣＤカメラ３４からの動画像を圧縮処理するＭＰＥＧエンコーダについては説明を省略した。このＭＰＥＧエンコーダにおいては、図２（Ａ）に示すようにハードウェア処理とソフトウェア処理とに分け、かつ、両処理部間にバッファとして圧縮データ用記憶部を設けることで、上記の実施形態と同様の作用・効果を奏することができる。
【００５７】
なお、本発明は上述した実施形態に限定されるものではなく、本発明の要旨の範囲内で種々の変形実施が可能である。本発明が適用される電子機器は携帯電話機に限定されず、他の電子機器特に携帯機器に好適に適用できる。また、動画像の圧縮手法についてはＭＰＥＧ４方式に限定されず、可変長符号及び量子化等の処理を含む他の圧縮方式であっても良い。
【図面の簡単な説明】
【図１】  本発明が適用される電子機器の一例である携帯電話機の概略ブロック図である。
【図２】  図２（Ａ）はＭＰＥＧエンコーダでの処理手順を、図２（Ｂ）はＭＰＥＧデコーダでの処理手順をそれぞれ示すフローチャートである。
【図３】  ＭＰＥＧエンコーダ、デコーダでの処理単位である１ブロック及び１マクロブロックを示す図である。
【図４】  離散コサイン変換（ＤＣＴ）にて得られるＤＣＴ係数の一例を示す図である。
【図５】  量子化の際に用いられる量子化テーブルの一例を示す図である。
【図６】  図４のＤＣＴ係数を図５の量子化テーブル中の数値にて除算して得られる量子化されたＤＣＴ係数（ＱＦデータ）を示す図である。
【図７】  図１中の部材のうち、ＭＰＥＧデコーダに関する構成を説明するためのブロック図である。
【図８】  ソフトウェア処理部とハードウェア処理部との間に設けられるバッファの一例を説明するための図である。
【図９】  バッファに格納された１フレーム分の情報を説明するための図である。
【図１０】  図１０（Ａ）〜図１０（Ｃ）は、図９中のＱＦデータパケットの種類を説明するための図である。
【図１１】  １ブロック内のＱＦデータを各種データパケットに格納する動作を説明するための図である。
【図１２】  図７のソフトウェア処理部内に設けられたデータ圧縮部でのデータ圧縮手順を示すフローチャートである。
【図１３】  図７のハードウェア処理部内に設けられたデータ伸張部でのデータ伸張手順を示すフローチャートである。
【符号の説明】
１０  携帯電話機、  ２０  通信機能部、  ２１  アンテナ、  ２２  ベースバンドＬＳＩ（第１の集積回路）、  ３０  付加機能部、  ３１  ホストＣＰＵ、３２  ＬＣＤコントローラ（第２の集積回路）、  ３３  ＬＣＤ（画像表示部）、  ３４  ＣＣＤカメラ（撮像部）、  ４０  ハードウェア処理部、  ４１  データ伸張部、  ４２  逆量子化部、  ４３  逆ＤＣＴ処理部、  ４４  動き補償処理部、  ４５  ポストフィルタ、  ４６  色情報変換処理部、  ４７  ＬＣＤインターフェース、  ５０  データ記憶部、  ５１  圧縮データ用記憶領域、５１Ａ  第１のフレームメモリ、  ５１Ｂ  第２のフレームメモリ、  ５２  表示用記憶領域、  ６０  ホストインターフェース、  ７０  ソフトウェア処理部、  ７１  ＣＰＵ、  ７１Ａ  データ圧縮部、  ７２  画像処理プログラム格納部
【図１】
0003680845.tif 000002
【図２】
0003680845.tif 000003
【図３】
0003680845.tif 000004
【図４】
0003680845.tif 000005
【図５】
0003680845.tif 000006
【図６】
0003680845.tif 000007
【図７】
0003680845.tif 000008
【図８】
0003680845.tif 000009
【図９】
0003680845.tif 000010
【図１０】
0003680845.tif 000011
【図１１】
0003680845.tif 000012
【図１２】
0003680845.tif 000013
【図１３】
0003680845.tif 000014