(57)【要約】      （修正有）【課題】  マルティメディア処理を効率良く実行できるマルティメディア処理システム及びマルチメディア処理方法の提供。【解決手段】  マルチメディア処理システム２０は、ホストＣＰＵ３０とマルチメディア処理用のプログラム群が記憶されるホストメモリ４０と表示コントローラ５０を含む。ホストＣＰＵ３０は、ホストメモリ４０に記憶されるマルチメディア処理用のプログラム群の中からマルチメディア処理用プログラムをリードして表示コントローラ５０に送信する。表示コントローラ５０は、送信されたマルチメディア処理用プログラムがロードされるメモリ９０と、マルチメディア処理用プログラムに基づいてマルチメディア処理のうちソフトウェア処理に割り当てられたソフトウェア処理部分を実行する内蔵ＣＰＵ７０と、マルティメディア処理のうちハードウェア処理に割り当てられたハードウェア処理部分を実行するＨ／Ｗアクセラレータ８０を含む。【選択図】        図１
2006186911.tif 000002
【特許請求の範囲】
【請求項１】
動画データ、静止画データ又は音データについてのエンコード又はデコード処理であるマルチメディア処理を行うためのマルチメディア処理システムであって、
マルチメディア処理用のプログラム群が記憶されるホストメモリと、
ホスト処理を行うホストプロセッサと、
前記ホストプロセッサにより制御される表示コントローラとを含み、
前記ホストプロセッサは、
前記ホストメモリに記憶されるマルチメディア処理用のプログラム群の中からマルチメディア処理用プログラムをリードして、前記表示コントローラに送信し、
前記表示コントローラは、
前記ホストプロセッサとのインターフェース処理を行うホストインターフェースと、
前記ホストプロセッサから送信された前記マルチメディア処理用プログラムがロードされるメモリと、
ロードされた前記マルチメディア処理用プログラムに基づいて、前記マルチメディア処理のうちソフトウェア処理に割り当てられたソフトウェア処理部分を実行する内蔵プロセッサと、
前記マルティメディア処理のうちハードウェア処理に割り当てられたハードウェア処理部分を実行する第１のハードウェアアクセラレータとを含むことを特徴とするマルチメディア処理システム。
【請求項２】
請求項１において、
前記ホストプロセッサは、
前記マルチメディア処理用プログラムを送信して前記メモリにロードした後に、リセット解除を指示して前記内蔵プロセッサのリセット状態を解除し、前記内蔵プロセッサの前記リセット状態の解除後に、前記マルチメディア処理用プログラムの実行開始を前記内蔵プロセッサに指示することを特徴とするマルチメディア処理システム。
【請求項３】
請求項２において、
前記ホストプロセッサは、
前記マルチメディア処理用プログラムを送信して前記メモリにロードした後、前記内蔵プロセッサの前記リセット状態が解除される前に、前記マルチメディア処理用プログラムのロード領域のプロテクト処理を行うことを特徴とするマルチメディア処理システム。
【請求項４】
請求項１乃至３のいずれかにおいて、
前記ホストプロセッサは、
階層構造を有しマルティメディア処理の対象となるストリームデータについての多重化処理、分離化処理、上位レイヤーのヘッダ解析処理の少なくとも１つを含む前処理を行い、
前記内蔵プロセッサは、
前記ストリームデータの下位レイヤーのヘッダ解析処理を行うことを特徴とするマルティメディア処理システム。
【請求項５】
請求項４において、
前記ホストプロセッサは、
前記前処理により得られた情報を所与の情報領域に設定して、前記内蔵プロセッサに知らせることを特徴とするマルティメディア処理システム。
【請求項６】
請求項１乃至５のいずれかにおいて、
前記マルチメディア処理用プログラムは、動画データのエンコード処理のソフトウェア処理部分を実行するためのエンコード処理用プログラムであり、
前記第１のハードウェアアクセラレータは、
前記ハードウェア処理部分である離散コサイン変換、量子化、逆量子化、逆離散コサイン変換、動き補償、動き検出の処理を行い、
前記内蔵プロセッサは、
前記ソフトウェア処理部分である可変長符号への符号化処理を行うことを特徴とするマルチメディア処理システム。
【請求項７】
請求項６において、
前記第１のハードウェアアクセラレータは、
フレーム間符号化の場合にはスキャニング処理を行い、
前記内蔵プロセッサは、
フレーム内符号化の場合にはＤＣ予測、スキャニングの処理を行うことを特徴とするマルチメディア処理システム。
【請求項８】
請求項１乃至５、６、７のいずれかにおいて、
前記マルチメディア処理用プログラムは、動画データのエンコード処理のソフトウェア処理部分を実行するためのエンコード処理用プログラムであり、
前記第１のハードウェアアクセラレータは、
前記ホストプロセッサからエンコード処理の実行開始を指示された場合に、エンコードデータバッファに書き込まれた動画データに対して、エンコード処理のハードウェア処理部分を実行し、実行後の動画データをＦＩＦＯバッファに書き込み、
前記内蔵プロセッサは、
前記ホストプロセッサから前記エンコード処理用プログラムの実行開始を指示された場合に、前記ＦＩＦＯバッファに書き込まれた動画データに対して、前記エンコード処理用プログラムに基づきエンコード処理のソフトウェア処理部分を実行し、実行後の動画データをホスト用バッファに書き込むことを特徴とするマルチメディア処理システム。
【請求項９】
請求項１乃至５のいずれかにおいて、
前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、
前記内蔵プロセッサは、
前記デコード処理用プログラムに基づいて、ソフトウェア処理部分である可変長符号の復号化処理を行い、
前記第１のハードウェアアクセラレータは、
ハードウェア処理部分である逆量子化、逆離散コサイン変換、動き補償の処理を行うことを特徴とするマルチメディア処理システム。
【請求項１０】
請求項９において、
前記内蔵プロセッサは、
フレーム内符号化の場合には逆スキャニング、逆ＤＣ／ＡＣ予測の処理を行い、
前記第１のハードウェアアクセラレータは、
フレーム間符号化の場合には逆スキャニング処理を行うことを特徴とするマルチメディア処理システム。
【請求項１１】
請求項１乃至５、９、１０のいずれかにおいて、
前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、
前記内蔵プロセッサは、
前記ホストプロセッサから前記デコード処理用プログラムの実行開始を指示された場合に、ホスト用バッファに書き込まれた動画データに対して、前記デコード処理用プログラムに基づきデコード処理のソフトウェア処理部分を実行し、実行後の動画データをＦＩＦＯバッファに書き込み、
前記第１のハードウェアアクセラレータは、
前記ホストプロセッサから前記デコード処理の実行開始を指示された場合に、前記ＦＩＦＯバッファに書き込まれた動画データに対して、デコード処理のハードウェア処理部分を実行し、実行後の動画データをデコードデータバッファに書き込むことを特徴とするマルチメディア処理システム。
【請求項１２】
請求項１乃至５、９、１０、１１のいずれかにおいて、
前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、
前記ホストプロセッサは、
前記内蔵プロセッサによるデコード処理にエラーが発生した場合には、内蔵プロセッサに代わってデコード処理のソフトウェア処理部分を実行することを特徴とするマルティメディア処理システム。
【請求項１３】
請求項１乃至１２のいずれかにおいて、
前記表示コントローラは、
前記内蔵プロセッサに制御され、前記マルティメディア処理のソフトウェア処理部分の一部をアシストする第２のハードウェアアクセラレータを含むことを特徴とするマルチメディア処理システム。
【請求項１４】
動画データ、静止画データ又は音データについてのエンコード又はデコード処理であるマルチメディア処理を行うためのマルチメディア処理方法であって、
表示コントローラに実行させるためのマルチメディア処理用のプログラム群を、ホストプロセッサによりアクセスされるホストメモリに記憶し、
前記ホストメモリに記憶されるマルチメディア処理用のプログラム群の中からマルチメディア処理用プログラムをリードして、前記表示コントローラに送信し、
送信された前記マルチメディア処理用プログラムを、表示コントローラのメモリにロードし、
前記マルチメディア処理のうちソフトウェア処理に割り当てられたソフトウェア処理部分を、ロードされた前記マルチメディア処理用プログラムに基づき動作する表示コントローラの内蔵プロセッサにより実行し、
前記マルティメディア処理のうちハードウェア処理に割り当てられたハードウェア処理部分を、表示コントローラの第１のハードウェアアクセラレータにより実行することを特徴とするマルチメディア処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディア処理システム及びマルティメディア処理方法に関する。
【背景技術】
【０００２】
動画、静止画、音データなどのマルチメディア情報に対する符号化方式として、ＭＰＥＧ−４（Moving Picture Experts Group Phase 4）が規格化されている。近年の携帯電話機などの携帯型電子機器は、このＭＰＥＧ−４の規格に準拠したエンコード、デコード機能を有している。このような機能を持つことで、カメラ（ＣＣＤ）で撮った動画データをエンコードして他の携帯電話（サーバー）に送信したり、アンテナを介して他の携帯電話（サーバー）から受信した動画データをデコードして表示（ＬＣＤ）パネルに表示したりすることが可能になる。
【０００３】
さて、ＭＰＥＧ−４のエンコード、デコードなどのマルチメディア処理を行う場合、一連の処理の全てをハードウェア処理回路（ＡＳＩＣ）により実現する第１の手法が考えられる。
【０００４】
しかしながらこの第１の手法では、ハードウェア処理回路が大規模化し、携帯型電子機器の小型化、低消費電力化の要請に応えることができない。
【０００５】
一方、携帯電話機などの携帯型電子機器では、機器全体を制御したりベースバンドエンジン（通信処理）を実現するためのホストＣＰＵ（Central Processing Unit）が組み込まれている。従って、このホストＣＰＵを用いたソフトウェア処理によりＭＰＥＧ−４などのマルチメディア処理を実現する第２の手法も考えられる。
【０００６】
しかしながら、この第２の手法では、ホストＣＰＵの処理負荷が増加してしまい、ホストＣＰＵが他の処理に費やす時間に制約が生じ、ホストＣＰＵが組み込まれた電子機器のパフォーマンスを低下させてしまう。またホストＣＰＵの処理時間の増加を招き、消費電力が大きくなり、バッテリの消耗抑制のための低消費電力化への要請に応えることができない。
【０００７】
また、ホストＣＰＵとＤＳＰ（Digital Signal Processor）によりマルチメディア処理を実現する第３の手法も考えられる。具体的には、ＤＳＰの内蔵メモリ（フラッシュＲＯＭなどの不揮発性メモリ）に、動画（ＭＰＥＧ）、静止画（ＪＰＥＧ）、音（オーディオ、音声）データのエンコード、デコードを実行するための全てのマルティメディア処理用プログラム群を記憶しておく。そしてホストＣＰＵが、起動コマンドを送信することで、起動が指示されたマルティメディア処理用プログラムをＤＳＰが実行する。
【０００８】
しかしながら、この第３の手法では、複雑な一連のマルティメディア処理の全てをＤＳＰが実行する必要がある。従って、コーデックの種類が増えたり、ストリームデータの多重化・分離化などの付加的な処理が増えて行くにつれて、ＤＳＰにマルティメディア処理を特化させて実行させるというアーキテクチャの意味合いが薄れ、結果的に、ＤＳＰやシステムのパフォーマンスが低下する。また、年々複雑化するマルティメディア処理に対応するために、ＤＳＰのクロック周波数を上昇させる必要が生じ、消費電力の増加や発熱の問題を招く。また、この第３の手法では、一連のマルティメディア処理用プログラム群の全てをＤＳＰの内蔵メモリ（フラッシュＲＯＭ）に記憶する必要があり、メモリの容量が増加し、消費電力の増加、製品の高コスト化の問題を招く。
【非特許文献１】MPEG-4 Visual Part(勧告書ISO/IEC 14496-2:1999(E) Annex L)
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明は、以上のような技術的課題に鑑みてなされたものであり、その目的とするところは、マルティメディア処理を効率良く実行できるマルティメディア処理システム及びマルチメディア処理方法を提供することにある。
【課題を解決するための手段】
【００１０】
本発明は、動画データ、静止画データ又は音データについてのエンコード又はデコード処理であるマルチメディア処理を行うためのマルチメディア処理システムであって、マルチメディア処理用のプログラム群が記憶されるホストメモリと、ホスト処理を行うホストプロセッサと、前記ホストプロセッサにより制御される表示コントローラとを含み、前記ホストプロセッサは、前記ホストメモリに記憶されるマルチメディア処理用のプログラム群の中からマルチメディア処理用プログラムをリードして、前記表示コントローラに送信し、前記表示コントローラは、前記ホストプロセッサとのインターフェース処理を行うホストインターフェースと、前記ホストプロセッサから送信された前記マルチメディア処理用プログラムがロードされるメモリと、ロードされた前記マルチメディア処理用プログラムに基づいて、前記マルチメディア処理のうちソフトウェア処理に割り当てられたソフトウェア処理部分を実行する内蔵プロセッサと、前記マルティメディア処理のうちハードウェア処理に割り当てられたハードウェア処理部分を実行する第１のハードウェアアクセラレータとを含むマルチメディア処理システムに関係する。
【００１１】
本発明によれば、ホストプロセッサが、マルティメディア処理用プログラム群の中から選択したマルティメディア処理用プログラムをホストメモリから読み出して、表示コントローラに送信する。そしてこの送信されたマルチメディア処理用プログラムが表示コントローラのメモリにロードされる。すると、表示コントローラの内蔵プロセッサが、このロードされたマルティメディア処理用プログラムに基づいてマルチメディア処理のソフトウェア処理部分を実行し、第１のハードウェアアクセラレータが、マルティメディア処理のハードウェア処理部分を実行する。このようにすれば、マルティメディア処理を効率良く実行できる。また、全てのマルティメディア処理用プログラムを表示コントローラのメモリにロードしなくても済むようになり、表示コントローラのメモリの記憶容量を節約できる。また、マルティメディア処理が複雑化した場合にも、これに柔軟に対応できるようになる。
【００１２】
また本発明では、前記ホストプロセッサは、前記マルチメディア処理用プログラムを送信して前記メモリにロードした後に、リセット解除を指示して前記内蔵プロセッサのリセット状態を解除し、前記内蔵プロセッサの前記リセット状態の解除後に、前記マルチメディア処理用プログラムの実行開始を前記内蔵プロセッサに指示するようにしてもよい。
【００１３】
このようにすれば、必要な時にだけ内蔵プロセッサのリセット状態を解除してマルティメディア処理用プログラムを実行させることが可能となり、低消費電力化を実現できる。
【００１４】
また本発明では、前記ホストプロセッサは、前記マルチメディア処理用プログラムを送信して前記メモリにロードした後、前記内蔵プロセッサの前記リセット状態が解除される前に、前記マルチメディア処理用プログラムのロード領域のプロテクト処理を行うようにしてもよい。
【００１５】
このようにすれば、リセット状態が解除されて動作を開始した内蔵プロセッサや、ホストプロセッサにより、マルチメディア処理用プログラムのロード領域にデータが書き込まれてマルチメディア処理用プログラムが破壊されてしまう事態を防止できる。
【００１６】
また本発明では、前記ホストプロセッサは、階層構造を有しマルティメディア処理の対象となるストリームデータについての多重化処理、分離化処理、上位レイヤーのヘッダ解析処理の少なくとも１つを含む前処理を行い、前記内蔵プロセッサは、前記ストリームデータの下位レイヤーのヘッダ解析処理を行うようにしてもよい。
【００１７】
このようにすれば、上位レイヤーのデバイスにより処理されるのが効率的であると考えられる前処理（多重化処理、分離化処理、上位レイヤーのヘッダ解析処理等）については、ホストプロセッサにより実行される。一方、下位レイヤーのデバイスにより処理されるのが効率的であると考えられる下位レイヤーのヘッダ解析処理については、内蔵プロセッサにより実行されるようになる。このように役割分担すれば、ホストプロセッサの制御の元で、マルチメディア処理を効率化良く実行できる。
【００１８】
また本発明では、前記ホストプロセッサは、前記前処理により得られた情報を所与の情報領域に設定して、前記内蔵プロセッサに知らせるようにしてもよい。
【００１９】
このようにすれば、内蔵プロセッサは、情報領域に設定された情報に基づいて、適切なマルチメディア処理を実行できる。
【００２０】
また本発明では、前記マルチメディア処理用プログラムは、動画データのエンコード処理のソフトウェア処理部分を実行するためのエンコード処理用プログラムであり、前記第１のハードウェアアクセラレータは、前記ハードウェア処理部分である離散コサイン変換、量子化、逆量子化、逆離散コサイン変換、動き補償、動き検出の処理を行い、前記内蔵プロセッサは、前記ソフトウェア処理部分である可変長符号への符号化処理を行うようにしてもよい。
【００２１】
このようにすれば、処理負荷が重く、変更の可能性が低い離散コサイン変換、量子化等のハードウェア処理部分については、第１のハードウェアアクセラレータにより実行される。一方、処理負荷が比較的低く、フレキシブルなプログラミングが要求されるソフトウェア処理部分については、内蔵プロセッサにより実行される。このように役割分担することで、マルティメディア処理のエンコード処理を更に効率良く実行できる。
【００２２】
また本発明では、前記第１のハードウェアアクセラレータは、フレーム間符号化の場合にはスキャニング処理を行い、前記内蔵プロセッサは、フレーム内符号化の場合にはＤＣ予測、スキャニングの処理を行うようにしてもよい。
【００２３】
このようにすれば、符号化の種類に応じた最適な役割分担でマルティメディア処理のエンコード処理を実行できる。
【００２４】
また本発明では、前記マルチメディア処理用プログラムは、動画データのエンコード処理のソフトウェア処理部分を実行するためのエンコード処理用プログラムであり、前記第１のハードウェアアクセラレータは、前記ホストプロセッサからエンコード処理の実行開始を指示された場合に、エンコードデータバッファに書き込まれた動画データに対して、エンコード処理のハードウェア処理部分を実行し、実行後の動画データをＦＩＦＯバッファに書き込み、前記内蔵プロセッサは、前記ホストプロセッサから前記エンコード処理用プログラムの実行開始を指示された場合に、前記ＦＩＦＯバッファに書き込まれた動画データに対して、前記エンコード処理用プログラムに基づきエンコード処理のソフトウェア処理部分を実行し、実行後の動画データをホスト用バッファに書き込むようにしてもよい。
【００２５】
このようにＦＩＦＯバッファを利用すれば、ホストプロセッサの制御の元で、マルチメディア処理のエンコード処理をスムーズに効率良く実行できる。
【００２６】
また本発明では、前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、前記内蔵プロセッサは、前記デコード処理用プログラムに基づいて、ソフトウェア処理部分である可変長符号の復号化処理を行い、前記第１のハードウェアアクセラレータは、ハードウェア処理部分である逆量子化、逆離散コサイン変換、動き補償の処理を行うようにしてもよい。
【００２７】
このようにすれば、処理負荷が重く、変更の可能性が低い逆量子化、逆離散コサイン変換等のハードウェア処理部分については、第１のハードウェアアクセラレータにより実行される。一方、処理負荷が比較的低く、フレキシブルなプログラミングが要求されるソフトウェア処理部分については、内蔵プロセッサにより実行される。このように役割分担することで、マルティメディア処理のデコード処理を更に効率良く実行できる。
【００２８】
また本発明では、前記内蔵プロセッサは、フレーム内符号化の場合には逆スキャニング、逆ＤＣ／ＡＣ予測の処理を行い、前記第１のハードウェアアクセラレータは、フレーム間符号化の場合には逆スキャニング処理を行うようにしてもよい。
【００２９】
このようにすれば、符号化の種類に応じた最適な役割分担でマルティメディア処理のデコード処理を実行できる。
【００３０】
また本発明では、前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、前記内蔵プロセッサは、前記ホストプロセッサから前記デコード処理用プログラムの実行開始を指示された場合に、ホスト用バッファに書き込まれた動画データに対して、前記デコード処理用プログラムに基づきデコード処理のソフトウェア処理部分を実行し、実行後の動画データをＦＩＦＯバッファに書き込み、前記第１のハードウェアアクセラレータは、前記ホストプロセッサから前記デコード処理の実行開始を指示された場合に、前記ＦＩＦＯバッファに書き込まれた動画データに対して、デコード処理のハードウェア処理部分を実行し、実行後の動画データをデコードデータバッファに書き込むようにしてもよい。
【００３１】
このようにＦＩＦＯバッファを利用すれば、ホストプロセッサの制御の元で、マルチメディア処理のデコード処理をスムーズに効率良く実行できる。
【００３２】
また本発明では、前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、前記ホストプロセッサは、前記内蔵プロセッサによるデコード処理にエラーが発生した場合には、内蔵プロセッサに代わってデコード処理のソフトウェア処理部分を実行するようにしてもよい。
【００３３】
このようにすれば、デコードエラーが発生した場合にも、そのエラーを回復して、その後のハードウェア処理部分を適正に実行することが可能になる。
【００３４】
また本発明では、前記表示コントローラは、前記内蔵プロセッサに制御され、前記マルティメディア処理のソフトウェア処理部分の一部をアシストする第２のハードウェアアクセラレータを含むようにしてもよい。
【００３５】
また本発明は、動画データ、静止画データ又は音データについてのエンコード又はデコード処理であるマルチメディア処理を行うためのマルチメディア処理方法であって、表示コントローラに実行させるためのマルチメディア処理用のプログラム群を、ホストプロセッサによりアクセスされるホストメモリに記憶し、前記ホストメモリに記憶されるマルチメディア処理用のプログラム群の中からマルチメディア処理用プログラムをリードして、前記表示コントローラに送信し、送信された前記マルチメディア処理用プログラムを、表示コントローラのメモリにロードし、前記マルチメディア処理のうちソフトウェア処理に割り当てられたソフトウェア処理部分を、ロードされた前記マルチメディア処理用プログラムに基づき動作する表示コントローラの内蔵プロセッサにより実行し、前記マルティメディア処理のうちハードウェア処理に割り当てられたハードウェア処理部分を、表示コントローラの第１のハードウェアアクセラレータにより実行するマルチメディア処理方法に関係する。
【発明を実施するための最良の形態】
【００３６】
以下、本発明の実施形態について詳細に説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが本発明の解決手段として必須であるとは限らない。
【００３７】
１．構成
図１に、本実施形態のマルティメディア処理システムと、このマルチメディア処理システムを含む電子機器の構成例を示す。なおマルチメディア処理システム、電子機器、表示コントローラの構成は図１に限定されず、同図の構成要素の一部を省略したり他の構成要素を加えてもよい。
【００３８】
図１は、マルチメディア処理システム２０を含む電子機器が携帯電話機である場合の例である。図１の携帯電話機（広義には電子機器）は、アンテナ１０、変復調器１２、操作部１４、表示ドライバ１６、表示パネル１７、カメラ１８、マルチメディア処理システム２０を含む。マルティメディア処理システム２０は、ホストＣＰＵ３０（広義にはホストプロセッサ）、ホストメモリ４０、表示コントローラ５０を含む。
【００３９】
アンテナ１０を介して他の機器（携帯電話機、サーバー）から受信したデータ（動画データ、ＭＰＥＧストリーム）は、変復調器１２で復調されてホストＣＰＵ３０に供給される。一方、ホストＣＰＵ３０からのデータは、変復調器１２で変調されて、アンテナ１０を介して他の機器に送信される。
【００４０】
ユーザからの操作情報は、操作部１４（操作ボタン）を介して入力される。この操作情報に基づいて、ホストＣＰＵ３０の制御の元で、データの通信処理、データのエンコード・デコード処理、表示パネル１７への画像の表示処理、カメラ１８（カメラモジュール）の撮像処理などが行われる。
【００４１】
表示パネル１７は表示ドライバ１６によって駆動される。表示パネル１７は、複数の走査線、複数のデータ線、複数の画素を含む。表示ドライバ１７は、走査線を駆動（選択）する走査ドライバの機能と、画像データ（表示データ）に対応した電圧をデータ線に供給するデータドライバの機能を有する。表示コントローラ５０は表示ドライバ１６に接続され、表示ドライバ１６に画像データを供給する。なお表示パネル１７としては液晶表示パネル（ＬＣＤ）を採用できるが、これに限定されず、エレクトロルミネッセンス表示パネルやプラズマ表示パネルなどであってもよい。
【００４２】
カメラ１８はＣＣＤ（Charge-Coupled Device）を含む。そしてＣＣＤで撮像した画像のデータを、ＹＵＶフォーマットで表示コントローラ５０に供給する。
【００４３】
ホストＣＰＵ３０は、ホストメモリ４０にアクセスしてホスト処理を行う。具体的には、表示コントローラ５０を制御する処理や、機器全体を制御する処理や、ベースバンドエンジン（通信処理エンジン）としての処理などを行う。ホストメモリ４０には種々のプログラムが記憶される。ホストＣＰＵ３０は、ホストメモリ４０に記憶されたプログラムにより動作してソフトウェア処理を実現する。このホストメモリ４０は、フラッシュＲＯＭなどの不揮発性メモリやＲＡＭなどにより実現できる。
【００４４】
表示コントローラ５０は、表示ドライバ１６を制御する。この表示コントローラ５０は、ホストインターフェース６０、内蔵ＣＰＵ７０（広義には内蔵プロセッサ）、ハードウェアアクセラレータ８０、メモリ９０を含む。なお本明細書中及び図面では、「インターフェース」、「ハードウェア」、「ソフトウェア」を、適宜、「Ｉ／Ｆ」、「Ｈ／Ｗ」、「Ｓ／Ｗ」と略称する。
【００４５】
表示コントローラ５０（画像コントローラ）は、カメラ１８からの画像データ（動画、静止画データ）をエンコードし、エンコード後の画像データをホストＣＰＵ３０に送信する。ホストＣＰＵ３０は、エンコード後の画像データをファイルとして保存したり、変復調器１２、アンテナ１０を介して他の機器に送信する。
【００４６】
また表示コントローラ５０は、ホストＣＰＵ３０から受信した画像データ（符号化データ、圧縮データ）をデコードし、デコード後の画像データを表示ドライバ１６に供給して表示パネル１７に表示させる。また表示コントローラ５０は、カメラ１８により撮像された画像データを受け、表示ドライバ１６に供給して表示パネル１７に表示させることもできる。
【００４７】
ホストメモリ４０はマルティメディア処理用プログラム群を記憶する。ここでマルチメディア処理は、動画データ、静止画データ又は音（オーディオ、音声）データについてのエンコード（圧縮）又はデコード（伸長）処理である。またマルティメディア処理用プログラムは、動画（狭義にはＭＰＥＧ）エンコード用プログラム、動画デコード用プログラム、静止画（狭義にはＪＰＥＧ）エンコード用プログラム、静止画デコード用プログラム、音エンコード用プログラム、或いは音デコード用プログラムなどである。なお、エンコードプログラムとデコードプログラムを１つのセットにしたコーデック用プログラムをマルティメディア処理用プログラムとしてホストメモリ４０に記憶してもよい。
【００４８】
本実施形態ではホストＣＰＵ３０（広義にはホストプロセッサ、ホスト）が、ホストメモリ４０に記憶されるマルチメディア処理用のプログラム群の中から選択したマルチメディア処理用プログラムをリードして、表示コントローラ５０に送信する。そして送信されたマルチメディア処理用プログラムは、表示コントローラ５０のメモリ９０にロードされる。
【００４９】
具体的にはホストＣＰＵ３０は、動画のエンコードが必要である場合には、動画データのエンコード処理のソフトウェア処理部分を実行するためのエンコード処理用プログラムをホストメモリ４０からリードして、表示コントローラ５０に送信する。例えばカメラ１８で撮影された動画データ（元データ）を、ファイルとして保存したり、アンテナ１０を介して他の機器に送信する場合には、動画（ＭＰＥＧ）のエンコード処理用プログラムをホストメモリ４０からリードして、表示コントローラ５０に送信する。そしてエンコード対象となる動画データは、例えばカメラ１８から表示コントローラ５０に入力される。
【００５０】
またホストＣＰＵ３０は、動画のデコードが必要である場合には、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムをホストメモリ４０からリードして、表示コントローラ５０に送信する。例えばアンテナ１０を介して他の機器から受信した動画データ（符号化データ、圧縮データ）や、ファイルとして保存した動画データ（符号化データ、圧縮データ）を、表示パネル１７に表示する場合には、ホストＣＰＵ３０は、動画（ＭＰＥＧ）のデコード処理用プログラムをホストメモリ４０からリードして、表示コントローラ５０に送信する。またホストＣＰＵ３０は、デコード対象となる動画データ（元データ）を表示コントローラ５０に送信する。
【００５１】
このように本実施形態では、マルティメディア処理用プログラム群の中から、必要なマルティメディア処理用プログラムがホストＣＰＵ３０により選択されて、表示コントローラ５０のメモリ９０にロードされる。従って、メモリ９０（ＲＡＭ）の使用記憶容量を節約できるため、メモリ９０を小規模化でき、表示コントローラ５０の低コスト化を図れる。また、１度にロードするデータ量を少なくできるため、起動時や、ハングアップした場合の再起動時に、長時間を要してしまうという問題を防止できる。
【００５２】
表示コントローラ５０が含むホストＩ／Ｆ６０は、ホストＣＰＵ３０とのインターフェース処理を行う。具体的にはホストＩ／Ｆ６０は、ホストＣＰＵ３０との間でコマンド、データ、ステータスの送信や受信処理（ハンドシェーク処理）を行う。また表示コントローラ５０からホストＣＰＵ３０に対する割り込み信号の生成などを行う。なお、ホストＩ／Ｆ６０にデータのＤＭＡ（Direct Memory Access）転送機能を持たせてもよい。
【００５３】
表示コントローラ５０が含む内蔵ＣＰＵ７０（広義には内蔵プロセッサ）は、表示コントローラ５０の全体制御や各部の制御を行う。そして本実施形態では内蔵ＣＰＵ７０（ＲＩＳＣプロセッサ）が、メモリ９０にロードされたマルチメディア処理用プログラムに基づいて、マルチメディア処理のうちソフトウェア処理に割り当てられたソフトウェア処理部分を実行する。このソフトウェア処理部分は、マルチメディア処理用プログラムを読み込んだ内蔵ＣＰＵ７０によりその処理が実行される部分である。
【００５４】
より具体的には、ホストＣＰＵ３０は、内蔵ＣＰＵ７０にリセットを指示することで（リセットコマンドを送信することで）、内蔵ＣＰＵ７０をリセット状態に設定する。そしてホストＣＰＵ３０は、マルチメディア処理用プログラムを送信してメモリ９０にロードした後に、リセット解除を指示して（リセット解除コマンドを送信して）、内蔵ＣＰＵ７０のリセット状態を解除する。そしてホストＣＰＵ３０は、内蔵ＣＰＵ７０のリセット状態の解除後に、マルチメディア処理用プログラムの実行開始を内蔵ＣＰＵ７０に指示する（実行開始コマンドを送信する）。内蔵ＣＰＵ７０は、ホストＣＰＵ３０からリセット解除を指示されると、そのリセット状態が解除される。そしてリセット状態の解除後に、メモリ９０にロードされたマルチメディア処理用プログラムを実行する。
【００５５】
なお、内蔵ＣＰＵ７０は、リセット状態の解除後に、ホストＣＰＵ３０からのコマンド（マルチメディア処理開始コマンド）の受信をウェイトするコマンドウェイト状態に移行する。そして、このコマンドウェイト状態において、マルチメディア処理用プログラムの実行開始をホストＣＰＵ３０から指示された場合に（マルチメディア処理開始コマンドを受信した場合に）、内蔵ＣＰＵ７０はマルチメディア処理用プログラムを実行する。
【００５６】
またホストＣＰＵ３０は、マルチメディア処理用プログラムを送信してメモリ９０にロードした後、内蔵ＣＰＵ７０のリセット状態が解除される前に、マルチメディア処理用プログラムのロード領域（図２の９１）のプロテクト（ライトプロテクト）処理を行う。
【００５７】
更にホストＣＰＵ３０は、階層構造を有しマルティメディア処理の対象となるストリームデータ（ＭＰＥＧストリーム）についての多重化処理（ビデオ、オーディオの多重化、ビデオ、オーディオのパケット分割）、分離化処理（ビデオ、オーディオの分離）、上位レイヤーのヘッダ解析処理(ＶＯＳ、ＶＯ、ＶＯＬ、ＧＯＶヘッダの解析）の少なくとも１つを含む前処理（pre processing）を行う。そして、前処理により得られた情報（データ、パラメータ）を情報領域（図２の９９）に設定して、内蔵ＣＰＵ７０に知らせる。一方、内蔵ＣＰＵ７０は、ストリームデータ（ＭＰＥＧストリーム）の下位レイヤーのヘッダ解析処理（ＶＯＰヘッダの解析）を行う。また情報領域に設定された情報（データ、パラメータ）に基づいて、マルチメディア処理のソフトウェア処理部分を実行する。
【００５８】
表示コントローラ５０が含むＨ／Ｗアクセラレータ８０（第１のＨ／Ｗアクセラレータ）は、マルティメディア処理のうちハードウェア処理に割り当てられたハードウェア処理部分を実行する回路（ハードウェア処理回路）である。このハードウェア処理部分は、プロセッサではない専用の回路によりその処理が実行される部分である。
【００５９】
表示コントローラ５０が含むメモリ９０は、プログラムのロード領域やデータバッファ領域や内蔵ＣＰＵ７０のワーク領域として機能する。具体的には、ホストＣＰＵ３０によりホストメモリ４０からリードされたマルチメディア処理用プログラムが、メモリ９０のプログラムロード領域にロードされる。また、エンコードデータやデコードデータが、メモリ９０のバッファ領域（ＦＩＦＯ領域）によりバッファリングされる。また内蔵ＣＰＵ７０は、メモリ９０のワーク領域にテーブル等を展開して処理を行う。このメモリ９０はＲＡＭ（ＳＲＡＭ、ＤＲＡＭ）などにより実現できる。
【００６０】
図２に表示コントローラの詳細な構成例を示す。なお表示コントローラの構成は図２に限定されず、同図の構成要素の一部を省略したり他の構成要素を加えてもよい。
【００６１】
図２に示すようにメモリ９０には、プログラムロード領域９１、ＦＩＦＯバッファ９２（ＭＰＥＧ４ＦＩＦＯ）、デコードデータバッファ９３（ＭＰＥＧ４デコードバッファ）、エンコードデータバッファ９４（ＭＰＥＧ４エンコードバッファ）、表示バッファ９５、ホスト用バッファ９６（ハフマンＦＩＦＯ）、ワーク領域９７、テーブルアシスト用領域９８、情報領域９９が確保（マッピング）されている。なお、これらの領域やバッファは、物理的に同一のメモリで実現してもよいし、物理的に異なるメモリで実現してもよい。
【００６２】
メモリコントローラ１００は、メモリ９０のアクセス（リード、ライトアクセス）制御を行う。即ちメモリコントローラ１００は、ホストＩ／Ｆ６０、内蔵ＣＰＵ７０、Ｈ／Ｗアクセラレータ８０、ドライバＩ／Ｆ１１０、カメラＩ／Ｆ１２０からのアクセスを調停する。そしてメモリ９０のリードアドレスやライトアドレスを発生して、ライトポインタやリードポインタを制御し、メモリ９０からデータやプログラムをリードしたり、メモリ９０にデータやプログラムをライトする。例えばプログラムロード領域９１へのマルティメディア処理用プログラムのロードは、このメモリコントローラ１００により実現できる。
【００６３】
ドライバＩ／Ｆ１１０は、表示ドライバ１６とのインターフェース処理を行う。具体的には、表示ドライバ１６に画像データ（動画、静止画データ）を送信する処理や、表示ドライバ１６の各種制御信号を生成する処理などを行う。
【００６４】
カメラＩ／Ｆ１２０は、カメラ１８との間のインターフェース処理を行う。例えばカメラ１８は、撮像により得られた画像データを例えばＹＵＣフォーマットで出力すると共に、１フレームの区切りを指定する同期信号（ＶＳＹＮＣ等）を出力する。カメラＩ／Ｆ１２０は、この同期信号に基づいて、カメラ１８からの画像データを取り込む。
【００６５】
なお図２では、内蔵ＣＰＵ７０に対してＨ／Ｗアクセラレータ７２（第２のアクセラレータ）が接続されている。このＨ／Ｗアクセラレータ７２は、内蔵ＣＰＵ７０に制御され、マルティメディア処理のソフトウェア処理部分の一部をアシストする回路（ハードウェア処理回路）である。具体的にはＨ／Ｗアクセラレータ７２は、可変長符号（ＶＬＣ：Variable Length Code）への符号化処理や可変長符号の復号化処理の一部について内蔵ＣＰＵ７０をアシストする。例えばＨ／Ｗアクセラレータ７２は、可変長符号処理に必要なテーブルのインデックス番号の生成処理などを、内蔵ＣＰＵ７０に代わって実行する。この場合にＨ／Ｗアクセラレータ７２は、メモリ９０のテーブルアシスト用領域９８をワーク領域として使用する。
【００６６】
２．エンコード、デコード処理
次に本実施形態のＭＰＥＧ−４のエンコード、デコード処理を図３、図４を用いて説明する。
【００６７】
図３に示すエンコード処理では、入力された１ＶＯＰ（Video Object Plane）分の画像データ（１フレーム分の画像データ）が、マクロブロック（基本処理単位）に分割される。１つのマクロブロックは６つのブロックから構成される。そして各ブロックに対して離散コサイン変換（ＤＣＴ：Discrete Cosine Transform）の処理が実行される（ステップＳ１）。離散コサイン変換は、８画素×８画素の１ブロック単位で行われ、１ブロック毎にＤＣＴ係数を求めるものである。離散コサイン変換後のＤＣＴ係数は、１ブロック内の画像の濃淡変化を、全体の明るさ（ＤＣ成分）と空間周波数（ＡＣ成分）とで表わしたものになる。図５（Ａ）に、８画素×８画素の１ブロック内のＤＣＴ係数の一例を示す。図５（Ａ）の左上隅のＤＣＴ係数がＤＣ成分を示し、それ以外のＤＣＴ係数がＡＣ成分を示す。なお、ＡＣ成分のうち、高周波成分を省略しても画像認識への影響が少ない。
【００６８】
次に、ＤＣＴ係数の量子化の処理が行われる（ステップＳ２）。量子化は、１ブロック内の各ＤＣＴ係数を、量子化テーブル中の対応する位置の量子化ステップ値で除算して、情報量を少なくするために実施される。例えば、図５（Ａ）のＤＣＴ係数を図５（Ｂ）の量子化テーブルを用いて量子化した場合の１ブロック内のＤＣＴ係数を図５（Ｃ）に示す。図５（Ｃ）に示すように、高周波成分のＤＣＴ係数を量子化ステップ値で除算し、その小数点以下を四捨五入すると、ほとんどがゼロデータとなり、情報量が大幅に減少する。
【００６９】
図３に示すように、フレーム内符号化（Ｉピクチャ）の場合には、ＤＣ（直流）予測、スキャニング、可変長符号化（ＶＬＣ：Variable Length Code）の処理が行われる（ステップＳ８、Ｓ９、Ｓ１０）。ＤＣ予測（ステップＳ８）は、ブロックのＤＣ成分に対する予測値を決定する処理である。スキャニング（ステップＳ９）は、ブロック内を周波数が低い側から高い側に向けてスキャン（ジグザグスキャン）する処理である。可変長符号化（ステップＳ１０）は、エントロピー符号化とも称され、符号化原理として、出現頻度の多いものは少ない符号で表すように符号化する処理である。なおフレーム間符号化（Ｐピクチャ）の場合には、ＤＣ予測は不要であるため、スキャニング（ステップＳ７）だけが行われ、スキャニング後のデータに対して可変長符号化（ステップＳ１０）が行われる。
【００７０】
エンコード処理では、現在のフレームと次のフレームとの間で動き検出（ＭＥ：Motion Estimation）を実施するために、帰還ルートが必要となる。この帰還ルート（ローカルデコード処理）では、図３に示すように、逆量子化、逆ＤＣＴ及び動き補償（ＭＣ：Motion Compensation）の処理が実行される（ステップＳ３、Ｓ４、Ｓ５）。次に、得られた再構築フレーム（参照ＶＯＰ）に基づいて動き検出（ＭＥ）が実行されて、動きベクトルが検出される。そして、検出された動きベクトルに基づいて、予測フレーム（予測マクロブロック）が求められる。そして符号化対象となるフレームと予測フレームとの差分に対してＤＣＴ、量子化の処理が行われる（ステップＳ１、Ｓ２）。
【００７１】
図４のデコード処理は、図３のエンコード処理を、逆順で且つ逆処理することで実現される。即ち、まず、可変長符号（ＶＬＣ）の復号化処理が行われる（ステップＳ２１）。そしてフレーム内符号化（Ｉピクチャ）の場合には、逆スキャニング、逆ＤＣ／ＡＣ予測の処理が行われる（ステップＳ２２、Ｓ２３）。一方、フレーム間符号化（Ｐピクチャ）の場合には、逆ＤＣ／ＡＣ予測は行われず、逆スキャニングの処理だけが行われる（ステップＳ２４）。
【００７２】
次に、逆量子化、逆ＤＣＴの処理が行われる（ステップＳ２５、Ｓ２６）。そして過去のフレームのデータとＶＬＣ復号化後のデータとに基づき動き補償処理が行われ（ステップＳ２７）、逆ＤＣＴ後のデータとの加算処理が行われる。
【００７３】
図３に示すように本実施形態では、メモリ９０にロードされるマルティメディア処理用プログラムが動画のエンコード処理用プログラムである場合には、Ｈ／Ｗアクセラレータ８０は、ハードウェア処理部分であるＤＣＴ、量子化、逆量子化、逆ＤＣＴ、動き補償、動き検出の処理（ステップＳ１〜Ｓ６）を行う。また内蔵ＣＰＵ７０は、エンコード処理用プログラムに基づいて、ソフトウェア処理部分であるＶＬＣへの符号化処理（ステップＳ１０）を行う。更に具体的には、Ｈ／Ｗアクセラレータ８０は、フレーム間符号化（Ｐピクチャ）の場合にはスキャニング処理（ステップＳ７）を行う。また内蔵ＣＰＵ７０は、フレーム内符号化（Ｉピクチャ）の場合にはＤＣ予測（ＤＣ／ＡＣ予測）、スキャニングの処理を行う（ステップＳ８、Ｓ９）。
【００７４】
また図４に示すように本実施形態では、メモリ９０にロードされるマルティメディア処理用プログラムが動画のデコード処理用プログラムである場合には、内蔵ＣＰＵ７０は、デコード処理用プログラムに基づいて、ソフトウェア処理部分であるＶＬＣの復号化処理（ステップＳ２１）を行う。またＨ／Ｗアクセラレータ８０は、ハードウェア処理部分である逆量子化、逆ＤＣＴ、動き補償の処理（ステップＳ２５、Ｓ２６、Ｓ２７）を行う。更に具体的には、内蔵ＣＰＵ７０は、フレーム内符号化（Ｉピクチャ）の場合には逆スキャニング、逆ＤＣ／ＡＣ予測の処理（ステップＳ２２、Ｓ２３）を行う。またＨ／Ｗアクセラレータ８０は、フレーム間符号化（Ｐピクチャ）の場合には逆スキャニング処理を行う（ステップＳ２４）。
【００７５】
なお本実施形態では、内蔵ＣＰＵ７０のデコード処理にデコードエラーが発生した場合には、ホストＣＰＵ３０が、内蔵ＣＰＵ７０に代わってデコード処理のソフトウェア処理部分（ステップＳ２１〜Ｓ２３）を実行する。
【００７６】
本実施形態において、図３、図４に示すような役割分担でソフトウェア処理部分とハードウェア処理部分を実現している理由は、以下の通りである。
【００７７】
即ち、図３のステップＳ２の量子化後であれば、図５（Ｃ）に示すように各ブロック内にはゼロデータが圧倒的に多く、図５（Ａ）の量子化前のデータに比べてデータの情報量の種類が圧倒的に少ない。しかも、ステップＳ８〜Ｓ１０の処理は、演算自体の負荷も少ない。従って、これらのステップＳ８〜Ｓ１０の処理については、演算処理能力がそれほど高くない内蔵ＣＰＵ７０を用いたソフトウェア処理で実現しても問題ない。また内蔵ＣＰＵ７０を用いたソフトウェア処理は低速であるが、フレキシブルなプログラミング可能である。従って、マルティメディア処理に付随する処理部分であり、負荷は軽いがフレキシブルなプログラミングが要求される処理部分を補うのに適している。
【００７８】
一方、図３のステップＳ１〜Ｓ６のＤＣＴ、量子化、逆量子化、逆ＤＣＴ、動き補償、動き検出は、情報量が多く、処理負荷が大きいと共に、処理の高速性が要求されるため、ソフトウェア処理にはあまり適していない。更に、ステップＳ１〜Ｓ６の処理は、負荷は重いが、その処理内容が規格である程度決まっているため、将来的な変更の必要性も乏しい。従って、ステップＳ１〜１６の処理は、専用のハードウェア回路（Ｈ／Ｗアクセラレータ８０）を用いたハードウェア処理に向いている。またステップＳ１〜Ｓ６の処理は、繰り返し処理が多いため、この意味においてもハードウェア処理に向いている。またステップＳ２の量子化後のデータ量は少ないため、Ｈ／Ｗアクセラレータ８０（ハードウェア処理部）から内蔵ＣＰＵ７０（ソフトウェア処理部）に伝送されるデータの量も少なくなり、データ転送制御の負担も軽くなる。同様の理由で、本実施形態では図４のデコード処理においても、ステップＳ２１〜Ｓ２３を、内蔵ＣＰＵ７０を用いたソフトウェア処理で実現し、ステップＳ２４〜Ｓ２７を、Ｈ／Ｗアクセラレータ８０を用いたハードウェア処理で実現している。
【００７９】
また本実施形態では図３に示すように、フレーム内符号化（Ｉピクチャ）についてのスキャニング処理はソフトウェア処理で実現し、フレーム間符号化（Ｐピクチャ）についてのスキャニング処理はハードウェア処理で実現している。その理由は以下の通りである。
【００８０】
即ちフレーム内符号化の場合は、ステップＳ８のＤＣ予測をソフトウェア処理で行うため、ＤＣ予測に続くステップＳ９のスキャニング処理についてもソフトウェア処理で実現するのが効率的である。これに対して、フレーム間符号化の場合には、ＤＣ予測は不要であり、ステップＳ７のスキャニング処理をソフトウェア処理ではなくハードウェア処理で行っても問題はない。またステップＳ７のスキャニング処理は、比較的単純な処理であるため、ハードウェア処理に向いている。このような理由で本実施形態ではステップＳ７のスキャニング処理についてはハードウェア処理で実現し、ステップＳ９のスキャニング処理についてはソフトウェア処理で実現している。同様の理由で、本実施形態では図４のデコード処理においても、ステップＳ２２の逆スキャニング処理についてはソフトウェア処理で実現し、ステップＳ２４のスキャニング処理についてはハードウェア処理で実現している。
【００８１】
以上のように本実施形態では、内蔵ＣＰＵ７０とＨ／Ｗアクセラレータ８０によりバランス良く作業を分担することにより、クロック周波数をそれほど増加させることなく、低消費電力なシステムでマルティメディア処理を実現することに成功している。
【００８２】
３．ＦＩＦＯバッファ
本実施形態では、図２のＦＩＦＯ（First In First Out）バッファ９２、デコードデータバッファ９３、エンコードデータバッファ９４、ホスト用バッファ９６を、図６（Ａ）（Ｂ）のように利用して、エンコード処理、デコード処理を実現している。
【００８３】
例えばメモリ９０にロードされたマルチメディア処理用プログラムが動画のエンコード処理用プログラムである場合には、図６（Ａ）に示すように、カメラ１８で撮像された動画データ（１ＶＯＰ分の動画データ）はエンコードデータバッファ９４（ＭＰＥＧ４エンコードバッファ）に書き込まれる。そしてＨ／Ｗアクセラレータ８０は、ホストＣＰＵ３０からエンコード処理の実行開始を指示された場合に、エンコードデータバッファ９４に書き込まれた動画データに対して、エンコード処理のハードウェア処理部分を実行する。そして実行後の動画データ（Ｈ／Ｗエンコード後の動画データ）をＦＩＦＯバッファ９２に書き込む。
【００８４】
次に、内蔵ＣＰＵ７０は、ホストＣＰＵ３０から、メモリ９０にロードされたエンコード処理用プログラムの実行開始を指示された場合に、ＦＩＦＯバッファ９２に書き込まれた動画データ（１ＶＯＰ分の動画データ）に対して、エンコード処理用プログラムに基づきエンコード処理のソフトウェア処理部分を実行する。そして実行後の動画データ（Ｓ／Ｗエンコード後の動画データ）をホスト用バッファ９６（ハフマンＦＩＦＯ）に書き込む。
【００８５】
またメモリ９０にロードされたマルチメディア処理用プログラムが動画のデコード処理用プログラムである場合には、図６（Ｂ）に示すように、ホストＣＰＵ３０が、ホスト用バッファ９６に、デコード対象となる動画データ（１ＶＯＰ分の動画データ）を書き込む。そして内蔵ＣＰＵ７０は、ホストＣＰＵ３０からデコード処理用プログラムの実行開始を指示された場合に、ホスト用バッファ９６に書き込まれた動画データに対して、デコード処理用プログラムに基づきデコード処理のソフトウェア処理部分を実行する。そして実行後の動画データ（Ｓ／Ｗデコード後の動画データ）をＦＩＦＯバッファ９２に書き込む。
【００８６】
次に、Ｈ／Ｗアクセラレータ８０は、ホストＣＰＵ３０からデコード処理の実行開始を指示された場合に、ＦＩＦＯバッファ９２に書き込まれた動画データ（１ＶＯＰ分の動画データ）に対して、デコード処理のハードウェア処理部分を実行する。そして実行後の動画データ（Ｈ／Ｗデコード後の動画データ）をデコードデータバッファ９３に書き込む。そしてデコードデータバッファ９３に書き込まれた動画データは、表示ドライバ１６に転送され、表示パネル１７の動画表示が行われる。
【００８７】
図６（Ａ）（Ｂ）のように本実施形態では、内蔵ＣＰＵ７０とＨ／Ｗアクセラレータ８０の間にＦＩＦＯバッファ９２を介在させている。このようにすることで、ホストＣＰＵ３０の制御の元で、ソフトウェア処理部分とハードウェア処理部分を内蔵ＣＰＵ７０とＨ／Ｗアクセラレータ８０で効率良く分担して実行することが可能になる。
【００８８】
例えば図６（Ａ）のエンコード処理において、エンコード後の符号量が多い場合には、ビットレートを遵守するためのレートコントロールが必要になる。この場合に本実施形態では、ホストＣＰＵ３０がスキップフレームを作成することで、レートコントロールを実現する。具体的には、レートコントロールのために、例えば第Ｋのフレーム（第ＫのＶＯＰ）をスキップする場合には、ホストＣＰＵ３０は、この第Ｋのフレームの動画データについてのＨ／Ｗエンコード処理の開始指示（Ｈ／Ｗアクセラレータ８０に対する指示）を行わないようにする。これにより、Ｈ／Ｗエンコード処理後の第Ｋのフレームの動画データはＦＩＦＯバッファ９２には書き込まれないようになり、内蔵ＣＰＵ７０も、この第Ｋのフレームの動画データに対するＳ／Ｗエンコード処理を行わないようになる。
【００８９】
そしてホストＣＰＵ３０は、例えば次の第Ｋ＋１のフレーム（第Ｋ＋１のＶＯＰ）については、Ｈ／Ｗエンコード処理の開始指示をＨ／Ｗアクセラレータ８０に対して行う。これにより、Ｈ／Ｗエンコード処理後の第Ｋ＋１のフレームの動画データがＦＩＦＯバッファ９２に書き込まれ、内蔵ＣＰＵ７０は、この第Ｋ＋１のフレームの動画データに対するＳ／Ｗエンコード処理を行うことができる。この場合、ＦＩＦＯバッファ９２には、スキップされた第Ｋのフレームの動画データは書き込まれていない。従って、この第Ｋのフレームの動画データを廃棄したり無視したりする処理が不要になり、スムーズな処理を実現できる。
【００９０】
また図６（Ｂ）のデコード処理において、内蔵ＣＰＵ７０によるデコード処理にエラーが発生した場合に、本実施形態では、内蔵ＣＰＵ７０が、そのエラーの発生をホストＣＰＵ３０にレジスタ等を用いて通知する。そして、このように内蔵ＣＰＵ７０によるデコード処理にエラーが発生した場合には、ホストＣＰＵ３０が、内蔵ＣＰＵ７０に代わってデコード処理のソフトウェア処理部分を実行する。そしてホストＣＰＵ３０は、Ｓ／Ｗデコード処理後の動画データをＦＩＦＯバッファ９２に書き込む。これにより、Ｈ／Ｗアクセラレータ８０は、書き込まれた動画データに対してＨ／Ｗデコード処理を実行できるようになる。
【００９１】
デコード処理にエラーが発生した場合には、動画データ（ＶＯＰ）の解析を行う必要がある。しかしながら、ホストＣＰＵ３０からの動画データは、ＦＩＦＯであるホスト用バッファ９６に格納されているため、内蔵ＣＰＵ７０は、任意のアドレスにアクセスして動画データのエラー解析を行うことができない。一方、この動画データは、ホストＣＰＵ３０が送信したものであり、ホストＣＰＵ３０は、自身のメモリ内に記憶された動画データの任意のアドレスにアクセスしてエラー解析を行うことができる。これにより、内蔵ＣＰＵ７０のデコード処理にエラーが発生した場合にも、そのエラーを回復して、デコード処理を完結させることが可能になる。
【００９２】
４．スタートアップ時の動作
次に、本実施形態のスタートアップ（立ち上げ）時の動作について図７のシーケンス図を用いて説明する。
【００９３】
まずホストＣＰＵ３０が、内蔵ＣＰＵ７０によるアシスト処理の初期化設定を行う。そしてマルチメディア処理用プログラムをメモリ９０のプログラムロード領域９１にロードする。即ちホストメモリ４０に記憶されたマルティメディア処理用プログラム群の中から所望のマルチメディア処理用プログラム（デコード用プログラム、エンコード用プログラム）を選択して、メモリ９０にロードする。
【００９４】
次にホストＣＰＵ３０は、メモリ９０のプログラムロード領域９１のプロテクト処理を行う。このようにすることで、プログラムロード領域９１にロードされたマルチメディア処理用プログラムを保護することが可能になる。即ち、このようなプロテクト処理を行わないと、ホストＣＰＵ３０や内蔵ＣＰＵ７０が、データ等を間違ってプログラムロード領域９１に書き込んでしまう事態が生じ得る。このような事態が生じると、ロードされたプログラムが破壊され、システムがハングアップするなどの問題を招く。プログラムロード領域９１のプロテクト処理を行うことで、このような問題の発生を未然に防止できる。
【００９５】
次にホストＣＰＵ３０は、アシスト機能のイネーブルコマンド、クロックのイネーブルコマンド、リセット解除コマンドを送信し、スタートアップ完了ステータスの受信ウェイト状態に移行する。
【００９６】
内蔵ＣＰＵ７０は、リセット解除コマンドを受信すると、そのリセット状態を解除し、ブート処理などの初期化設定を行う。またメモリ９０のワーク領域９７の初期化（０クリア）を行う。そして内蔵ＣＰＵ７０は、スタートアップが完了すると、スタートアップ完了ステータスをホストＣＰＵ３０に送信し、ＡＣＫの受信ウェイト状態に移行する。するとホストＣＰＵ３０は、ＡＣＫを送信し、内蔵ＣＰＵ７０は、ＡＣＫを受信すると、デコード、エンコード開始コマンドのウェイト状態に移行する。
【００９７】
図７に示すように本実施形態では、ホストＣＰＵ３０からリセット解除コマンドを受信するまで、内蔵ＣＰＵ７０はリセット状態に設定される。そしてリセット解除コマンドを受信すると、内蔵ＣＰＵ７０のリセット状態が解除されて、マルティメディア処理用プログラムが実行される。そしてその後にホストＣＰＵ３０からリセットコマンドを受信すると、内蔵ＣＰＵ７０は再度リセット状態に設定される。このように本実施形態では、マルティメディア処理用プログラムを実行する時に、その都度、内蔵ＣＰＵ７０のリセット状態が解除され、それ以外の期間では、内蔵ＣＰＵ７０をリセット状態に設定できる。従って、動作する必要が無い期間において内蔵ＣＰＵ７０の動作を停止でき、省電力化を実現できる。なお図７では、ホストＣＰＵ３０によるリセット解除指示によりマルティメディア処理用プログラムが実行される方式を採用しているが、ホストＣＰＵ３０からの割り込みによりマルティメディア処理用プログラムが実行される方式を採用してもよい。
【００９８】
５．デコード処理時の動作
次に、本実施形態のデコード処理時の動作について図８のフローチャート及び図９のシーケンス図を用いて説明する。図８は主にホストＣＰＵ３０の動作・処理を説明するフローチャートである。
【００９９】
図８に示すように、ホストＣＰＵ３０は、エンコードデータバッファ９４へのデータ（カメラ１８からの動画データ）のライトが完了したか否かを判断する（ステップＳ３１）。そしてデータのライトが完了すると、データのライト完了フラグをクリアし（ステップＳ３２）、動き検出（ＭＥ）処理の開始を指示する（ステップＳ３３）。そして動き検出が完了したと判断すると、動き検出完了フラグをクリアする（ステップＳ３４、Ｓ３５）。
【０１００】
次に、ホストＣＰＵ３０は、レートコントロール処理を行う（ステップＳ３６）。即ち符号化データサイズに基づいて、量子化処理（図３のステップＳ２）の量子化ステップを変化させる。例えば符号化データサイズが大きい場合には、量子化ステップを大きくする。これにより量子化後のＤＣＴ係数（図５（Ｃ））のゼロデータの数が増える。一方、符号化データサイズが小さい場合には、量子化ステップを小さくする。これにより量子化後のＤＣＴ係数のゼロデータの数が減る。
【０１０１】
次に、ホストＣＰＵ３０は、ＱＰ値（量子化パラメータ）を設定して、Ｈ／Ｗエンコード処理の開始を指示する（ステップＳ３７）。これにより、Ｈ／Ｗアクセラレータ８０によるＨ／Ｗエンコード処理が実行される。そしてＨ／Ｗエンコード処理が終了したと判断すると、内蔵ＣＰＵ７０によるＳ／Ｗエンコード処理の開始を指示する（ステップＳ３８、Ｓ３９）。そして、エンコードストップか否かを判断し、エンコードストップではない場合にはステップＳ３１に戻り、エンコードストップの場合（所定フレーム数のエンコードが完了した場合）には処理を終了する（ステップＳ４０）。
【０１０２】
次に、図９のシーケンス図を説明する。まず、ホストＣＰＵ３０は、ＱＰ値を設定して、Ｈ／Ｗアクセラレータ８０によるＨ／Ｗエンコード処理の開始を指示し、エンコードの完了をウェイトする。そしてＨ／Ｗエンコード処理が完了すると、必要があればＧＯＶ（Group Of VOP）ヘッダを作成する。またＶＯＰ（Video Object Plane）ヘッダを作成して、メモリ９０の情報領域９９に、エンコードに必要な種々の情報を設定する。
【０１０３】
図１０（Ａ）に、エンコード処理時に情報領域９９に設定される情報の例を示す。内蔵ＣＰＵ７０等は、図１０（Ａ）に示す情報をホストＣＰＵ３０から知らされることで、適切なエンコード処理を実現できる。
【０１０４】
次に、ホストＣＰＵ３０は、Ｓ／Ｗエンコード処理の開始コマンドを送信し、ＡＣＫの受信ウェイト状態に移行する。そして内蔵ＣＰＵ７０がＡＣＫを送信すると、ホストＣＰＵ３０がそのＡＣＫを受信する。そして内蔵ＣＰＵ７０は、Ｓ／Ｗエンコード処理を開始し、処理後のデータ（動画データ）をホスト用バッファ９６（ＦＩＦＯ）にライトする。そして１ＶＯＰ分（広義には１フレーム分）のエンコード処理が終了したら、ｌａｓｔｅｎｃ＝１に設定する。
【０１０５】
ホストＣＰＵ３０は、ホスト用バッファ９６（ＦＩＦＯ）をリードする。即ちｌａｓｔｅｎｃ＝１になるまでホスト用バッファ９６からデータ（ハフマンデータ）をリードする。そして、バイトアライメントのためのＶＯＰのスタッフィングを行う。なおレートコントロールによるスキップフレーム（ＶＯＰ）の作成はホストＣＰＵ３０が行う。
【０１０６】
６．エンコード処理時の動作
次に、本実施形態のエンコード処理時の動作について図１１のフローチャート及び図１２のシーケンス図を用いて説明する。図１１は主にホストＣＰＵ３０の動作・処理を説明するフローチャートである。
【０１０７】
図１１に示すように、ホストＣＰＵ３０は、ＶＯＳ（Video Object Sequence）ヘッダ、ＶＯ（Video Object）ヘッダ、ＶＯＬ（Video Object Layer）ヘッダの解析を行う（ステップＳ５１、Ｓ５２、Ｓ５３）。またスタートコードの検出を行い（ステップＳ５４）、ＧＯＶヘッダがある場合にはＧＯＶヘッダの解析を行う（ステップＳ５５、Ｓ５６）。
【０１０８】
次に、ホストＣＰＵ３０は、Ｓ／Ｗデコード処理の開始を指示する（ステップＳ５７）。これにより、内蔵ＣＰＵ７０によるＶＯＰヘッダ解析とＶＣＬ復号化、逆スキャニング、逆ＤＣ／ＡＣ予測が行われるようになる。
【０１０９】
次に、全てのフレーム（ＶＯＰ）のデコード処理が完了したか否かを判断し（ステップＳ５８）、完了した場合には処理を終了する。一方、全てのフレームのデコード処理が完了していない場合には、１フレーム分のデコード処理が完了したか否かを判断し（ステップＳ５９）、完了した場合にはデコード完了フラグをクリアする（ステップＳ６０）。
【０１１０】
次にインターバル値を取得し、インターバル値分の時間（フレームレートに応じた時間）が経過したか否かを判断する（ステップＳ６１、Ｓ６２）。そして経過した場合には、表示エリア（ダブルバッファ構造のデコードデータバッファ９３の第１、第２のバッファのいずれか）の選択を行い（ステップＳ６３）、選択された表示エリアの表示データ（画像データ）を表示ドライバ１６に転送する（ステップＳ６４）。
【０１１１】
図１１のステップＳ５１〜Ｓ５６に示すように、本実施形態では、ＭＰＥＧストリーム（広義にはストリームデータ）の上位レイヤーのヘッダ解析（ＶＯＳ、ＶＯ、ＶＯＬ、ＧＯＶヘッダの解析）はホストＣＰＵ３０が行う。一方、ＭＰＥＧストリームの下位レイヤーのヘッダ解析（ＶＯＰヘッダの解析）は内蔵ＣＰＵ７０が行う。このように役割分担すれば、ホストＣＰＵ３０の制御の元で、ＭＰＥＧのデコード処理を効率化良く実施できるようになる。
【０１１２】
次に、図１２のシーケンス図を説明する。まず、ホストＣＰＵ３０は、ＶＯＳ、ＶＯ、ＶＯＬ、ＧＯＶのヘッダを解析し、情報領域９９に情報（データ、パラメータ）を設定する。そしてホスト用バッファ９６（ＦＩＦＯ）の初期化処理を行う。
【０１１３】
次にホストＣＰＵ３０はデコードリセットコマンドを送信し、ＡＣＫの受信ウェイト態に移行する。一方、内蔵ＣＰＵ７０は、アシストテーブルの展開後、ホストＣＰＵ３０からデコードリセットコマンドを受信すると、動作モードをデコードモードに設定する。またＨ／Ｗアクセラレータの初期化処理を行い、ＡＣＫを送信する。
【０１１４】
ホストＣＰＵ３０は、ＡＣＫを受信すると、データ（ハフマンデータ）をホスト用バッファ９６にライトする。即ち１ＶＯＰ分のデータをホスト用バッファ９６にライトする。      
【０１１５】
次にホストＣＰＵ３０は、Ｓ／Ｗデコード開始コマンドを送信し、ＡＣＫの受信ウェイト状態に移行する。一方、内蔵ＣＰＵ７０は、デコード開始コマンドを受信すると、情報領域９９の情報を取得し、ＡＣＫを送信し、ホストＣＰＵ３０がそのＡＣＫを受信する。
【０１１６】
図１０（Ｂ）に、デコード処理時に情報領域９９に設定される情報の例を示す。内蔵ＣＰＵ７０は、図１０（Ｂ）に示す情報をホストＣＰＵ３０から知らされることで、適切なデコード処理を実現できる。
【０１１７】
次に内蔵ＣＰＵ７０は、Ｓ／Ｗデコード処理を開始する。そして処理後のデータをＦＩＦＯバッファ９２にライトする。そして１ＶＯＰ分のデータのデコード処理が終了したら、ｌａｓｔｄｅｃ＝１に設定する。また、ハフマンデータの解析中にエラーを検出したら、ｄｅｃｅｒｒ＝１に設定する。
【０１１８】
ホストＣＰＵ３０は、ｌａｓｔｄｅｃ＝１になるのをウェイトする。そして、ｌａｓｔｄｅｃ＝１になった場合には、ｄｅｃｅｒｒを確認する。そして、ｄｅｃｅｒｒ＝１の場合には、ＦＩＦＯバッファ９２をクリアし、内蔵ＣＰＵ７０に代わってホストＣＰＵ３０がＳ／Ｗデコード処理を実行する。
【０１１９】
次にホストＣＰＵ３０は、Ｈ／Ｗデコード処理の開始を指示する。そして開始の指示後、ホスト用バッファ９６の初期化処理に戻る。
【０１２０】
図１２に示すように本実施形態では、Ｓ／Ｗデコード処理にエラーが発生した場合には、内蔵ＣＰＵ７０に代わってホストＣＰＵ３０がＳ／Ｗデコード処理を実行する。このようにすることで、エラーが発生した場合にも、そのエラーを回復してＨ／Ｗデコード処理に移行し、デコード処理を完結できるようになる。
【０１２１】
７．ハンドシェーク通信
本実施形態では、ホストＣＰＵ３０、内蔵ＣＰＵ７０間でのコマンド、ステータスの転送を、レジスタ（出力レジスタ、入力レジスタ）を用いたハンドシェーク通信により実現している。これらのレジスタは、ホストＩ／Ｆ６０内に設けることができる。
【０１２２】
図１３、図１４のフローチャートを用いて本実施形態のハンドシェーク通信を説明する。なお、図１５には、ハンドシェーク通信により転送されるコマンドやステータスの例を示す。
【０１２３】
図１３は、ホストＣＰＵ３０から内蔵ＣＰＵ７０にデータ（コマンド、ステータス）を送信（出力）する場合のフローチャートである。まず、ホストＣＰＵ３０が、出力レジスタ（ビット７〜０）にデータをライトする（ステップＳ７１）。このライトにより出力ステータス（ビット８）＝１に自動設定される。
【０１２４】
次にホストＣＰＵ３０は、タイマをスタートし（ステップＳ７２）、出力ステータス＝０になるのをウェイトする（ステップＳ７３）。そして出力ステータス＝０になった場合には処理を終了する。一方、出力ステータス＝０にならない場合には、ステップＳ７２でスタートしたタイマがタイムオーバーになったか否かを判断する（ステップＳ７４）。そしてタイムオーバーになっていない場合にはステップＳ７３に戻り、タイムオーバーになった場合には処理を終了する。
【０１２５】
一方、内蔵ＣＰＵ７０は、出力レジスタ（ビット１５〜０）をリードする（ステップＳ７５）。このリードにより出力ステータス（ビット８）＝０に自動設定される。
【０１２６】
次に、ステップＳ７５のリード時に出力ステータス＝１になっていたか否かを判断する（ステップＳ７６）。そして出力ステータス＝１になっていなかった場合にはステップＳ７５に戻り、出力レジスタ（ビット１５〜０）を再度リードする。一方、ホストＣＰＵ３０がステップＳ７１で出力レジスタ（ビット７〜０）にデータをライトし、出力ステータス＝１になると、ホストＣＰＵ３０は出力レジスタのデータ（ビット７〜０）を取得する（ステップＳ７７）。
【０１２７】
図１４は、ホストＣＰＵ３０が内蔵ＣＰＵ７０からデータ（コマンド、ステータス）を受信（入力）する場合のフローチャートである。まず内蔵ＣＰＵ７０が入力レジスタ（ビット２３〜１６）にデータをライトする（ステップＳ８１）。このライトにより入力ステータス（ビット２４）＝１に自動設定される。次に内蔵ＣＰＵ７０は出力レジスタ（ビット１５〜０）をリードする（ステップＳ８２）。そして出力ステータス＝１か否かを判断し（ステップＳ８３）、出力ステータス＝１の場合には出力レジスタのデータ（ビット７〜０）を取得する（ステップＳ８４）。次に、内蔵ＣＰＵ７０は入力ステータス＝０か否かを判断し（ステップＳ８５）、入力ステータス＝０ではない場合にはステップＳ８２に戻り、入力ステータス＝０の場合には処理を終了する。
【０１２８】
ホストＣＰＵ３０は、入力レジスタ（ビット３１〜１６）をリードする（ステップＳ８６）。このリードにより入力ステータス（ビット２４）＝０に自動設定される。次に、ホストＣＰＵ３０は、入力ステータス＝１か否かを判断する（ステップＳ８７）。そして入力ステータス＝１ではない場合にはステップＳ８６に戻り、入力レジスタを再度リードする。一方、ステップＳ８１で内蔵ＣＰＵ７０により入力レジスタにデータがライトされ、入力ステータス＝１になった場合には、ホストＣＰＵ３０は、入力レジスタのデータ（ビット２３〜１６）を取得する（ステップＳ８８）。
【０１２９】
なお、本発明は本実施形態に限定されず、本発明の要旨の範囲内で種々の変形実施が可能である。例えば、明細書又は図面中の記載において広義や同義な用語（ホストプロセッサ、内蔵プロセッサ、フレーム、電子機器等）として引用された用語（ホストＣＰＵ、内蔵ＣＰＵ、ＶＯＰ、携帯電話機等）は、明細書又は図面中の他の記載においても広義や同義な用語に置き換えることができる。
【０１３０】
また本発明の電子機器、マルチメディア処理システム、表示コントローラの構成は、図１、図２等で説明した構成に限定されず、種々の変形実施が可能である。例えばこれらの図の構成要素の一部を省略したり、その接続関係を変更してもよい。また本発明で実現されるエンコード処理、デコード処理も図３、図４に限定されず、ＭＰＥＧ等の規格に応じた種々の変形実施が可能である。
【図面の簡単な説明】
【０１３１】
【図１】本実施形態の電子機器、マルチメディア処理システムの構成例。
【図２】本実施形態の表示コントローラの構成例。
【図３】エンコード処理の説明図。
【図４】デコード処理の説明図。
【図５】図５（Ａ）〜図５（Ｃ）はＤＣＴ、量子化の説明図。
【図６】図６（Ａ）、図６（Ｂ）はＦＩＦＯバッファを用いる手法の説明図。
【図７】スタートアップ時のシーケンス図。
【図８】エンコード処理のフローチャート。
【図９】エンコード処理のシーケンス図。
【図１０】図１０（Ａ）、図１０（Ｂ）は情報領域の説明図。
【図１１】デコード処理のフローチャート。
【図１２】デコード処理のシーケンス図。
【図１３】レジスタを用いたハンドシェーク通信の説明図。
【図１４】レジスタを用いたハンドシェーク通信の説明図。
【図１５】ハンドシェーク通信により転送されるコマンド、ステータスの例。
【符号の説明】
【０１３２】
１０  アンテナ、１２  変復調器、１４  操作部、１６  表示ドライバ、
１７  表示パネル、１８  カメラ、２０  マルティメディア処理システム、
３０  ホストＣＰＵ、４０  ホストメモリ、５０  表示コントローラ、
６０  ホストＩ／Ｆ、７０  内蔵ＣＰＵ、７２  第１のＨ／Ｗアクセラレータ、
８０  第２のＨ／Ｗアクセラレータ、９０  メモリ、９１  プログラムロード領域９１、
９２  ＦＩＦＯバッファ、９３  デコードデータバッファ、
９４  エンコードデータバッファ、９５  表示バッファ、９６  ホスト用バッファ、
９７  ワーク領域、９８  テーブルアシスト用領域、９９  情報領域、
１００  メモリコントローラ、１１０  ドライバＩ／Ｆ、１２０  カメラＩ／Ｆ、
【図１】
2006186911.tif 000003
【図２】
2006186911.tif 000004
【図３】
2006186911.tif 000005
【図４】
2006186911.tif 000006
【図５】
2006186911.tif 000007
【図６】
2006186911.tif 000008
【図７】
2006186911.tif 000009
【図８】
2006186911.tif 000010
【図９】
2006186911.tif 000011
【図１０】
2006186911.tif 000012
【図１１】
2006186911.tif 000013
【図１２】
2006186911.tif 000014
【図１３】
2006186911.tif 000015
【図１４】
2006186911.tif 000016
【図１５】
2006186911.tif 000017
【手続補正書】
【提出日】平成17年12月14日(2005.12.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
動画データ、静止画データ又は音データについてのエンコード又はデコード処理であるマルチメディア処理を行うためのマルチメディア処理システムであって、
マルチメディア処理用のプログラム群が記憶されるホストメモリと、
ホスト処理を行うホストプロセッサと、
前記ホストプロセッサにより制御される表示コントローラとを含み、
前記ホストプロセッサは、
前記ホストメモリに記憶されるマルチメディア処理用のプログラム群の中からマルチメディア処理用プログラムをリードして、前記表示コントローラに送信し、
前記表示コントローラは、
前記ホストプロセッサとのインターフェース処理を行うホストインターフェースと、
前記ホストプロセッサから送信された前記マルチメディア処理用プログラムがロードされるメモリと、
ロードされた前記マルチメディア処理用プログラムに基づいて、前記マルチメディア処理のうちソフトウェア処理に割り当てられたソフトウェア処理部分を実行する内蔵プロセッサと、
前記マルチメディア処理のうちハードウェア処理に割り当てられたハードウェア処理部分を実行する第１のハードウェアアクセラレータとを含むことを特徴とするマルチメディア処理システム。
【請求項２】
請求項１において、
前記ホストプロセッサは、
前記マルチメディア処理用プログラムを送信して前記メモリにロードした後に、リセット解除を指示して前記内蔵プロセッサのリセット状態を解除し、前記内蔵プロセッサの前記リセット状態の解除後に、前記マルチメディア処理用プログラムの実行開始を前記内蔵プロセッサに指示することを特徴とするマルチメディア処理システム。
【請求項３】
請求項２において、
前記ホストプロセッサは、
前記マルチメディア処理用プログラムを送信して前記メモリにロードした後、前記内蔵プロセッサの前記リセット状態が解除される前に、前記マルチメディア処理用プログラムのロード領域のプロテクト処理を行うことを特徴とするマルチメディア処理システム。
【請求項４】
請求項１乃至３のいずれかにおいて、
前記ホストプロセッサは、
階層構造を有しマルチメディア処理の対象となるストリームデータについての多重化処理、分離化処理、上位レイヤーのヘッダ解析処理の少なくとも１つを含む前処理を行い、
前記内蔵プロセッサは、
前記ストリームデータの下位レイヤーのヘッダ解析処理を行うことを特徴とするマルチメディア処理システム。
【請求項５】
請求項４において、
前記ホストプロセッサは、
前記前処理により得られた情報を所与の情報領域に設定して、前記内蔵プロセッサに知らせることを特徴とするマルチメディア処理システム。
【請求項６】
請求項１乃至５のいずれかにおいて、
前記マルチメディア処理用プログラムは、動画データのエンコード処理のソフトウェア処理部分を実行するためのエンコード処理用プログラムであり、
前記第１のハードウェアアクセラレータは、
前記ハードウェア処理部分である離散コサイン変換、量子化、逆量子化、逆離散コサイン変換、動き補償、動き検出の処理を行い、
前記内蔵プロセッサは、
前記ソフトウェア処理部分である可変長符号への符号化処理を行うことを特徴とするマルチメディア処理システム。
【請求項７】
請求項６において、
前記第１のハードウェアアクセラレータは、
フレーム間符号化の場合にはスキャニング処理を行い、
前記内蔵プロセッサは、
フレーム内符号化の場合にはＤＣ予測、スキャニングの処理を行うことを特徴とするマルチメディア処理システム。
【請求項８】
請求項１乃至５、６、７のいずれかにおいて、
前記マルチメディア処理用プログラムは、動画データのエンコード処理のソフトウェア処理部分を実行するためのエンコード処理用プログラムであり、
前記第１のハードウェアアクセラレータは、
前記ホストプロセッサからエンコード処理の実行開始を指示された場合に、エンコードデータバッファに書き込まれた動画データに対して、エンコード処理のハードウェア処理部分を実行し、実行後の動画データをＦＩＦＯバッファに書き込み、
前記内蔵プロセッサは、
前記ホストプロセッサから前記エンコード処理用プログラムの実行開始を指示された場合に、前記ＦＩＦＯバッファに書き込まれた動画データに対して、前記エンコード処理用プログラムに基づきエンコード処理のソフトウェア処理部分を実行し、実行後の動画データをホスト用バッファに書き込むことを特徴とするマルチメディア処理システム。
【請求項９】
請求項１乃至５のいずれかにおいて、
前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、
前記内蔵プロセッサは、
前記デコード処理用プログラムに基づいて、ソフトウェア処理部分である可変長符号の復号化処理を行い、
前記第１のハードウェアアクセラレータは、
ハードウェア処理部分である逆量子化、逆離散コサイン変換、動き補償の処理を行うことを特徴とするマルチメディア処理システム。
【請求項１０】
請求項９において、
前記内蔵プロセッサは、
フレーム内符号化の場合には逆スキャニング、逆ＤＣ／ＡＣ予測の処理を行い、
前記第１のハードウェアアクセラレータは、
フレーム間符号化の場合には逆スキャニング処理を行うことを特徴とするマルチメディア処理システム。
【請求項１１】
請求項１乃至５、９、１０のいずれかにおいて、
前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、
前記内蔵プロセッサは、
前記ホストプロセッサから前記デコード処理用プログラムの実行開始を指示された場合に、ホスト用バッファに書き込まれた動画データに対して、前記デコード処理用プログラムに基づきデコード処理のソフトウェア処理部分を実行し、実行後の動画データをＦＩＦＯバッファに書き込み、
前記第１のハードウェアアクセラレータは、
前記ホストプロセッサから前記デコード処理の実行開始を指示された場合に、前記ＦＩＦＯバッファに書き込まれた動画データに対して、デコード処理のハードウェア処理部分を実行し、実行後の動画データをデコードデータバッファに書き込むことを特徴とするマルチメディア処理システム。
【請求項１２】
請求項１乃至５、９、１０、１１のいずれかにおいて、
前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、
前記ホストプロセッサは、
前記内蔵プロセッサによるデコード処理にエラーが発生した場合には、内蔵プロセッサに代わってデコード処理のソフトウェア処理部分を実行することを特徴とするマルチメディア処理システム。
【請求項１３】
請求項１乃至１２のいずれかにおいて、
前記表示コントローラは、
前記内蔵プロセッサに制御され、前記マルチメディア処理のソフトウェア処理部分の一部をアシストする第２のハードウェアアクセラレータを含むことを特徴とするマルチメディア処理システム。
【請求項１４】
動画データ、静止画データ又は音データについてのエンコード又はデコード処理であるマルチメディア処理を行うためのマルチメディア処理方法であって、
表示コントローラに実行させるためのマルチメディア処理用のプログラム群を、ホストプロセッサによりアクセスされるホストメモリに記憶し、
前記ホストメモリに記憶されるマルチメディア処理用のプログラム群の中からマルチメディア処理用プログラムをリードして、前記表示コントローラに送信し、
送信された前記マルチメディア処理用プログラムを、表示コントローラのメモリにロードし、
前記マルチメディア処理のうちソフトウェア処理に割り当てられたソフトウェア処理部分を、ロードされた前記マルチメディア処理用プログラムに基づき動作する表示コントローラの内蔵プロセッサにより実行し、
前記マルチメディア処理のうちハードウェア処理に割り当てられたハードウェア処理部分を、表示コントローラの第１のハードウェアアクセラレータにより実行することを特徴とするマルチメディア処理方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディア処理システム及びマルチメディア処理方法に関する。
【背景技術】
【０００２】
動画、静止画、音データなどのマルチメディア情報に対する符号化方式として、ＭＰＥＧ−４（Moving Picture Experts Group Phase 4）が規格化されている。近年の携帯電話機などの携帯型電子機器は、このＭＰＥＧ−４の規格に準拠したエンコード、デコード機能を有している。このような機能を持つことで、カメラ（ＣＣＤ）で撮った動画データをエンコードして他の携帯電話（サーバー）に送信したり、アンテナを介して他の携帯電話（サーバー）から受信した動画データをデコードして表示（ＬＣＤ）パネルに表示したりすることが可能になる。
【０００３】
さて、ＭＰＥＧ−４のエンコード、デコードなどのマルチメディア処理を行う場合、一連の処理の全てをハードウェア処理回路（ＡＳＩＣ）により実現する第１の手法が考えられる。
【０００４】
しかしながらこの第１の手法では、ハードウェア処理回路が大規模化し、携帯型電子機器の小型化、低消費電力化の要請に応えることができない。
【０００５】
一方、携帯電話機などの携帯型電子機器では、機器全体を制御したりベースバンドエンジン（通信処理）を実現するためのホストＣＰＵ（Central Processing Unit）が組み込まれている。従って、このホストＣＰＵを用いたソフトウェア処理によりＭＰＥＧ−４などのマルチメディア処理を実現する第２の手法も考えられる。
【０００６】
しかしながら、この第２の手法では、ホストＣＰＵの処理負荷が増加してしまい、ホストＣＰＵが他の処理に費やす時間に制約が生じ、ホストＣＰＵが組み込まれた電子機器のパフォーマンスを低下させてしまう。またホストＣＰＵの処理時間の増加を招き、消費電力が大きくなり、バッテリの消耗抑制のための低消費電力化への要請に応えることができない。
【０００７】
また、ホストＣＰＵとＤＳＰ（Digital Signal Processor）によりマルチメディア処理を実現する第３の手法も考えられる。具体的には、ＤＳＰの内蔵メモリ（フラッシュＲＯＭなどの不揮発性メモリ）に、動画（ＭＰＥＧ）、静止画（ＪＰＥＧ）、音（オーディオ、音声）データのエンコード、デコードを実行するための全てのマルチメディア処理用プログラム群を記憶しておく。そしてホストＣＰＵが、起動コマンドを送信することで、起動が指示されたマルチメディア処理用プログラムをＤＳＰが実行する。
【０００８】
しかしながら、この第３の手法では、複雑な一連のマルチメディア処理の全てをＤＳＰが実行する必要がある。従って、コーデックの種類が増えたり、ストリームデータの多重化・分離化などの付加的な処理が増えて行くにつれて、ＤＳＰにマルチメディア処理を特化させて実行させるというアーキテクチャの意味合いが薄れ、結果的に、ＤＳＰやシステムのパフォーマンスが低下する。また、年々複雑化するマルチメディア処理に対応するために、ＤＳＰのクロック周波数を上昇させる必要が生じ、消費電力の増加や発熱の問題を招く。また、この第３の手法では、一連のマルチメディア処理用プログラム群の全てをＤＳＰの内蔵メモリ（フラッシュＲＯＭ）に記憶する必要があり、メモリの容量が増加し、消費電力の増加、製品の高コスト化の問題を招く。
【非特許文献１】MPEG-4 Visual Part(勧告書ISO/IEC 14496-2:1999(E) Annex L)
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明は、以上のような技術的課題に鑑みてなされたものであり、その目的とするところは、マルチメディア処理を効率良く実行できるマルチメディア処理システム及びマルチメディア処理方法を提供することにある。
【課題を解決するための手段】
【００１０】
本発明は、動画データ、静止画データ又は音データについてのエンコード又はデコード処理であるマルチメディア処理を行うためのマルチメディア処理システムであって、マルチメディア処理用のプログラム群が記憶されるホストメモリと、ホスト処理を行うホストプロセッサと、前記ホストプロセッサにより制御される表示コントローラとを含み、前記ホストプロセッサは、前記ホストメモリに記憶されるマルチメディア処理用のプログラム群の中からマルチメディア処理用プログラムをリードして、前記表示コントローラに送信し、前記表示コントローラは、前記ホストプロセッサとのインターフェース処理を行うホストインターフェースと、前記ホストプロセッサから送信された前記マルチメディア処理用プログラムがロードされるメモリと、ロードされた前記マルチメディア処理用プログラムに基づいて、前記マルチメディア処理のうちソフトウェア処理に割り当てられたソフトウェア処理部分を実行する内蔵プロセッサと、前記マルチメディア処理のうちハードウェア処理に割り当てられたハードウェア処理部分を実行する第１のハードウェアアクセラレータとを含むマルチメディア処理システムに関係する。
【００１１】
本発明によれば、ホストプロセッサが、マルチメディア処理用プログラム群の中から選択したマルチメディア処理用プログラムをホストメモリから読み出して、表示コントローラに送信する。そしてこの送信されたマルチメディア処理用プログラムが表示コントローラのメモリにロードされる。すると、表示コントローラの内蔵プロセッサが、このロードされたマルチメディア処理用プログラムに基づいてマルチメディア処理のソフトウェア処理部分を実行し、第１のハードウェアアクセラレータが、マルチメディア処理のハードウェア処理部分を実行する。このようにすれば、マルチメディア処理を効率良く実行できる。また、全てのマルチメディア処理用プログラムを表示コントローラのメモリにロードしなくても済むようになり、表示コントローラのメモリの記憶容量を節約できる。また、マルチメディア処理が複雑化した場合にも、これに柔軟に対応できるようになる。
【００１２】
また本発明では、前記ホストプロセッサは、前記マルチメディア処理用プログラムを送信して前記メモリにロードした後に、リセット解除を指示して前記内蔵プロセッサのリセット状態を解除し、前記内蔵プロセッサの前記リセット状態の解除後に、前記マルチメディア処理用プログラムの実行開始を前記内蔵プロセッサに指示するようにしてもよい。
【００１３】
このようにすれば、必要な時にだけ内蔵プロセッサのリセット状態を解除してマルチメディア処理用プログラムを実行させることが可能となり、低消費電力化を実現できる。
【００１４】
また本発明では、前記ホストプロセッサは、前記マルチメディア処理用プログラムを送信して前記メモリにロードした後、前記内蔵プロセッサの前記リセット状態が解除される前に、前記マルチメディア処理用プログラムのロード領域のプロテクト処理を行うようにしてもよい。
【００１５】
このようにすれば、リセット状態が解除されて動作を開始した内蔵プロセッサや、ホストプロセッサにより、マルチメディア処理用プログラムのロード領域にデータが書き込まれてマルチメディア処理用プログラムが破壊されてしまう事態を防止できる。
【００１６】
また本発明では、前記ホストプロセッサは、階層構造を有しマルチメディア処理の対象となるストリームデータについての多重化処理、分離化処理、上位レイヤーのヘッダ解析処理の少なくとも１つを含む前処理を行い、前記内蔵プロセッサは、前記ストリームデータの下位レイヤーのヘッダ解析処理を行うようにしてもよい。
【００１７】
このようにすれば、上位レイヤーのデバイスにより処理されるのが効率的であると考えられる前処理（多重化処理、分離化処理、上位レイヤーのヘッダ解析処理等）については、ホストプロセッサにより実行される。一方、下位レイヤーのデバイスにより処理されるのが効率的であると考えられる下位レイヤーのヘッダ解析処理については、内蔵プロセッサにより実行されるようになる。このように役割分担すれば、ホストプロセッサの制御の元で、マルチメディア処理を効率化良く実行できる。
【００１８】
また本発明では、前記ホストプロセッサは、前記前処理により得られた情報を所与の情報領域に設定して、前記内蔵プロセッサに知らせるようにしてもよい。
【００１９】
このようにすれば、内蔵プロセッサは、情報領域に設定された情報に基づいて、適切なマルチメディア処理を実行できる。
【００２０】
また本発明では、前記マルチメディア処理用プログラムは、動画データのエンコード処理のソフトウェア処理部分を実行するためのエンコード処理用プログラムであり、前記第１のハードウェアアクセラレータは、前記ハードウェア処理部分である離散コサイン変換、量子化、逆量子化、逆離散コサイン変換、動き補償、動き検出の処理を行い、前記内蔵プロセッサは、前記ソフトウェア処理部分である可変長符号への符号化処理を行うようにしてもよい。
【００２１】
このようにすれば、処理負荷が重く、変更の可能性が低い離散コサイン変換、量子化等のハードウェア処理部分については、第１のハードウェアアクセラレータにより実行される。一方、処理負荷が比較的低く、フレキシブルなプログラミングが要求されるソフトウェア処理部分については、内蔵プロセッサにより実行される。このように役割分担することで、マルチメディア処理のエンコード処理を更に効率良く実行できる。
【００２２】
また本発明では、前記第１のハードウェアアクセラレータは、フレーム間符号化の場合にはスキャニング処理を行い、前記内蔵プロセッサは、フレーム内符号化の場合にはＤＣ予測、スキャニングの処理を行うようにしてもよい。
【００２３】
このようにすれば、符号化の種類に応じた最適な役割分担でマルチメディア処理のエンコード処理を実行できる。
【００２４】
また本発明では、前記マルチメディア処理用プログラムは、動画データのエンコード処理のソフトウェア処理部分を実行するためのエンコード処理用プログラムであり、前記第１のハードウェアアクセラレータは、前記ホストプロセッサからエンコード処理の実行開始を指示された場合に、エンコードデータバッファに書き込まれた動画データに対して、エンコード処理のハードウェア処理部分を実行し、実行後の動画データをＦＩＦＯバッファに書き込み、前記内蔵プロセッサは、前記ホストプロセッサから前記エンコード処理用プログラムの実行開始を指示された場合に、前記ＦＩＦＯバッファに書き込まれた動画データに対して、前記エンコード処理用プログラムに基づきエンコード処理のソフトウェア処理部分を実行し、実行後の動画データをホスト用バッファに書き込むようにしてもよい。
【００２５】
このようにＦＩＦＯバッファを利用すれば、ホストプロセッサの制御の元で、マルチメディア処理のエンコード処理をスムーズに効率良く実行できる。
【００２６】
また本発明では、前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、前記内蔵プロセッサは、前記デコード処理用プログラムに基づいて、ソフトウェア処理部分である可変長符号の復号化処理を行い、前記第１のハードウェアアクセラレータは、ハードウェア処理部分である逆量子化、逆離散コサイン変換、動き補償の処理を行うようにしてもよい。
【００２７】
このようにすれば、処理負荷が重く、変更の可能性が低い逆量子化、逆離散コサイン変換等のハードウェア処理部分については、第１のハードウェアアクセラレータにより実行される。一方、処理負荷が比較的低く、フレキシブルなプログラミングが要求されるソフトウェア処理部分については、内蔵プロセッサにより実行される。このように役割分担することで、マルチメディア処理のデコード処理を更に効率良く実行できる。
【００２８】
また本発明では、前記内蔵プロセッサは、フレーム内符号化の場合には逆スキャニング、逆ＤＣ／ＡＣ予測の処理を行い、前記第１のハードウェアアクセラレータは、フレーム間符号化の場合には逆スキャニング処理を行うようにしてもよい。
【００２９】
このようにすれば、符号化の種類に応じた最適な役割分担でマルチメディア処理のデコード処理を実行できる。
【００３０】
また本発明では、前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、前記内蔵プロセッサは、前記ホストプロセッサから前記デコード処理用プログラムの実行開始を指示された場合に、ホスト用バッファに書き込まれた動画データに対して、前記デコード処理用プログラムに基づきデコード処理のソフトウェア処理部分を実行し、実行後の動画データをＦＩＦＯバッファに書き込み、前記第１のハードウェアアクセラレータは、前記ホストプロセッサから前記デコード処理の実行開始を指示された場合に、前記ＦＩＦＯバッファに書き込まれた動画データに対して、デコード処理のハードウェア処理部分を実行し、実行後の動画データをデコードデータバッファに書き込むようにしてもよい。
【００３１】
このようにＦＩＦＯバッファを利用すれば、ホストプロセッサの制御の元で、マルチメディア処理のデコード処理をスムーズに効率良く実行できる。
【００３２】
また本発明では、前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、前記ホストプロセッサは、前記内蔵プロセッサによるデコード処理にエラーが発生した場合には、内蔵プロセッサに代わってデコード処理のソフトウェア処理部分を実行するようにしてもよい。
【００３３】
このようにすれば、デコードエラーが発生した場合にも、そのエラーを回復して、その後のハードウェア処理部分を適正に実行することが可能になる。
【００３４】
また本発明では、前記表示コントローラは、前記内蔵プロセッサに制御され、前記マルチメディア処理のソフトウェア処理部分の一部をアシストする第２のハードウェアアクセラレータを含むようにしてもよい。
【００３５】
また本発明は、動画データ、静止画データ又は音データについてのエンコード又はデコード処理であるマルチメディア処理を行うためのマルチメディア処理方法であって、表示コントローラに実行させるためのマルチメディア処理用のプログラム群を、ホストプロセッサによりアクセスされるホストメモリに記憶し、前記ホストメモリに記憶されるマルチメディア処理用のプログラム群の中からマルチメディア処理用プログラムをリードして、前記表示コントローラに送信し、送信された前記マルチメディア処理用プログラムを、表示コントローラのメモリにロードし、前記マルチメディア処理のうちソフトウェア処理に割り当てられたソフトウェア処理部分を、ロードされた前記マルチメディア処理用プログラムに基づき動作する表示コントローラの内蔵プロセッサにより実行し、前記マルチメディア処理のうちハードウェア処理に割り当てられたハードウェア処理部分を、表示コントローラの第１のハードウェアアクセラレータにより実行するマルチメディア処理方法に関係する。
【発明を実施するための最良の形態】
【００３６】
以下、本発明の実施形態について詳細に説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが本発明の解決手段として必須であるとは限らない。
【００３７】
１．構成
図１に、本実施形態のマルチメディア処理システムと、このマルチメディア処理システムを含む電子機器の構成例を示す。なおマルチメディア処理システム、電子機器、表示コントローラの構成は図１に限定されず、同図の構成要素の一部を省略したり他の構成要素を加えてもよい。
【００３８】
図１は、マルチメディア処理システム２０を含む電子機器が携帯電話機である場合の例である。図１の携帯電話機（広義には電子機器）は、アンテナ１０、変復調器１２、操作部１４、表示ドライバ１６、表示パネル１７、カメラ１８、マルチメディア処理システム２０を含む。マルチメディア処理システム２０は、ホストＣＰＵ３０（広義にはホストプロセッサ）、ホストメモリ４０、表示コントローラ５０を含む。
【００３９】
アンテナ１０を介して他の機器（携帯電話機、サーバー）から受信したデータ（動画データ、ＭＰＥＧストリーム）は、変復調器１２で復調されてホストＣＰＵ３０に供給される。一方、ホストＣＰＵ３０からのデータは、変復調器１２で変調されて、アンテナ１０を介して他の機器に送信される。
【００４０】
ユーザからの操作情報は、操作部１４（操作ボタン）を介して入力される。この操作情報に基づいて、ホストＣＰＵ３０の制御の元で、データの通信処理、データのエンコード・デコード処理、表示パネル１７への画像の表示処理、カメラ１８（カメラモジュール）の撮像処理などが行われる。
【００４１】
表示パネル１７は表示ドライバ１６によって駆動される。表示パネル１７は、複数の走査線、複数のデータ線、複数の画素を含む。表示ドライバ１７は、走査線を駆動（選択）する走査ドライバの機能と、画像データ（表示データ）に対応した電圧をデータ線に供給するデータドライバの機能を有する。表示コントローラ５０は表示ドライバ１６に接続され、表示ドライバ１６に画像データを供給する。なお表示パネル１７としては液晶表示パネル（ＬＣＤ）を採用できるが、これに限定されず、エレクトロルミネッセンス表示パネルやプラズマ表示パネルなどであってもよい。
【００４２】
カメラ１８はＣＣＤ（Charge-Coupled Device）を含む。そしてＣＣＤで撮像した画像のデータを、ＹＵＶフォーマットで表示コントローラ５０に供給する。
【００４３】
ホストＣＰＵ３０は、ホストメモリ４０にアクセスしてホスト処理を行う。具体的には、表示コントローラ５０を制御する処理や、機器全体を制御する処理や、ベースバンドエンジン（通信処理エンジン）としての処理などを行う。ホストメモリ４０には種々のプログラムが記憶される。ホストＣＰＵ３０は、ホストメモリ４０に記憶されたプログラムにより動作してソフトウェア処理を実現する。このホストメモリ４０は、フラッシュＲＯＭなどの不揮発性メモリやＲＡＭなどにより実現できる。
【００４４】
表示コントローラ５０は、表示ドライバ１６を制御する。この表示コントローラ５０は、ホストインターフェース６０、内蔵ＣＰＵ７０（広義には内蔵プロセッサ）、ハードウェアアクセラレータ８０、メモリ９０を含む。なお本明細書中及び図面では、「インターフェース」、「ハードウェア」、「ソフトウェア」を、適宜、「Ｉ／Ｆ」、「Ｈ／Ｗ」、「Ｓ／Ｗ」と略称する。
【００４５】
表示コントローラ５０（画像コントローラ）は、カメラ１８からの画像データ（動画、静止画データ）をエンコードし、エンコード後の画像データをホストＣＰＵ３０に送信する。ホストＣＰＵ３０は、エンコード後の画像データをファイルとして保存したり、変復調器１２、アンテナ１０を介して他の機器に送信する。
【００４６】
また表示コントローラ５０は、ホストＣＰＵ３０から受信した画像データ（符号化データ、圧縮データ）をデコードし、デコード後の画像データを表示ドライバ１６に供給して表示パネル１７に表示させる。また表示コントローラ５０は、カメラ１８により撮像された画像データを受け、表示ドライバ１６に供給して表示パネル１７に表示させることもできる。
【００４７】
ホストメモリ４０はマルチメディア処理用プログラム群を記憶する。ここでマルチメディア処理は、動画データ、静止画データ又は音（オーディオ、音声）データについてのエンコード（圧縮）又はデコード（伸長）処理である。またマルチメディア処理用プログラムは、動画（狭義にはＭＰＥＧ）エンコード用プログラム、動画デコード用プログラム、静止画（狭義にはＪＰＥＧ）エンコード用プログラム、静止画デコード用プログラム、音エンコード用プログラム、或いは音デコード用プログラムなどである。なお、エンコードプログラムとデコードプログラムを１つのセットにしたコーデック用プログラムをマルチメディア処理用プログラムとしてホストメモリ４０に記憶してもよい。
【００４８】
本実施形態ではホストＣＰＵ３０（広義にはホストプロセッサ、ホスト）が、ホストメモリ４０に記憶されるマルチメディア処理用のプログラム群の中から選択したマルチメディア処理用プログラムをリードして、表示コントローラ５０に送信する。そして送信されたマルチメディア処理用プログラムは、表示コントローラ５０のメモリ９０にロードされる。
【００４９】
具体的にはホストＣＰＵ３０は、動画のエンコードが必要である場合には、動画データのエンコード処理のソフトウェア処理部分を実行するためのエンコード処理用プログラムをホストメモリ４０からリードして、表示コントローラ５０に送信する。例えばカメラ１８で撮影された動画データ（元データ）を、ファイルとして保存したり、アンテナ１０を介して他の機器に送信する場合には、動画（ＭＰＥＧ）のエンコード処理用プログラムをホストメモリ４０からリードして、表示コントローラ５０に送信する。そしてエンコード対象となる動画データは、例えばカメラ１８から表示コントローラ５０に入力される。
【００５０】
またホストＣＰＵ３０は、動画のデコードが必要である場合には、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムをホストメモリ４０からリードして、表示コントローラ５０に送信する。例えばアンテナ１０を介して他の機器から受信した動画データ（符号化データ、圧縮データ）や、ファイルとして保存した動画データ（符号化データ、圧縮データ）を、表示パネル１７に表示する場合には、ホストＣＰＵ３０は、動画（ＭＰＥＧ）のデコード処理用プログラムをホストメモリ４０からリードして、表示コントローラ５０に送信する。またホストＣＰＵ３０は、デコード対象となる動画データ（元データ）を表示コントローラ５０に送信する。
【００５１】
このように本実施形態では、マルチメディア処理用プログラム群の中から、必要なマルチメディア処理用プログラムがホストＣＰＵ３０により選択されて、表示コントローラ５０のメモリ９０にロードされる。従って、メモリ９０（ＲＡＭ）の使用記憶容量を節約できるため、メモリ９０を小規模化でき、表示コントローラ５０の低コスト化を図れる。また、１度にロードするデータ量を少なくできるため、起動時や、ハングアップした場合の再起動時に、長時間を要してしまうという問題を防止できる。
【００５２】
表示コントローラ５０が含むホストＩ／Ｆ６０は、ホストＣＰＵ３０とのインターフェース処理を行う。具体的にはホストＩ／Ｆ６０は、ホストＣＰＵ３０との間でコマンド、データ、ステータスの送信や受信処理（ハンドシェーク処理）を行う。また表示コントローラ５０からホストＣＰＵ３０に対する割り込み信号の生成などを行う。なお、ホストＩ／Ｆ６０にデータのＤＭＡ（Direct Memory Access）転送機能を持たせてもよい。
【００５３】
表示コントローラ５０が含む内蔵ＣＰＵ７０（広義には内蔵プロセッサ）は、表示コントローラ５０の全体制御や各部の制御を行う。そして本実施形態では内蔵ＣＰＵ７０（ＲＩＳＣプロセッサ）が、メモリ９０にロードされたマルチメディア処理用プログラムに基づいて、マルチメディア処理のうちソフトウェア処理に割り当てられたソフトウェア処理部分を実行する。このソフトウェア処理部分は、マルチメディア処理用プログラムを読み込んだ内蔵ＣＰＵ７０によりその処理が実行される部分である。
【００５４】
より具体的には、ホストＣＰＵ３０は、内蔵ＣＰＵ７０にリセットを指示することで（リセットコマンドを送信することで）、内蔵ＣＰＵ７０をリセット状態に設定する。そしてホストＣＰＵ３０は、マルチメディア処理用プログラムを送信してメモリ９０にロードした後に、リセット解除を指示して（リセット解除コマンドを送信して）、内蔵ＣＰＵ７０のリセット状態を解除する。そしてホストＣＰＵ３０は、内蔵ＣＰＵ７０のリセット状態の解除後に、マルチメディア処理用プログラムの実行開始を内蔵ＣＰＵ７０に指示する（実行開始コマンドを送信する）。内蔵ＣＰＵ７０は、ホストＣＰＵ３０からリセット解除を指示されると、そのリセット状態が解除される。そしてリセット状態の解除後に、メモリ９０にロードされたマルチメディア処理用プログラムを実行する。
【００５５】
なお、内蔵ＣＰＵ７０は、リセット状態の解除後に、ホストＣＰＵ３０からのコマンド（マルチメディア処理開始コマンド）の受信をウェイトするコマンドウェイト状態に移行する。そして、このコマンドウェイト状態において、マルチメディア処理用プログラムの実行開始をホストＣＰＵ３０から指示された場合に（マルチメディア処理開始コマンドを受信した場合に）、内蔵ＣＰＵ７０はマルチメディア処理用プログラムを実行する。
【００５６】
またホストＣＰＵ３０は、マルチメディア処理用プログラムを送信してメモリ９０にロードした後、内蔵ＣＰＵ７０のリセット状態が解除される前に、マルチメディア処理用プログラムのロード領域（図２の９１）のプロテクト（ライトプロテクト）処理を行う。
【００５７】
更にホストＣＰＵ３０は、階層構造を有しマルチメディア処理の対象となるストリームデータ（ＭＰＥＧストリーム）についての多重化処理（ビデオ、オーディオの多重化、ビデオ、オーディオのパケット分割）、分離化処理（ビデオ、オーディオの分離）、上位レイヤーのヘッダ解析処理(ＶＯＳ、ＶＯ、ＶＯＬ、ＧＯＶヘッダの解析）の少なくとも１つを含む前処理（pre processing）を行う。そして、前処理により得られた情報（データ、パラメータ）を情報領域（図２の９９）に設定して、内蔵ＣＰＵ７０に知らせる。一方、内蔵ＣＰＵ７０は、ストリームデータ（ＭＰＥＧストリーム）の下位レイヤーのヘッダ解析処理（ＶＯＰヘッダの解析）を行う。また情報領域に設定された情報（データ、パラメータ）に基づいて、マルチメディア処理のソフトウェア処理部分を実行する。
【００５８】
表示コントローラ５０が含むＨ／Ｗアクセラレータ８０（第１のＨ／Ｗアクセラレータ）は、マルチメディア処理のうちハードウェア処理に割り当てられたハードウェア処理部分を実行する回路（ハードウェア処理回路）である。このハードウェア処理部分は、プロセッサではない専用の回路によりその処理が実行される部分である。
【００５９】
表示コントローラ５０が含むメモリ９０は、プログラムのロード領域やデータバッファ領域や内蔵ＣＰＵ７０のワーク領域として機能する。具体的には、ホストＣＰＵ３０によりホストメモリ４０からリードされたマルチメディア処理用プログラムが、メモリ９０のプログラムロード領域にロードされる。また、エンコードデータやデコードデータが、メモリ９０のバッファ領域（ＦＩＦＯ領域）によりバッファリングされる。また内蔵ＣＰＵ７０は、メモリ９０のワーク領域にテーブル等を展開して処理を行う。このメモリ９０はＲＡＭ（ＳＲＡＭ、ＤＲＡＭ）などにより実現できる。
【００６０】
図２に表示コントローラの詳細な構成例を示す。なお表示コントローラの構成は図２に限定されず、同図の構成要素の一部を省略したり他の構成要素を加えてもよい。
【００６１】
図２に示すようにメモリ９０には、プログラムロード領域９１、ＦＩＦＯバッファ９２（ＭＰＥＧ４ＦＩＦＯ）、デコードデータバッファ９３（ＭＰＥＧ４デコードバッファ）、エンコードデータバッファ９４（ＭＰＥＧ４エンコードバッファ）、表示バッファ９５、ホスト用バッファ９６（ハフマンＦＩＦＯ）、ワーク領域９７、テーブルアシスト用領域９８、情報領域９９が確保（マッピング）されている。なお、これらの領域やバッファは、物理的に同一のメモリで実現してもよいし、物理的に異なるメモリで実現してもよい。
【００６２】
メモリコントローラ１００は、メモリ９０のアクセス（リード、ライトアクセス）制御を行う。即ちメモリコントローラ１００は、ホストＩ／Ｆ６０、内蔵ＣＰＵ７０、Ｈ／Ｗアクセラレータ８０、ドライバＩ／Ｆ１１０、カメラＩ／Ｆ１２０からのアクセスを調停する。そしてメモリ９０のリードアドレスやライトアドレスを発生して、ライトポインタやリードポインタを制御し、メモリ９０からデータやプログラムをリードしたり、メモリ９０にデータやプログラムをライトする。例えばプログラムロード領域９１へのマルチメディア処理用プログラムのロードは、このメモリコントローラ１００により実現できる。
【００６３】
ドライバＩ／Ｆ１１０は、表示ドライバ１６とのインターフェース処理を行う。具体的には、表示ドライバ１６に画像データ（動画、静止画データ）を送信する処理や、表示ドライバ１６の各種制御信号を生成する処理などを行う。
【００６４】
カメラＩ／Ｆ１２０は、カメラ１８との間のインターフェース処理を行う。例えばカメラ１８は、撮像により得られた画像データを例えばＹＵＣフォーマットで出力すると共に、１フレームの区切りを指定する同期信号（ＶＳＹＮＣ等）を出力する。カメラＩ／Ｆ１２０は、この同期信号に基づいて、カメラ１８からの画像データを取り込む。
【００６５】
なお図２では、内蔵ＣＰＵ７０に対してＨ／Ｗアクセラレータ７２（第２のアクセラレータ）が接続されている。このＨ／Ｗアクセラレータ７２は、内蔵ＣＰＵ７０に制御され、マルチメディア処理のソフトウェア処理部分の一部をアシストする回路（ハードウェア処理回路）である。具体的にはＨ／Ｗアクセラレータ７２は、可変長符号（ＶＬＣ：Variable Length Code）への符号化処理や可変長符号の復号化処理の一部について内蔵ＣＰＵ７０をアシストする。例えばＨ／Ｗアクセラレータ７２は、可変長符号処理に必要なテーブルのインデックス番号の生成処理などを、内蔵ＣＰＵ７０に代わって実行する。この場合にＨ／Ｗアクセラレータ７２は、メモリ９０のテーブルアシスト用領域９８をワーク領域として使用する。
【００６６】
２．エンコード、デコード処理
次に本実施形態のＭＰＥＧ−４のエンコード、デコード処理を図３、図４を用いて説明する。
【００６７】
図３に示すエンコード処理では、入力された１ＶＯＰ（Video Object Plane）分の画像データ（１フレーム分の画像データ）が、マクロブロック（基本処理単位）に分割される。１つのマクロブロックは６つのブロックから構成される。そして各ブロックに対して離散コサイン変換（ＤＣＴ：Discrete Cosine Transform）の処理が実行される（ステップＳ１）。離散コサイン変換は、８画素×８画素の１ブロック単位で行われ、１ブロック毎にＤＣＴ係数を求めるものである。離散コサイン変換後のＤＣＴ係数は、１ブロック内の画像の濃淡変化を、全体の明るさ（ＤＣ成分）と空間周波数（ＡＣ成分）とで表わしたものになる。図５（Ａ）に、８画素×８画素の１ブロック内のＤＣＴ係数の一例を示す。図５（Ａ）の左上隅のＤＣＴ係数がＤＣ成分を示し、それ以外のＤＣＴ係数がＡＣ成分を示す。なお、ＡＣ成分のうち、高周波成分を省略しても画像認識への影響が少ない。
【００６８】
次に、ＤＣＴ係数の量子化の処理が行われる（ステップＳ２）。量子化は、１ブロック内の各ＤＣＴ係数を、量子化テーブル中の対応する位置の量子化ステップ値で除算して、情報量を少なくするために実施される。例えば、図５（Ａ）のＤＣＴ係数を図５（Ｂ）の量子化テーブルを用いて量子化した場合の１ブロック内のＤＣＴ係数を図５（Ｃ）に示す。図５（Ｃ）に示すように、高周波成分のＤＣＴ係数を量子化ステップ値で除算し、その小数点以下を四捨五入すると、ほとんどがゼロデータとなり、情報量が大幅に減少する。
【００６９】
図３に示すように、フレーム内符号化（Ｉピクチャ）の場合には、ＤＣ（直流）予測、スキャニング、可変長符号化（ＶＬＣ：Variable Length Code）の処理が行われる（ステップＳ８、Ｓ９、Ｓ１０）。ＤＣ予測（ステップＳ８）は、ブロックのＤＣ成分に対する予測値を決定する処理である。スキャニング（ステップＳ９）は、ブロック内を周波数が低い側から高い側に向けてスキャン（ジグザグスキャン）する処理である。可変長符号化（ステップＳ１０）は、エントロピー符号化とも称され、符号化原理として、出現頻度の多いものは少ない符号で表すように符号化する処理である。なおフレーム間符号化（Ｐピクチャ）の場合には、ＤＣ予測は不要であるため、スキャニング（ステップＳ７）だけが行われ、スキャニング後のデータに対して可変長符号化（ステップＳ１０）が行われる。
【００７０】
エンコード処理では、現在のフレームと次のフレームとの間で動き検出（ＭＥ：MotionEstimation）を実施するために、帰還ルートが必要となる。この帰還ルート（ローカル
デコード処理）では、図３に示すように、逆量子化、逆ＤＣＴ及び動き補償（ＭＣ：Motion Compensation）の処理が実行される（ステップＳ３、Ｓ４、Ｓ５）。次に、得られた再構築フレーム（参照ＶＯＰ）に基づいて動き検出（ＭＥ）が実行されて、動きベクトルが検出される。そして、検出された動きベクトルに基づいて、予測フレーム（予測マクロブロック）が求められる。そして符号化対象となるフレームと予測フレームとの差分に対してＤＣＴ、量子化の処理が行われる（ステップＳ１、Ｓ２）。
【００７１】
図４のデコード処理は、図３のエンコード処理を、逆順で且つ逆処理することで実現される。即ち、まず、可変長符号（ＶＬＣ）の復号化処理が行われる（ステップＳ２１）。そしてフレーム内符号化（Ｉピクチャ）の場合には、逆スキャニング、逆ＤＣ／ＡＣ予測の処理が行われる（ステップＳ２２、Ｓ２３）。一方、フレーム間符号化（Ｐピクチャ）の場合には、逆ＤＣ／ＡＣ予測は行われず、逆スキャニングの処理だけが行われる（ステップＳ２４）。
【００７２】
次に、逆量子化、逆ＤＣＴの処理が行われる（ステップＳ２５、Ｓ２６）。そして過去のフレームのデータとＶＬＣ復号化後のデータとに基づき動き補償処理が行われ（ステップＳ２７）、逆ＤＣＴ後のデータとの加算処理が行われる。
【００７３】
図３に示すように本実施形態では、メモリ９０にロードされるマルチメディア処理用プログラムが動画のエンコード処理用プログラムである場合には、Ｈ／Ｗアクセラレータ８０は、ハードウェア処理部分であるＤＣＴ、量子化、逆量子化、逆ＤＣＴ、動き補償、動き検出の処理（ステップＳ１〜Ｓ６）を行う。また内蔵ＣＰＵ７０は、エンコード処理用プログラムに基づいて、ソフトウェア処理部分であるＶＬＣへの符号化処理（ステップＳ１０）を行う。更に具体的には、Ｈ／Ｗアクセラレータ８０は、フレーム間符号化（Ｐピクチャ）の場合にはスキャニング処理（ステップＳ７）を行う。また内蔵ＣＰＵ７０は、フレーム内符号化（Ｉピクチャ）の場合にはＤＣ予測（ＤＣ／ＡＣ予測）、スキャニングの処理を行う（ステップＳ８、Ｓ９）。
【００７４】
また図４に示すように本実施形態では、メモリ９０にロードされるマルチメディア処理用プログラムが動画のデコード処理用プログラムである場合には、内蔵ＣＰＵ７０は、デコード処理用プログラムに基づいて、ソフトウェア処理部分であるＶＬＣの復号化処理（ステップＳ２１）を行う。またＨ／Ｗアクセラレータ８０は、ハードウェア処理部分である逆量子化、逆ＤＣＴ、動き補償の処理（ステップＳ２５、Ｓ２６、Ｓ２７）を行う。更に具体的には、内蔵ＣＰＵ７０は、フレーム内符号化（Ｉピクチャ）の場合には逆スキャニング、逆ＤＣ／ＡＣ予測の処理（ステップＳ２２、Ｓ２３）を行う。またＨ／Ｗアクセラレータ８０は、フレーム間符号化（Ｐピクチャ）の場合には逆スキャニング処理を行う（ステップＳ２４）。
【００７５】
なお本実施形態では、内蔵ＣＰＵ７０のデコード処理にデコードエラーが発生した場合には、ホストＣＰＵ３０が、内蔵ＣＰＵ７０に代わってデコード処理のソフトウェア処理部分（ステップＳ２１〜Ｓ２３）を実行する。
【００７６】
本実施形態において、図３、図４に示すような役割分担でソフトウェア処理部分とハードウェア処理部分を実現している理由は、以下の通りである。
【００７７】
即ち、図３のステップＳ２の量子化後であれば、図５（Ｃ）に示すように各ブロック内にはゼロデータが圧倒的に多く、図５（Ａ）の量子化前のデータに比べてデータの情報量の種類が圧倒的に少ない。しかも、ステップＳ８〜Ｓ１０の処理は、演算自体の負荷も少ない。従って、これらのステップＳ８〜Ｓ１０の処理については、演算処理能力がそれほど高くない内蔵ＣＰＵ７０を用いたソフトウェア処理で実現しても問題ない。また内蔵ＣＰＵ７０を用いたソフトウェア処理は低速であるが、フレキシブルなプログラミング可能である。従って、マルチメディア処理に付随する処理部分であり、負荷は軽いがフレキシブルなプログラミングが要求される処理部分を補うのに適している。
【００７８】
一方、図３のステップＳ１〜Ｓ６のＤＣＴ、量子化、逆量子化、逆ＤＣＴ、動き補償、動き検出は、情報量が多く、処理負荷が大きいと共に、処理の高速性が要求されるため、ソフトウェア処理にはあまり適していない。更に、ステップＳ１〜Ｓ６の処理は、負荷は重いが、その処理内容が規格である程度決まっているため、将来的な変更の必要性も乏しい。従って、ステップＳ１〜１６の処理は、専用のハードウェア回路（Ｈ／Ｗアクセラレータ８０）を用いたハードウェア処理に向いている。またステップＳ１〜Ｓ６の処理は、繰り返し処理が多いため、この意味においてもハードウェア処理に向いている。またステップＳ２の量子化後のデータ量は少ないため、Ｈ／Ｗアクセラレータ８０（ハードウェア処理部）から内蔵ＣＰＵ７０（ソフトウェア処理部）に伝送されるデータの量も少なくなり、データ転送制御の負担も軽くなる。同様の理由で、本実施形態では図４のデコード処理においても、ステップＳ２１〜Ｓ２３を、内蔵ＣＰＵ７０を用いたソフトウェア処理で実現し、ステップＳ２４〜Ｓ２７を、Ｈ／Ｗアクセラレータ８０を用いたハードウェア処理で実現している。
【００７９】
また本実施形態では図３に示すように、フレーム内符号化（Ｉピクチャ）についてのスキャニング処理はソフトウェア処理で実現し、フレーム間符号化（Ｐピクチャ）についてのスキャニング処理はハードウェア処理で実現している。その理由は以下の通りである。
【００８０】
即ちフレーム内符号化の場合は、ステップＳ８のＤＣ予測をソフトウェア処理で行うため、ＤＣ予測に続くステップＳ９のスキャニング処理についてもソフトウェア処理で実現するのが効率的である。これに対して、フレーム間符号化の場合には、ＤＣ予測は不要であり、ステップＳ７のスキャニング処理をソフトウェア処理ではなくハードウェア処理で行っても問題はない。またステップＳ７のスキャニング処理は、比較的単純な処理であるため、ハードウェア処理に向いている。このような理由で本実施形態ではステップＳ７のスキャニング処理についてはハードウェア処理で実現し、ステップＳ９のスキャニング処理についてはソフトウェア処理で実現している。同様の理由で、本実施形態では図４のデコード処理においても、ステップＳ２２の逆スキャニング処理についてはソフトウェア処理で実現し、ステップＳ２４のスキャニング処理についてはハードウェア処理で実現している。
【００８１】
以上のように本実施形態では、内蔵ＣＰＵ７０とＨ／Ｗアクセラレータ８０によりバランス良く作業を分担することにより、クロック周波数をそれほど増加させることなく、低消費電力なシステムでマルチメディア処理を実現することに成功している。
【００８２】
３．ＦＩＦＯバッファ
本実施形態では、図２のＦＩＦＯ（First In First Out）バッファ９２、デコードデータバッファ９３、エンコードデータバッファ９４、ホスト用バッファ９６を、図６（Ａ）（Ｂ）のように利用して、エンコード処理、デコード処理を実現している。
【００８３】
例えばメモリ９０にロードされたマルチメディア処理用プログラムが動画のエンコード処理用プログラムである場合には、図６（Ａ）に示すように、カメラ１８で撮像された動画データ（１ＶＯＰ分の動画データ）はエンコードデータバッファ９４（ＭＰＥＧ４エンコードバッファ）に書き込まれる。そしてＨ／Ｗアクセラレータ８０は、ホストＣＰＵ３０からエンコード処理の実行開始を指示された場合に、エンコードデータバッファ９４に書き込まれた動画データに対して、エンコード処理のハードウェア処理部分を実行する。そして実行後の動画データ（Ｈ／Ｗエンコード後の動画データ）をＦＩＦＯバッファ９２に書き込む。
【００８４】
次に、内蔵ＣＰＵ７０は、ホストＣＰＵ３０から、メモリ９０にロードされたエンコード処理用プログラムの実行開始を指示された場合に、ＦＩＦＯバッファ９２に書き込まれた動画データ（１ＶＯＰ分の動画データ）に対して、エンコード処理用プログラムに基づきエンコード処理のソフトウェア処理部分を実行する。そして実行後の動画データ（Ｓ／Ｗエンコード後の動画データ）をホスト用バッファ９６（ハフマンＦＩＦＯ）に書き込む。
【００８５】
またメモリ９０にロードされたマルチメディア処理用プログラムが動画のデコード処理用プログラムである場合には、図６（Ｂ）に示すように、ホストＣＰＵ３０が、ホスト用バッファ９６に、デコード対象となる動画データ（１ＶＯＰ分の動画データ）を書き込む。そして内蔵ＣＰＵ７０は、ホストＣＰＵ３０からデコード処理用プログラムの実行開始を指示された場合に、ホスト用バッファ９６に書き込まれた動画データに対して、デコード処理用プログラムに基づきデコード処理のソフトウェア処理部分を実行する。そして実行後の動画データ（Ｓ／Ｗデコード後の動画データ）をＦＩＦＯバッファ９２に書き込む。
【００８６】
次に、Ｈ／Ｗアクセラレータ８０は、ホストＣＰＵ３０からデコード処理の実行開始を指示された場合に、ＦＩＦＯバッファ９２に書き込まれた動画データ（１ＶＯＰ分の動画データ）に対して、デコード処理のハードウェア処理部分を実行する。そして実行後の動画データ（Ｈ／Ｗデコード後の動画データ）をデコードデータバッファ９３に書き込む。そしてデコードデータバッファ９３に書き込まれた動画データは、表示ドライバ１６に転送され、表示パネル１７の動画表示が行われる。
【００８７】
図６（Ａ）（Ｂ）のように本実施形態では、内蔵ＣＰＵ７０とＨ／Ｗアクセラレータ８０の間にＦＩＦＯバッファ９２を介在させている。このようにすることで、ホストＣＰＵ３０の制御の元で、ソフトウェア処理部分とハードウェア処理部分を内蔵ＣＰＵ７０とＨ／Ｗアクセラレータ８０で効率良く分担して実行することが可能になる。
【００８８】
例えば図６（Ａ）のエンコード処理において、エンコード後の符号量が多い場合には、ビットレートを遵守するためのレートコントロールが必要になる。この場合に本実施形態では、ホストＣＰＵ３０がスキップフレームを作成することで、レートコントロールを実現する。具体的には、レートコントロールのために、例えば第Ｋのフレーム（第ＫのＶＯＰ）をスキップする場合には、ホストＣＰＵ３０は、この第Ｋのフレームの動画データについてのＨ／Ｗエンコード処理の開始指示（Ｈ／Ｗアクセラレータ８０に対する指示）を行わないようにする。これにより、Ｈ／Ｗエンコード処理後の第Ｋのフレームの動画データはＦＩＦＯバッファ９２には書き込まれないようになり、内蔵ＣＰＵ７０も、この第Ｋのフレームの動画データに対するＳ／Ｗエンコード処理を行わないようになる。
【００８９】
そしてホストＣＰＵ３０は、例えば次の第Ｋ＋１のフレーム（第Ｋ＋１のＶＯＰ）については、Ｈ／Ｗエンコード処理の開始指示をＨ／Ｗアクセラレータ８０に対して行う。これにより、Ｈ／Ｗエンコード処理後の第Ｋ＋１のフレームの動画データがＦＩＦＯバッファ９２に書き込まれ、内蔵ＣＰＵ７０は、この第Ｋ＋１のフレームの動画データに対するＳ／Ｗエンコード処理を行うことができる。この場合、ＦＩＦＯバッファ９２には、スキップされた第Ｋのフレームの動画データは書き込まれていない。従って、この第Ｋのフレームの動画データを廃棄したり無視したりする処理が不要になり、スムーズな処理を実現できる。
【００９０】
また図６（Ｂ）のデコード処理において、内蔵ＣＰＵ７０によるデコード処理にエラーが発生した場合に、本実施形態では、内蔵ＣＰＵ７０が、そのエラーの発生をホストＣＰＵ３０にレジスタ等を用いて通知する。そして、このように内蔵ＣＰＵ７０によるデコード処理にエラーが発生した場合には、ホストＣＰＵ３０が、内蔵ＣＰＵ７０に代わってデコード処理のソフトウェア処理部分を実行する。そしてホストＣＰＵ３０は、Ｓ／Ｗデコード処理後の動画データをＦＩＦＯバッファ９２に書き込む。これにより、Ｈ／Ｗアクセラレータ８０は、書き込まれた動画データに対してＨ／Ｗデコード処理を実行できるようになる。
【００９１】
デコード処理にエラーが発生した場合には、動画データ（ＶＯＰ）の解析を行う必要がある。しかしながら、ホストＣＰＵ３０からの動画データは、ＦＩＦＯであるホスト用バッファ９６に格納されているため、内蔵ＣＰＵ７０は、任意のアドレスにアクセスして動画データのエラー解析を行うことができない。一方、この動画データは、ホストＣＰＵ３０が送信したものであり、ホストＣＰＵ３０は、自身のメモリ内に記憶された動画データの任意のアドレスにアクセスしてエラー解析を行うことができる。これにより、内蔵ＣＰＵ７０のデコード処理にエラーが発生した場合にも、そのエラーを回復して、デコード処理を完結させることが可能になる。
【００９２】
４．スタートアップ時の動作
次に、本実施形態のスタートアップ（立ち上げ）時の動作について図７のシーケンス図を用いて説明する。
【００９３】
まずホストＣＰＵ３０が、内蔵ＣＰＵ７０によるアシスト処理の初期化設定を行う。そしてマルチメディア処理用プログラムをメモリ９０のプログラムロード領域９１にロードする。即ちホストメモリ４０に記憶されたマルチメディア処理用プログラム群の中から所望のマルチメディア処理用プログラム（デコード用プログラム、エンコード用プログラム）を選択して、メモリ９０にロードする。
【００９４】
次にホストＣＰＵ３０は、メモリ９０のプログラムロード領域９１のプロテクト処理を行う。このようにすることで、プログラムロード領域９１にロードされたマルチメディア処理用プログラムを保護することが可能になる。即ち、このようなプロテクト処理を行わないと、ホストＣＰＵ３０や内蔵ＣＰＵ７０が、データ等を間違ってプログラムロード領域９１に書き込んでしまう事態が生じ得る。このような事態が生じると、ロードされたプログラムが破壊され、システムがハングアップするなどの問題を招く。プログラムロード領域９１のプロテクト処理を行うことで、このような問題の発生を未然に防止できる。
【００９５】
次にホストＣＰＵ３０は、アシスト機能のイネーブルコマンド、クロックのイネーブルコマンド、リセット解除コマンドを送信し、スタートアップ完了ステータスの受信ウェイト状態に移行する。
【００９６】
内蔵ＣＰＵ７０は、リセット解除コマンドを受信すると、そのリセット状態を解除し、ブート処理などの初期化設定を行う。またメモリ９０のワーク領域９７の初期化（０クリア）を行う。そして内蔵ＣＰＵ７０は、スタートアップが完了すると、スタートアップ完了ステータスをホストＣＰＵ３０に送信し、ＡＣＫの受信ウェイト状態に移行する。するとホストＣＰＵ３０は、ＡＣＫを送信し、内蔵ＣＰＵ７０は、ＡＣＫを受信すると、デコード、エンコード開始コマンドのウェイト状態に移行する。
【００９７】
図７に示すように本実施形態では、ホストＣＰＵ３０からリセット解除コマンドを受信するまで、内蔵ＣＰＵ７０はリセット状態に設定される。そしてリセット解除コマンドを受信すると、内蔵ＣＰＵ７０のリセット状態が解除されて、マルチメディア処理用プログラムが実行される。そしてその後にホストＣＰＵ３０からリセットコマンドを受信すると、内蔵ＣＰＵ７０は再度リセット状態に設定される。このように本実施形態では、マルチメディア処理用プログラムを実行する時に、その都度、内蔵ＣＰＵ７０のリセット状態が解除され、それ以外の期間では、内蔵ＣＰＵ７０をリセット状態に設定できる。従って、動作する必要が無い期間において内蔵ＣＰＵ７０の動作を停止でき、省電力化を実現できる。なお図７では、ホストＣＰＵ３０によるリセット解除指示によりマルチメディア処理用プログラムが実行される方式を採用しているが、ホストＣＰＵ３０からの割り込みによりマルチメディア処理用プログラムが実行される方式を採用してもよい。
【００９８】
５．エンコード処理時の動作
次に、本実施形態のエンコード処理時の動作について図８のフローチャート及び図９のシーケンス図を用いて説明する。図８は主にホストＣＰＵ３０の動作・処理を説明するフローチャートである。
【００９９】
図８に示すように、ホストＣＰＵ３０は、エンコードデータバッファ９４へのデータ（カメラ１８からの動画データ）のライトが完了したか否かを判断する（ステップＳ３１）。そしてデータのライトが完了すると、データのライト完了フラグをクリアし（ステップＳ３２）、動き検出（ＭＥ）処理の開始を指示する（ステップＳ３３）。そして動き検出が完了したと判断すると、動き検出完了フラグをクリアする（ステップＳ３４、Ｓ３５）。
【０１００】
次に、ホストＣＰＵ３０は、レートコントロール処理を行う（ステップＳ３６）。即ち符号化データサイズに基づいて、量子化処理（図３のステップＳ２）の量子化ステップを変化させる。例えば符号化データサイズが大きい場合には、量子化ステップを大きくする。これにより量子化後のＤＣＴ係数（図５（Ｃ））のゼロデータの数が増える。一方、符号化データサイズが小さい場合には、量子化ステップを小さくする。これにより量子化後のＤＣＴ係数のゼロデータの数が減る。
【０１０１】
次に、ホストＣＰＵ３０は、ＱＰ値（量子化パラメータ）を設定して、Ｈ／Ｗエンコード処理の開始を指示する（ステップＳ３７）。これにより、Ｈ／Ｗアクセラレータ８０によるＨ／Ｗエンコード処理が実行される。そしてＨ／Ｗエンコード処理が終了したと判断すると、内蔵ＣＰＵ７０によるＳ／Ｗエンコード処理の開始を指示する（ステップＳ３８、Ｓ３９）。そして、エンコードストップか否かを判断し、エンコードストップではない場合にはステップＳ３１に戻り、エンコードストップの場合（所定フレーム数のエンコードが完了した場合）には処理を終了する（ステップＳ４０）。
【０１０２】
次に、図９のシーケンス図を説明する。まず、ホストＣＰＵ３０は、ＱＰ値を設定して、Ｈ／Ｗアクセラレータ８０によるＨ／Ｗエンコード処理の開始を指示し、エンコードの完了をウェイトする。そしてＨ／Ｗエンコード処理が完了すると、必要があればＧＯＶ（Group Of VOP）ヘッダを作成する。またＶＯＰ（Video Object Plane）ヘッダを作成して、メモリ９０の情報領域９９に、エンコードに必要な種々の情報を設定する。
【０１０３】
図１０（Ａ）に、エンコード処理時に情報領域９９に設定される情報の例を示す。内蔵ＣＰＵ７０等は、図１０（Ａ）に示す情報をホストＣＰＵ３０から知らされることで、適切なエンコード処理を実現できる。
【０１０４】
次に、ホストＣＰＵ３０は、Ｓ／Ｗエンコード処理の開始コマンドを送信し、ＡＣＫの受信ウェイト状態に移行する。そして内蔵ＣＰＵ７０がＡＣＫを送信すると、ホストＣＰＵ３０がそのＡＣＫを受信する。そして内蔵ＣＰＵ７０は、Ｓ／Ｗエンコード処理を開始し、処理後のデータ（動画データ）をホスト用バッファ９６（ＦＩＦＯ）にライトする。そして１ＶＯＰ分（広義には１フレーム分）のエンコード処理が終了したら、ｌａｓｔｅｎｃ＝１に設定する。
【０１０５】
ホストＣＰＵ３０は、ホスト用バッファ９６（ＦＩＦＯ）をリードする。即ちｌａｓｔｅｎｃ＝１になるまでホスト用バッファ９６からデータ（ハフマンデータ）をリードする。そして、バイトアライメントのためのＶＯＰのスタッフィングを行う。なおレートコントロールによるスキップフレーム（ＶＯＰ）の作成はホストＣＰＵ３０が行う。
【０１０６】
６．デコード処理時の動作
次に、本実施形態のデコード処理時の動作について図１１のフローチャート及び図１２のシーケンス図を用いて説明する。図１１は主にホストＣＰＵ３０の動作・処理を説明するフローチャートである。
【０１０７】
図１１に示すように、ホストＣＰＵ３０は、ＶＯＳ（Video Object Sequence）ヘッダ、ＶＯ（Video Object）ヘッダ、ＶＯＬ（Video Object Layer）ヘッダの解析を行う（ステップＳ５１、Ｓ５２、Ｓ５３）。またスタートコードの検出を行い（ステップＳ５４）、ＧＯＶヘッダがある場合にはＧＯＶヘッダの解析を行う（ステップＳ５５、Ｓ５６）。
【０１０８】
次に、ホストＣＰＵ３０は、Ｓ／Ｗデコード処理の開始を指示する（ステップＳ５７）。これにより、内蔵ＣＰＵ７０によるＶＯＰヘッダ解析とＶＣＬ復号化、逆スキャニング、逆ＤＣ／ＡＣ予測が行われるようになる。
【０１０９】
次に、全てのフレーム（ＶＯＰ）のデコード処理が完了したか否かを判断し（ステップＳ５８）、完了した場合には処理を終了する。一方、全てのフレームのデコード処理が完了していない場合には、１フレーム分のデコード処理が完了したか否かを判断し（ステップＳ５９）、完了した場合にはデコード完了フラグをクリアする（ステップＳ６０）。
【０１１０】
次にインターバル値を取得し、インターバル値分の時間（フレームレートに応じた時間）が経過したか否かを判断する（ステップＳ６１、Ｓ６２）。そして経過した場合には、表示エリア（ダブルバッファ構造のデコードデータバッファ９３の第１、第２のバッファのいずれか）の選択を行い（ステップＳ６３）、選択された表示エリアの表示データ（画像データ）を表示ドライバ１６に転送する（ステップＳ６４）。
【０１１１】
図１１のステップＳ５１〜Ｓ５６に示すように、本実施形態では、ＭＰＥＧストリーム（広義にはストリームデータ）の上位レイヤーのヘッダ解析（ＶＯＳ、ＶＯ、ＶＯＬ、ＧＯＶヘッダの解析）はホストＣＰＵ３０が行う。一方、ＭＰＥＧストリームの下位レイヤーのヘッダ解析（ＶＯＰヘッダの解析）は内蔵ＣＰＵ７０が行う。このように役割分担すれば、ホストＣＰＵ３０の制御の元で、ＭＰＥＧのデコード処理を効率化良く実施できるようになる。
【０１１２】
次に、図１２のシーケンス図を説明する。まず、ホストＣＰＵ３０は、ＶＯＳ、ＶＯ、ＶＯＬ、ＧＯＶのヘッダを解析し、情報領域９９に情報（データ、パラメータ）を設定する。そしてホスト用バッファ９６（ＦＩＦＯ）の初期化処理を行う。
【０１１３】
次にホストＣＰＵ３０はデコードリセットコマンドを送信し、ＡＣＫの受信ウェイト態に移行する。一方、内蔵ＣＰＵ７０は、アシストテーブルの展開後、ホストＣＰＵ３０からデコードリセットコマンドを受信すると、動作モードをデコードモードに設定する。またＨ／Ｗアクセラレータの初期化処理を行い、ＡＣＫを送信する。
【０１１４】
ホストＣＰＵ３０は、ＡＣＫを受信すると、データ（ハフマンデータ）をホスト用バッファ９６にライトする。即ち１ＶＯＰ分のデータをホスト用バッファ９６にライトする。
【０１１５】
次にホストＣＰＵ３０は、Ｓ／Ｗデコード開始コマンドを送信し、ＡＣＫの受信ウェイト状態に移行する。一方、内蔵ＣＰＵ７０は、デコード開始コマンドを受信すると、情報領域９９の情報を取得し、ＡＣＫを送信し、ホストＣＰＵ３０がそのＡＣＫを受信する。
【０１１６】
図１０（Ｂ）に、デコード処理時に情報領域９９に設定される情報の例を示す。内蔵ＣＰＵ７０は、図１０（Ｂ）に示す情報をホストＣＰＵ３０から知らされることで、適切なデコード処理を実現できる。
【０１１７】
次に内蔵ＣＰＵ７０は、Ｓ／Ｗデコード処理を開始する。そして処理後のデータをＦＩＦＯバッファ９２にライトする。そして１ＶＯＰ分のデータのデコード処理が終了したら、ｌａｓｔｄｅｃ＝１に設定する。また、ハフマンデータの解析中にエラーを検出したら、ｄｅｃｅｒｒ＝１に設定する。
【０１１８】
ホストＣＰＵ３０は、ｌａｓｔｄｅｃ＝１になるのをウェイトする。そして、ｌａｓｔｄｅｃ＝１になった場合には、ｄｅｃｅｒｒを確認する。そして、ｄｅｃｅｒｒ＝１の場合には、ＦＩＦＯバッファ９２をクリアし、内蔵ＣＰＵ７０に代わってホストＣＰＵ３０がＳ／Ｗデコード処理を実行する。
【０１１９】
次にホストＣＰＵ３０は、Ｈ／Ｗデコード処理の開始を指示する。そして開始の指示後、ホスト用バッファ９６の初期化処理に戻る。
【０１２０】
図１２に示すように本実施形態では、Ｓ／Ｗデコード処理にエラーが発生した場合には、内蔵ＣＰＵ７０に代わってホストＣＰＵ３０がＳ／Ｗデコード処理を実行する。このようにすることで、エラーが発生した場合にも、そのエラーを回復してＨ／Ｗデコード処理に移行し、デコード処理を完結できるようになる。
【０１２１】
７．ハンドシェーク通信
本実施形態では、ホストＣＰＵ３０、内蔵ＣＰＵ７０間でのコマンド、ステータスの転送を、レジスタ（出力レジスタ、入力レジスタ）を用いたハンドシェーク通信により実現している。これらのレジスタは、ホストＩ／Ｆ６０内に設けることができる。
【０１２２】
図１３、図１４のフローチャートを用いて本実施形態のハンドシェーク通信を説明する。なお、図１５には、ハンドシェーク通信により転送されるコマンドやステータスの例を示す。
【０１２３】
図１３は、ホストＣＰＵ３０から内蔵ＣＰＵ７０にデータ（コマンド、ステータス）を送信（出力）する場合のフローチャートである。まず、ホストＣＰＵ３０が、出力レジスタ（ビット７〜０）にデータをライトする（ステップＳ７１）。このライトにより出力ステータス（ビット８）＝１に自動設定される。
【０１２４】
次にホストＣＰＵ３０は、タイマをスタートし（ステップＳ７２）、出力ステータス＝０になるのをウェイトする（ステップＳ７３）。そして出力ステータス＝０になった場合には処理を終了する。一方、出力ステータス＝０にならない場合には、ステップＳ７２でスタートしたタイマがタイムオーバーになったか否かを判断する（ステップＳ７４）。そしてタイムオーバーになっていない場合にはステップＳ７３に戻り、タイムオーバーになった場合には処理を終了する。
【０１２５】
一方、内蔵ＣＰＵ７０は、出力レジスタ（ビット１５〜０）をリードする（ステップＳ７５）。このリードにより出力ステータス（ビット８）＝０に自動設定される。
【０１２６】
次に、ステップＳ７５のリード時に出力ステータス＝１になっていたか否かを判断する（ステップＳ７６）。そして出力ステータス＝１になっていなかった場合にはステップＳ７５に戻り、出力レジスタ（ビット１５〜０）を再度リードする。一方、ホストＣＰＵ３０がステップＳ７１で出力レジスタ（ビット７〜０）にデータをライトし、出力ステータス＝１になると、ホストＣＰＵ３０は出力レジスタのデータ（ビット７〜０）を取得する（ステップＳ７７）。
【０１２７】
図１４は、ホストＣＰＵ３０が内蔵ＣＰＵ７０からデータ（コマンド、ステータス）を受信（入力）する場合のフローチャートである。まず内蔵ＣＰＵ７０が入力レジスタ（ビット２３〜１６）にデータをライトする（ステップＳ８１）。このライトにより入力ステータス（ビット２４）＝１に自動設定される。次に内蔵ＣＰＵ７０は出力レジスタ（ビット１５〜０）をリードする（ステップＳ８２）。そして出力ステータス＝１か否かを判断し（ステップＳ８３）、出力ステータス＝１の場合には出力レジスタのデータ（ビット７〜０）を取得する（ステップＳ８４）。次に、内蔵ＣＰＵ７０は入力ステータス＝０か否かを判断し（ステップＳ８５）、入力ステータス＝０ではない場合にはステップＳ８２に戻り、入力ステータス＝０の場合には処理を終了する。
【０１２８】
ホストＣＰＵ３０は、入力レジスタ（ビット３１〜１６）をリードする（ステップＳ８６）。このリードにより入力ステータス（ビット２４）＝０に自動設定される。次に、ホストＣＰＵ３０は、入力ステータス＝１か否かを判断する（ステップＳ８７）。そして入力ステータス＝１ではない場合にはステップＳ８６に戻り、入力レジスタを再度リードする。一方、ステップＳ８１で内蔵ＣＰＵ７０により入力レジスタにデータがライトされ、入力ステータス＝１になった場合には、ホストＣＰＵ３０は、入力レジスタのデータ（ビット２３〜１６）を取得する（ステップＳ８８）。
【０１２９】
なお、本発明は本実施形態に限定されず、本発明の要旨の範囲内で種々の変形実施が可能である。例えば、明細書又は図面中の記載において広義や同義な用語（ホストプロセッサ、内蔵プロセッサ、フレーム、電子機器等）として引用された用語（ホストＣＰＵ、内蔵ＣＰＵ、ＶＯＰ、携帯電話機等）は、明細書又は図面中の他の記載においても広義や同義な用語に置き換えることができる。
【０１３０】
また本発明の電子機器、マルチメディア処理システム、表示コントローラの構成は、図１、図２等で説明した構成に限定されず、種々の変形実施が可能である。例えばこれらの図の構成要素の一部を省略したり、その接続関係を変更してもよい。また本発明で実現されるエンコード処理、デコード処理も図３、図４に限定されず、ＭＰＥＧ等の規格に応じた種々の変形実施が可能である。
【図面の簡単な説明】
【０１３１】
【図１】本実施形態の電子機器、マルチメディア処理システムの構成例。
【図２】本実施形態の表示コントローラの構成例。
【図３】エンコード処理の説明図。
【図４】デコード処理の説明図。
【図５】図５（Ａ）〜図５（Ｃ）はＤＣＴ、量子化の説明図。
【図６】図６（Ａ）、図６（Ｂ）はＦＩＦＯバッファを用いる手法の説明図。
【図７】スタートアップ時のシーケンス図。
【図８】エンコード処理のフローチャート。
【図９】エンコード処理のシーケンス図。
【図１０】図１０（Ａ）、図１０（Ｂ）は情報領域の説明図。
【図１１】デコード処理のフローチャート。
【図１２】デコード処理のシーケンス図。
【図１３】レジスタを用いたハンドシェーク通信の説明図。
【図１４】レジスタを用いたハンドシェーク通信の説明図。
【図１５】ハンドシェーク通信により転送されるコマンド、ステータスの例。
【符号の説明】
【０１３２】
１０  アンテナ、１２  変復調器、１４  操作部、１６  表示ドライバ、
１７  表示パネル、１８  カメラ、２０  マルチメディア処理システム、
３０  ホストＣＰＵ、４０  ホストメモリ、５０  表示コントローラ、
６０  ホストＩ／Ｆ、７０  内蔵ＣＰＵ、７２  第１のＨ／Ｗアクセラレータ、
８０  第２のＨ／Ｗアクセラレータ、９０  メモリ、９１  プログラムロード領域９１、９２  ＦＩＦＯバッファ、９３  デコードデータバッファ、
９４  エンコードデータバッファ、９５  表示バッファ、９６  ホスト用バッファ、
９７  ワーク領域、９８  テーブルアシスト用領域、９９  情報領域、
１００  メモリコントローラ、１１０  ドライバＩ／Ｆ、１２０  カメラＩ／Ｆ