JP2010166525A - マルチメディア処理制御装置 - Google Patents

Abstract

【課題】クライアント・コンポーネント間のデータ通信回数・通信量を低減し、処理要求発行から実際に機能が実現されるまでの時間を短縮することができるマルチメディア処理制御装置を提供する。
【解決手段】画像や音声に関する処理要求を発行するクライアント２１を備えたホストＣＰＵ２と、ホストＣＰＵ２とバス４を介して接続され、複数のコンポーネント３２ａ〜３２ｃを備えたマルチメディアプロセッサ３とを有しており、クライアント２１は、一つのコンポーネント３２ａ〜３２ｃに対する個別処理要求、及び、複数のコンポーネント３２ａ〜３２ｃに対してシーケンス処理を要求する一括処理要求を発行することができる。また、マルチメディアプロセッサ３は、クライアント２１から発行される一括処理要求に応じて複数のコンポーネント３２ａ〜３２ｃの個々に対して内部処理要求を送信し、シーケンス処理を制御する一括制御部３１を有する。
【選択図】図２

Description

本発明は、複数のプロセッサを有し、異なるプロセッサ間でのシーケンス制御処理を行うマルチメディア処理制御装置に関する。

従来、携帯電話やＴＶなど、画像や音声の情報を記録、及び／又は再生するマルチメディア処理制御装置は、記録や再生などの各種機能を実現するために、上位アプリケーションから下位のアプリケーションに対し、処理単位ごとに処理要求を発行する必要があった。このような従来のマルチメディア処理制御装置として、例えば、ＯｐｅｎＭＡＸ ＩＬ^ＴＭによって既定されている仕様に準拠した装置が知られている（非特許文献１参照）。

非特許文献１に記載された装置では、情報の記録再生や加工などの単機能を処理・実行する複数の機能ブロックがコンポーネントとして定義及び生成され、各コンポーネントの制御は、上位アプリケーション（以下、クライアントと示す）によって行われている。

非特許文献１に示すような装置においては、通常、クライアントと各コンポーネントとは別のプロセッサで動作しており、バスを介して情報を送受信している。また、コンポーネントは機能毎に構成されているため、複雑な機能を実現させるためには、クライアントから複数のコンポーネントに対して複数の処理要求を順次発行し、これらの処理が適切なシーケンスで実行されるように制御する必要がある。

従って、従来のマルチメディア処理制御装置においては、機能実現のために、クライアントから複数のコンポーネントに対して複数の処理要求を発行しなくてはならないので、バス上でのデータ通信回数や通信量が大きくなってしまう。通常、バス上の通信はプロセッサの内部処理と比べて処理時間が長いため、処理要求発行から実際に機能が実現されるまでの処理時間が長くなってしまうという問題があった。
クロノス・グループ・インク、「オープンオーブンマックス・インテグレーション・レイヤ・アプリケーション・プログラミング・インターフェース・スペシフィケーション」、１．１．２．０版、２００８（The Khronos Group Inc.， OpenMAXTM Integration Layer Application Programming Interface Specification ver1.1.2.0 (2008)）

本発明は、以上の点に鑑みてなされたもので、クライアント・コンポーネント間のデータ通信回数・通信量を低減し、処理要求発行から実際に機能が実現されるまでの時間を短縮することができる、マルチメディア処理制御装置を提供することを目的とする。

本発明の一形態に係るマルチメディア処理制御装置は、画像や音声に関する処理要求を発行してサービスを提供するアプリケーションを備えた第１のプロセッサと、前記第１のプロセッサとバスを介して接続され、画像や音声の記録再生加工などを実現する機能に対応した処理を行う複数のコンポーネントを備えた第２のプロセッサと、を備えたマルチメディア処理制御装置であって、前記アプリケーションは、前記コンポーネントの個々に対して単機能処理を要求する個別処理要求、及び、複数の前記コンポーネントに対してシーケンス処理を要求する一括処理要求を発行することができ、前記第２のプロセッサは、前記アプリケーションから発行される前記一括処理要求に応じて前記複数のコンポーネントの個々に対して内部処理要求を送信し、前記シーケンス処理を制御するコンポーネント制御部を有することを特徴とする。

