特許 6223224 画像処理装置、及びその制御方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6223224

(24)【登録日】2017年10月13日

(45)【発行日】2017年11月1日

(54)【発明の名称】画像処理装置、及びその制御方法

(51)【国際特許分類】

   G06F 9/48 20060101AFI20171023BHJP

   G06F 9/50 20060101ALI20171023BHJP

【ＦＩ】

   G06F9/46 452F

   G06F9/46 465C

   G06F9/46 465A

【請求項の数】14

【全頁数】26

(21)【出願番号】特願2014-31387(P2014-31387)

(22)【出願日】2014年2月21日

(65)【公開番号】特開2015-156165(P2015-156165A)

(43)【公開日】2015年8月27日

【審査請求日】2016年10月12日

(73)【特許権者】

【識別番号】302062931

【氏名又は名称】ルネサスエレクトロニクス株式会社

(74)【代理人】

【識別番号】100103894

【弁理士】

【氏名又は名称】家入 健

(72)【発明者】

【氏名】松原 勝重

(72)【発明者】

【氏名】松見 隆之

(72)【発明者】

【氏名】望月 誠二

(72)【発明者】

【氏名】岩田 憲一

(72)【発明者】

【氏名】加谷 俊之

【審査官】 小林 哲雄

(56)【参考文献】

【文献】 特開２００２−３１２３３１（ＪＰ，Ａ）

【文献】 特開２００６−１４６９３７（ＪＰ，Ａ）

【文献】 特開２０１０−２７７２７２（ＪＰ，Ａ）

【文献】 特開２００５−１００２６４（ＪＰ，Ａ）

【文献】 特開２００８−２８７５９２（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４６−９／５４

Ｇ０６Ｆ １３／００

Ｇ０６Ｆ １５／８０

(57)【特許請求の範囲】

【請求項1】

複数のコンテンツからのリクエストを受け付ける受付部と、
前記コンテンツをデコードするコーデック処理部と、
前記リクエストに応じたタスクを並列して実行する複数の画像処理部と、
前記コーデック処理部で用いられるデコードのパラメータに基づいて、それぞれの前記画像処理部において前記タスクの処理が完了する推定時間を推定する推定部と、
前記タスクが目標完了時刻以内に完了するように、前記推定部で推定された推定時間に基づいて、複数の前記画像処理部が実行するタスクをスケジューリングするスケジュール部であって、前記推定時間に基づいて、前記タスクの実行順の入れ替えを行う、あるいは、前記タスクの実行先の前記画像処理部を決定するスケジュール部と、を備え、
前記パラメータに基づいて、前記画像処理部がバスにアクセスするアクセス回数を求め、前記アクセス回数に基づいて、前記推定時間を推定する画像処理装置。

【請求項2】

前記アクセス回数に応じた推定時間を、前記画像処理部が前回の前記タスクの実行に要した処理時間により補正する請求項１に記載の画像処理装置。

【請求項3】

前記推定部が、前記バスのレイテンシに基づいて、前記推定時間を推定している請求項１に記載の画像処理装置。

【請求項4】

前記アクセス回数に応じた推定時間を、前記バスのレイテンシにより補正する請求項３に記載の画像処理装置。

【請求項5】

前記複数のコンテンツに応じたタスクを、前記目標完了時刻以内に完了できない場合は、前記スケジュール部が、予め定められた優先度に応じてスケジューリングを行う請求項１に記載の画像処理装置。

【請求項6】

前記複数の画像処理部が少なくとも第１〜第３の画像処理部を含み、
前記スケジュール部が第１のタスクを前記第１の画像処理部に割り当てるようスケジューリングした後、前記第１のタスクが未実行である場合に、前記第１のタスクを前記第２の画像処理部に割り当てることで、前記第３の画像処理部をタスクが割り当てられない画像処理部とし、
前記第３の画像処理部のクロック又は電源を停止する請求項１に記載の画像処理装置。

【請求項7】

前記第１のタスクが前記第１の画像処理部に割り当てられてから実行開始されるまでの間に新たなリクエストが受け付けられた場合、前記新たなリクエストに対する第２のタスクの推定時間と、前記第１のタスクの推定時間を比較して、
前記推定時間の比較結果に応じて、前記第１のタスクを前記第２の画像処理部に割り当てるとともに、前記第２のタスクを前記第１の画像処理部に割り当てる請求項６に記載の画像処理装置。

【請求項8】

リクエストに応じたタスクを並列して実行する複数の画像処理部を備えた画像処理装置の制御方法であって、
複数のコンテンツからのリクエストを受け付け、
前記コンテンツをデコードし、
前記デコードのパラメータに基づいて、それぞれの前記画像処理部において前記タスクの処理が完了する推定時間を推定し、
前記タスクが目標完了時間以内に完了するように、前記推定時間に基づいて、複数の前記画像処理部が実行するタスクをスケジューリングし、
前記スケジューリングでは、前記推定時間に基づき、前記タスクの実行順の入れ替えを行う、あるいは、前記タスクの実行先の前記画像処理部を決定し、
前記パラメータに基づいて、前記画像処理部がバスにアクセスするアクセス回数を求め、前記アクセス回数に基づいて、前記推定時間を推定する制御方法。

【請求項9】

前記アクセス回数に応じた推定時間を、前記画像処理部が前回の前記タスクの実行に要した処理時間により補正する請求項８に記載の制御方法。

【請求項10】

前記バスのレイテンシに基づいて、前記推定時間を推定している請求項９に記載の制御方法。

【請求項11】

前記アクセス回数に応じた推定時間を、前記バスのレイテンシにより補正する請求項１０に記載の制御方法。

【請求項12】

前記複数のコンテンツに応じたタスクを、目標完了時刻以内に完了できない場合は、予め定められた優先度に応じてスケジューリングを行う請求項８に記載の制御方法。

【請求項13】

前記複数の画像処理部が少なくとも第１〜第３の画像処理部を含み、
第１のタスクを前記第１の画像処理部に割り当てるようスケジューリングした後、前記第１のタスクが未実行である場合に、前記第１のタスクを前記第２の画像処理部に割り当てることで、前記第３の画像処理部をタスクが割り当てられない画像処理部とし、
前記第３の画像処理部のクロック又は電源を停止する請求項８に記載の制御方法。

【請求項14】

新たなリクエストが受け付けられた後、前記新たなリクエストに対する第２のタスクの推定時間と、前記第１のタスクの推定時間とを比較して、
前記推定時間の比較結果に応じて、前記第１のタスクを前記第２の画像処理部に割り当てるとともに、前記第２のタスクを前記第１の画像処理部に割り当てる請求項１３に記載の制御方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は画像処理装置、及びその制御方法に関する。

【背景技術】

【0002】

特許文献１には、マルチプロセッサシステムにおいてプロセッサの利用効率を増加させる方法が開示されている。特許文献１に記載されたマルチプロセッサシステムでは、動作条件の主要なセットの評価に基づいて、厳密リアルタイムスケジュールと疑似リアルタイムスケジュールを交代的に選択している。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００６−１４６９３７号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

厳密リアルタイムスケジュールでは、予め決められた固定のタイミングでタスクを実行している。厳密リアルタイムスケジュールでは、性能は保証されるが、プロセッサの動作効率が低下してしまう。一方、疑似リアルタイムスケジュールでは、予め決められた固定の優先度で、ベストエフォートでタスクを実行している。この場合、プロセッサの動作効率を向上することはできるが、性能は保証されなくなってしまう。特許文献１では、バッファ中で占有するエントリ数を閾値と比較することで、疑似リアルタイムスケジューリングと厳密リアルタイムスケジューリングとを切り替えている。

【0005】

疑似リアルタイムスケジューリングでは、ベストエフォートで各プロセッサにタスクをスケジューリングしている。ここで、各タスクの終了時間を事前に推測することができないため、予め決められた固定の優先度に従ったスケジューリングしかできない。その結果、各タスクの処理量が変動して、特定のプロセッサにタスク負荷が偏ると、高効率でのスケジューリングができなくなってしまうという問題点がある。

【0006】

その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

【課題を解決するための手段】

【0007】

一実施の形態によれば、画像処理装置は、デコード又はエンコードのパラメータに基づいて、それぞれの処理部において前記タスクが完了する推定時間を推定して、推定された推定時間に基づいて、前記複数の処理部が実行するタスクをスケジューリングする。

【0008】

なお、上記実施の形態の装置を方法やシステムに置き換えて表現したもの、該装置または該装置の一部の処理をコンピュータに実行せしめるプログラム、該装置を備えたシステムなども、本発明の態様としては有効である。

【発明の効果】

【0009】

前記一実施の形態によれば、効率よくタスクをスケジューリングすることができる。

【図面の簡単な説明】

【0010】

【図1】実施形態１にかかる画像処理装置の構成を示すブロック図である。

