(57)【要約】【課題】コンポーネント制御部がコンポーネントと異なるアドレス空間に存在する場合でも、コンポーネントを制御することができるマルチメディア処理制御装置を提供する。【解決手段】マルチメディア処理制御装置１は、ノード１０２のコンポーネント１５〜１７の識別子のそれぞれに対応するノード１０１のコンポーネント１５〜１７の識別子を保持するテーブル３１と、要求が発行されると、テーブル３１を参照して、コンポーネント制御部１１が指定したノード１０１のコンポーネント１５〜１７の識別子のそれぞれを、ノード１０２のコンポーネント１５〜１７の識別子に変換して要求を発行する制御部API１２と、コンポーネント１５〜１７が存在するアドレス空間から変換された要求を発行する処理部API１３と、変換された要求に基づいて、コンポーネント１５〜１７の制御を行うコンポーネント処理部１４とを有する。【選択図】図２
2011039981.tif 000002
【特許請求の範囲】
【請求項１】
第１のアドレス空間に生成されたそれぞれが所定の処理を実行する複数のコンポーネントの管理情報と、前記複数のコンポーネントの管理情報のそれぞれを指し示す複数の第１のアドレス情報とを保持すると共に、前記複数のコンポーネントの制御を行うコンポーネント制御部が存在する第２のアドレス空間に前記複数の第１のアドレス情報のそれぞれに対応する複数の第２のアドレス情報を保持する保持部と、
前記コンポーネント制御部から処理要求が発行されると、前記保持部を参照して、前記コンポーネント制御部が指定した前記第２のアドレス空間における前記複数の第２のアドレス情報のそれぞれを、前記第１のアドレス空間における前記複数の第１のアドレス情報に変換して前記処理要求を発行する制御部用要求発行部と、
前記制御部用要求発行部により発行された前記コンポーネント制御部からの前記処理要求を前記第１のアドレス空間から発行する処理部用要求発行部と、
前記処理部用要求発行部により発行された前記処理要求の前記第１のアドレス空間における前記複数の第１のアドレス情報に基づいて、前記複数のコンポーネントの制御を行うコンポーネント処理部と、
を有することを特徴とするマルチメディア処理制御装置。
【請求項２】
前記保持部は、前記コンポーネント制御部と前記複数のコンポーネントとの間で共有するバッファの前記第１のアドレス空間における第３のアドレス情報を保持すると共に、前記第２のアドレス空間に前記第３のアドレス情報に対応する第４のアドレス情報を保持し、
前記制御部用要求発行部は、前記処理要求が発行されると、前記保持部を参照して、前記コンポーネント制御部が指定した前記第２のアドレス空間における前記第４のアドレス情報を、前記第１のアドレス空間における前記複数の第３のアドレス情報に変換し、前記処理部用要求発行部に前記処理要求を発行することを特徴とする請求項１に記載のマルチメディア処理制御装置。
【請求項３】
前記処理部用要求発行部は、前記複数のコンポーネントまたは前記コンポーネント処理部から前記処理要求に対する処理結果の通知及び処理データの通知が発生すると、前記処理結果及び処理データを前記制御部用要求発行部に通知することを特徴とする請求項１または２に記載のマルチメディア処理制御装置。
【請求項４】
前記制御部用要求発行部及び前記処理部用要求発行部は、互いにデータ通信を行い、前記処理要求の発行、前記処理結果の通知及び前記処理データの通知を行うことを特徴とする請求項３に記載のマルチメディア処理制御装置。
【請求項５】
前記制御部用要求発行と対応する前記コンポーネント制御部との組を、それぞれが異なるアドレス空間に複数有し、
前記複数の制御部用要求発行部のそれぞれは、対応する前記コンポーネント制御部から前記複数のコンポーネントのインスタンスの生成要求が発行されると、前記インスタンスの共有が設定されているか否かを判定し、前記共有が設定されているとき、前記異なるアドレス空間に存在する前記複数の制御部用要求発行部に前記複数のコンポーネントと同一の前記インスタンスが存在するか否かを問い合わせ、インスタンスが存在する場合、前記インスタンスの生成を行わず、前記複数のコンポーネントの管理情報及び前記複数のコンポーネントの管理情報のそれぞれを指し示す複数の第１のアドレス情報を共有することを特徴とする請求項１から４のいずれか１項に記載のマルチメディア処理制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディア処理制御装置に関し、特に、コンポーネントの制御を行うマルチメディア処理制御装置に関する。
【背景技術】
【０００２】
従来、例えば画像処理技術の分野において、複数の機能ブロックを複数利用して所望の機能を実現するマルチメディア処理制御装置が用いられている。例えば、OpenMAXの規格では、動画像の記録または再生を実現する複数の機能ブロックのそれぞれをコンポーネントと定義している。そして、複数のコンポーネントのそれぞれは、データ通信用のポートを有し、コンポーネント間においてデータ通信用のポートの接続設定が行われることにより、ポートを経由してコンポーネント間においてデータ転送が行われる。
【０００３】
OpenMAXの規格では、クライアントモジュール（以下、単にクライアントという）が規定インターフェースを呼び出し、各コンポーネントの制御を行う。各コンポーネントの制御とは、例えば、動画像の再生を行うための複数のコンポーネントの生成、上述したポートの接続設定及び生成した複数のコンポーネントに対してのデータ処理の要求の発行等である。これにより、マルチメディア処理制御装置は、複数のコンポーネントを利用して動画像の再生等の処理を行うことができる。この場合、コンポーネントの生成及び制御を行うコンポーネント制御部としてのクライアントと各コンポーネントとは従来、同一のチップに存在している。
【０００４】
しかし、コンポーネント及び規定インターフェースが１つのチップに実装され、このチップの外からクライアントがコンポーネントの制御を行おうとする場合、クライアントがコンポーネントの情報を規定インターフェースでは参照できない。即ち、クライアントがコンポーネントと異なるチップにある場合は、コンポーネントの制御ができないという問題があった。
【０００５】
これは、クライアントの存在するアトレス空間がコンポーネント及び規定インターフェースの存在するアドレス空間と異なるためである。そのため、クライアントがコンポーネント及び規定インターフェースとは別のアドレス空間にあるリモートシステムでは、クライアントがコンポーネントの生成及び制御を行うことができない。
【０００６】
また、例えば、クライアント及びコンポーネントが通信ネットワークを介して接続されているシステムが提案されている（例えば、特許文献１参照）。しかし、この提案のシステムは、クライアントがコンポーネントの存在するコンポーネントホストのIPアドレスを用いてノード指定するものであり、クライアントがコンポーネントの生成及び制御をすることができない。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開平１１−３３８８４１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明は、コンポーネント制御部の存在するアドレス空間がコンポーネントの存在するアドレス空間と異なる場合でも、コンポーネント制御部がコンポーネントを制御することができるマルチメディア処理制御装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の一態様によれば、第１のアドレス空間に生成されたそれぞれが所定の処理を実行する複数のコンポーネントの管理情報と、前記複数のコンポーネントの管理情報のそれぞれを指し示す複数の第１のアドレス情報とを保持すると共に、前記複数のコンポーネントの制御を行うコンポーネント制御部が存在する第２のアドレス空間に前記複数の第１のアドレス情報のそれぞれに対応する複数の第２のアドレス情報を保持する保持部と、前記コンポーネント制御部から処理要求が発行されると、前記保持部を参照して、前記コンポーネント制御部が指定した前記第２のアドレス空間における前記複数の第２のアドレス情報のそれぞれを、前記第１のアドレス空間における前記複数の第１のアドレス情報に変換して前記処理要求を発行する制御部用要求発行部と、前記制御部用要求発行部により発行された前記コンポーネント制御部からの前記処理要求を前記第１のアドレス空間から発行する処理部用要求発行部と、前記処理部用要求発行部により発行された前記処理要求の前記第１のアドレス空間における前記複数の第１のアドレス情報に基づいて、前記複数のコンポーネントの制御を行うコンポーネント処理部とを有することを特徴とするマルチメディア処理制御装置を提供することができる。
【発明の効果】
【００１０】
本発明のマルチメディア処理制御装置によれば、コンポーネント制御部の存在するアドレス空間がコンポーネントの存在するアドレス空間と異なる場合でも、コンポーネント制御部がコンポーネントを制御することができる。
【図面の簡単な説明】
【００１１】
【図１】第１の実施の形態に係るマルチメディア処理制御システムの構成を説明するための説明図である。
【図２】第１の実施の形態に係るマルチメディア処理制御装置の構成を説明するための説明図である。
【図３】制御部API１２が保持及び管理するテーブルの例を説明するための説明図である。
【図４】コンポーネント生成時の処理の流れの例を説明するためのフローチャートである。
【図５】コンポーネント制御時の処理の流れの例を説明するためのフローチャートである。
【図６】第２の実施の形態に係るマルチメディア処理制御システムの構成を説明するための説明図である。
【図７】第２の実施の形態に係るマルチメディア処理制御装置の構成を説明するための説明図である。
【図８】制御部API１２ａが保持及び管理するテーブルの例を説明するための説明図である。
【発明を実施するための形態】
【００１２】
以下、図面を参照して本発明の実施の形態について詳細に説明する。
【００１３】
（第１の実施の形態）
まず、図１に基づき、本発明の第１の実施の形態に係るマルチメディア処理制御システムの構成について説明する。図１は、第１の実施の形態に係るマルチメディア処理制御システムの構成を説明するための説明図である。
【００１４】
図１に示すように、マルチメディア処理制御システム１００は、ノード１０１と、１チップの半導体装置であるノード１０２と、バス１０３とを有して構成されている。ノード１０１及びノード１０２は、互いにバス１０３を介して接続されている。また、ノード１０１、ノード１０２及びバス１０３は、図示しない基板に積層され構成されている。
【００１５】
ノード１０１は、例えば、外付けのCPUであり、ノード１０２の制御を行う。このノード１０１は、CPU１１１と、ROM１１２と、RAM１１３と、バスインターフェース（以下、バスI/Fという）１１４と、ローカルバス１１５とを有して構成されている。CPU１１１、ROM１１２、RAM１１３及びバスI/F１１４は、互いにローカルバス１１５を介して接続されている。
【００１６】
ROM１１２には、コンポーネント制御プログラムと制御部向けAPIとが格納されている。CPU１１１は、これらのプログラムをROM１１２から読み出し、RAM１１３上に展開し実行する。コンポーネント制御プログラム及び制御部向けAPIがCPU１１１によって実行されることにより、それぞれ後述するコンポーネント制御部及び制御部向けAPIが構成される。
【００１７】
一方、ノード１０２は、１チップの半導体装置として構成され、ノード１０１からの制御により動画像の再生または録画等を行う。このノード１０２は、CPU１２１と、ROM１２２と、RAM１２３と、バスI/F１２４と、ローカルバス１２５とを有して構成されている。CPU１２１、ROM１２２、RAM１２３及びバスI/F１２４は、互いにローカルバス１２５を介して接続されている。
【００１８】
ROM１２２には、処理部向けAPIとコンポーネント処理プログラムと複数のコンポーネントプログラムとが格納されている。CPU１２１は、これらのプログラムをROM１２２から読み出し、RAM１２３上に展開し実行する。処理部向けAPI、コンポーネント処理プログラム及び複数のコンポーネントプログラムがCPU１２１によって実行されることにより、それぞれ後述する処理部向けAPI、コンポーネント処理部、複数のコンポーネントが構成される。
【００１９】
複数のコンポーネントプログラムのそれぞれは、例えば、ビデオのデコード処理あるいはフィルタ処理等の単機能の処理を行うプログラムである。これらの単機能の処理を組み合わせて、最終的なデータ処理、例えば、動画像の記録または再生を行い、処理結果を図示しない表示装置に表示する。
【００２０】
このように、マルチメディア処理制御システム１００は、ノード１０１及びノード１０２がバス１０３を介して接続される構成のため、ノード１０１に格納されているコンポーネント制御プログラムのアドレス空間とノード１０２に格納されているコンポーネントプログラムのアドレス空間とが異なる構成となっている。
【００２１】
なお、マルチメディア処理制御システム１００は、ノード１０１及びノード１０２がバス１０３を介して接続される構成であるが、ノード１０１のコンポーネント制御プログラム及びノード１０２のコンポーネントプログラムのアドレス空間が異なる構成であればこれに限定されるものではない。例えば、ノード１０１及び１０２のそれぞれがパーソナルコンピュータであり、それらのパーソナルコンピュータが、バス１０３に代わりネットワークを介して接続される構成であってもよい。そして、一方のパーソナルコンピュータにコンポーネント制御プログラム及び制御部向けAPIが格納され、他方のパーソナルコンピュータに処理部向けAPI、コンポーネント処理プログラム及び複数のコンポーネントプログラムが格納され構成される。
【００２２】
コンポーネント制御プログラム及び制御部向けAPIがCPU１１１上において実行され、処理部向けAPI、コンポーネント処理プログラム及び複数のコンポーネントプログラムがCPU１２１上において実行されることにより、図２に示すマルチメディア処理制御装置が構成される。
【００２３】
ここで、このように構成されるマルチメディア処理制御装置の構成について説明する。図２は、第１の実施の形態に係るマルチメディア処理制御装置の構成を説明するための説明図である。
【００２４】
図２に示すように、マルチメディア処理制御装置１は、コンポーネント制御部１１と、制御部向けAPI（以下、制御部APIと略す）１２と、処理部向けAPI（以下、処理部APIと略す）１３と、コンポーネント処理部１４と、複数、ここでは３つのコンポーネント１５〜１７とを有して構成されている。
【００２５】
マルチメディア処理制御装置１は、動画像の再生処理が指示されたときの状態を示している。例えば、コンポーネント１５は、ビデオデコード処理を実行する機能ブロックであり、コンポーネント１６は、フィルタリング処理を実行する機能ブロックであり、コンポーネント１７は、画面に出力処理する機能ブロックである。マルチメディア処理制御装置１は、これらのコンポーネント１５〜１７を組み合わせて、動画像の再生を行う。なお、マルチメディア処理制御装置１は、３つのコンポーネント１５〜１７の他に、図示しない複数のコンポーネントを有していてもよい。そして、マルチメディア処理制御装置１は、例えば、動画像の録画処理が指示された場合、これらの複数のコンポーネントを組み合わせ動画像の録画を行う。
【００２６】
ノード１０１においてコンポーネント制御部１１が動作しており、ノード１０２においてコンポーネント処理部１４とコンポーネント１５〜１７が動作している例を示している。ノード１０１及びノード１０２は、上述したように、バス１０３を介して接続されており、互いにデータ通信が可能となっている。
【００２７】
コンポーネント制御部１１が動作しているノード１０１には、コンポーネント１５〜１７を制御するためのインターフェースを提供する制御部API１２が動作しており、コンポーネント処理部１４、コンポーネント１５〜１７が動作しているノード１０２には、処理部API１３が動作している。制御部用要求発行部である制御部API１２と処理部用要求発行である処理部API１３とは、互いに通信しながら動作するソフトウエアであり、制御部API１２は、コンポーネント制御部１１に対して、コンポーネント処理部１４、コンポーネント１５〜１７のように振る舞い、処理部API１３は、コンポーネント処理部１４、コンポーネント１５〜１７に対して、コンポーネント制御部１１のように振る舞う。
【００２８】
コンポーネント制御部１１からコンポーネント処理部１４、コンポーネント１５〜１７に対する要求は、コンポーネント制御部１１が制御部API１２のインターフェースを呼び出すことで行う。コンポーネント制御部１１からの要求を受けた制御部API１２は、バス１０３を用いたデータ通信によって、処理部API１３に対してコンポーネント制御部１１の要求を通知する。このとき、制御部API１２及び処理部API１３間におけるデータ通信は、事前に定義されたデータ通信プロトコルを用いて行われる。
【００２９】
制御部API１２からの要求を受けた処理部API１３は、受けた要求をコンポーネント処理部１４あるいはコンポーネント１５〜１７への要求に変換した後、コンポーネント処理部１４あるいはコンポーネント１５〜１７に対して要求を発行する。
【００３０】
コンポーネント処理部１４あるいはコンポーネント１５〜１７からの結果の通知あるいはイベントの通知が発生する場合、処理部API１３がこれらの通知を受け、制御部API１２へ通知する。制御部API１２、処理部API１３からの通知を受けて、コンポーネント制御部１１に対して通知を行う。
【００３１】
コンポーネント１５〜１７は、動画像の再生処理を行うために、コンポーネント１５〜１７間においてデータの送受信を行う。そのため、コンポーネント１５〜１７は、データの送受信を行うためのポートを有している。
【００３２】
図２に示すように、コンポーネント１５は、３つのポート２１ａ〜２１ｃを有している。また、コンポーネント１６は、４つのポート２２ａ〜２２ｄを有し、コンポーネント１７は、２つのポート２３ａ及び２３ｂを有している。コンポーネント１５の持つポート２１ａ〜２１ｃは、他のコンポーネント１６又は１７の持つポートと接続設定を行うことで、ポート間のデータ転送を実現する。
【００３３】
図２の例では、コンポーネント１５の保持するポート２１ｂ及び２１ｃが、それぞれコンポーネント１６の保持するポート２２ａ及び２２ｂに接続設定されている。マルチメディア処理制御装置１は、これらのポート２１ｂ及び２２ａあるいはポート２１ｃ及び２２ｂを用いて、コンポーネント１５及びコンポーネント１６間におけるデータ転送を行う。同様に、コンポーネント１６の保持するポート２２ｃ及び２２ｄが、それぞれコンポーネント１７の保持するポート２３ａ及び２３ｂに接続設定されている。マルチメディア処理制御装置１は、これらのポート２２ｃ及び２３ａあるいはポート２２ｄポート２３ｂを用いて、コンポーネント１６及びコンポーネント１７間におけるデータ転送を行う。
【００３４】
コンポーネント制御部１１は、コンポーネント１５〜１７の各ポートと接続設定することが可能である。図２の例では、コンポーネント制御部１１とコンポーネント１５の保持するポート２１ａとが接続設定されている。これにより、コンポーネント制御部１１及びコンポーネント１５間におけるデータ転送が行われる。
【００３５】
また、コンポーネント１５〜１７は、それぞれバッファ２４〜２６を保持しており、上述したポートの接続を行うことにより、接続したコンポーネント制御部１１及びコンポーネント１５〜１７間あるいはコンポーネント１５〜１７間において、バッファ２４〜２６を用いデータを共有することができる。図２の例では、バッファ２４のデータは、コンポーネント制御部１１とコンポーネント１５間において共有されている。この場合、コンポーネント制御部１１は、バッファ２４に格納されるデータを制御可能となっている。同様に、バッファ２５のデータは、コンポーネント１５及び１６間において共有され、バッファ２６のデータは、コンポーネント１６及び１７間において共有されている。
【００３６】
コンポーネント制御部１１は、実現したい機能に応じてコンポーネント１５〜１７の生成及び配置を行うための要求コマンドを、制御部API１２及び処理部API１３を介してコンポーネント処理部１４に発行し、コンポーネント１５〜１７の生成及び生成したコンポーネント１５〜１７のそれぞれが保持する各ポートの接続を事前に設定する。そして、コンポーネント制御部１１は、生成されたコンポーネント１５〜１７の制御を行うために、例えば、動画像の再生を行うための要求コマンドを、制御部API１２及び処理部API１３を介してコンポーネント処理部１４に発行し、動画像の再生を行う。
【００３７】
ここで、コンポーネント１５〜１７の生成及び制御時の処理について詳細に説明する。  
まず、コンポーネント１５〜１７の生成時の処理について説明する。  
コンポーネント制御部１１は、制御部API１２に対して、実現したい機能に応じたコンポーネントの生成を要求する。ここでは、コンポーネント制御部１１は、動画像の再生を行うために、コンポーネント１５〜１７の生成の要求を発行したものとする。
【００３８】
制御部API１２は、コンポーネント制御部１１からの要求をデータパケットに変換し、バス１０３を介して処理部API１３に通知する。
【００３９】
処理部API１３は、制御部API１２からの要求に従って、コンポーネント処理部１４を呼び出す。
【００４０】
コンポーネント処理部１４は、処理部API１３からの要求に従って、コンポーネント１５〜１７のインスタンスを生成する。ここで、コンポーネント１５〜１７のインスタンスは、コンポーネント１５〜１７の管理情報及び識別子等である。ここで、コンポーネント１５〜１７の管理情報のそれぞれは、コンポーネント１５〜１７の名称、コンポーネント１５〜１７の状態、ポートの数及びポートの状態等である。また、コンポーネント１５〜１７の識別子のそれぞれは、ノード１０２のアドレス空間上のコンポーネント１５〜１７の管理情報へのポインタである。即ち、これらのポインタのそれぞれは、コンポーネント１５〜１７の管理情報を格納したアドレスの先頭を指している。
【００４１】
コンポーネント処理部１４は、このコンポーネント１５〜１７のインスタンス、ここでは、コンポーネント１５〜１７の管理情報及び識別子をRAM１２３に格納する。また、コンポーネント処理部１４は、実行結果、ノード１０２のコンポーネント１５〜１７の管理情報及び識別子を処理部API１３に通知する。処理部API１３は、実行結果、ノード１０２のコンポーネント１５〜１７の管理情報及び識別子を、バス１０３を介して制御部API１２に通知する。
【００４２】
制御部API１２は、ノード１０２におけるコンポーネント１５〜１７の識別子のそれぞれに対応する、ノード１０１におけるコンポーネント１５〜１７の識別子を生成する。制御部API１２は、生成したノード１０１におけるコンポーネント１５〜１７の識別子をコンポーネント制御部１１に返却する。また、制御部API１２は、ノード１０１におけるコンポーネント１５〜１７の識別子と、ノード１０２におけるコンポーネント１５〜１７の管理情報及び識別子とを対応付けたコンポーネント情報を保持及び管理する。制御部API１２は、このコンポーネント情報を後述する図３に示すテーブルとしてRAM１１３に格納し、コンポーネント情報の保持及び管理を行う。
【００４３】
次に、このように生成されたコンポーネント１５〜１７を制御する処理について説明する。  
コンポーネント制御部１１が制御部API１２に対して、コンポーネント１５〜１７へのパラメータ設定あるいはコンポーネント１５〜１７の状態遷移を要求する。パラメータ設定では、例えば、デコードするデータのフォーマット及び出力する画像サイズ等の設定が行われる。また、コンポーネント１５〜１７の状態遷移では、例えば、メモリの確保及び処理の実行等への遷移が行われる。
【００４４】
制御部API１２は、コンポーネント制御部１１からの要求をデータパケットに変換し、バス１０３を介して処理部API１３に通知する。制御部API１２は、ノード１０１におけるコンポーネント１５〜１７の識別子をそれぞれノード１０２におけるコンポーネント１５〜１７の識別子に変換し、変換したノード１０２におけるコンポーネント１５〜１７の識別子を処理部API１３に通知する。この変換は、後述する図３、即ち、コンポーネント１５〜１７の生成のときに制御部API１２によって保持及び管理されているテーブルを用いて行われる。
【００４５】
処理部API１３は、制御部API１２からの要求に従ってコンポーネント処理部１４を呼び出す。
【００４６】
コンポーネント処理部１４は、ノード１０２におけるコンポーネント１５〜１７の識別子に基づいて、ノード１０２のコンポーネント１５〜１７の管理情報を示すデータ構造にアクセスし、コンポーネント１５〜１７へ処理要求を発行する。コンポーネント処理部１４は、処理結果及び出力データを処理部API１３に通知する。処理部API１３は、この処理結果及び出力データを、バス１０３を介して制御部API１２へ通知する。
【００４７】
制御部API１２は、処理結果、出力データをコンポーネント制御部１１に通知する。コンポーネント制御部１１は、このような要求を繰り返し発行することで、所定のデータ処理、ここでは、動画像の再生処理を行う。
【００４８】
ここで、制御部API１２が保持及び管理するテーブルについて説明する。図３は、制御部API１２が保持及び管理するテーブルの例を説明するための説明図である。
【００４９】
図３に示すように、制御部API１２が保持及び管理するテーブル３１には、コンポーネント情報３２とバッファメタ情報３３との２つの情報がある。
【００５０】
コンポーネント情報３２は、ノード１０１におけるコンポーネント１５〜１７の識別子と、ノード１０２におけるコンポーネント１５〜１７の管理情報及び識別子とが対応付けられている。また、バッファメタ情報３３は、ノード１０１におけるバッファ２４の識別子と、ノード１０２におけるバッファ２４の識別子とが対応付けられている。
【００５１】
上述したように、コンポーネント制御部１１がコンポーネント１５〜１７の生成をコンポーネント処理部１４に要求すると、コンポーネント処理部１４は、コンポーネント１５〜１７のインスタンス、ここでは、管理情報及び識別子を生成する。コンポーネント処理部１４は、コンポーネント１５〜１７の管理情報及び識別子をRAM１２３上において保持及び管理するが、コンポーネント処理部１４の存在するノード１０２のRAM１２３のアドレス空間は、コンポーネント制御部１１のRAM１１３のアドレス空間とは異なる。そのため、コンポーネント制御部１１は、コンポーネント処理部１４が保持したコンポーネント１５〜１７の管理情報及び識別子を用いて、コンポーネント１５〜１７を制御することができない。
【００５２】
そこで、コンポーネント処理部１４は、ノード１０２におけるコンポーネント１５〜１７の管理情報及び識別子を、処理部API１３を介して制御部API１２に通知する。制御部API１２は、ノード１０２におけるコンポーネント１５〜１７の管理情報及び識別子のそれぞれに対応するノード１０１におけるコンポーネント１５〜１７の識別子を生成し、テーブル３１として保持する。さらに、ノード１０１におけるコンポーネント１５〜１７の識別子は、コンポーネント制御部１１に返却される。
【００５３】
コンポーネント制御部１１と制御部API１２との間では、このノード１０１におけるコンポーネント１５〜１７の識別子であるアドレスが用いられ、コンポーネント１５〜１７の制御が行われる。コンポーネント制御部１１からコンポーネント１５〜１７に対して処理要求が行われた場合、制御部API１２は管理するコンポーネント情報３２、即ち、テーブル３１を検索し、コンポーネント制御部１１が要求を発行したいコンポーネント１５〜１７を特定する。その後、制御部API１２は、コンポーネント制御部１１から発行されたノード１０１におけるコンポーネント１５〜１７の識別子を、コンポーネント処理部１４が管理するノード１０２におけるコンポーネント１５〜１７の識別子に変換し、処理部API１３へ渡し、処理要求を発行する。
【００５４】
また、図２では、コンポーネント制御部１１とコンポーネント１５との間において、バッファ２４を用いてデータが共有されている。しかし、上述したように、コンポーネント処理部１４の存在するノード１０２のRAM１２３のアドレス空間は、コンポーネント制御部１１のRAM１１３のアドレス空間とは異なる。そのため、コンポーネント制御部１１は、コンポーネント処理部１４が保持するバッファ２４の識別子を用いてバッファ２４を制御することができない。そこで、制御部API１２は、ノード１０２におけるバッファ２４の識別子と１対１に対応するノード１０１におけるバッファ２４の識別子を生成し、生成したノード１０１におけるバッファ２４の識別子をコンポーネント制御部１１に返却する。さらに、制御部API１２は、ノード１０１におけるバッファ２４の識別子とノード１０２におけるバッファ２４の識別子を対応付け、バッファメタ情報３３としてテーブル３１に保持する。
【００５５】
コンポーネント制御部１１は、バッファ２４を制御する際に、ノード１０１におけるバッファ２４の識別子を制御部API１２に通知する。そして、制御部API１２は、テーブル３１のバッファメタ情報３３を参照して、ノード１０１におけるバッファ２４の識別子をノード１０２におけるバッファ２４の識別子に変換し、処理部API１３に通知する。これにより、コンポーネント制御部１１とコンポーネント１５との間において、バッファ２４を用いてデータの共有が可能となる。
【００５６】
本実施の形態では、バッファ２５は、コンポーネント１５及び１６間において共有され、バッファ２６は、コンポーネント１６及び１７間において共有されているため、制御部API１２がバッファ２５及び２６に関するバッファメタ情報３３を管理する必要はない。また、図３に示すテーブル３１のバッファメタ情報３３には、ノード１０１におけるバッファ２４の識別子とノード１０２におけるバッファ２４の識別子とが対応付けられているが、コンポーネント制御部１１及びコンポーネント１６間において、バッファ２５が共有される場合、制御部API１２は、ノード１０１におけるバッファ２５の識別子とノード１０２におけるバッファ２５の識別子とを対応付け、バッファメタ情報３３としてテーブル３１に追加する。
【００５７】
なお、制御部API１２がコンポーネント情報３２とバッファメタ情報３３とをテーブル３１として保持及び管理するとして説明したが、制御部API１２に代わり処理部API１３がこのテーブル３１を保持及び管理するようにしてもよい。
【００５８】
ここで、このように構成されるマルチメディア処理制御装置１の動作について説明する。
【００５９】
図４は、コンポーネント生成時の処理の流れの例を説明するためのフローチャートである。
【００６０】
まず、コンポーネント制御部１１が制御部API１２に対してコンポーネント１５〜１７の生成を要求する（ステップＳ１）。制御部API１２は、コンポーネント制御部１１からの要求をデータパケットへ変換し、バス１０３を介して処理部API１３に送信する（ステップＳ２）。処理部API１３は、受信したデータパケットからコンポーネント制御部１１の要求を判別し、コンポーネント処理部１４へ処理要求を発行する（ステップＳ３）。コンポーネント処理部１４は、発行された処理要求に応じて、コンポーネント１５〜１７を新規に生成する（ステップＳ４）。コンポーネント処理部１４は、実行結果、コンポーネント１５〜１７の管理情報、コンポーネント１５〜１７の識別子を処理部API１３へ通知する（ステップＳ５）。処理部API１３は、実行結果、コンポーネント１５〜１７の管理情報及びノード１０２におけるコンポーネント１５〜１７の識別子を制御部API１２へ通知する（ステップＳ６）。制御部API１２は、コンポーネントの管理情報を保存する（ステップＳ７）。制御部API１２は、ノード１０２におけるコンポーネント１５〜１７の識別子と１対１に対応するノード１０１におけるコンポーネント１５〜１７の識別子を新規に生成し、新規に生成したノード１０１におけるコンポーネント１５〜１７の識別子をコンポーネント制御部１１へ返却する（ステップＳ８）。このノード１０１におけるコンポーネント１５〜１７の識別子は、ステップＳ７において保存したコンポーネント１５〜１７の管理情報へのポインタである。
【００６１】
図５は、コンポーネント制御時の処理の流れの例を説明するためのフローチャートである。
【００６２】
まず、コンポーネント制御部１１が制御部API１２に対してコンポーネント１５〜１７の制御を要求する（ステップＳ１１）。コンポーネント制御部１１は、要求発行時に対象のコンポーネント１５〜１７を指定するために、ノード１０１におけるコンポーネント１５〜１７の識別子を指定する。制御部API１２は、処理要求対象のコンポーネント１５〜１７の識別子をノード１０１における識別子からノード１０２における識別子へ変換する（ステップＳ１２）。そして、制御部API１２は、コンポーネント制御部１１の要求をデータパケットへ変換して、バス１０３を介して処理部API１３へ送信する（ステップＳ１３）。処理部API１３は、受信したデータパケットからコンポーネント制御部１１の要求を判別し、コンポーネント処理部１４へ処理要求を発行する（ステップＳ１４）。コンポーネント処理部１４は、コンポーネント１５〜１７に対して処理要求発行を行い、実行結果、出力データを処理部API１３へ通知する（ステップＳ１５）。処理部API１３は、実行結果、出力データを制御部API１２へ通知する（ステップＳ１６）。制御部API１２は、実行結果、出力データをコンポーネント制御部１１へ通知する（ステップＳ１７）。制御部API１２は、バッファメタ情報等の模擬化したデータがある場合、ノード１０２のデータをノード１０１のデータへ変換した後、コンポーネント制御部１１に通知する（ステップＳ１８）。
【００６３】
以上のように、制御部API１２は、コンポーネント制御部１１からの要求をデータに変換して、処理部API１３に通知する。処理部API１３は、生成されたノード１０２におけるコンポーネント１５〜１７の管理情報及び識別子を制御部API１２に通知する。制御部API１２は、ノード１０２におけるコンポーネント１５〜１７の識別子に対応するノード１０１における識別子を生成し、コンポーネント制御部１１に通知するようにした。この結果、コンポーネント制御部１１が異なるアドレス空間に存在するコンポーネント１５〜１７を制御する際に、このノード１０１におけるコンポーネント１５〜１７の識別子を用いて要求を制御部API１２に通知すると、制御部API１２がノード１０１におけるコンポーネント１５〜１７の識別子をノード１０２におけるコンポーネント１５〜１７の識別子に変換する。そして、変換されたノード１０２におけるコンポーネント１５〜１７の識別子が処理部API１３を介してコンポーネント処理部１４に供給されることにより、コンポーネント処理部１４は、ノード１０２におけるコンポーネント１５〜１７の識別子に基づいて、対応するコンポーネント１５〜１７の管理情報を指定し、コンポーネント１５〜１７の制御を行うことができる。
【００６４】
よって、本実施の形態のマルチメディア処理制御装置によれば、コンポーネント制御部の存在するアドレス空間がコンポーネントの存在するアドレス空間と異なる場合でも、コンポーネント制御部がコンポーネントを制御することが可能となる。
【００６５】
（第２の実施の形態）
次に、第２の実施の形態について説明する。従来、コンポーネント制御部とコンポーネントとのアドレス空間が異なるリモートシステムにおいては、複数のコンポーネント制御部からコンポーネントを共有することはできなかった。そこで、本実施の形態のマルチメディア処理制御装置では、複数のノードのそれぞれにコンポーネント制御部が存在する場合も、複数のノードのコンポーネント制御部がコンポーネントの制御が可能となり、かつ複数のノードのコンポーネント制御部間において、生成したコンポーネントのインスタンスを共有することができるようにしている。
【００６６】
図６は、第２の実施の形態に係るマルチメディア処理制御システムの構成を説明するための説明図である。なお、図６において図１と同様の構成については、同一の符号を付して説明を省略する。
【００６７】
図６に示すように、マルチメディア処理制御システム１００ａは、図１のノード１０１、ノード１０２、バス１０３に加え、ノード１０１ａが追加され構成されている。ノード１０１、ノード１０１ａ及びノード１０２は、互いにバス１０３を介して接続されている。
【００６８】
ノード１０１ａは、ノード１０１と同様の構成であり、CPU１１１ａと、ROM１１２ａと、RAM１１３ａと、バスI/F１１４ａと、ローカルバス１１５ａとを有して構成されている。CPU１１１ａ、ROM１１２ａ、RAM１１３ａ及びバスI/F１１４ａは、互いにローカルバス１１５ａを介して接続されている。
【００６９】
ROM１１２ａには、ROM１１２と同様にコンポーネント制御部プログラムと制御部APIとが格納されている。CPU１１１ａは、これらのプログラムをROM１１２ａから読み出し、RAM１１３ａ上に展開し実行する。
【００７０】
ノード１０１ａは、バス１０３を介して、ノード１０２のコンポーネント１５〜１７の制御を行う。即ち、マルチメディア処理制御システム１００ａは、２つのコンポーネント制御部がコンポーネント１５〜１７を共有することが可能となっている。
【００７１】
なお、マルチメディア処理制御システム１００ａは、２つのノード１０１及び１０１ａを有する構成であるが、３つ以上のノードを有する構成であってもよい。即ち、３つ以上のコンポーネント制御部のそれぞれがコンポーネント１５〜１７を共有する構成であってもよい。
【００７２】
図７は、第２の実施の形態に係るマルチメディア処理制御装置の構成を説明するための説明図である。なお、図７において図２と同様の構成については、同一符号を付して説明を省略する。
【００７３】
図７に示すように、マルチメディア処理制御装置１ａは、図２のマルチメディア処理制御装置１にコンポーネント制御部１１ａと、制御部API１２ａとが追加され構成されている。
【００７４】
ノード１０１ａのコンポーネント制御部１１ａは、新たにコンポーネント１５〜１７の生成要求を発行するときに、生成する予定のコンポーネント１５〜１７のインスタンス共有の設定がされているか否かを判定する。コンポーネント制御部１１ａは、インスタンス共有の設定がされている場合、別のノード、ここでは、ノード１０１に生成する予定のコンポーネント１５〜１７と同一のコンポーネント１５〜１７のインスタンスがあるか否かを問い合わせる。即ち、コンポーネント制御部１１ａは、例えば、コンポーネント１５を生成する際に、ノード１０１にコンポーネント１５のインスタンスがあるか否かを問い合わせる。言い換えると、コンポーネント制御部１１ａは、ノード１０１のコンポーネント制御部１１によってコンポーネント１５が生成されているか否かを問い合わせることになる。ノード１０１にコンポーネント１５のインスタンスがある場合、即ち、コンポーネント制御部１１によってコンポーネント１５が生成されている場合、コンポーネント制御部１１ａは、コンポーネント１５の生成を行わずに、コンポーネント１５の管理情報及び識別子を共有する。そのため、制御部API１２ａは、後述する共有情報及び参照先アドレス情報を保持及び管理するとともに、コンポーネント制御部１１ａへノード１０１ａにおけるコンポーネント１５の識別子を返却する。制御部API１２ａは、コンポーネント１６及び１７についても同様の処理を行う。
【００７５】
一方、コンポーネント制御部１１ａは、生成する予定のコンポーネント１５〜１７のインスタンス共有の設定がされていない場合、上述した図４の生成処理を実行する。同様に、コンポーネント制御部１１ａは、コンポーネント制御部１１によって生成する予定のコンポーネント１５〜１７のインスタンスが生成されていない場合も、上述した図４の生成処理を実行する。
【００７６】
ここで、制御部API１２ａが管理及び保持するテーブルについて説明する。なお、制御部API１２も同様のテーブルを保持及び管理する。図８は、制御部API１２ａが保持及び管理するテーブルの例を説明するための説明図である。
【００７７】
図８に示すように、制御部API１２ａが管理するテーブル３１ａは、コンポーネント情報３２ａと、バッファメタ情報３３ａとを有し、このコンポーネント情報３２ａには、図３のコンポーネント情報３２にコンポーネント１５〜１７の共有情報及び参照先アドレス情報が追加され構成されている。
【００７８】
共有情報には、他のノード、ここではノード１０１にコンポーネント１５のインスタンスがあるか否かを示す情報が格納される。また、参照先アドレス情報には、共有情報がある場合、ノード１０１が保持しているノード１０２におけるコンポーネント１５の管理情報及び識別子のアドレスの情報が格納される。
【００７９】
コンポーネント制御部１１ａは、コンポーネント１５〜１７を制御する際に、ノード１０１ａにおけるコンポーネント１５〜１７の識別子を制御部API１２ａに出力する。制御部API１２ａは、コンポーネント１５〜１７の共有情報に別のノード１０１にコンポーネント１５〜１７のインスタンスがあることを示す情報がある場合、コンポーネント１５〜１７の参照先アドレス情報を参照する。そして、制御部API１２ａは、コンポーネント１５〜１７の参照先アドレス情報に基づいて、ノード１０１が管理しているノード１０２におけるコンポーネント１５〜１７の管理情報及び識別子を参照し、コンポーネント１５〜１７の制御を行う。
【００８０】
以上のように、制御部API１２ａは、コンポーネント情報３２ａとして、ノード１０１ａにおけるコンポーネント１５〜１７に識別子、ノード１０２におけるコンポーネント１５〜１７の管理情報及び識別子に加え、共有情報及び参照先アドレスを保持するようにした。これにより、バス１０３を介して異なるアドレス空間に存在する複数のコンポーネント制御部１１及び１１ａは、バス１０３を介して異なるアドレス空間に存在するコンポーネント１５〜１７を共有及び制御することが可能となる。
【００８１】
この結果、本実施の形態のマルチメディア処理制御装置１ａによれば、複数のノードのそれぞれにコンポーネント制御部が存在する場合も、複数のノードのコンポーネント制御部がコンポーネントの制御が可能となる。加えて、複数のノードのコンポーネント制御部間において、生成したコンポーネントのインスタンスを共有することが可能となる。
【００８２】
本明細書における各「部」は、実施の形態の各機能に対応する概念的なもので、必ずしも特定のハードウェアやソフトウェア・ルーチンに１対１には対応しない。従って、本明細書では、実施の形態の各機能を有する仮想的回路ブロック（部）を想定して実施の形態を説明した。なお、本明細書におけるフローチャート中の各ステップは、その性質に反しない限り、実行順序を変更し、複数同時に実行し、あるいは実行毎に異なった順序で実行してもよい。
【００８３】
なお、以上説明した動作を実行するプログラムは、コンピュータプログラム製品として、フレキシブルディスク、ＣＤ−ＲＯＭ等の可搬媒体や、ハードディスク等の記憶媒体に、その全体あるいは一部が記録され、あるいは記憶されている。そのプログラムコードがコンピュータにより読み取られて、動作の全部あるいは一部が実行される。あるいは、そのプログラムコードの全体あるいは一部を通信ネットワークを介して流通または提供することができる。利用者は、通信ネットワークを介してそのプログラムをダウンロードしてコンピュータにインストールしたり、あるいは記録媒体からコンピュータにインストールすることで、容易に本発明のマルチメディア処理制御装置を実現することができる。
【００８４】
本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。
【符号の説明】
【００８５】
１…マルチメディア処理制御装置、１１…コンポーネント制御部、１２…制御部API、１３…処理部API、１４…コンポーネント処理部、１５〜１７…コンポーネント、２１ａ〜２１ｃ，２２ａ〜２２ｄ，２３ａ，２３ｂ…ポート、２４〜２６…バッファ、３１，３１ａ…テーブル、１００…マルチメディア処理制御システム、１０１，１０１ａ，１０２…ノード、１０３…バス。
【図１】
2011039981.tif 000003
【図２】
2011039981.tif 000004
【図３】
2011039981.tif 000005
【図４】
2011039981.tif 000006
【図５】
2011039981.tif 000007
【図６】
2011039981.tif 000008
【図７】
2011039981.tif 000009
【図８】
2011039981.tif 000010