クライアント・コンポーネント間のデータ通信回数・通信量を低減し、処理要求発行から実際に機能が実現されるまでの時間を短縮することができる。

以下、図面を参照して本発明の実施の形態を説明する。

始めに、図１，図２を参照して、本発明の実施の形態に係わるマルチメディア処理制御装置の構成を説明する。図１は、本発明の実施の形態に係わるマルチメディア処理制御装置のハードウェア構成の一例を説明する概略ブロック図である。また、図２は、本発明の実施の形態に係わるマルチメディア処理制御装置のソフトウェア構成の一例を説明する概略ブロック図である。

本発明のマルチメディア処理制御装置は、ＯｐｅｎＭＡＸ^ＴＭなど、上位アプリケーションから下位アプリケーション（単機能処理ブロック）に対して処理要求を発行することにより、上位アプリケーションが下位アプリケーションの動作を制御し、動画像情報の記録や再生、加工などの機能を実現する装置全般に適用することが可能であり、例えば、携帯電話やテレビなどの情報家電に適用することができる。ここでは、動画像再生機能を有する携帯電話を一例に挙げ、構成を説明する。

図１に示すように、本発明の実施の形態の係わるマルチメディア処理制御装置１は、サービス処理のプロセッサである、第１のプロセッサとしてのホストＣＰＵ２と、音声画像処理のプロセッサである、第２のプロセッサとしてのマルチメディアプロセッサ３とを有しており、これらはバス４を介して接続されている。バス４には、データなどを格納するＲＡＭ５と、外部との間で情報を送受信するためのＩ／Ｆ６とが接続されている。Ｉ／Ｆ６には、外部のアンテナ７や着脱可能なメモリ装置８が接続されている。また、バス４には、画像表示部であるモニタ９ａと、音声出力部であるスピーカ９ｂとが接続されている。

また、本実施の形態に係わるマルチメディア処理制御装置１のソフトウェア構成は、図２に示すように、画像や音声の記録や再生、加工などの処理要求を発行する、アプリケーションとしてのクライアント２１と、各機能を実現する機能単位のブロックであるコンポーネント３２ａ〜３２ｃと、クライアント２１からの処理要求をハンドリングし、シーケンス処理の一括処理制御を実行する、コンポーネント制御部としての一括制御部３１とから主に構成される。

クライアント２１は、サービス処理のプロセッサであるホストＣＰＵ２に設けられている。また、一括制御部３１と、コンポーネント３２ａ〜３２ｃとは、音声画像処理のプロセッサであるマルチメディアプロセッサ３に設けられている。従って、クライアント２１から発行される処理要求は、バス４を介して一括制御部３１に送信される。一括制御部３１は、受信した処理要求の内容を識別し、適切なコンポーネント３２ａ〜３２ｃに対して個々に処理要求を送信する。

従来のマルチメディア処理制御装置１では、クライアント２１から個々のコンポーネント３２ａ〜３２ｃに対して個別に処理要求を発行する必要がある。例えば、コンポーネント３２ａが画像の回転処理を実現する機能ブロック、コンポーネント３２ｂが画像のリサイズ処理を実現する機能ブロック、コンポーネント３２ｃが画像の表示位置変更処理を実現する機能ブロックで構成されている場合について考える。

モニタ９ａに表示されている画像を９０度回転させた後に画面の大きさに合わせて縮小し、更に表示位置を所望の位置に変更させる場合、クライアント２１は最初に、コンポーネント３２ａに対して画像を９０度回転させる旨の処理要求（以下、処理要求Ａと示す）を発行する。処理要求Ａが実行されると、次にクライアント２１はコンポーネント３２ｂに対して、回転処理済みの画像を画面の大きさに合わせて縮小する旨の処理要求（以下、処理要求Ｂと示す）を発行する。処理要求Ｂが実行されると、最後にクライアント２１はコンポーネント３２ｃに対して、リサイズ処理済みの画像の表示位置を指定された位置に変更する旨の処理要求（以下、処理要求Ｃと示す）を発行する。処理要求Ｃの実行が完了すると、全ての要求が実現される。