【図2】実施形態１にかかる画像処理装置の制御方法を示すフローチャートである。

【図3】各処理部の動作タイミングを示す図である。

【図4】バスアクセス回数と推定時間との関係の一例を示すグラフである。

【図5】実施形態１にかかる画像処理装置でのスケジューリング処理を示すフローチャートである。

【図6】推定時間を用いないスケジューリングを説明するための図である。

【図7】推定時間を用いたスケジューリングを説明するための図である。

【図8】バスアクセス回数と推定時間との関係の別の例を示すグラフである。

【図9】バスアクセス回数と推定時間との関係の別の例を示すグラフである。

【図10】バスアクセス回数と推定時間との特性の別の例を示すグラフである。

【図11】実施形態２にかかる画像処理装置の構成を示すブロック図である。

【図12】バスアクセス回数と推定時間との関係の一例を示すグラフである。

【図13】タスクの再スケジューリングを行わない例を示す図である。

【図14】実施の形態３にかかるスケジューリング方法を説明するための図である

【図15】実施の形態３にかかるスケジューリング方法を説明するための図である

【図16】実施の形態３にかかるスケジューリング方法を説明するための図である

【図17】実施の形態３にかかるスケジューリング方法を説明するための図である

【図18】実施の形態３にかかるスケジューリング方法を説明するための図である

【図19】実施形態３にかかる画像処理装置でのスケジューリング処理を示すフローチャートである。

【図20】画像処理装置を用いた車載システムを示すブロック図である。

【図21】実施形態４にかかる画像処理装置の構成を示すブロック図である。

【発明を実施するための形態】

【0011】

説明の明確化のため、以下の記載及び図面は、適宜、省略、及び簡略化がなされている。また、様々な処理を行う機能ブロックとして図面に記載される各要素は、ハードウェア的には、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、メモリ、その他の回路で構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。なお、各図面において、同一の要素には同一の符号が付されており、必要に応じて重複説明は省略されている。

【0012】

また、上述したプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ ｃｏｍｐｕｔｅｒ ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（ｔａｎｇｉｂｌｅ ｓｔｏｒａｇｅ ｍｅｄｉｕｍ）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ ＰＲＯＭ）、フラッシュＲＯＭ、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（ｔｒａｎｓｉｔｏｒｙ ｃｏｍｐｕｔｅｒ ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

【0013】

実施の形態１
本実施の形態に係る画像処理装置は、コンテンツに対して符号化又は復号化等の画像処理を行うプロセッサシステムである。画像処理装置は複数のプロセッサを備えたマルチプロセッサシステムである。複数のプロセッサは、並列に画像処理を行う。より具体的には、画像処理装置は、複数のコンテンツに対して、並列にビデオ符号化・復号化を行う。本実施の形態にかかる画像処理装置とその制御方法について、図１を用いて説明する。図１は、画像処理装置の全体構成を示すブロック図である。

【0014】

画像処理装置１００は、リクエスト受付部１１、リクエストキュー１２、リクエスト選択部１３、可変長符号処理部ＶＬＣ、画像信号処理部ＣＥ０、画像信号処理部ＣＥ１、画像信号処理部ＣＥ２、推定部１６、スケジュール部１５、優先情報記憶部４１と、データバス５１、メモリコントローラ５２、及びメモリ５３を備えている。ここでは、画像処理装置１００が、映像コンテンツをリアルタイムで再生するためのデコーダであるとして説明する。

【0015】

リクエスト受付部１１は、リクエスト元３１〜３４からのリクエストを受け付ける。ここでは、リクエスト受付部１１が、リクエスト元３１〜３４から、コンテンツＡ〜コンテンツＤに対するリクエストをそれぞれ受け付けている。リクエスト元３１からリクエストされたコンテンツをコンテンツＡとし、リクエスト元３２からリクエストされたコンテンツをコンテンツＢとし、リクエスト元３３からリクエストされたコンテンツをコンテンツＣとし、リクエスト元３４からリクエストされたコンテンツをコンテンツＤとしている。コンテンスＡ〜Ｄは、それぞれ独立したコンテンツである。

【0016】

以下、説明の簡略化のため、コンテンツＡのリクエストをリクエストＡとする。同様に、コンテンツＢ、Ｃ、ＤのリクエストをそれぞれリクエストＢ、Ｃ、Ｄとする。さらに、リクエストＡに応じて、画像処理装置１００が実行するタスクをタスクＡとする。同様に、リクエストＢ、Ｃ、Ｄに応じて、画像処理装置１００が実行するタスクをそれぞれ、タスクＢ、Ｃ、Ｄとする。例えば、コンテンツＡを再生するための処理がタスクＡとなる。

【0017】

例えば、リクエスト元３１は画像処理装置１００に、コンテンツＡの再生をリクエストする。そして、リクエスト元３１は、リクエストＡを画像処理装置１００に順次送信する。すなわち、コンテンツＡを再生させるために、リクエスト元３１は、繰り返しリクエストＡを画像処理装置１００に送信する。例えば、リクエスト元３１は、コンテンツＡのピクチャ単位（フレーム単位もしくはフィールド単位）で送信する。そして、画像処理装置１００は、リクエスト元３１から送信されるコンテンツをリアルタイムで再生する。すなわち、リクエストが受け付けられたコンテンツデータに対して随時画像処理を行う。

【0018】

リクエスト元３１〜３４から送信されたリクエストには、所定の符号化方式で符号化されたコンテンツデータが含まれている。例えば、コンテンツデータは、ハフマン符号を用いて圧縮されている。符号化形式としては、例えば、Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣ等を用いることができる。

【0019】

リクエストキュー１２は、リクエスト受付部１１で受け付けられたリクエストを格納する。リクエストキュー１２は複数のリクエストを格納できるようになっている。なお、リクエストキュー１２に空きがない場合、リクエスト受付部１１は、リクエストを受け付けない。また、リクエストキュー１２は、リクエストに応じて、目標となる完了時刻（以下、目標完了時刻）をスケジュール部１５に出力する。

【0020】

なお、目標完了時刻とは、コンテンツの再生などを遅滞なく行うためにタスクを完了しなければならない時刻を示す。目標完了時刻は、リクエストごとに設定されている。すなわち、あるリクエストに対して画像信号処理部ＣＥ０〜ＣＥ２が実行するタスクが、目標完了時刻までに完了すれば、当該コンテンツが遅滞なく再生される。一方、コンテンツに対応するタスクが目標完了時刻までに完了できなくなってしまった場合、コンテンツ再生時にコマ落ちなどが発生するおそれがある。

【0021】

リクエスト選択部１３は、リクエストキュー１２に格納されたリクエストに応じて、タスクを実行する画像信号処理部ＣＥ０〜ＣＥ２を選択する。例えば、リクエスト選択部１３は、リクエストＡに対するタスクＡを実行するプロセッサとして、画像信号処理部ＣＥ０を選択する。また、リクエスト選択部１３は、スケジュール部１５で設定されたスケジュールに応じて、タスクを実行する画像信号処理部ＣＥを選択している。

【0022】

可変長符号処理部ＶＬＣは、可変長符号デコードを行うコーデック処理部である。可変長符号処理部ＶＬＣは、リクエスト元３１〜３４からのコンテンツデータに対してデコード処理を行う。可変長符号処理部ＶＬＣは、例えばハフマン符号に対してデコード処理を行うことで、非圧縮データを生成する。そして、メモリコントローラ５２は、非圧縮データとなったコンテンツデータをメモリ５３にバッファする。可変長符号処理部ＶＬＣは、例えば、リクエストの受付順に、コンテンツデータをデコードする。あるいは、可変長符号処理部ＶＬＣは、ビットレートの高いコンテンツデータをビットレートの低いコンテンツデータよりも先にデコードしてもよい。

【0023】

さらに、可変長符号化処理部ＶＬＣは、推定用コーデックパラメータを推定部１６に出力する。推定用コーデックパラメータは、推定部１６における完了時間の推定に用いられる。例えば、符号化のタイプや、動きベクトルの本数が推定用コーデックパラメータとなる。

【0024】

画像信号処理部ＣＥ０〜ＣＥ２は、リクエストに応じたタスクを実行する画像処理プロセッサである。なお、以下の説明において、画像信号処理部ＣＥ０〜ＣＥ２を識別せずに説明する場合、画像信号処理部ＣＥとして記載する。画像信号処理部ＣＥは、可変長符号処理部ＶＬＣでデコード処理が行われたコンテンツデータに対して、画像処理を行う。画像信号処理部ＣＥ０〜ＣＥ２は、例えば、離散的逆コサイン変換（ＩＤＣＴ）等の数学的な信号処理を実行する。これにより、コンテンツデータが再生可能となる。

【0025】