すなわち、従来のマルチメディア処理制御装置１では、ＣＰＵ２からマルチメディアプロセッサ３に対し、処理要求Ａ，Ｂ，Ｃの３つの処理要求が発行されるため、低速通信であるバス間通信を３回行う必要があった。

これに対し、本実施の形態におけるマルチメディア処理制御装置１では、クライアント２１から一括制御部３１に対し、画像の回転・リサイズ・表示位置変更の処理要求を一括して（１つの処理要求として）発行する（以下、一括処理要求Ａと示す）。

一括制御部３１は、受信した処理要求が一括処理要求であると識別し、コンポーネント３２ａに対して画像を９０度回転させる旨の内部処理要求（以下、内部処理要求ａと示す）を送信する。内部処理要求ａが実行されると、次に一括制御部３１はコンポーネント３２ｂに対して、回転処理済みの画像を画面の大きさに合わせて縮小する旨の内部処理要求（以下、内部処理要求ｂと示す）を送信する。内部処理要求ｂが実行されると、最後に一括制御部３１はコンポーネント３２ｃに対して、リサイズ処理済みの画像の表示位置を指定された位置に変更する旨の内部処理要求（以下、内部処理要求ｃと示す）を送信する。内部処理要求ｃの実行が完了すると、全ての要求が実現される。

このように、本実施の形態のマルチメディア処理制御装置１では、ＣＰＵ２からマルチメディアプロセッサ３に対し、一括処理要求Ａが発行され、マルチメディアプロセッサ３内部で内部処理要求ａ，ｂ，ｃの３つの処理要求が送信される。従って、低速処理であるバス間を１回と、高速処理であるプロセッサの内部通信を３回行うことで所望の機能を実現することができ、処理時間の短縮を図ることができる。

次に、一括制御部３１におけるクライアント２１からの処理要求のハンドリングについて、図３を用いて説明する。図３は、一括制御部３１における処理要求の一連の流れを説明するフローチャートである。

図３に示すように、一括制御部３１は、クライアント２１から発行された処理要求を受信すると、該処理要求が一括処理要求（１つまたは複数のコンポーネントに対するシーケンス処理を行う処理要求）であるか、通常の処理要求（１つのコンポーネントに対する１つの処理要求、以下、個別処理要求と示す）であるかを判断する（ステップＳ１）。

一括処理要求か否かの判断は、例えば、クライアント２１から受信する処理要求のコマンドコードによって行われる。一括制御部３１は、処理要求を受信すると、図４（ａ）に示すような要求内容識別テーブル１０において、受信したコマンドコードと一致するレコードを検索する。図４は、処理要求内容の識別に用いるテーブルの一例を説明する図である。

具体的には、図４（ａ）に示す要求内容識別テーブル１０のコマンドコード１１カラムを検索し、受信したコマンドコードと一致するレコードを抽出する。抽出したレコードのコンポーネントＩＤ１２に、個別のコンポーネント３２ａ〜３２ｃを示すコードが記述されていた場合、受信した処理要求は当該コードを有するコンポーネントに対する個別処理要求であると判定する。

抽出したレコードのコンポーネントＩＤ１２に、個別のコンポーネント３２ａ〜３２ｃを示すコード以外の内容が記述されていた場合、受信した処理要求は一括処理要求であると判定する。例えば、受信したコマンドコードが”０Ｘ８００１”である場合、図４（ａ）の要求内容識別テーブル１０を検索すると、抽出したレコードのコンポーネントＩＤ１２は”Ｘ１”である。

コンポーネント３２ａのコードがＡ、コンポーネント３２ｂのコードがＢ、コンポーネント３２ｃのコードがＣと設定されているとすると抽出したレコードのコンポーネントＩＤ１２である”Ｘ１”はこれらのコードに存在しない。従って、この場合、クライアント２１から受信した処理要求は、一括処理要求であると判断される。

なお、処理要求の識別方法は、上述のコンポーネントＩＤ１２による方法に限らず、種々の方法を用いることができる。例えば、コマンドコードの特定桁数を処理要求の識別コードとして設定してもよい。具体的には、コマンドコードの下４桁目を処理要求識別コードとし、”０”である場合は個別処理要求であると識別し、それ以外の数値（例えば”８”）で場合は一括処理要求と識別するように設定してもよい。

また、要求内容識別テーブル１０を用いる場合においても、各カラムに設定する項目や、カラムの数などは、必要に応じて変更してもよい。例えば、コンポーネントＩＤ１２の代わりに、コンポーネント（一括処理の場合はコンポーネントリスト）の格納先アドレスなどを用いてもよい。

ステップＳ１において、クライアントからの処理要求が一括処理要求であると判断した場合、ステップＳ２に進み、一括処理を行うためにコンポーネントに対して送信する個々のコマンド（内部コマンド）を生成する。一括処理要求の場合、一括制御部３１から処理要求を送信するコンポーネントと、該コンポーネントに送信する個々の処理要求の内部コマンドとを識別・生成する必要がある。

まず、個々の処理要求を送信する（一括処理要求を実現するために処理を実行させる）対象コンポーネントを識別・設定する。コンポーネントの設定には、例えば、ステップＳ１で抽出されたコンポーネントＩＤ１２を用いる。一括制御部３１は、処理要求を受信すると、一括処理対象コンポーネント識別テーブルとしての一括処理実行コンポーネントテーブル２０において、抽出されたコンポーネントＩＤ１２をキーとして一致するレコードを検索・抽出する。一括処理実行コンポーネントテーブル２０には、コンポーネントＩＤ１２と、個別の処理要求を送信するコンポーネントのコードがリスト形式で記述されたコンポーネントリスト１３とが記述されている。

例えば、コンポーネントＩＤが”Ｘ１”である場合、図４（ｂ）に示すようなリストが抽出される。図４（ｂ）に示す例の場合、コンポーネントＩＤ”Ｘ１”を持つコンポーネントリスト１３には、コンポーネントコードＡ，コンポーネントコードＢ，コンポーネントコードＣの３つのコンポーネントが対象コンポーネントとして記述されている。なお、リストの最後に記述されている”ｅｎｄ”は、コンポーネントリスト１３の末尾であることを示すものである。

一括処理要求で用いられる内部コマンドは、クライアント２１から発行されたコマンドコードと対応付けられており、予めマルチメディアプロセッサ３にシーケンス一括制御プログラムとして設定されている。すなわち、本ステップでは、受信したコマンドコードをキーとして内部コマンドを検索し、実行可能な形態に展開する一連の作業が行われる。

例えば、画像の回転・リサイズ・表示位置変更が、コマンドコード”０Ｘ８００１”の一括処理要求としてクライアント２１から発行された場合、コマンドコード”０Ｘ８００１”をキーとして予め設定されている内部コマンドを検索し、画像の回転処理要求、画像のリサイズ処理要求、画像の表示位置変更処理要求の３つの処理要求の内部コマンドを生成する。

次に、ステップＳ３において、ステップＳ２で識別したコンポーネントリスト１３に記述された最初のコンポーネントコードを持つコンポーネントを、処理対象のコンポーネントとして設定する。例えばコンポーネントリスト１３が図４（ｂ）に示したリストである場合、コンポーネントコードＡを持つコンポーネント（＝コンポーネント３２ａ）が処理対象コンポーネントとしてセットされる。

続いてステップＳ４において、ステップＳ３でセットしたコンポーネントに対し、ステップＳ２で生成した処理要求の内部コマンドを送信する。上述の例の場合、コンポーネント３２ａに対して画像の回転処理要求の内部コマンドを送信する。コンポーネント３２ａは内部コマンドを受信すると、処理を実行する。