画像信号処理部ＣＥ０〜ＣＥ２は、それぞれ並列に信号処理を行う。例えば、画像信号処理部ＣＥ０がコンテンツＡに対する画像処理を行っている間、画像信号処理部ＣＥ１がコンテンツＢに対する画像処理を行い、かつ、画像信号処理部ＣＥ２がコンテンツＣに対する画像処理を行う。これにより、画像処理装置１００が異なるコンテンツを並列に再生することができる。あるいは、リクエストＡが連続した場合、画像信号処理部ＣＥ０〜ＣＥ２がタスクＡを並行して処理していてもよい。画像信号処理部ＣＥ０〜ＣＥ２は、同等のプロセッサとなっている。

【0026】

画像信号処理部ＣＥは、画像信号処理における補正用コーデックパラメータを推定部１６に出力する。補正用コーデックパラメータは、推定部１６における推定完了時間の補正に用いられる。例えば、符号化のタイプや、動きベクトルの本数が補正用コーデックパラメータとなる。あるいは、バスアクセス回数を補正用コーデックパラメータとしてもよい。さらに、画像信号処理部ＣＥは、タスクの完了に要した処理時間を推定部１６に出力する。画像信号処理部ＣＥは、実際のタスク処理に要した処理時間を補正用コーデックパラメータに対応付けて、推定部１６に出力する。画像信号処理ＣＥは、リクエスト毎に、タスクの処理時間を推定部１６に出力する。

【0027】

可変長符号処理部ＶＬＣ、画像信号処理部ＣＥは、ピクチャ単位（フレーム単位もしくはフィールド単位）で、コンテンツデータを処理する。可変長符号処理部ＶＬＣ、画像信号処理部ＣＥは、データバス５１を介してメモリコントローラ５２と接続されている。メモリコントローラ５２は、メモリ５３に対するデータの書き込み、及び読み出しを制御する。メモリ５３は、例えば、ＤＤＲ（Ｄｏｕｂｌｅ Ｄａｔａ Ｒａｔｅ）メモリであり、コンテンツデータやコーデックパラメータ等をバッファする。

【0028】

例えば、可変長符号処理部ＶＬＣ、及び画像信号処理部ＣＥが処理を行うとき、コンテンツデータはメモリ５３に書き込まれる。あるいは、可変長符号処理部ＶＬＣ、及び画像信号処理部ＣＥが処理を行うとき、メモリ５３から必要なデータを読み出す。例えば、可変長符号処理部ＶＬＣが可変長符号処理を行うためのデータを、メモリコントローラ５２は、メモリ５３に書き込む、又はメモリ５３から読み出す。また、画像信号処理部ＣＥが画像信号処理を行うためのデータを、メモリコントローラ５２は、メモリ５３に書き込む、又はメモリ５３から読み出す。すなわち、可変長符号処理部ＶＬＣ、及び画像信号処理部ＣＥがデータバス５１にアクセスすることで、メモリ５３へのデータの書き込み、及び読み出しが実行させる。

【0029】

推定部１６は、補正用コーデックパラメータ、推定用コーデックパラメータ、及び処理時間に基づいて、画像信号処理部ＣＥがタスク処理に要する時間を推定する。すなわち、推定部１６は、リクエストに応じたタスクの実行にかかる処理時間を推定時間として推定する。推定部１６は、推定時間をスケジュール部１５に出力する。推定部１６は、コンテンツの１処理（ピクチャ）単位に、推定時間を動的に推定する。推定部１６は、可変長符号処理部ＶＬＣ、及び画像信号処理部ＣＥから出力されるパラメータや実際の処理時間を用いて、随時、推定時間を補正する。

【0030】

優先情報記憶部４１は、コンテンツの優先情報を記憶している。優先情報は、どのコンテンツを優先して処理するかを示す情報である。すなわち、優先情報記憶部４１は、コンテンツＡ〜Ｄのうち、どのコンテンツを優先して処理するかが設定されている。優先情報記憶部４１は、優先情報をスケジュール部１５に出力する。

【0031】

スケジュール部１５は、目標完了時刻、優先情報、及び推定時間に基づいて、画像信号処理部ＣＥ０〜ＣＥ２が実行するタスクのスケジューリングを行う。すなわち、スケジュール部１５は、リクエストキュー１２に格納されているリクエストのそれぞれに対して、タスク実行先の画像信号処理部ＣＥを指定する。例えば、リクエストＡ、Ｂがリクエストキューに格納されている場合、画像信号処理部ＣＥ０がタスクＡを実行し、画像信号処理部ＣＥ１がタスクＢを実行するように、スケジュール部１５は、リクエストと画像信号処理部ＣＥを対応付けていく。

【0032】

スケジュール部１５は、各リクエストの実行開始と、実行先を動的に決定する。スケジュール部１５は、推定時間を用いて、各リクエストの目標完了時刻を満たすように、実行順や実行先を決定する。全てのリクエストが目標完了時刻内にスケジューリングできない場合は、予め決められたコンテンツ間の優先順に従って決定する。すなわち、優先情報に従った順番で、タスクの実行順、及び実行先を決定する。例えば、コンテンツＡがコンテンツＢ〜Ｄよりも優先度が高い場合、コンテンツＡに対するタスクＡを優先的に実行させる。

【0033】

そして、スケジュール部１５は、リクエスト毎に、タスク実行先のプロセッサを指定する。リクエスト選択部１３は、スケジュール部１５で設定されたスケジュールに従って、タスク実行先の画像信号処理部ＣＥを選択する。したがって、リクエスト選択部１３は、画像信号処理部ＣＥ０〜ＣＥ２の中からタスクの実行先となる画像信号処理部ＣＥを選択する。よって、タスクの実行先に選択された画像信号処理部ＣＥは、当該タスクを実行する。

【0034】

次に、図２を用いて、画像処理装置１００の動作について、説明する。図２は、画像処理装置１００の全体動作を示すフローチャートである。

【0035】

まず、リクエスト受付部１１がリクエスト元からのリクエストを受け付ける（Ｓ１０１）。すると、リクエストに対応するコンテンツデータに対して、可変長符号処理部ＶＬＣが符号化処理を実行する（Ｓ１０２）。可変長符号化処理部ＶＬＣは、例えば、リクエストが受け付けられた順番に、コンテンツデータをデコードする。さらに、可変長符号処理部ＶＬＣは、推定用コーデックパラメータを推定部１６に出力する。

【0036】

推定部１６が、画像信号処理部ＣＥがリクエストに対応するタスクを完了する推定時間を推定する（Ｓ１０３）。推定部１６は、可変長符号処理部ＶＬＣから出力された推定用コーデックパラメータ等に基づいて、推定時間を推定している。

【0037】

そして、スケジュール部１５は、推定時間に基づいて、リクエストのスケジューリングを行う（Ｓ１０４）。スケジュール部１５でのスケジュールに従って、画像信号処理部ＣＥがタスクを実行する、あるいは、画像信号処理部ＣＥに対する実行予約がなされる（Ｓ１０５）。そして、画像信号処理部ＣＥがタスクの実行を終了したら、補正用コーデックパラメータを推定部１６に出力する（Ｓ１０６）。すなわち、実際の処理時間に、動きベクトルの本数と符号化のタイプを対応付けて、推定部１６に出力する。

【0038】

可変長符号処理部ＶＬＣと画像信号処理部ＣＥは、それぞれ別個にリクエストを受ける。すなわち、あるリクエストについて、可変長符号処理部ＶＬＣがリクエストを受けた後、画像信号処理部ＣＥがリクエストを受ける。図３に可変長符号処理部ＶＬＣと画像信号処理部ＣＥのデコーダ動作タイミング例を示す。可変長符号処理部ＶＬＣでの処理結果は一度メモリ５３にバッファされる。そして、画像信号処理部ＣＥがメモリ５３から処理結果を読み出して、処理を行う。このように、あるリクエストについて、可変長符号処理部ＶＬＣが処理を行った後、画像信号処理部ＣＥが処理を行う。

【0039】

次に、推定部１６における推定処理について説明する。推定部１６は、受け付けたリクエストのタスク実行にかかる画像信号処理部ＣＥの処理時間を推定時間として推定する。推定部１６は、可変長符号処理部ＶＬＣが出力するパラメータを用いたフィードフォワード推定値に基づいて、推定時間を求めている。すなわち、フィードフォワード推定値を基に、画像信号処理部ＣＥが直前に出力した処理時間をフィードバック補正する。

【0040】

推定部１６における推定時間の推定について、図４を用いて詳細に説明する。図４はバスアクセス回数と推定時間との関係の一例を示すグラフである。図４では、横軸が画像信号処理部ＣＥのバスアクセス回数を示し、縦軸が推定時間を示している。すなわち、図４は、バスアクセス回数に対する推定時間の特性を示している。

【0041】