次に、ステップＳ５において、ステップＳ４で処理を実行したコンポーネントの状態を記録する。コンポーネントの状態は、例えば図５に示すような状態管理テーブル４０に書き込まれる。図５は、コンポーネントの状態を管理するテーブルの一例を説明する図である。図５に示す状態管理テーブル４０は、コンポーネント識別子４１（例えばコンポーネントＩＤ１２）と、コンポーネントの処理実行の状態を識別する処理状態フラグ４２と、処理に関する付属情報の有無を識別する付属情報ビット４３と、付属情報が存在する場合に該情報を格納している場所を識別する付属情報格納先アドレス４４との項目を有する。

状態管理テーブル４０には、マルチメディアプロセッサ３に生成・構築されている全てのコンポーネント３２に関する情報が格納されている。すなわち、状態管理テーブル４０のレコード数は、マルチメディアプロセッサ３に生成・構築されている全てのコンポーネント３２の数と等しく、コンポーネント３２とレコードとが１対１に対応づけられている。状態管理テーブル４０は、一括制御部３１によって管理されており、ホストＣＰＵ２のクライアント２１からも参照することができる。

一括制御部３１は、状態管理テーブル４０に格納されているレコードの中から、コンポーネント識別子４１をキーとして、ステップＳ４で処理を実行させたコンポーネントのレコードを抽出する。ステップＳ４における処理が正常に終了した場合、抽出したレコードの処理状態フラグ４２を、正常に処理が終了したことを示す”ＯＫ”にセットする。なお、処理状態フラグ４２には、”ＯＫ”のほか、エラーが発生するなどして処理が正常に終了できなかったことを示す”Ｅｒｒｏｒ”などをセットすることができる。

ステップＳ４における処理に関し、クライアント２１や他のコンポーネントなどに通知すべき情報が発生した場合、付属情報ビット４３を、付属情報が存在することを示す”１”にセットする。なお、付属情報がない場合、付属情報ビット４３には”０”をセットする。付属情報ビット４３に”１”をセットした場合、付属情報を格納している場所を示すアドレスなどを、付属情報格納先アドレス４４にセットする。

例えば、ステップＳ４においてコンポーネント３２ａの処理が正常に終了し、該処理に関して特に付属情報がない場合、一括制御部３１は、図５に示すように、コンポーネント識別子４１が”Ａ”のレコードに関し、処理状態フラグ４２に”ＯＫ”を、付属情報ビット４３に”０”を、付属情報格納先アドレス４４に空欄を、それぞれセット（上書き）する。

本実施の形態のマルチメディア処理制御装置１では、マルチメディアプロセッサ３が処理要求をハンドリングして実行するため、一括処理要求実行時において、ホストＣＰＵ２のクライアント２１からは個々のコンポーネントの状態を管理・認識することが困難である。しかし、一括制御部３１が状態管理テーブル４０を保持・管理し、このテーブルに全てのコンポーネントの状態を逐次書き込んでいるので、クライアント２１は必要に応じて状態管理テーブル４０の所定のレコードを読み出すことにより、コンポーネントの状態を誤認識したり、不適切な処理要求を発行したりすることを防止することができる。

処理状態の記録が完了すると、ステップＳ６に進み、ステップＳ２で識別したコンポーネントリスト１３に記述された全てのコンポーネントに対して処理要求を送信し、処理を実行させたか否かを判定する。未処理のコンポーネントが残っている場合、ステップＳ３に戻り、コンポーネントリスト１３の記述順に沿って、現在処理対象のコンポーネントとして設定されているコンポーネント（コード）の次のコンポーネントコードを持つコンポーネントを、処理対象のコンポーネントとして設定する。

例えばコンポーネントリスト１３が図４（ｂ）に示したリストであり、コンポーネントコードＡを持つコンポーネント（＝コンポーネント３２ａ）が処理対象コンポーネントとしてセットされ、その処理を完了している場合、次の処理対象コンポーネントとして、コンポーネントコードＢを持つコンポーネント（＝コンポーネント３２ｂ）を次の処理対象のコンポーネントとしてセットする。

このように、ステップＳ３からステップＳ５を繰り返し、コンポーネントリスト１３に記述された全ての処理対象コンポーネントについて処理が完了した場合、ステップＳ６からステップＳ９に進み、メモリの開放など終了処理を行う。

一方、ステップＳ１において、クライアントからの処理要求が個別処理要求、すなわち、１つのコンポーネントに対する１つの処理要求であると判断した場合、ステップＳ７に進み、処理対象のコンポーネントを識別し、該コンポーネントに対して送信するコマンド（内部コマンド）を生成する。

処理対象のコンポーネントの識別には、図４（ａ）において抽出されたレコードのコンポーネントＩＤ１２をそのまま用いてもよいし、図６に示すような個別処理実行コンポーネントテーブル５０から、クライアント２１から発行されたのコマンドコード１１をキーとして一致するレコードを検索・抽出してもよい。個別処理実行コンポーネントテーブル５０には、コマンドコード１１と、処理要求を送信するコンポーネントのコードとが記述されている。

例えば、コマンドコードが”０Ｘ０００１”である場合、図６に示すようなレコードが抽出される。図６に示す例の場合、コマンドコードが”０Ｘ０００１”の処理要求の場合、コンポーネントコードＡを持つコンポーネント（＝コンポーネント３２ａ）が対象コンポーネントとして設定される。

個別処理要求で用いられる内部コマンドは、一括処理要求で用いられる内部コマンドと同様に、クライアント２１から発行されたコマンドコードと対応付けられており、予めマルチメディアプロセッサ３に設定されている。すなわち、本ステップでは、受信したコマンドコードをキーとして内部コマンドを検索し、実行可能な形態に展開する一連の作業が行われる。

例えば、画像の回転が、コマンドコード”０Ｘ０００１”の一括処理要求としてクライアント２１から発行された場合、コマンドコード”０Ｘ０００１”をキーとして予め設定されている内部コマンドを検索し、画像の回転処理要求の内部コマンドを生成する。

次に、ステップＳ８において、ステップＳ７で識別したコンポーネントを、処理対象のコンポーネントとして設定し、同じくステップＳ７で生成した処理要求の内部コマンドを送信する。上述の例の場合、コンポーネント３２ａに対して画像の回転処理要求の内部コマンドを送信する。コンポーネント３２ａは内部コマンドを受信すると、処理を実行する。

処理が完了すると、ステップＳ９に進み、メモリの開放や終了通知など終了処理を行う。ステップＳ９の終了処理が完了すると、一括制御部３１における処理要求の一連の流れが終了する。

このように、本実施の形態のマルチメディア処理制御装置１においては、シーケンス処理、すなわち、連続して実行させる複数の処理要求を予め一括処理要求として定義しておき、ホストＣＰＵ２のクライアント２１からマルチメディアプロセッサ３の一括制御部３１に対して一括処理要求を発行する。一括制御部３１は定義に従って受信した一括処理要求を複数の処理要求に展開し、マルチメディアプロセッサ３の所定のコンポーネント３２に処理要求を送信し、機能を実行させる。すなわち、ホストＣＰＵ２からマルチメディアプロセッサ３に対し、低速通信であるバス通信を用いた処理要求の通信回数・通信量を低減することができるため、処理要求発行から実際に機能が実現されるまでの時間を短縮することができる。

なお、上述のマルチメディア処理制御装置１は１つのマルチメディアプロセッサ３のみを有する構成としているが、図７に示すように、マルチメディア処理制御装置１´を複数のマルチメディアプロセッサ３ａ，３ｂを有する構成としてもよい。図７は、複数のマルチメディアプロセッサで構成されたマルチメディア処理制御装置のハードウェア構成の一例を説明する概略ブロック図である。