可変長符号処理部ＶＬＣでは、デコードのパラメータとして、符号化のタイプや動きベクトルの本数などが決まる。そして、推定部１６は、符号化のタイプや動きベクトルの本数に基づいて、画像信号処理部ＣＥがバスにアクセスする回数を求める。推定部１６は、バスアクセス回数に応じて、推定時間を推定する。具体的には、符号化のタイプがフレーム間符号化の場合、フレーム内符号化に比べて、処理が複雑になるため、バスアクセス回数が増加する。また、動きベクトルの本数が多いほど、処理が複雑になるため、バスアクセス回数が増加する。例えば、推定部１６は、予め設定されたテーブルを参照して、符号化のタイプ及び動きベクトルの本数からバスアクセス回数を求める。

【0042】

可変長符号処理部ＶＬＣは、あるリクエストに符号化のタイプ及び動きベクトルの本数をコーデックパラメータとして推定部１６に出力する。推定部１６は、符号化のタイプ及び動きベクトルの本数に応じて、当該リクエストにおける画像信号処理部ＣＥのバスアクセス回数を算出する。そして、推定部１６は、バスアクセス回数に基づいて、処理時間を推定する。

【0043】

図４では、バスアクセス回数に応じて推定時間が線形に増加する特性を示している。したがって、推定部１６は、バスアクセス回数に基づいて、処理時間をフィードフォワード推定することができる。さらに、画像信号処理部ＣＥで以前のリクエストの処理に要した処理時間を用いて、推定時間をフィードバック補正している。例えば、前回のリクエストの処理に要した処理時間を用いて、推定時間の増分の傾きや基準値（切片）を補正している。図４では、処理時間の実績値を用いたフィードバック補正後の特性を実線で示し、フィードバック補正前の特性を破線で示している。推定部１６は、フィードバック補正後の特性を参照して、バスアクセス回数に応じた推定時間を推定する。

【0044】

そして、スケジュール部１５は、推定部１６で推定した推定時間を用いて、リクエストのスケジューリングを行う。すなわち、スケジュール部１５はリクエストを処理する画像信号処理部ＣＥとその順番を決定する。スケジュール部１５は、各タスクが目標完了時刻を越えないように、リクエストの順番入れ替えや、実行する画像信号処理部ＣＥを決定する。

【0045】

図５にスケジュール部１５におけるスケジューリングのフローチャートを示す。まず、リクエストがあるとｉ＝０に設定する（Ｓ２０１）。なお、ｉは画像信号処理部ＣＥ０〜ＣＥ２を識別する数である。図１の場合、すなわち、画像信号処理部ＣＥが３個の場合、ｉは０、１、２となる。ｉ＝０の場合、画像信号処理部ＣＥ０を示し、ｉ＝１の場合の画像信号処理部ＣＥ１を示し、ｉ＝２の場合、画像信号処理部ＣＥ２を示す。

【0046】

ｉ＝０に設定した後、画像信号処理部ＣＥｉが実行中、かつ割り当て可能か否かを判定する（Ｓ２０２）。すなわち、他のタスクを実行中の画像信号処理ＣＥｉ（ここでは、ｉ＝０のため画像信号処理部ＣＥ０）において、リクエストのタスクを実行した場合、そのタスクが目標完了時刻までに完了するか否かを判定する。画像信号処理部ＣＥｉが実行中、かつ割り当て可能な場合、スケジュール部１５が画像信号処理部ＣＥｉに処理開始予約を行う（Ｓ２０３）。そして、スケジュール部１５がタスクのスケジューリングを終了する。なお、処理開始予約がなされた場合、画像信号処理部ＣＥｉが現在実行しているタスクが終了したら、その後に該当リクエストのタスクを実行する。もちろん、画像信号処理部ＣＥｉに処理開始を予約する前に、既に画像信号処理部ＣＥｉに他のタスクの処理開始予約がなされていた場合、現在実行中のタスクと、既に処理開始予約済みのタスクの処理が完了したら、画像信号処理部ＣＥｉは、該当リクエストのタスクを実行する。

【0047】

一方、画像信号処理部ＣＥｉが実行中、かつ割り当て可能でない場合、ｉをインクリメントする（Ｓ２０４）。そして、ｉが（ＣＥ最大数−１）を超えているか否かいないかを判定する（Ｓ２０５）。ｉが（ＣＥ最大数−１）以下の場合（Ｓ２０５のＮＯ）、ステップＳ２０２に戻る。すなわち、画像信号処理部ＣＥｉ（ここでは、ｉ＝１）が実行中であり、かつ割り当て可能かを判定する。このように、ステップＳ２０２〜ステップＳ２０５の処理を繰り返すことで、実行中、かつ割り当て可能な画像信号処理部ＣＥｉを画像信号処理部ＣＥ０から順番に探索することができる。

【0048】

ｉが（ＣＥ最大数−１）を越えた場合（Ｓ２０５のＹＥＳ）、すなわち、実行中、かつ割り当て可能な画像信号処理部ＣＥｉがない場合、ｉ＝０に設定する（Ｓ２０６）。すなわち、処理を実行中の画像信号処理部ＣＥのうち、タスクを処理可能な画像信号処理部ＣＥがない場合、ステップＳ２０６に移行する。そして、ｉ＝０に設定したら、画像信号処理部ＣＥｉが未実行であるか否かを判定する（Ｓ２０７）。すなわち、画像信号処理部ＣＥ０がタスクを処理中であるか否かを判定する。画像信号処理部ＣＥｉが未実行の場合（Ｓ２０７のＹＥＳ）、画像信号処理部ＣＥｉで処理を開始する（Ｓ２０８）。そして、スケジュール部１５がタスクのスケジューリングを終了する。すなわち、スケジュール部１５がタスクを実行する画像信号処理部ＣＥｉを決定したら、即座に、画像信号処理部ＣＥｉがタスクの実行を開始する。

【0049】

一方、画像信号処理部ＣＥｉが未実行の場合（Ｓ２０７のＮＯ）、ｉをインクリメントする（Ｓ２０９）。そして、ステップＳ２０５と同様に、ｉが（ＣＥ最大数−１）を超えているか否かいないかを判定する（Ｓ２１０）。ｉが（ＣＥ最大数−１）以下の場合（Ｓ２１０のＮＯ）、ステップＳ２０７に戻る。すなわち、画像信号処理部ＣＥｉ（ここでは、ｉ＝１）がタスクを処理中であるか否かを判定する。このように、ステップＳ２０７〜ステップＳ２１０の処理を繰り返すことで、タスクを未実行の画像信号処理部ＣＥｉを画像信号処理部ＣＥ０から順番に探索することができる。

【0050】

ｉが（ＣＥ最大数−１）を越えた場合、すなわち、未実行の画像信号処理部ＣＥｉがない場合（Ｓ２１０のＹＥＳ）、ステップＳ２１１に移行する。ステップＳ２１１では、スケジュール部１５が優先情報を参照して、リクエストのタスクが優先タスクであるか否かを判定する。リクエストのタスクが優先タスクでない場合（Ｓ２１１のＮＯ）、そのタスクの処理開始を予約せずに終了する。リクエストのタスクが優先タスクであるか否かを判定する。リクエストのタスクが優先タスクである場合（Ｓ２１１のＹＥＳ）、一番早く処理が完了する画像信号処理部ＣＥに処理開始を予約する（Ｓ２１２）。すなわち、処理中のタスク、及び処理開始予約されているタスクの全てを完了する時刻が最も早い画像信号処理部ＣＥにタスクの処理開始を予約する。そして、そのタスクに対するスケジューリングを終了する。

【0051】

なお、スケジュール部１５は、優先タスクであるか否かは、優先情報記憶部４１に記憶された優先情報に基づいて判定される。例えば、優先順位の高いコンテンツに関するタスクの場合、スケジュール部１５は、優先タスクと判定する。

【0052】

このように、動作中の画像信号処理部ＣＥｉの目標完了時刻までの時間を使いきることを優先して、スケジュール部１５は、タスクをスケジューリングしている。例えば、動作中の画像信号処理部ＣＥ０が、目標完了時刻内にタスクを完了できない場合、次の画像信号処理部ＣＥ１にタスクを割り当てている。このようにすることで、効率よくスケジューリングすることができる。さらに、いずれの画像信号処理部ＣＥも、目標完了時刻までにタスクを完了できない場合、優先タスクが優先的に処理されるように、スケジュール部１５がスケジューリングしている。こうすることで、優先順位の高いコンテンツを優先的に再生することができる。

【0053】