この場合、ホストＣＰＵ２のクライアント２１から、マルチメディアプロセッサ３ａの一括制御部３１に対して一括処理要求が発行される。一括制御部３１は上述した手順と同様に、一括処理実行コンポーネントテーブル２０ａから該一括処理要求のコマンドコード１１をキーとし、一致するレコードを抽出して、処理要求を送信するコンポーネントリスト１３ａを取得する（図８参照）。

図８は、複数のマルチメディアプロセッサ３ａ，３ｂにおける処理要求内容の識別に用いるテーブルの一例を説明する図であり、（ａ）は要求内容識別テーブル１０を、（ｂ）はマルチメディアプロセッサ３ａの一括処理実行コンポーネントテーブル２０ａを、（ｃ）はマルチメディアプロセッサ３ｂの一括処理実行コンポーネントテーブル２０ｂを示している。

このとき、コンポーネントリスト１３ａに、マルチメディアプロセッサ３ａに存在するコンポーネントのコンポーネントコード以外のコードが記述されていた場合、一括制御部３１は、マルチメディアプロセッサ３ｂの一括制御部３１に対して、該コードを送信する。マルチメディアプロセッサ３ｂの一括制御部３１は、一括処理実行コンポーネントテーブル２０ｂから受信したコードをキーとし、一致するレコードを抽出して、処理要求を送信するコンポーネントリスト１３ｂを取得する。

マルチメディアプロセッサ３ａ，３ｂの一括制御部３１は、コンポーネントリスト１３ａ、１３ｂに記述されたコードの順に従って内部処理コマンドを送信し、機能を実行させる。

図８を例に用いて具体的に説明する。まず、ホストＣＰＵ２のクライアント２１から、マルチメディアプロセッサ３ａの一括制御部３１に対してコマンドコード”０Ｘ８０１１”の一括処理要求が発行される。マルチメディアプロセッサ３ａの一括制御部３１は、一括処理実行コンポーネントテーブル２０ａからコマンドコードが”０Ｘ８０１１”であるレコードを抽出して、処理要求を送信するコンポーネントリスト１３ａを取得する。コンポーネントリスト１３ａには、”Ａ”，”Ｂ”，”Ｃ”，”Ｚ１”の順にコンポーネントコードが記述されている。

ここで、マルチメディアプロセッサ３ａにはコンポーネントコードＡ，Ｂ，Ｃの３つのコンポーネントが存在しているとすると、リストの４番目に記述されている”Ｚ１”は、マルチメディアプロセッサ３ａに存在するコンポーネントのコンポーネントコード以外のコードであると識別される。すると、マルチメディアプロセッサ３ａの一括制御部３１は、マルチメディアプロセッサ３ｂの一括制御部３１に対して、コンポーネントコード”Ｚ１”を送信する。

マルチメディアプロセッサ３ｂの一括制御部３１は、一括処理実行コンポーネントテーブル２０ｂから受信したコード”Ｚ１”をキーとするリストを抽出し、処理要求を送信するコンポーネントリスト１３ｂを取得する。コンポーネントリスト１３ｂには、”ａ”，”ｂ”の順にコンポーネントコードが記述されている。

マルチメディアプロセッサ３ａ，３ｂの一括制御部３１は、コンポーネントリスト１３ａ，１３ｂに記述されたコンポーネントコードの順に内部処理コマンドを送信し、機能を実行させる。すなわち、マルチメディアプロセッサ３ａのコードＡを有するコンポーネント、マルチメディアプロセッサ３ａのコードＢを有するコンポーネント、マルチメディアプロセッサ３ａのコードＣを有するコンポーネント、マルチメディアプロセッサ３ｂのコードａを有するコンポーネント、マルチメディアプロセッサ３ｂのコードｂを有するコンポーネント、の順に内部処理コマンドを送信し、機能を実行させる。