次に、コンテンツＡ→Ｂ→Ｃ→Ｄの順にリクエストを受け付けた例を説明する。図６は、本実施の形態にかかるスケジューリング方法を用いずにスケジューリングした例である。すなわち、図６では、推定部１６が推定時間を推定していない例を示している。図７は、本実施の形態にかかるスケジューリング方法を用いてスケジューリングした例を示す。図６、図７では、画像信号処理部ＣＥ０〜画像信号処理部ＣＥ２にコンテンツＡ〜Ｄのタスクを割り当てる例を示している。さらに、コンテンツＡ〜Ｄの目標完了時刻は同じになっている。

【0054】

図６では、１番目のタスクＡを画像信号処理部ＣＥ０に割り当てている。そして、２番目のタスクＢを画像信号処理部ＣＥ１に割り当て、３番目のタスクＣを画像信号処理部ＣＥ２に割り当てている。リクエストＣの後に、リクエストＤを受け付けた場合、画像信号処理部ＣＥ０〜ＣＥ２のいずれもタスクＤを目標完了時刻までに完了することができない。すなわち、リクエストＤに対するタスク処理は目標完了時刻を越えてしまい、目標未達が発生してしまう。画像信号処理部ＣＥ１の動作スロットは半分近く残っており、動作効率が悪くなってしまう。

【0055】

本実施の形態に係るスケジュール方法では、リクエスト受付部１１が１番目のリクエストＡを受け付けると、推定部１６がタスクＡの推定時間を推定している。そして、推定時間に応じて、図７に示すように、スケジュール部１５がタスクＡを画像信号処理部ＣＥ０に割り当てる。次に、２番目のリクエストＢを受け付けると、推定部１６がタスクＢの推定時間を推定する。スケジュール部１５は、タスクＡ、Ｂの推定時間により、画像信号処理部ＣＥ０がタスクＡの処理後、タスクＢを実行しても、タスクＢの処理が目標完了時刻を越えないことと判定する。したがって、スケジュール部１５は、タスクＡの後に、タスクＢの処理開始予約を行う。

【0056】

次に、リクエスト受付部１１がリクエストＣを受け付けると、推定部１６がタスクＣの推定時間を推定する。スケジュール部１５は、タスクＡ〜Ｃの推定時間により、画像信号処理部ＣＥ０でタスクＣを実行すると、タスクＣの処理が、目標完了時刻を越えてしまうと判定する。したがって、スケジュール部１５は、タスクＣを画像信号処理部ＣＥ１に割り当てる。未実行の画像信号処理部ＣＥ１は、タスクＣが割り当てられると、タスクＣの処理を開始する。

【0057】

さらに、リクエスト受付部１１がリクエストＤを受け付けると、推定部１６がタスクＤの推定時間を推定する。なお、リクエストＤの受付時には、画像信号処理部ＣＥ０がタスクＡを処理しており、画像信号処理部ＣＥ１がタスクＣを処理している。スケジュール部１５は、タスクＡ〜Ｄの推定時間により、画像信号処理部ＣＥ０、又は画像信号処理部ＣＥ１がタスクＤを実行すると、タスクＤの処理が、目標完了時刻を越えてしまうと判定する。したがって、スケジュール部１５は、タスクＤを画像信号処理部ＣＥ２に割り当てる。未実行の画像信号処理部ＣＥ２は、タスクＤが割り当てられると、タスクＤの処理を開始する。

【0058】

このように、本実施の形態に係るスケジュール方法では、推定部１６は、リアルタイムでタスクの推定時間を推定している。タスクＢの割り当て前に、タスクＢの推定時間を得ることができる。よって、画像信号処理部ＣＥ０でタスクＡに続いてタスクＢを実行開始予約することができる。これにより、全リクエストＡ〜Ｄの目標完了時刻内にタスクを完了でき、動作効率のよいスケジューリングを実現することができる。このように、推定部１６が各リクエストの処理時間を推定している。そして、スケジュール部１５は、推定時間を基に各リクエストのタスクの実行順の入れ替えや実行先の画像信号処理部ＣＥを決定している。こうすることで、画像信号処理部ＣＥの動作効率を改善することができ、高い実行効率を得ることができる。

【0059】

ここでは、可変長符号処理部ＶＬＣでのコーデックパラメータに基づいて、推定時間を推定している。これにより、推定精度を向上することができ、処理時間が変動する場合でも、目標完了時刻内にタスクを完了することができるよう、適切にスケジューリングすることができる。

【0060】

より具体的には、推定部１６は、コーデックパラメータに基づいて、画像信号処理部ＣＥのバスのアクセス回数を求めている。そして、推定部１６は、バスのアクセス回数に基づいて、推定時間を推定している。これにより、簡便かつ正確に推定時間を求めることができる。さらに、推定部１６は、画像信号処理部ＣＥが前回のタスクの実行に要した処理時間により、推定時間を補正している。こうすることで、推定精度を向上することができる。

【0061】

また、目標完了時刻内にタスクが終了するようにスケジューリングできない場合、予め設定された優先度に基づいて、スケジューリングしている。これにより、適切にスケジューリングすることができる。すなわち、優先度の高いコンテンツを再生することができる。

【0062】

（推定時間の推定処理１）
次に、図４に戻り、バスアクセス回数から、推定時間を求めるための推定処理についての１例について説明する。図４は、バスアクセス回数と推定時間の関係を示すグラフである。図４では、フィードバック補正前の直線（図４中の破線）と、フィードバック補正後の直線（図４中の実線）で傾きが異なっている。

【0063】

例えば、フィードバック補正前のバスアクセス回数と推定時間の関係が線形の場合、以下の式（１）が得られる。
ｔ＝ａｘ＋ｂ ・・・（１）

【0064】

なお、ｔはフィードバック補正前の推定時間、ｘはバスアクセス回数、ａ及びｂは任意の定数である。図４において、式（１）のａは、傾きを示し、ｂは切片を示している。推定処理１では、定数ｂを一定にしている。そして、一つ前のタスクの処理にかかった時間を用いて、定数ａを補正する。例えば、推定部１６は、画像信号処理部ＣＥが既に実行したタスクの処理時間をバスアクセス回数に対応付けて保存している。そして、推定部１６は、画像信号処理部ＣＥの推定時間を推定する場合、処理時間を用いて、傾きａを補正する。

【0065】

フィードバック補正後のバスアクセス回数と推定時間の関係は、以下の式（２）で示される。
ｔ’＝ａ’ｘ＋ｂ ・・・（２）

【0066】

なお、ｔ’は、フィードバック補正後の推定時間であり、ａ’は、補正後の傾きを示す定数である。このように、一つ前のタスクの処理時間に基づいて、補正前後で切片ｂを一定にして、傾きを補正している。そして、式（２）のｘにバスアクセス回数を代入することで、推定部１６は、推定時間ｔ’を算出している。よって、より正確に推定時間を推定することができる。

【0067】

なお、上記の説明では、一つ前のタスクの処理時間を用いて、傾きａ’を求めたが、複数のタスクの処理時間を用いて、傾きａ’を求めてもよい。この場合、複数の処理時間を用いて、特性を示す近似式を求めることができる。さらには、タスクの処理順に重み付けを持たせて、近似してもよい。すなわち、新しいタスクの処理時間ほど重みを大きくして、近似式を求めればよい。これにより、より正確に推定時間を求めることができる。

【0068】

（推定時間の推定処理２）
次に、推定時間の推定処理の変形例について、図８を用い説明する。図８は、バスアクセス回数と推定時間の関係を示すグラフであり、図４に対応するグラフを示している。図８では、フィードバック補正前の直線（図９中の破線）と、フィードバック補正後の直線（図８中の実線）で切片が異なっている。

【0069】

フィードバック補正前のバスアクセス回数と推定時間の関係が上記の（１）式で示されるとすると、補正後の関係式は以下の式（３）のようになる。
ｔ’＝ａｘ＋ｂ’ ・・・（３）

【0070】

なお、ｔ’は、フィードバック補正後の推定時間であり、ｂ’は、補正後の切片を示す定数である。このように、一つ前のタスクの処理時間に基づいて、補正前後で傾きａを一定にして、切片を補正している。そして、式（３）のｘにバスアクセス回数を代入することで、推定部１６は、推定時間ｔ’を算出している。よって、より正確に推定時間を推定することができる。

【0071】

なお、上記の説明では、一つ前のタスクの処理時間を用いて、切片ｂ’を求めたが、複数のタスクの処理時間を用いて、切片ｂ’を求めてもよい。この場合、複数の処理時間を用いて、特性を示す近似式を求めることができる。さらには、タスクの処理順に重み付けを持たせて、近似してもよい。すなわち、新しいタスクの処理時間ほど重みを大きくして、近似式を求めればよい。これにより、より正確に推定時間を求めることができる。

【0072】

（推定時間の推定処理３）
推定時間の推定処理の別の変形例について、図９を用い説明する。図９は、バスアクセス回数と推定時間の関係を示すグラフであり、図４に対応するグラフを示している。図９では、フィードバック補正前の直線（図９中の破線）と、フィードバック補正後の直線（図９中の実線）で切片及び傾きが異なっている。

【0073】

フィードバック補正前のバスアクセス回数と推定時間の特性が上記の（１）式で示されるとすると、補正後の特性は以下の式（４）で示される。
ｔ’＝ａ’ｘ＋ｂ’ ・・・（４）

【0074】

なお、ｔ’は、フィードバック補正後の推定時間であり、ａ’は、補正後の傾きを示す定数である。ｂ’は、補正後の切片を示す定数である。このように、実行済みのタスクの処理時間に基づいて、傾き及び切片を補正している。そして、式（４）にｘの値を代入することで、推定部１６は、推定時間ｔ’を算出している。よって、より正確に推定時間を推定することができる。複数のタスクの処理時間を用いて、傾きａ’ 切片ｂ’を求めてもよい。この場合、複数の処理時間を用いて、特性を示す近似式を求めることができる。さらには、タスクの処理順に重み付けを持たせて、近似してもよい。すなわち、新しいタスクの処理時間ほど重みを大きくして、近似式を求めればよい。これにより、より正確に推定時間を求めることができる。

【0075】

（推定時間の推定処理４）
推定時間の推定処理の別の変形例について、図１０を用い説明する。図１０は、バスアクセス回数と推定時間の関係を示すグラフであり、図４に対応するグラフを示している。図１０では、バスアクセス回数と閾値との大小関係に応じて、特性の傾きを変えている。例えば、バスアクセス回数が閾値よりも大きい場合、補正前の傾きａを一定にして、切片を補正する。一方、バスアクセス回数が閾値以下の場合、補正前の切片ｂを一定にして、傾きを補正する。このようにすることで、より正確に推定時間を推定することができる。複数のタスクの処理時間を用いて、図１０のようにフィードバック補正することができる。

【0076】

推定処理１〜４において、補正後の傾きａ’、切片ｂ’は、画像信号処理部ＣＥに応じて、異なる値となっていてもよい。この場合、上記のフィードバック補正を画像信号処理部ＣＥ０〜ＣＥ２のそれぞれに対して行う。すなわち、画像信号処理部ＣＥ０〜ＣＥ２でのそれぞれの処理時間を用いて、画像信号処理部ＣＥ０〜ＣＥ２を独立してフィードバック補正してもよい。画像信号処理部ＣＥ０〜ＣＥ２に対して、異なる傾きａ’又は切片ｂ’が求められる。あるいは、画像信号処理部ＣＥ０〜ＣＥ２に対して、傾きａ’又は切片ｂ’を共通にしてもよい。すなわち、画像信号処理部ＣＥ０〜ＣＥ２をまとめてフィードバック補正してもよい。この場合、画像信号処理部ＣＥ０〜ＣＥ２のそれぞれに対して求められた傾きａ’、切片ｂ’の平均値を用いればよい。

【0077】

上記の説明では、バスアクセス回数と推定時間の関係が線形になっているものと説明したが、２次以上の多項式となっていてもよい。すなわち、バスアクセス回数と推定時間の関係を多項式で近似してもよい。

【0078】

実施の形態２．
本実施の形態にかかる画像処理装置１００について、図１１を用いて説明する。図１１は、画像処理装置１００の構成を示すブロック図である。本実施の形態では、実施の形態１に比べて、環境情報記憶部４２が追加されている。なお、環境情報記憶部４２以外の構成、及び処理については、実施の形態２と同様であるため、説明を省略する。

【0079】

本実施形態では、外部の環境情報を用いて、推定部１６が推定する値を補正する。例えば、直前の画像信号処理部ＣＥがアクセスしたバスの遅延時間(レイテンシ)の平均値を環境情報として用いている。そして、バスレイテンシを用いて、バスアクセス回数から推定時間を求める特性を補正する。図１２にバスレイテンシを補正に用いたときの特性例を示す。

【0080】

図１２では、フィードバック補正した特性を、バスレイテンシを用いてさらに補正している。ここでは、バスレイテンシに基づいて、バスアクセス回数と推定時間の関係の傾き及び切片を補正している。例えば、バスレイテンシが大きいほど、タスクの処理時間が長くなるため、傾き、及び切片を大きくしている。もちろん、バスレイテンシによって、傾き、及び切片の一方のみを補正してもよい。

【0081】

バスレイテンシは、図４に示されていないＣＰＵや３Ｄグラフィックスの動作状況に応じて変化する。すなわち、データバス５１におけるデータの粗密に応じて、バスレイテンシが変化する。

【0082】

例えば、バスレイテンシは、実際にメモリ５３へのデータ書き込みが行われた書き込み時間又はデータ読み出しが行われた読み出し時間によって求めることができる。すなわち、画像信号処理部ＣＥによるデータ書き込み又は読み出しのリクエストからレスポンスまでの時間に応じて、バスレイテンシを求めることができる。

【0083】

本実施の形態の制御方法によれば、バスレイテンシを用いて推定時間を推定している。より具体的には、バスレイテンシを用いて推定時間を補正している。よって、推定時間が外部要因で変動しても、推定精度を向上できる。例えばメモリバスのレイテンシは、データバス５１の混雑度を表している。バスレイテンシを用いると、混雑度に比例して処理時間を見積もることができる。つまり、混雑度が小さいときは早くタスクが完了し、混雑度が大きい時は遅くタスクが完了するといったことを推定できる。また、バスレイテンシが時間とともに変動しても、それに追従して、精度のよい推定を行うことができる。

【0084】

実施の形態３．
本実施の形態では、処理開始予約済みで未実行のタスクを再スケジューリングする点で、実施の形態１、２と異なっている。なお、画像処理装置１００の構成、及びその制御方法については、実施の形態１、２と同様であるため、説明を省略する。

【0085】

具体的には、本実施の形態では、実行予約済みだが、未実行のリクエストがある場合、そのリクエストを入れ替えることで、処理を行わない画像信号処理部ＣＥを設けている。すなわち、一度ある画像信号処理部ＣＥに割り当てられたタスクを、他の画像信号処理部ＣＥに割り当てることで、画像信号処理部ＣＥの動作スロットをより埋めるように、スケジュールを変更している。

【0086】

実施の形態３の処理について、図１３〜図１８を用いて説明する。図１３〜図１８は、本実施の形態におけるスケジューリングを説明するための図である。図１３は、リクエストの入れ替えを行わない場合の動作を示す図である。図１３に示すように、リクエストを入れ替えない場合、画像信号処理部ＣＥ０にタスクＡ、及びタスクＢが割り当てられている。画像信号処理部ＣＥ０は、タスクＡの後に、タスクＢを実行する。画像信号処理部ＣＥ１には、タスクＣが割り当てられ、画像信号処理部ＣＥ２には、タスクＤが割り当てられている。

【0087】

図１３では、画像信号処理部ＣＥ０〜ＣＥ２のいずれも動作スロットに空きが残っている。すなわち、画像信号処理部ＣＥ０〜ＣＥ２のいずれも、目標完了時刻まで余裕がある状態で、タスクＡ〜Ｄを完了することができる。動作スロットに空きが残っている状態で、全て画像信号処理部ＣＥが動作している。そこで、本実施の形態では、スケジュール済みのタスクの割り当てを変更することで、動作しない画像信号処理部ＣＥを設けている。

【0088】

以下、画像信号処理部ＣＥ２が動作しないように、タスクを再割り当てする処理について説明する。ここでは、リクエストがＡ、Ｂ、Ｃ、Ｄの順に受け付けられているとして説明する。リクエスト受付部１１にリクエストＡが受け付けられると、推定部１６は、タスクＡの推定時間を推定する。画像信号処理部ＣＥ０〜ＣＥ２のいずれにもタスクが割り当てられていないため、スケジュール部１５は、タスクＡを画像信号処理部ＣＥ０に割り当てる（図１４）。そして、画像信号処理部ＣＥ０はタスクＡを実行する。

【0089】

次に、リクエスト受付部１１がリクエストＢを受け付けると、推定部１６は、タスクＢの推定時間を推定する。そして、タスクＡ、Ｂの推定時間から、スケジュール部１５は、画像信号処理部ＣＥ０がタスクＢにスケジュール可能であると判定する。すなわち、スケジュール部１５は、画像信号処理部ＣＥ０がタスクＡの後に、タスクＢを処理したとしても、タスクＢを目標完了時刻までに完了できると判断する。したがって、スケジュール部１５は、画像信号処理部ＣＥ０にタスクＢを割り当てる（図１５）。すなわち、画像信号処理部ＣＥ０にタスクＢの処理開始予約がなされる。

【0090】