このように、複数のマルチメディアプロセッサで構成される場合においても、１つのマルチメディアプロセッサで構成される場合と同様に、連続して実行させる複数の処理要求を予め一括処理要求として定義しておき、代表的な一つのマルチメディアプロセッサ（＝ホストＣＰＵ２のクライアント２１からマルチメディアプロセッサ３ａ）の一括制御部３１に対して一括処理要求を発行する。

一括処理要求を受信した一括制御部３１は、定義に従って処理対象のコンポーネントに展開し、他のマルチマルチメディアプロセッサ３ｂでの処理が必要な場合は、該マルチマルチメディアプロセッサ３ｂの一括制御部に（一括）処理要求を送信し、機能を実行させる。すなわち、低速のバス通信であるホストＣＰＵ２からマルチメディアプロセッサ３ａへの通信、及びマルチメディアプロセッサ３ａ，３ｂ間の通信を用いた処理要求の通信回数・通信量を低減することができるため、処理要求発行から実際に機能が実現されるまでの時間を短縮することができる。

なお、本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。

本発明の実施の形態に係わるマルチメディア処理制御装置のハードウェア構成の一例を説明する概略ブロック図。 本発明の実施の形態に係わるマルチメディア処理制御装置のソフトウェア構成の一例を説明する概略ブロック図。 一括制御部３１における処理要求の一連の流れを説明するフローチャート。 処理要求内容の識別に用いるテーブルの一例を説明する図。 コンポーネントの状態を管理するテーブルの一例を説明する図。 個別処理実行コンポーネントテーブル５０の一例を説明する図。 複数のマルチメディアプロセッサで構成されたマルチメディア処理制御装置のハードウェア構成の一例を説明する概略ブロック図。 複数のマルチメディアプロセッサ３ａ，３ｂにおける処理要求内容の識別に用いるテーブルの一例を説明する図。

２…ホストＣＰＵ、３…マルチメディアプロセッサ、４…バス，２１…クライアント、３１…一括制御部、３２ａ，３２ｂ，３２ｃ…コンポーネント、

Claims (5)

1. 画像や音声に関する処理要求を発行してサービスを提供するアプリケーションを備えた第１のプロセッサと、
   前記第１のプロセッサとバスを介して接続され、画像や音声の記録再生加工などを実現する機能に対応した処理を行う複数のコンポーネントを備えた第２のプロセッサと、
   を備えたマルチメディア処理制御装置であって、
   前記アプリケーションは、前記コンポーネントの個々に対して単機能処理を要求する個別処理要求、及び、複数の前記コンポーネントに対してシーケンス処理を要求する一括処理要求を発行することができ、
   前記第２のプロセッサは、前記アプリケーションから発行される前記一括処理要求に応じて前記複数のコンポーネントの個々に対して内部処理要求を送信し、前記シーケンス処理を制御するコンポーネント制御部を有することを特徴とする、マルチメディア処理制御装置。
2. 前記コンポーネント制御部は、前記アプリケーションから発行される前記処理要求を、予め設定された要求内容識別テーブルと照合し、前記処理要求が前記個別処理要求であるか前記一括処理要求であるかを識別することを特徴とする、請求項１に記載のマルチメディア処理制御装置。
3. 前記コンポーネント制御部には、前記一括処理要求に応じて前記内部処理要求を送信する複数の前記コンポーネントを特定し、特定された複数の前記コンポーネントの処理順番を特定することができる、一括処理対象コンポーネント識別テーブルが設定されていることを特徴とする、請求項１または請求項２に記載のマルチメディア処理制御装置。
4. 前記第２のプロセッサを複数備え、一つの前記一括処理要求で複数の前記第２のプロセッサを用いる前記シーケンス処理が実現可能であることを特徴とする、請求項１から請求項３のいずれか一項に記載のマルチメディア処理制御装置。
5. 前記コンポーネント制御部は、前記シーケンス処理が行われる複数の前記コンポーネントの処理状態を記録し管理することを特徴とする、請求項１から請求項４のいずれか一項に記載のマルチメディア処理制御装置。

Images