次に、リクエスト受付部１１がタスクＢの処理開始前に、リクエストＣを受け付ける。すると、推定部１６がタスクＣの処理時間を推定する。ここで、実施の形態１のように、タスクの入れ替えを行わないと、図１６のように、タスクＣは、画像信号処理部ＣＥ１に割り当てられる。すなわち、画像信号処理部ＣＥ０がタスクＡ、及びタスクＢの後に、タスクＣを実行すると、タスクＣの目標完了時刻を越えてしまう。本実施形態に示す再スケジューリングを行わない場合に、スケジュール部１５は、タスクＡ〜Ｃの推定時間に基づいて、図１６に示したように画像信号処理部ＣＥ１にタスクＣを割り当てる。

【0091】

しかしながら、タスクＢとタスクＣの割り当てを入れ替えると、画像信号処理部ＣＥ０を有効に利用することができる。したがって、本実施形態では、図１７に示すように、タスクＢの割り当て先を画像信号処理部ＣＥ０から画像信号処理部ＣＥ１に変更するとともに、タスクＣを画像信号処理部ＣＥ０に割り当てる。すなわち、スケジュール部１５は、画像信号処理部ＣＥ０にタスクＣの処理開始予約を行うとともに、画像信号処理部ＣＥ１にタスクＢを実行させる。このように、画像信号処理部ＣＥ０がタスクＡの後に、タスクＣを実行した場合、タスクＡの後にタスクＢを実行した場合よりも、画像信号処理部ＣＥの空きスロットが小さくなる。よって、画像信号処理部ＣＥ０を有効に利用することができる。

【0092】

画像信号処理部ＣＥ０がタスクＢの処理を開始する前に、リクエストＣが受け付けられた場合、タスクＢとタスクＣの推定時間を比較する。そして、タスクＢの推定時間とタスクＣの推定時間を比較している。すなわち、タスクＢが画像処理部ＣＥ１に割り当てられてから実行されるまでの間に新たなリクエストＣが受け付けられた場合、新たなリクエストＣに対するタスクＣの推定時間をタスクＢの推定時間と比較している。そして、画像信号処理部ＣＥ０がタスクＢを処理した場合と、タスクＣを処理した場合とで、どちらが効率的であるかを判定している。より効率よく画像信号処理部ＣＥ０を利用することできるように、スケジュール部１５がスケジューリングを行う。

【0093】

画像信号処理部ＣＥ０がタスクＣの処理を開始する前にリクエストＤのリクエストが受け付けられると、推定部１６がタスクＤの推定時間を推定する。上記と同様に、タスクＤの推定時間をタスクＣの推定時間と比較する。そして、スケジュール部１５が、処理時間の比較結果に基づいて、図１８に示すように、画像信号処理部ＣＥ１にタスクＤを割り当てる。すなわち、タスクＤの処理時間はタスクＣの処理時間が短い。よって、タスクＣの代わりにタスクＤを画像信号処理部ＣＥ０に割り当てると、画像信号処理部ＣＥ０の空きスロットが増えてしまう。よって、タスクＤとタスクＣを入れ替えない。タスクＢの後、タスクＤを画像信号処理部ＣＥ１に割り当てても、タスクＤの目標完了時刻を越えない。したがって、タスクＤを画像信号処理部ＣＥ１に割り当てる。

【0094】

このようにすることで、画像信号処理部ＣＥ２にタスクが割り当てられなくなる。すなわち、画像信号処理部ＣＥ２が常に空きスロットになり、動作しなくなる。動作しない画像信号処理部ＣＥ２に対して、クロック停止や電源停止を適用することができる。こうすることで、消費電力を低減することができる。さらに、目標完了時刻以内に全てのタスクＡ〜Ｄの処理が完了する。よって、画像処理装置１００は、コンテンツＡ〜Ｄをコマ落ち無く再生することができる。

【0095】

図１９を用いて、本実施の形態にかかるスケジューリング方法を示す説明する。図１９は、本実施形態にかかるスケジューリング方法を示すフローチャートである。なお、実施の形態１の図５で示したフローと重複する箇所については、適宜説明を省略する。

【0096】

新しいリクエストＸを受け付けると（Ｓ３０１）、ｉ＝０に設定する（Ｓ３０２）。なお、以下の説明において、リクエストＸのタスクをタスクＸとして説明する。次に、ｉが画像信号処理部ＣＥの個数以上であるか否かを判定する（Ｓ３０３）。ｉが画像信号処理部ＣＥの個数以上である場合（Ｓ３０３のＹＥＳ）、タスクＸの処理を保留する（Ｓ３０４）。そして、タスクＸの割り当てを終了する。なお、処理が保留された場合、新たなリクエストを受け付けた後、処理が保留されたタスクＸがスケジュール可能かを確認してもよい。ｉが画像信号処理部ＣＥの個数以上でない場合（Ｓ３０３のＮＯ）、画像信号処理部ＣＥｉが未使用であるか否かを判定する（Ｓ３０５）。

【0097】

画像信号処理部ＣＥｉが未使用である場合（Ｓ３０５のＹＥＳ）、画像信号処理部ＣＥｉがタスクＸの処理を開始する（Ｓ３０６）。そして、タスクＸの割り当てを終了する。画像信号処理部ＣＥｉが未使用でない場合（Ｓ３０５のＮＯ）、画像信号処理部ＣＥｉに処理開始予約が有るか無いかを確認する（Ｓ３０７）。すなわち、画像信号処理部ＣＥｉにスケジュールされたタスクを確認する。スケジュール部１５は、画像信号処理部ＣＥｉに未実行で、かつ処理開始予約がなされているタスクがあるか否かを判定する。

【0098】

画像信号処理部ＣＥｉに処理開始予約がなされたタスクがない場合（Ｓ３０７の無）、すなわち、画像信号処理部ＣＥｉに処理開始予約がない場合、スケジュール部１５は、タスクＸを画像信号処理部ＣＥｉにスケジュール可能か否かを判定する（Ｓ３０８）。すなわち、スケジュール部１５は、画像信号処理部ＣＥｉにタスクＸを割り当てた場合、目標完了時刻よりも前に、タスクＸを実行できるか否かを判定する。

【0099】

タスクＸを画像信号処理部ＣＥｉにスケジュール可能である場合（Ｓ３０８のＹＥＳ）、すなわち、画像信号処理部ＣＥｉがタスクＸを目標完了時刻までに完了できる場合、スケジュール部１５は、画像信号処理部ＣＥｉにタスクＸの処理開始予約を行う（Ｓ３０９）。そして、タスクＸの割り当てを終了する。一方、タスクＸを画像信号処理部ＣＥｉにスケジュール可能でない場合（Ｓ３０８のＮＯ）、すなわち、画像信号処理部ＣＥｉがタスクＸを目標完了時刻までに完了できない場合、ｉをインクリメントして（Ｓ３１０）、ステップＳ３０３に戻る。Ｓ３０３、Ｓ３０５、Ｓ３０７、Ｓ３０８、及びＳ３１０等の処理を繰り返すことで、画像信号処理部ＣＥ０〜ＣＥ２の中から、タスクＸを実行可能な又は処理開始予約可能な画像信号処理部ＣＥを探索することができる。

【0100】

画像信号処理部ＣＥｉに処理開始予約がある場合（Ｓ３０７の有）、すなわち、画像信号処理部ＣＥｉにスケジューリングされたタスクが有る場合、画像信号処理部ＣＥｉのキュー推定時間が、タスクＸの推定時間よりも短いか否かを判定する（Ｓ３１１）。すなわち、スケジュール部１５は、処理開始予約済みのタスク（以下、タスクＹとする）の推定時間と、タスクＸの推定時間を比較する。

【0101】

画像信号処理部ＣＥｉのキュー推定時間が、タスクＸの推定時間よりも短くない場合（Ｓ３１１のＮＯ）、ｉをインクリメントする（Ｓ３１３）。すなわち、タスクＹの処理時間がタスクＸの処理時間よりも長い場合、スケジュールを変更せずに、ｉをインクリメントする。そして、ｉをインクリメントした後、ステップＳ３０３に戻る。タスクＹの処理時間が新しいタスクＸの処理時間よりも長い場合、画像信号処理部ＣＥｉがタスクＹを実行したほうが、画像信号処理部ＣＥｉのスロットを有効に利用することができる。よって、画像信号処理部ＣＥｉのスケジュールを変更せずに、ｉをインクリメントする。そして、ステップＳ３０３からの処理を実行することで、次の画像信号処理部ＣＥにタスクＸを割り当てることができるかを確認することができる。

【0102】

画像信号処理部ＣＥｉのキュー推定時間が、タスクＸの推定時間よりも短い場合（Ｓ３１１のＹＥＳ）、画像信号処理部ＣＥｉにタスクＸをスケジュールできるか否かを判定する（Ｓ３１２）。すなわち、処理開始予約済みのタスクＹの代わりに、タスクＸを画像信号処理部ＣＥｉに割り当てた場合、スケジュール部１５は、画像信号処理部ＣＥｉがタスクＸを目標完了時刻までにタスクＸを完了できるか否かを判定する。

【0103】

画像信号処理部ＣＥｉにタスクＸをスケジュールできない場合（Ｓ３１２のＮＯ）、ｉをインクリメントして（Ｓ３１３）、ステップＳ３０３に戻る。すなわち、画像信号処理部ＣＥｉにタスクＸを処理開始予約すると、目標完了時刻を越えてしまうので、画像信号処理部ＣＥｉには、タスクＸを割り当てない。換言すると、画像信号処理部ＣＥｉには、タスクＹが処理開始予約されたままとなる。そして、ｉをインクリメントした後、ステップＳ３０３からの処理を実行することで、次の画像信号処理部ＣＥにタスクＸを割り当てることができるかを確認することができる。

【0104】

一方、画像信号処理部ＣＥｉにタスクＸをスケジュールできる場合（Ｓ３１２のＹＥＳ）、タスクＸを画像信号処理部ＣＥｉに割り当てる（Ｓ３１４）。すなわち、スケジュール部１５は、画像信号処理部ＣＥｉにタスクＸの処理開始を予約する。さらに、タスクＸの処理開始予約前に、画像信号処理部ＣＥｉにスケジュールされていたタスクＹを要求する（Ｓ３１５）。そして、ステップＳ３０２に戻る。すなわち、スケジュール部１５は、上記と同様の処理により、画像信号処理部ＣＥｉにタスクＹの再割り当てを行う。これにより、画像信号処理部ＣＥｉに処理開始予約されていたタスクＹが、他の画像信号処理部ＣＥに割り当てられる。すなわち、タスクＸの前にリクエストが受け付けられたタスクＹに対して、ステップＳ３０２からの処理が実行されて、再度スケジューリングされる。

【0105】

本実施の形態では、処理開始予約済みで未実行のタスクに対して、画像信号処理部ＣＥの再割り当てを行っている。このように、画像処理装置１００を制御することで、動作しない画像信号処理部ＣＥ２を設けることができる。すなわち、タスクの再スケジュールを行わない場合、図１３に示すように、画像信号処理部ＣＥ２にタスクＤが割り当てられるのに対して、タスクの再スケジュールを行う場合、図１８に示すように、画像信号処理部ＣＥ２にいずれのタスクも割り当てられなくなる。動作しない画像信号処理部ＣＥに対して、クロック停止や電源停止を適用する。これにより、消費電力を低減することができる。さらに、目標完了時刻以内に全てのタスクＡ〜Ｄの処理が完了する。よって、コマ落ち無く、コンテンツＡ〜Ｄを再生することができる。

【0106】

上記のように、新たなリクエストが受け付けられた時に、再スケジューリングしている。これにより、リクエストが受け付けられる毎に、適切なスケジュールを設定することができる。よって、動作効率を維持しつつ、動作しない画像信号処理部ＣＥを設けることが可能になる。

【0107】

本実施の形態１〜３にかかる画像処理装置の応用例について、図２０を用いて説明する。図２０は、画像処理装置１００を適用した車載システムを模式的に示すブロック図である。車載システム５００は、リクエスト元となる、Ｂｌｕ−Ｒａｙプレーヤ２０１、Ｗｅｂコンテンツ２０２、周辺カメラ２０３、メニュー画面２０４を備えている。さらに、車載システム５００は、画像処理装置１００、後席ディスプレイ３０１、助手席ディスプレイ３０２、画像認識処理部３０３、無線ＬＡＮ３０４を備えている。

【0108】

Ｂｌｕ−Ｒａｙプレーヤ２０１、Ｗｅｂコンテンツ２０２、周辺カメラ２０３、メニュー画面２０４は、実施の形態〜３で示したコンテンツのリクエスト元となる。画像処理装置１００は、ビデオデコーダ１２１〜１２３、及びビデオエンコーダ１２４を備えている。ビデオデコーダ１２１〜１２３、及びビデオエンコーダ１２４は、実施の形態１〜３で示した画像信号処理部ＣＥに対応する。

【0109】

後席ディスプレイ３０１は、Ｂｌｕ−Ｒａｙプレーヤ２０１で再生された映像データを表示する。助手席ディスプレイ３０２は、Ｗｅｂコンテンツで再生された映像データを表示する。画像認識処理部３０３は、周辺カメラ２０３で取得された映像データに対して画像認識を行う。ビデオエンコーダ１２４は、メニュー画面をエンコードする。そして、無線ＬＡＮ３０４は、エンコードされたデータを送信する。

【0110】

上記のように、ビデオデコーダ１２１〜１２３、及びビデオエンコーダ１２４は、画像信号処理部ＣＥに対応している。よって、ビデオデコーダ１２１〜１２３、及びビデオエンコーダ１２４は、図１に示したスケジュール部１５で決定されたスケジュールで処理を実行する。すなわち、画像処理装置１００は、推定時間に基づいて、スケジューリングを行っている。

【0111】

各処理の要求性能にばらつきがある場合、あるいは個々の処理においても時間方向に処理量がばらつく場合、上記のスケジュール方法は有効に作用する。

【0112】

実施の形態４．
本実施の形態４にかかる画像処理装置１００について、図２１を用いて説明する。画像処理装置は、受付部１１１、コーデック処理部１０１、複数の画像処理部１０２、推定部１１６、スケジュール部１１５を備えている。

【0113】

受付部１１１は、複数のコンテンツからのリクエストを受け付ける。コーデック処理部１０１はコンテンツをデコード又はエンコードする。画像処理部１０２ａ、１０２ｂは、リクエストに応じたタスクを並列して実行する。推定部１１６は、コーデック処理部で用いられるデコード又はエンコードのパラメータに基づいて、それぞれの画像処理部１０２においてタスクの処理が完了する推定時間を推定する。スケジュール部１１５は、推定部１１６で推定された推定時間に基づいて、複数の画像処理部１０２が実行するタスクをスケジューリングする。なお、図２１では、画像処理部１０２の数は画像処理部１０２ａ、１０２ｂの２つであるが、画像処理部１０２の数は３以上であってもよい。

【0114】

受付部１１１は上記の実施の形態のリクエスト受付部１１と同様の処理を行ってもよい。コーデック処理部１０１は、上記の実施の形態の可変長符号処理部ＶＬＣと同様の処理を行ってもよい。推定部１１６は、上記の実施の形態の推定部１１６と同様の処理を行ってもよい。画像処理部１０２は、上記の実施の形態の画像信号処理部ＣＥと同様の処理を行ってもよい。スケジュール部１１５は、上記の実施の形態のスケジュール部１５と同様の処理を行ってもよい。

【0115】

その他の実施形態．
上記の実施形態１〜３において、画像信号処理部ＣＥ０〜２は、それぞれ、同一コンテンツＡの異なるフレームを並列処理する場合にも適用できる。実施形態において、信号処理部が１つの場合でも適用することができる。画像信号処理部ＣＥの処理単位は、フレームだけでなく、マクロブロックや、複数フレームまとめたＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅｓ）単位となっていてもよい。また、画像信号処理部ＣＥがデコーダである例について説明したが、エンコーダでも同様に適用できる。

【0116】

本実施の形態は、複数ビデオまたは同一ビデオの複数フレームの同時圧縮・伸長機能を備える半導体装置およびそれを用いたシステムに適している。複数ビデオまたは同一ビデオの複数フレームの同時処理を行う装置において、複数のハードウェアの効率的な動作方法を得ることができる。特にビデオ符号・復号処理のように、入力信号の内容によって、処理量が大きく変動する性質を持つ処理において、従来よりもハードウェアの動作効率を良くするスケジューリングを実現することができる。

【0117】

実施形態１〜４のうち、２以上の実施形態を適宜組み合わせて用いることも可能である。例えば、実施形態１の環境情報と実施形態２の優先情報の両方を用いて、スケジューリングを行ってもよい。あるいは、実施の形態３で示した画像処理装置の制御方法において、実施の形態１で示した優先情報や、実施の形態２で示した環境情報を用いてもよい。また、画像信号処理部ＣＥや画像処理部１０２の数は、複数であればよく、例えば、４以上であってもよい。また、上記の説明では、リクエストＡ〜Ｄの目標完了時刻を同じとして説明したが、異なっていても同様の効果を得ることができる。

【0118】

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は既に述べた実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において種々の変更が可能であることはいうまでもない。

【符号の説明】

【0119】

１１ リクエスト受付部
１２ リクエストキュー
１３ リクエスト選択部
１５ スケジュール部
１６ 推定部
４１ 優先情報記憶部
４２ 環境情報記憶部
５１ データバス
５２ メモリコントローラ
５３ メモリ
１００ 画像処理装置
ＣＥ 画像信号処理部
ＶＬＣ 可変長符号処理部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】