JP2006031261A - マルチメディア処理システム - Google Patents

Abstract

【課題】処理単位の論理モジュールが、実際に処理を行う処理モジュールと１対１対応になっていなくても、適切な処理モジュールを起動可能とすること。
【解決手段】マルチメディア処理抽象部（１−１）は、論理モジュール（１−２）と、各論理モジュール間を接続するストリームパス（１−４）、各論理モジュールとアプリケーションとの間でデータを送受信するストリームパイプ（１−３）、論理モジュールとストリームパイプとストリームパスの構成情報を持ちマルチメディア処理モジュールとの対応付けを行う対応付け管理部（１−５）からなり、各論理モジュールの生成、接続の度に、対応付け管理部により構成情報を更新し、以降、ストリームパイプ、ストリームパスを接続しなくなった時点で、アプリケーションから構成の確定という意味のＬＯＣＫ命令を受け付け、対応するマルチメディア処理モジュールを１つ確定し、起動させる。
【選択図】 図１

Description

本発明は、デジタル圧縮されたオーディオ（音声）・ビデオ（画像）・テキスト・静止画データ等のマルチメディアデータを処理するマルチメディア処理システムに関する。

近年、情報インフラの整備、マルチメディア技術の進展により、様々な伝送路、媒体から様々なコーデック方式（データ圧縮解凍方式）のマルチメディアストリームを記録、再生するマルチメディア機器が製品化されるようになった。例えば、１つの機器で、エムペグ（ＭＰＥＧ：Moving Picture Experts Group）の再生、録画、音声の再生、録画静止画の再生、録画と複数の処理を行える製品も現れている。

そのような機器で、様々なコーデック方式のマルチメディア処理を行う方法として、一連のマルチメディア処理を小さな処理単位に論理モジュール化して、それらの論理モジュールの接続を変えることで処理の変更を行うというシステムが特許文献１等により提案されている。これらのシステムでは、処理単位の論理モジュールが、あるハードウェアのドライバであったり、ソフトウェアフィルタであるなど、実際に処理を行う処理モジュールと１対１対応になっていた。
特開平１０−２８３１９５号公報

しかし、複数の論理モジュールの機能を併せた１つの処理モジュールが存在する場合、従来のシステムでは、論理モジュールの接続がいつ完了するか判断できないため、適切な処理モジュールを起動できないという課題があった。例えば、論理モジュールとしてオーディオデコーダとオーディオ出力の２つの機能を持つオーディオ再生処理モジュールや、同じく論理モジュールとしてオーディオデコーダ、オーディオ出力、ビデオデコーダ、ビデオ出力の４つの機能を持つオーディオ・ビデオ（ＡＶ）再生処理モジュールが存在する場合、従来のシステムでは、オーディオデコーダ、オーディオ出力の論理モジュールを生成し、接続した時点で、以降、ビデオデコーダ、ビデオ出力処理モジュールの生成、接続が無いかが判断できないため、オーディオ再生処理モジュールを起動していいのか、ビデオデコーダ、ビデオ出力処理モジュールの生成、接続を待つべきかの判断ができなかった。

以上の課題を解決するため、
本発明の請求項１に係るマルチメディア処理システムでは、
論理モジュールの生成、接続の指示、その構成の確定の通知を行うアプリケーションと、
アプリケーションからの指示に従うマルチメディア処理抽象部と、
実際のマルチメディア処理を行う処理モジュールとからなり、
マルチメディア処理抽象部は、
マルチメディア処理の各機能を抽象化する論理モジュールと、
各論理モジュール間を接続するストリームパスと、
各論理モジュールとアプリケーションの間でデータを送受信するストリームパイプと、
論理モジュールとストリームパイプとストリームパスの構成情報を持ち処理モジュールとの対応付けを行う対応付け管理部と、
から構成されており、
対応付け管理部は、アプリケーションからの指示に従い、各論理モジュールの生成、接続を行う度に構成情報を更新し、以降、ストリームパイプ、ストリームパスを接続しなくなった時点で、アプリケーションから構成の確定というＬＯＣＫ命令を受け付けることで、対応する処理モジュールを１つ確定し、起動させることを特徴とする（図１、図２、図３参照）。

請求項１の発明の場合、マルチメディア処理を抽象化した論理モジュールと実際に処理を行うマルチメディア処理モジュールとが１対１に対応していないシステムにおいても、適切な処理モジュールを起動することができる。

本発明の請求項２に係るマルチメディア処理システムでは、請求項１のマルチメディア処理システムで、ある論理モジュールにおいて、ストリームパイプ、ストリームパスの接続が完了した時点で、その論理モジュールは、アプリケーションから構成が確定したという意味のＬＯＣＫ命令を受け、その論理モジュールにストリームパス接続された全ての論理モジュールがＬＯＣＫ命令を受け付けた時点で、対応する処理モジュールを確定し、起動するシステムを提供する（図４参照）。

請求項２の発明の場合、複数のタスク（プロセス）が論理モジュールを生成、接続を行う場合でも、他のタスク（プロセス）の構成確定を気にすることなく、自分の生成した論理モジュールの構成確定を通知するのみで、適切な処理モジュールを起動することができる。

本発明の請求項３に係るマルチメディア処理システムでは、請求項１のマルチメディア処理システムで、複数のアプリケーションタスク（プロセス）から論理モジュールを生成、接続して処理モジュールを作成する場合に、どのタスクからロック命令が論理モジュールに来るかの情報を事前にテーブルで保持しておき、アプリケーションからＬＯＣＫ命令が呼ばれると、どのアプリケーションタスクからＬＯＣＫ命令が呼ばれたかを調べ、１つのアプリケーションタスクからの全てのＬＯＣＫが終了した時点で対応する処理モジュールがない場合は、アプリケーションタスクをスイッチさせることで、対応する処理モジュールが起動するまでは後続の処理を行わないようにするシステムを提供する（図５参照）。

請求項３の発明の場合、複数のアプリケーションタスクが論理モジュールを生成、接続を行う場合でも、自分の構成確定をした後、自動的に他のアプリケーションタスクに切り替わるため、他のアプリケーションタスクとの通信を行わずに、適切な処理モジュールを起動した後に後続の命令を実行することができる。

本発明の請求項４に係るマルチメディア処理システムでは、請求項１のマルチメディア処理システムで、各処理モジュールを動作させた場合に消費するＣＰＵ使用量、メモリ使用量等の処理モジュール動作環境情報を保持し、処理モジュールが動作するプロセッサの現在のＣＰＵ使用量、メモリ使用量等のプロセッサ環境情報を取得するプロセッサ環境情報取得手段、及び前記プロセッサ環境情報取得手段で取得したプロセッサ環境情報と処理モジュール動作環境情報とを比較して最適なマルチメディア処理モジュールを判定して起動する処理モジュール判定手段を持つシステムを提供する（図６参照）。

請求項４の発明の場合、構成に対応する複数の処理モジュールがあった場合に、最適な処理モジュールを起動することができる。

本発明の請求項５に係るマルチメディア処理システムでは、請求項１のマルチメディア処理システムで、ＬＯＣＫ時のマッチングで、２つ以上の処理モジュールの組み合わせで同じ処理ができるものがあった場合に、複数の処理モジュールの輻輳可能性を調査してそれぞれを起動するシステムを提供する（図７参照）。

請求項５の発明の場合、行いたい処理が２つの処理モジュールの組み合わせで実現できる場合に、それらの処理モジュールを起動して行うことができる。

本発明の請求項６に係るマルチメディア処理システムでは、請求項１のマルチメディア処理システムＬＯＣＫ時のマッチングで、部分的にマッチングする処理モジュールがあった場合に、そのモジュールを起動して、必要な処理のみを行うシステムを提供する（図８参照）。

請求項６の発明の場合、行いたい処理が１つの処理モジュールの１部分の機能で実現できる場合に、その処理モジュールを起動して行うことができる。

発明の請求項７に係るマルチメディア処理システムでは、請求項１のマルチメディア処理システムで、ＬＯＣＫ時のマッチングで、無駄な接続があった場合に、その接続を最適化してから対応する処理モジュールのマッチングを行うシステムを提供する（図９参照）。

請求項７の発明の場合、論理モジュールの無駄な接続があっても最適化することで、対応する処理モジュールを起動することができる。

本発明の請求項８に係るマルチメディア処理システムでは、請求項１のマルチメディア処理システムで、各ストリームを処理するのに必要な論理モジュール構成を表したストリーム対応論理モジュール構成テーブルを持ち、流し込むストリームのコーデック情報のみを与えることで、対応する構成をストリーム対応論理モジュール構成テーブルにより生成し、処理可能な処理モジュールを判定して起動するシステムを提供する（図１０参照）。

請求項８の発明の場合、ストリーム情報のみを与えるだけで、論理モジュール構成を確定し、適切な処理モジュールを起動することができる。

本発明の請求項９に係るマルチメディア処理システムでは、請求項１のマルチメディア処理システムで、実際に書き込まれたストリームを解析するストリーム解析手段を持ち、ストリームを書き込むだけで実際に書き込まれたストリームをストリーム解析手段により解析することで、書き込んだストリームに対応する構成を自動生成して、処理可能な処理モジュールを判定して起動するシステムを提供する（図１１参照）。

請求項９の発明の場合、ストリームを実際に書き込むだけで、論理モジュール構成を確定し、適切な処理モジュールを起動することができる。

本発明の請求項１０に係るマルチメディア処理システムでは、請求項１のマルチメディア処理システムで、ＬＯＣＫ時のマッチングにおいて、対応する処理モジュールがそのシステムに存在しないときに、ダウンロードサーバを調べて、対応する処理モジュールがあった場合はダウンロードして実行するシステムを提供する（図１２参照）。

請求項１０の発明の場合、対応する処理モジュールがマルチメディア処理システムにない場合でも、ダウンロードサーバからダウンロードし実行することができる。

本発明の請求項１１に係るマルチメディア処理システムでは、請求項１のマルチメディア処理システムで、ＬＯＣＫ時のマッチングにおいて、対応する処理モジュールがそのシステムに存在する場合でもダウンロードサーバを調べて、対応する別の処理モジュールがあった場合は、ＣＰＵ使用量、メモリ使用量等を比較して、存在する処理モジュールより好条件の場合は、その処理モジュールをダウンロードして実行するシステムを提供する（図１３参照）。

請求項１１の発明の場合、対応する処理モジュールがマルチメディア処理システムにある場合でも、ダウンロードサーバを調べることで、より最適な処理モジュールを実行することができる。

本発明の請求項１２に係るマルチメディア処理システムでは、請求項８のマルチメディア処理システムで、対応する処理モジュールがない場合に、コーデック情報をダウンロードサーバに送り、ダウンロードサーバ内で対応する構成を調査して、処理モジュールと構成テーブルをダウンロードする、システムを提供する（図１４参照）。

請求項１２の発明の場合、コーデック情報のみを与えることで、対応する処理モジュールがマルチメディア処理システムない場合でも、ダウンロードサーバからダウンロードし実行することができる。

本発明の請求項１３に係るマルチメディア処理システムでは、請求項１のマルチメディア処理システムで、新しい処理モジュールと処理モジュール構成管理テーブルがダウンロードサーバで追加された場合に、処理モジュールと構成情報をダウンロードすることで、新たな処理モジュールを追加することができるシステムを提供する（図１５参照）。

請求項１３の発明の場合、新しい処理モジュールと処理モジュール構成管理テーブルがダウンロードサーバで追加された場合に、自動的にダウンロードすることで、構成確定時にダウンロードするよりも、より早くマルチメディア処理システムで実行することができる。

本発明の請求項１４に係るマルチメディア処理システムでは、請求項１のマルチメディア処理システムで、新しい処理モジュールがダウンロードサーバで追加された場合に、ダウンロードサーバ内で処理モジュールの構成を調査する構成調査部を実行することで、処理モジュール構成管理テーブルを作成して、ダウンロードするシステムを提供する（図１６参照）。

請求項１４の発明の場合、新しい処理モジュールがダウンロードサーバで追加された場合に、処理モジュール構成管理テーブルを登録しなくても、自動的に作成することができる。

本発明の請求項１５に係るマルチメディア処理システムでは、請求項１のマルチメディア処理システムで、対応する処理モジュールを起動した後、各論理モジュールにコマンドが送信されると、どの処理モジュールにコマンドを送信するかを検索して送信する処理モジュール検索手段を含むシステムを提供する（図１７参照）。

請求項１５の発明の場合、対応する処理モジュールを起動した後に、論理モジュールに命令があった場合に、適切な処理モジュールに命令を送ることができる。

本発明の請求項１６に係るマルチメディア処理システムでは、請求項１５のマルチメディア処理システムで、対応する処理モジュールを起動した後、各論理モジュールにコマンドが送信されると、前記対応する処理モジュール検索手段で処理モジュールを検索した後、保持している処理モジュールの情報から、または処理モジュールに問い合わせることにより、送信するのに適したタイミングを判定して送信する送信タイミング判定手段を持つシステムを提供する（図１８参照）。

請求項１６の発明の場合、対応する処理モジュールを起動した後に、論理モジュールに命令があった場合に、適切な処理モジュールに適切なタイミングで命令を送ることができる。

本発明の請求項１７に係るマルチメディア処理システムでは、請求項１のマルチメディア処理システムで、対応する処理モジュールを起動した後、対応する処理モジュールからイベントが上がった場合に、どの論理モジュールへのイベントかを構成情報により判定するイベント振り分け手段を持つシステムを提供する（図１９参照）。

請求項１７の発明の場合、対応する処理モジュールを起動した後に、処理モジュールからイベントが上がった場合に、適切な論理モジュールにイベントを振り分けることができる。

本発明によると、マルチメディア処理を抽象化した論理モジュールと実際に処理を行うマルチメディア処理モジュールが１対１に対応していないシステムにおいても、適切な処理モジュールを起動することができる。

以下に、本発明をその実施の形態を示す添付した図面に基づいて説明する。

（実施の形態１）
図１ないし図３は、本発明の最良の実施の形態に係り、図１は、マルチメディア処理システムの構成を示すブロック図である。図１を参照して、実施の形態１のマルチメディア処理システムを示す。本実施の形態に係るマルチメディア処理システムは、アプリケーション（１−７）と、マルチメディアの処理を抽象化するマルチメディア処理抽象部（１−１）と、実際にマルチメディアの処理を行うマルチメディア処理モジュール（１−６）とから構成されている。

マルチメディア処理抽象部（１−１）は、マルチメディア処理の各機能を抽象化したＤＭＸ，ＶＤＥＣ，ＶＲＥＮ，ＡＤＥＣ，ＡＲＥＮ等の各論理モジュール（１−２）と、各論理モジュール（１−２）間を抽象的に接続するもので各論理モジュール（１−２）間のデータの流れを表すストリームパス（１−４）と、各論理モジュール（１−２）とアプリケーション（１−７）との間でデータを送受信するストリームパイプ（１−３）と、論理モジュール（１−２）とストリームパイプ（１−３）とストリームパス（１−４）との構成情報を持ち、マルチメディア処理抽象部（１−１）とマルチメディア処理モジュール（１−６）との対応付けを行う対応付け管理部（１−５）とから構成されている。

対応付け管理部（１−５）は、各論理モジュール（１−２）の生成、接続の度に対応付け構成情報を更新し、以降、ストリームパイプ（１−３）やストリームパス（１−４）を接続しなくなった時点で、アプリケーション（１−７）から構成の確定という意味のＬＯＣＫ命令を受け付けることで、対応する処理モジュールを１つ確定し、起動させるようになっている。

図２を参照して、本マルチメディア処理システムにおけるアプリケーション（１−７）からの構成確定手順を説明すると、２−１で各論理モジュール（１−２）を生成し、（２−２）で各論理モジュール（１−２）をストリームパス（１−４）で接続する。この生成、接続の度に、対応付け管理部（１−５）は、後述する論理モジュールＩＤ管理テーブル（３−１）で管理されている構成情報を更新する。

２−３でアプリケーション（１−７）から論理モジュール（１−２）に対してストリームを送信するストリームパイプ（１−３）を生成する。

２−４でアプリケーション（１−５）からマルチメディア処理抽象部（１−１）に処理の構成確定という意味の通知であるＬＯＣＫ命令を送信する。マルチメディア処理抽象部（１−１）の対応付け管理部（１−５）は、アプリケーション（１−７）からのＬＯＣＫ命令を受け付けると、対応する処理モジュール（１−６）を１つ確定し、起動する。

なお、論理モジュール（１−２）の作成（２−１）において、Ｃｒｅａｔｅ＿Ｄｅｖ（ＤＭＸ）は、多重分離論理モジュール（ＤＭＸ）の生成であり、Ｃｒｅａｔｅ＿Ｄｅｖ（ＶＤＥＣ）は、ビデオデコード論理モジュール（ＶＤＥＣ）の生成であり、Ｃｒｅａｔｅ＿Ｄｅｖ（ＶＲＥＮ）はビデオレンダー出力論理モジュール（ＶＲＥＮ）の生成であり、Ｃｒｅａｔｅ＿Ｄｅｖ（ＡＤＥＣ）はオーディオデコード論理モジュール（ＡＤＥＣ）の生成であり、Ｃｒｅａｔｅ＿Ｄｅｖ（ＡＲＥＮ）はオーディオレンダー出力論理モジュール（ＡＲＥＮ）の生成である。論理モジュール（１−２）のストリームパス（１−４）の接続（２−２）においては、Ｃｏｎｎｅｃｔ＿Ｄｅｖ（ＤＭＸ，ＶＤＥＣ）は、ＤＭＸ−ＶＤＥＣ間の接続であり、Ｃｏｎｎｅｃｔ＿Ｄｅｖ（ＤＭＸ，ＶＤＥＣ）は、ＤＭＸ−ＡＤＥＣ間の接続であり、Ｃｏｎｎｅｃｔ＿Ｄｅｖ（ＶＤＥＣ，ＶＲＥＮ）はＶＤＥＣ−ＶＲＥＮ間の接続であり、Ｃｏｎｎｅｃｔ＿Ｄｅｖ（ＡＤＥＣ，ＡＲＥＮ）はＡＤＥＣ−ＡＲＥＮ間の接続である。ストリームパイプ（１−３）の生成において、Ｃｒｅａｔ＿Ｐｉｐｅ（ＤＭＸ）は、ＤＭＸにストリームパイプ（１−３）を生成することである。また、Ｆｉｎｉｓｈ＿Ｃｏｎｓｔｒｕｃｔｉｏｎは、構成確定を通知することである。

図３は、図１の対応付け管理部（１−５）の構成を示している。３−１は各論理モジュールのＩＤを管理する論理モジュールＩＤ（識別データ）管理テーブルである。３−２は現在の構成に対応した論理モジュール構成管理テーブルであり、図３では例として現在の論理モジュールの接続構成３−５の内容を表している。３−５は、図１の論理モジュール（１−２）の接続構成に対応している。論理モジュール（１−２）には、それぞれ、論理モジュールＩＤが付けられる。

論理モジュール構成管理テーブル（３−２）の縦軸（３−２−１）は、ストリームパス（１−４）の接続元の論理モジュールＩＤ、論理モジュール構成管理テーブル（３−２）の横軸（３−２−２）は接続先の論理モジュールＩＤを表す。接続元ＩＤ、接続先ＩＤが共にｎのところは、論理モジュール（ＩＤ＝ｎ）の存在を表す。論理モジュール構成管理テーブル（３−２）の作成は、論理モジュールＮ（＝０−９）を生成すると、接続元Ｎ（＝０−９）、接続先Ｎ（＝０−９）のところに１を入れることにより行われる。

図３の場合、論理モジュール構成（３−５）において、現在の構成のＤＭＸ（ＩＤ＝０）の存在に対応して、接続元、接続先をＤＭＸ（ＩＤ＝０）とし、縦軸（３−２−１）の「０」と横軸（３−２−２）の「０」とのクロスポイントである（３−３）に「１」を代入して、ＤＭＸの抽象的存在を示す。接続元をＤＭＸ（ＩＤ＝０）、接続先をＶＤＥＣ（ＩＤ＝１）としこれらを接続するストリームパス（１−４）の抽象的存在として、縦軸（３−２−１）の「０」と横軸（３−２−２）の「１」とのクロスポイント（３−４）に「１」を代入して、ストリームパス（１−４）の抽象的存在を示す。接続元をＶＤＥＣ（ＩＤ＝１）、接続先をＶＤＥＣ（ＩＤ＝１）として縦軸（３−２−１）の「１」と横軸（３−２−２）の「１」とのクロスポイントに「１」を代入して、ＶＤＥＣの抽象的存在を示す。接続元をＶＤＥＣ（ＩＤ＝１）、接続先をＶＲＥＮ（ＩＤ＝２）とし、これらを接続するストリームパス（１−４）の抽象的存在として、縦軸（３−２−１）の「１」と横軸（３−２−２）の「２」とのクロスポイント（３−４）に「１」を代入して、ストリームパス（１−４）の抽象的存在を示す。以降、同様に行うが、これについては説明を省略する。このようにして、対応付け管理部（１−５）において、論理モジュール構成管理テーブル（３−２）を作成する。

そして、対応付け管理部（１−５）は、起動できる処理モジュール１つずつに対応した処理モジュール構成管理テーブル（３−６、３−８）を保持しておき、アプリケーション（１−７）から構成確定という意味のＬＯＣＫ命令が通知されると、上記作成して保持している論理モジュール構成管理テーブル（３−２）と処理モジュール構成管理テーブル（３−６、３−８）とを比較し、一致（３−１０）するものを起動する。この例では、論理モジュール構成管理テーブル（３−２）と処理モジュール構成管理テーブル（３−６）とが一致する。論理モジュール構成管理テーブル（３−２）と処理モジュール構成管理テーブル（３−８）とは一致しない。３−７は、処理モジュール構成管理テーブル（３−６）の処理モジュールの構成、３−９は、処理モジュール構成管理テーブル（３−８）の処理モジュールの構成を示す。

図１ないし図３に示す実施の形態では、マルチメディア処理を抽象化した論理モジュール（１−２）と実際に処理を行うマルチメディア処理モジュール（１−６）とが１対１に対応していないシステムにおいても、適切な処理モジュールを起動することができる。

（実施の形態２）
図４により、実施の形態２のマルチメディア処理システムを示す。実施の形態２においては、マルチメディア処理抽象部（４−１）で、或る論理モジュール（４−２）（この場合、ＤＭＸを例にする）において、ＤＭＸに対してストリームパイプ（４−３）とストリームパス（４−４）それぞれの接続が完了した時点で、論理モジュール（４−２）であるＤＭＸは、アプリケーション（４−７）から構成が確定したという意味のＬＯＣＫ命令を受ける。その時点で、その論理モジュール（４−２）であるＤＭＸからストリームパス（４−４）を通して到達できる全ての論理モジュール（この場合、ＶＤＥＣ、ＡＤＥＣ、ＶＲＥＮ、ＡＲＥＮ）がＬＯＣＫ命令を受け付けていると、対応する処理モジュール（この場合、ＡＶ再生処理モジュール）を確定し、起動する。

すなわち、図１の例と同じＡＶ再生処理モジュールを起動する場合に、或る論理モジュール（４−２）にストリームパイプ（４−３）とストリームパス（４−４）とをつなぎ終え、以降その論理モジュール（４−２）にストリームパイプ（４−３）とストリームパス（４−４）をつなぐことがなくなった時点で、その論理モジュール（４−２）の構成確定という意味の命令を送付する。

図４の場合は、ＤＭＸがストリームパイプ（４−３）とストリームパス（４−４）とをつなぎ終えたため、アプリケーション（４−７）から構成確定をマルチメディア処理抽象部（４−１）の論理モジュール（４−２）であるＤＭＸに対して送付する。その時点で、対応付け管理部（４−５）は、論理モジュール構成管理テーブル（４−２）により、ＤＭＸからストリームパス（４−４）でたどりつける論理モジュール（４−２）であるＶＤＥＣ，ＡＤＥＣ、ＡＲＥＮ，ＶＲＥＮそれぞれに対しても構成確定が通知されているかを調べ、上記ＤＭＸ，ＶＤＥＣ，ＡＤＥＣ、ＡＲＥＮ，ＶＲＥＮ全てに構成確定が通知されている場合、これらＤＭＸ，ＶＤＥＣ，ＡＤＥＣ、ＡＲＥＮ，ＶＲＥＮ
で構成される処理モジュールの構成と、処理モジュール構成管理テーブルで管理している処理モジュールの構成とのマッチングを行い、対応する処理モジュール（４−６）であるＡＶ再生処理モジュールを起動する。このように、各論理モジュールの構成が確定した時点で通知を行うことで、アプリケーション（４−７）が複数のモジュールに分かれて、使用する論理モジュールも異なる場合に、自分の論理モジュールを生成、接続が終わったら、構成確定を通知すればよいため、アプリケーションのモジュール間で、構成確定してよいかを確認する通信がいらないため、効率的にアプリケーションを開発することが可能となる。

（実施の形態３）
図５を参照して、実施の形態３のマルチメディア処理システムを説明する。実施の形態３におけるマルチメディア処理システムでは、アプリケーション（５−１）を構成するＡｕｄｉｏタスク（５−１ａ）やＶｉｄｅｏタスク（５−１ｂ）等の複数のアプリケーションタスク（プロセス）が論理モジュールを生成し、この生成した各論理モジュールを接続することで、実際にマルチメディア処理を行うＡＶ処理モジュール（５−７）を生成する。図５には、アプリケーション（５−１）と、マルチメディア処理抽象部内の対応付け管理部（５−２）と、マルチメディア処理モジュールであるＡＶ処理モジュール（５−７）とを示している。対応付け管理部（５−２）には、論理モジュール構成管理テーブル（５−３）、処理モジュール構成管理テーブル（５−５）に加えて、Ａｕｄｉｏタスク用処理モジュール構成管理テーブル（５−４）、Ｖｉｄｅｏタスク用処理モジュール構成管理テーブル（５−６）が存在する。実施の形態３では、どのタスクから論理モジュールの生成、接続を行うかの情報を、事前に各タスク別の処理モジュール構成管理テーブル（５−４）（５−６）で保持しておき、アプリケーション（５−１）から論理モジュールの生成、接続命令が来ると、論理モジュール構成管理テーブル（５−３）を更新し、あるタスクの処理モジュール構成管理テーブル（５−４ ｏｒ ５−６）の構成が、論理モジュール構成管理テーブル（５−３）に部分的に含まれた場合に、処理モジュール構成管理テーブル（５−５）と比較して、一致する場合は、対応するＡＶ処理モジュール（５−７）を起動し、そうでないならタスクを寝かせて待たせて、その間に他のタスクが論理デバイスの生成、接続を行うことにより、各タスクは他のタスクとの同期を取らずに自分の使用する論理モジュールの処理のみを行えばよいことになる。

（実施の形態４）
図６を参照して、実施の形態４のマルチメディア処理システムを説明する。図６に示すマルチメディア処理システムは、処理モジュールＡ（６−１ａ）、処理モジュールＢ（６−１ｂ）を動作させた場合に消費するＣＰＵ使用量、メモリ使用量等の処理モジュール動作環境情報を保持し、処理モジュールＡ（６−１ａ）、処理モジュールＢ（６−１ｂ）が動作するプロセッサの現在のＣＰＵ使用量、メモリ使用量等のプロセッサ環境情報を取得するプロセッサ環境情報取得手段（６−２）と、プロセッサ環境情報取得手段（６−２）で取得したプロセッサ環境情報と処理モジュール動作環境情報とを比較して最適なマルチメディア処理モジュールを判定して起動する起動処理モジュール判定手段（６−３）とを備えたシステムである。

詳しくは、図６にはそのマルチメディア処理システムの対応付け管理部（１−５）の構成を示しており、６−１ａ，６−１ｂは各マルチメディアの処理モジュールの使用資源を示した処理モジュール動作環境情報であり、例として処理モジュールＡ（６−１ａ）と処理モジュールＢ（６−１ｂ）の使用ＣＰＵ周波数と使用メモリとを記載している。６−２はプロセッサ環境情報取得手段であり、処理モジュールＡ，Ｂ（６−１ａ）（６−１ｂ）を自プロセッサで動作させる場合は、自プロセッサで現在動作しているマルチメディア処理モジュールＡ，Ｂ（６−１ａ）（６−１ｂ）のＣＰＵ使用率等を計算したりするなどして情報を取得する。処理モジュールＡ，Ｂ（６−１ａ）（６−１ｂ）を他プロセッサで動作させる場合は、他プロセッサに問い合わせるか、外部メモリにかかれた情報を直接見るなどして情報を取得する。６−４に取得したプロセッサ環境情報の例を示す。この場合、空きＣＰＵは６０ＭＨｚ、空きＭｅｍｏｒｙが３０Ｍｂｙｔｅである。起動処理モジュール判定手段（６−３）は処理モジュールＡと処理モジュールＢそれぞれの処理モジュール動作環境情報と比較して、処理モジュールＡはＣＰＵを処理モジュールＢよりＣＰＵを多く使用するがメモリは少なく済むので、アプリケーションから省メモリ優先という指示があったり、省メモリ優先と先に決めている場合等には、処理モジュールＡを起動する。なお、６−４は論理モジュールの構成管理テーブル、６−５は処理モジュールＡの構成管理テーブル、６−６は処理モジュールＢの構成管理テーブルを示す。

（実施の形態５）
図７を参照して、実施の形態５のマルチメディア処理システムを説明する。実施の形態５のマルチメディア処理システムは、ＬＯＣＫ時のマッチングで、２つ以上の処理モジュールの組み合わせで同じ処理ができるものがあった場合に、複数の処理モジュールの輻輳可能性を調査してそれぞれを起動するシステムを提供するものである。

すなわち、実施の形態５のマルチメディア処理システムでは、ＡＶ再生をする場合に７−１のように論理モジュールを接続すると、論理モジュール構成管理テーブルは７−２のようになる。ここで、システムにＶｉｄｅｏ再生のみできるＶｉｄｅｏ再生処理モジュール（７−３）と、Ａｕｄｉｏ再生のみできるＡｕｄｉｏ再生処理モジュール（７−５）とがあった場合、それぞれ処理モジュール構成管理テーブルは７−４、７−６のようになる。この場合、論理モジュール構成管理テーブル（７−２）はビデオの処理モジュール構成管理テーブル（７−４）とオーディオの処理モジュール構成管理テーブル（７−６）とを重ね合わせたものである。重ね合わせを７−８、７−９の矢印で示す。そこで、各処理モジュールが同時に実行できるかを示す処理モジュール輻輳管理テーブル（７−７）を見ると、ビデオ処理モジュールＩＤ＝１とオーディオ処理モジュールＩＤ＝２とは輻輳可能なため、同時に起動して処理を行うと判断されるので、ビデオ再生処理モジュール（７−３）とオーディオ再生処理モジュール（７−５）とを起動する。なお、７−１０は、論理モジュール（７−１）のＩＤ管理テーブルを示す。

（実施の形態６）
図８を参照して、実施の形態６のマルチメディア処理システムを説明する。実施の形態６のマルチメディア処理システムは、ＬＯＣＫ時のマッチングで、部分的にマッチングする処理モジュールがあった場合に、そのモジュールを起動して、必要な処理のみを行うシステムを提供するものである。

すなわち、図８に示すマルチメディア処理システムでは、オーディオ再生をする場合に、論理モジュールを８−２のような構成でつなげると、論理モジュール構成管理テーブルは８−１のようになる。ここで、システムに８−３のＡＶ再生処理モジュールと８−５のＡＶ記録処理モジュールとが存在する場合に、８−１の論理モジュール構成管理テーブルで「１」である部分（１を○で囲んで示す部分）が８−３のＡＶ再生処理モジュールの処理モジュール構成管理テーブル８−４で全て「１」（１を○で囲んで示す部分）であるため、部分マッチング（８−７）に相当するので、図８ではＡＶ再生処理モジュール（８−３）を起動して、そのＡＶ再生処理モジュールのオーディオ部分だけを使って再生することができる。なお、８−８は、論理モジュールＩＤ管理テーブルを示す。

（実施の形態７）
図９を参照して、実施の形態７のマルチメディア処理システムを説明する。実施の形態７のマルチメディア処理システムは、ＬＯＣＫ時のマッチングで、無駄な接続があった場合に、その接続を最適化してから対応する処理モジュールのマッチングを行うシステムを提供するものである。

すなわち、図９に示すマルチメディア処理システムでは、論理モジュールが９−１のような構成で接続されていて、論理モジュール構成管理テーブルが９−２のようになっている場合、次のようにして、無駄なストリームパスを見つけて最適化する。９−２の論理モジュール構成管理テーブルの横軸（行）で１つの論理モジュールしかつながっていないものがある場合（図９の例では９−３のＶＥＮＣはＶＤＥＣのみ）、その論理モジュールの縦軸（列）（図９の例では９−４のＶＥＮＣ）で繋がっているのが先ほどの論理モジュール（ＶＤＥＣ）のみの場合は、その論理モジュールは取り除くことができ、行（９−３）、列（９−４）を全て「０」にすることができる。こうして、最適化を行った後、処理モジュール構成管理テーブルと一致（９−５）して、この場合、最適化をすると、ＡＶ再生処理モジュール構成管理テーブル９−７と等しくなるので、ＡＶ再生モジュールを起動する。なお、９−６は「０」になることを示す。９−７はＡＶ再生処理モジュール用テーブル、９−８はＡＶ再生処理モジュール、９−９はＡＶ記録処理モジュール用テーブル、９−１０はＡＶ記録処理モジュール、９−１１は論理モジュールＩＤ管理テーブルを示す。

（実施の形態８）
図１０を参照して、実施の形態８のマルチメディア処理システムを説明する。実施の形態８のマルチメディア処理システムは、各ストリームを処理するのに必要な論理モジュール構成を表したストリーム対応論理モジュール構成テーブルを持ち、流し込むストリームのコーデック情報のみを与えることで、対応する構成をストリーム対応論理モジュール構成テーブルにより生成し、処理可能な処理モジュールを判定して起動するシステムを提供するものである。

すなわち、図１０に示すマルチメディア処理システムは、アプリケーションから処理して欲しいストリームを指定（ｐｔｒ＝ＳＴＲＭ（ＭＰＥＧ２））されると（１０ー１）、ストリームの種類と対応するその論理モジュール構成テーブルを表した、ストリーム対応論理モジュール構成テーブル１０−２により対応する論理モジュール構成を調べ、図１０の場合は、ＭＰＥＧ２ならＩＤ１と分かるため、１０−３のＩＤ１の論理モジュール構成管理テーブルにより、構成が確定する。以降、アプリケーションは必要な論理モジュール等を付け加えた後、構成確定命令を送付し、対応する処理モジュールを確定する。１０−４はＡＶ再生処理モジュール、１０−５は静止画再生処理モジュール、１０−６は論理モジュールＩＤ管理テーブルを示す。

（実施の形態９）
図１１を参照して、実施の形態９のマルチメディア処理システムを説明する。実施の形態９のマルチメディア処理システムは、実際に書き込まれたストリームを解析するストリーム解析手段を持ち、ストリームを書き込むと実際に書き込まれたストリームをストリーム解析手段により解析することで、書き込んだストリームに対応する構成を自動生成して、処理可能な処理モジュールを判定して起動するシステムを提供するものである。図１１はマルチメディア処理システムのストリーム解析手段の動作フローである。まず、１１−１でアプリケーション（１−７）がストリームを書き込み、１１−２で最初は起動させる処理モジュール構成テーブルＩＤを表した変数ｔａｂｌｅ＿ｉｄを１にセットし、１１−３で対応付け管理部は処理モジュール構成テーブルのＩＤがｔａｂｌｅ＿ｉｄである処理モジュールを起動し、１１−４で対応付け管理部は、処理モジュールへストリームを渡して対応しているかを問い合わせる。１１−５で処理モジュールはストリームが処理可能かを判断する。１１−６は１１−５で処理可能であるというＹＥＳの判定のとき、論理モジュールの構成をアプリケーションに提示する、１１−５で対応していないＮＯの判定のときは、１１−７で処理モジュールを終了させ、１１−８で、ｔａｂｌｅ＿ｉｄを＋１して再度繰り返す。

（実施の形態１０）
図１２を参照して、実施の形態１０のマルチメディア処理システムを説明する。実施の形態１０のマルチメディア処理システムは、ＬＯＣＫ時のマッチングにおいて、対応する処理モジュールがそのシステムに存在しないときに、ダウンロードサーバ（１２−５）を調べて、対応する処理モジュールがあった場合はダウンロードして実行するシステムを提供するものである。図１２で、１２−１はアプリケーション、１２−２はマルチメディア処理抽象部、１２−３はマルチメディア処理モジュールを示す。マルチメディア処理抽象部（１２−２）は、対応付け管理部（１２−２ａ）、ダウンロード処理部（１２−２ｂ）、処理モジュール構成管理テーブル（１２−２ｃ）を備える。

一方、ダウンロードサーバ（１２−５）は、マルチメディア処理抽象部（１２−２）に対して、ＬＡＮ（有線、無線を含む）や電話回線等の通信回線（１２−４）で接続されている。ダウンロードサーバ（１２−５）は、対応付け管理部（１２−５ａ）、ダウンロード処理部（１２−５ｂ）、処理モジュール構成管理テーブル（１２−５ｃ）、処理モジュール（１２−５ｄ）を備える。

以上の構成を備えた図１２に示すマルチメディア処理システムでは、対応付け管理部（１２−２ａ）は、対応する処理モジュール（１２−３）が存在しない場合に、通信回線（１２−４）を通して、ダウンロードサーバ（１２−５）に問い合わせ、対応するモジュールが存在するかを調べる。存在する場合は、ダウンロード処理部（１２−５ｂ）により、対応する処理モジュール（１２−５ｄ）及び、処理モジュール構成管理テーブル（１２−５ｃ）をダウンロードして、起動する。

（実施の形態１１）
図１３を参照して、実施の形態１１のマルチメディア処理システムを説明する。実施の形態１１のマルチメディア処理システムは、ＬＯＣＫ時のマッチングにおいて、対応する処理モジュールがそのシステムに存在する場合でもダウンロードサーバを調べて、対応する別の処理モジュールがあった場合は、ＣＰＵ使用量、メモリ使用量等を比較して、存在する処理モジュールより好条件の場合は、その処理モジュールをダウンロードして実行するシステムを提供するものである。

図１３で、１３−１はアプリケーション、１３−２はマルチメディア処理抽象部、１３−３は処理モジュール、１３−４は通信回線、１３−５はダウンロードサーバを示す。マルチメディア処理抽象部（１３−２）は、対応付け管理部（１３−２ａ）、ダウンロード処理部（１３−２ｂ）、処理モジュール構成管理テーブル（１３−２ｃ）、処理モジュール動作環境情報（１３−２ｄ）を備える。一方、ダウンロードサーバ（１３−５）は、マルチメディア処理抽象部（１３−２）に対して通信回線（１３−４）で接続されている。

ダウンロードサーバ（１３−５）は、対応付け管理部（１３−５ａ）、ダウンロード処理部（１３−５ｂ）、処理モジュール構成管理テーブル（１３−５ｃ）、処理モジュール（１３−５ｄ）、処理モジュール動作環境情報（１３−５ｅ）を備える。

すなわち、図１３に示すマルチメディア処理システムは、ダウンロードサーバにも、図６の６−１ａ，６−１ｂの処理モジュール動作環境情報（１３−５ｅ）を持つ。構成のマッチングでマルチメディア処理システムに対応する処理モジュールがあった場合でも、ダウンロードサーバに問い合わせ、対応する処理モジュールの動作環境情報（１３−５ｅ）と比較して、ダウンロードサーバの処理モジュールの方が、より使用資源の少ない等、好条件の場合には、ダウンロードして処理モジュールを実行する。

（実施の形態１２）
図１４を参照して、実施の形態１２のマルチメディア処理システムを説明する。実施の形態１２のマルチメディア処理システムは、ダウンロードサーバ（１４−５）もストリーム対応論理モジュール構成テーブル（１４−５ｅ）を持ち、マルチメディア処理システムで対応するストリーム対応論理モジュール構成テーブル（１４−２ｃ）がない場合は、ストリーム情報をダウンロードサーバ（１４−５）に送り、ダウンロードサーバ内で、ストリーム対応論理モジュール構成テーブル（１４−５ｅ）を探し、マッチングすればダウンロードを行う。なお、１４−１はアプリケーション、１４−２はマルチメディア処理抽象部、１４−３は処理モジュール、１４−４は通信回線、１４−５はダウンロードサーバを示す。マルチメディア処理抽象部（１４−２）は、対応付け管理部（１４−２ａ）、ダウンロード処理部（１４−２ｂ）、ストリーム対応論理モジュール構成テーブル（１４−２ｃ）、処理モジュール構成管理テーブル（１４−２ｄ）を備える。

一方、ダウンロードサーバ（１４−５）は、マルチメディア処理抽象部（１４−２）に対して通信回線（１４−４）で接続されている。ダウンロードサーバ（１４−５）は、対応付け管理部（１４−５ａ）、ダウンロード処理部（１４−５ｂ）、ストリーム対応論理モジュール構成テーブル（１４−５ｃ）、処理モジュール構成管理テーブル（１４−５ｄ）、処理モジュール（１４−５ｅ）、を備える。図１４においても、対応付け管理部（１４−２ａ）は、マルチメディア処理抽象部（１４−２）内に対応するストリーム対応論理モジュール構成管理テーブル（１４−２ｃ）が存在しない場合に、通信回線（１４−４）を通して、ダウンロードサーバ（１４−５）の対応付け管理部（１４−５ａ）に問い合わせ、対応するストリーム対応構成管理テーブル（１４−５ｃ）が存在するかを調べる。存在する場合は、ダウンロード処理部（１４−５ｂ）により、対応するストリーム対応論理モジュール構成テーブル（１４−５ｃ）をダウンロードして、起動する。

（実施の形態１３）
図１５を参照して、実施の形態１３のマルチメディア処理システムを説明する。実施の形態１３のマルチメディア処理システムは、ダウンロードサーバ（１５−５）に処理モジュール（１５−４ｄ）と処理モジュール構成管理テーブル（１５−３ｃ）とが追加された時点で、マルチメディア処理システムに処理モジュール（１５−４ｄ）と処理モジュール構成管理テーブル（１５−３ｃ）とをダウンロードする。このようにすることで、常に新しい処理モジュール（１５−３）を保持することができ、マルチメディア処理システムの端末にない場合に取得するよりもオーバーヘッドを少なくすることができる。図１５において、１５−１はアプリケーション、１５−２はマルチメディア処理抽象部、１５−３は処理モジュール、１５−４は通信回線を示す。マルチメディア処理抽象部（１５−２）は、対応付け管理部（１５−２ａ）、ダウンロード処理部（１５−２ｂ）、処理モジュール構成管理テーブル（１５−２ｃ）、処理モジュール（１５−３）を備える。一方、ダウンロードサーバ（１５−５）は、マルチメディア処理抽象部（１５−２）に対して通信回線（１５−４）で接続されている。ダウンロードサーバ（１５−５）は、対応付け管理部（１５−５ａ）、ダウンロード処理部（１５−５ｂ）、処理モジュール構成管理テーブル（１５−５ｃ）、処理モジュール（１５−５ｄ）を備える。

（実施の形態１４）
図１６を参照して、実施の形態１４のマルチメディア処理システムを説明する。実施の形態１４のマルチメディア処理システムは、新しい処理モジュール（１６−５ｄ）がダウンロードサーバ（１６−５）で追加された場合に、ダウンロードサーバ内で処理モジュール（１６−５ｄ）の構成を調査する処理モジュール構成管理テーブル作成部（１６−５ｅ）を実行することで、処理モジュール構成管理テーブル（１６−５ｃ）を作成して、ダウンロードするシステムを提供するものである。図１６において、１６−１はアプリケーション、１６−２マルチメディア処理抽象部、１６−３は処理モジュール、１６−４は通信回線、１６−５はダウンロードサーバを示す。マルチメディア処理抽象部（１６−２）は、対応付け管理部（１６−２ａ）、ダウンロード処理部（１６−２ｂ）、処理モジュール構成管理テーブル（１６−２ｃ）を備える。一方、ダウンロードサーバ（１６−５）は、マルチメディア処理抽象部（１６−２）に対して通信回線（１６−４）で接続されている。ダウンロードサーバ（１６−５）は、対応付け管理部（１６−５ａ）、ダウンロード処理部（１６−５ｂ）、処理モジュール構成管理テーブル（１６−５ｃ）、処理モジュール（１６−５ｄ）、処理モジュール構成管理テーブル作成部（１６−５ｅ）を備える。

すなわち、図１６に示すマルチメディア処理システムでは、ダウンロードサーバに処理モジュールが追加された時点で、処理モジュールを実行させ、ダウンロードサーバ内の処理モジュール構成管理テーブル作成部（１６−５ｅ）が、処理モジュール（１６−５ｄ）に対して、各機能毎の実装を問い合わせて調査して、処理モジュール構成管理テーブル（１６−５ｃ）を作成するものである。

（実施の形態１５）
図１７を参照して、実施の形態１５のマルチメディア処理システムを説明する。実施の形態１５のマルチメディア処理システムは、処理モジュールが生成された後、アプリケーションが各論理モジュールに制御コマンドを送信した場合に、対応する処理モジュールを検索してその処理モジュールに制御コマンドを送信する手段を提供する。

図１７の１７−１はアプリケーション、１７−２はマルチメディア処理抽象部、マルチメディア処理モジュール（１７−３）である。マルチメディア処理モジュール（１７−３）はＡＶ再生処理モジュール（１７−３ａ）、静止画再生処理モジュール（１７−３ｂ）の２つ存在する。マルチメディア処理抽象部１７−２において、１７−２ａ、１７−２ｂはアプリケーション（１７−１）からのコマンド送信、１７−２ｃは処理モジュール検索手段、１７−２ｄは論理モジュールと対応する処理モジュールのＩＤの関係を保持する論理モジュール対応処理モジュールテーブル、１７−２ｅは対応付け管理部、１７−２ｆはストリームパイプ、１７−２ｇはＡＶ再生用論理モジュール、１７−ｈは静止画再生用論理モジュールを示す。

実施の形態１５のマルチメディア処理システムでは、対応する処理モジュールを起動した後、各論理モジュール（１７−２ｇ）（１７−２ｈ）にコマンド（１７−２ａ）（１７−２ｂ）が送信されると、どの処理モジュール（１７−３ａ）（１７−３ｂ）にコマンド（１７−２ａ）（１７−２ｂ）を送信するかを検索して送信する処理モジュール検索手段（１７−２ｃ）を含むシステムを提供するものである。

すなわち、実施の形態１５のマルチメディア処理システムでは、アプリケーション（１７−１）から論理モジュール（１７−２ｇ）（１７−２ｈ）にコマンド（１７−２ａ）（１７−２ｂ）が発行されると、処理モジュール検索手段（１７−２ｅ）に問い合わせる。処理モジュール検索手段（１７−２ｅ）は、論理モジュール（１７−２ｇ）（１７−２ｈ）と処理モジュール（１７−３ａ）（１７−３ｂ）との対応関係を表した、論理モジュール対応処理モジュールテーブル（１７−２ｄ）を検索して、対応する処理モジュール（１７−３ａ）（１７−３ｂ）を見つけ、論理モジュールに教える。論理モジュール（１７−２ｇ）（１７−２ｈ）は対応する処理モジュール（１７−３ａ）（１７−３ｂ）に対して制御を行う。

（実施の形態１６）
図１８を参照して、実施の形態１６のマルチメディア処理システムを説明する。実施の形態１６のマルチメディア処理システムは、処理モジュールが生成された後、アプリケーションが各論理モジュールに制御コマンドを送信した場合に、対応する処理モジュールを検索してその処理モジュールに制御コマンドを送信する場合、適切なタイミングを計って制御コマンドを送信する手段を提供する。

図１８の１８−１はアプリケーション、１８−２はマルチメディア処理抽象部、１８−３はマルチメディア処理モジュールである。マルチメディア処理モジュール（１８−３）はＡＶ再生処理モジュール（１８−３ａ）、静止画再生処理モジュール（１８−３ｂ）から成り立つ。マルチメディア処理抽象部１８−２において、１８−２ａ、１８−２ｂはアプリケーション（１８−１）からのコマンド送信、１８−２ｃは処理モジュール検索手段、１８−２ｄは論理モジュールと対応する処理モジュールをＩＤの関係を保持する論理モジュール対応処理モジュールテーブル、１８−２ｅは対応付け管理部、１８−２ｆはストリームパイプ、１８−２ｇはＡＶ再生用論理モジュール、１８−ｈは静止画再生用論理モジュールを示す。１８−ｉは送信タイミング判定手段、１８−ｊは処理モジュール状態保持手段である。

実施の形態１６のマルチメディア処理システムは、対応する処理モジュール（１８−３ａ）（１８−３ｂ）を起動した後、各論理モジュール（１８−２ｇ）（１８−２ｈ）にコマンド（１８−２ａ）（１８−２ｂ）が送信されると、処理モジュール検索手段（１８−２ｃ）で処理モジュール（１８−３ａ）（１８−３ｂ）を検索した後、保持している処理モジュールの情報（１８−２ｊ）から、もしくは処理モジュールに問い合わせることにより、送信するのにふさわしいタイミングを送信タイミング判定手段（１８−２ｉ）により判定して送信するシステムを提供するものである。

すなわち、図１８に示すマルチメディア処理システムでは、処理モジュール検索手段（１８−２ｃ）により、対応する処理モジュールを確定した後、送信タイミング判定手段（１８−２ｉ）は、処理モジュール状態管理テーブル（１８−２ｊ）や、処理モジュールに問い合わせて、処理量が少ないとき等、適切なタイミングをみて、コマンドを発行する。

（実施の形態１７）
図１９を参照して、実施の形態１７のマルチメディア処理システムを説明する。実施の形態１７のマルチメディア処理システムは、対応する処理モジュールを起動した後、処理モジュールからイベントが上がってきた場合に、適切な論理モジュールにそのイベントを振り分ける手段をもつマルチメディア処理システムである。

実施の形態１７のマルチメディア処理システムは、対応する処理モジュール（１９−３ａ）（１９−３ｂ）を起動した後、対応する処理モジュールからイベント（１９−３ｃ）が上がった場合に、どの論理モジュールへのイベントかを構成情報により判定するイベント振り分け手段（１９−２ｉ）を持つシステムを提供するものである。

すなわち、図１９に示すマルチメディア処理システムでは、ＡＶ再生処理モジュールや静止画再生処理モジュールからイベント（１９−３ｃ）が上がると、イベント振り分け手段（１９−２ｉ）がイベントを受ける。イベント振り分け手段（１９−２ｉ）は、論理モジュール対応処理モジュールテーブル（１９−２ｄ）とイベント（１９−３ｃ）の内容により、どの論理モジュール（１９−２ｇ）（１９−２ｈ）に振り分けるかを判定して、その論理モジュール（１９−２ｇ）（１９−２ｈ）にイベント（１９−２ｊ）を伝える。

（適用機器の例）
図２０および図２１を参照して、本発明を適用した機器の例を説明する。図２０は本発明を適用する機器の構成である。Ａ−１は、機器本体部、Ａ−２はカメラ部、Ａ−３は音楽、動画等のデータが記録されているメモリカード、Ａ−４は、メモリカードＡ−３を差し込むスロット、Ａ−５は、画像、動画データを見るための液晶表示部、Ａ−６は、ヘッドホン、Ａ−７は再生等の指示を出すリモコンを示す。

図２１に示すように、図２０の機器のアプリケーション（１−７）は、ユーザインタフェースタスクＢ−１、ビデオ録再タスクＢ−２、オーディオ録再タスクＢ−３、静止画録再タスクＢ−４のような構成で成り立つ。リモコンＡ−７等により、ユーザが行いたいモードへの変更の指示を受けて、ユーザインタフェースタスクＢ−１は、オーディオを聞くモードに切り替える場合はオーディオ録再タスクＢ−２へ、また、ビデオを撮るモードへ切り替える場合はビデオ録再タスクＢ−３へ、静止画を撮るモードへ切り替える場合は静止画録再タスクＢ−４へ指示を送る。それぞれのタスクは、マルチメディア処理抽象部（１−１）へ必要な論理モジュール（１−２）の生成や接続を指示して、ＬＯＣＫ命令を発行することにより実際のマルチメディア処理モジュール（１−６）が生成される。その後、リモコンＡ−７で再生ボタンが押されると、ユーザインタフェースタスクＢ−１は、現在のモードに対するタスクＢ−２，Ｂ−３，Ｂ−４に対してその指示を伝え、各タスクは、マルチメディア処理抽象部（１−１）に対して、指示を行う。

本発明のマルチメディア処理システムは、抽象化デバイスと実際の処理モジュールが１対１に対応していないシステムにおいても、処理モジュールを抽象化して利用できるので、例えば、テレビ、ビデオ、ＤＶＤ、携帯などのソフトウェアを処理モジュールに抽象化して流用する場合等に利用することができる。

本発明の実施の形態に係るマルチメディア処理システムの構成図 図１の実施の形態のシステムにおけるアプリケーションからの構成確定手順を表した図 図１の実施形態のシステムにおける対応付け管理部の構成を示した図 他の実施形態に係るマルチメディア処理システムの構成図 さらに他の実施形態に係るマルチメディア処理システムの構成図 さらに他の実施形態に係るマルチメディア処理システムの対応付け管理部である。 さらに他の実施形態に係るマルチメディア処理システムの構成図 さらに他の実施形態に係るマルチメディア処理システムの構成図 さらに他の実施形態に係るマルチメディア処理システムの構成図 さらに他の実施形態に係るマルチメディア処理システムの構成図 さらに他の実施形態に係るマルチメディア処理システムのストリーム解析手段の動作フロー図 さらに他の実施形態に係るマルチメディア処理システムの構成図 さらに他の実施形態に係るマルチメディア処理システムの構成図 さらに他の実施形態に係るマルチメディア処理システムの構成図 さらに他の実施形態に係るマルチメディア処理システムの構成図 さらに他の実施形態に係るマルチメディア処理システムの構成図 さらに他の実施形態に係るマルチメディア処理システムの構成図 さらに他の実施形態に係るマルチメディア処理システムの構成図 さらに他の実施形態に係るマルチメディア処理システムの構成図 本発明のマルチメディア処理システムを適用した機器の外観図 図２０の機器の内部構成図

符号の説明

１−１ マルチメディア処理抽象部
１−２ 論理モジュール
１−３ ストリームパイプ
１−４ ストリームパス
１−５ 対応付け管理部
１−６ 処理モジュール
１−７ アプリケーション

Claims (17)

1. 論理モジュールの生成、接続の指示、その構成の確定の通知を行うアプリケーションと、
   アプリケーションからの指示に従うマルチメディア処理抽象部と、
   実際のマルチメディア処理を行う処理モジュールとからなり、
   マルチメディア処理抽象部は、
   マルチメディア処理の各機能を抽象化する論理モジュールと、
   各論理モジュール間を接続するストリームパスと、
   各論理モジュールとアプリケーションの間でデータを送受信するストリームパイプと、
   論理モジュールとストリームパイプとストリームパスの構成情報を持ち処理モジュールとの対応付けを行う対応付け管理部と、
   から構成されており、
   対応付け管理部は、アプリケーションからの指示に従い、各論理モジュールの生成、接続を行う度に構成情報を更新し、以降、ストリームパイプ、ストリームパスを接続しなくなった時点で、アプリケーションから構成の確定というＬＯＣＫ命令を受け付けることで、対応する処理モジュールを１つ確定し、起動させるマルチメディア処理システム。
2. 請求項１記載のマルチメディア処理システムにおいて、
   マルチメディア処理抽象部は、或る論理モジュールにおいて、ストリームパイプ、ストリームパスの接続が完了した時点で、アプリケーションから前記論理モジュールの構成が確定したという意味のＬＯＣＫ命令を受け、前記論理モジュールからストリームパスで到達できる全ての論理モジュールがＬＯＣＫ命令を受け付けた時点で、対応する処理モジュールを確定し、起動するマルチメディア処理システム。
3. 請求項１記載のマルチメディア処理システムにおいて、
   複数のアプリケーションタスクから論理モジュールを生成、接続して処理モジュールを作成する場合に、どのアプリケーションタスクからロック命令が論理モジュールに来るかの情報を事前にテーブルで保持しておき、アプリケーションからＬＯＣＫ命令が呼ばれると、どのアプリケーションタスクからＬＯＣＫ命令が呼ばれたかを調べ、１つのアプリケーションタスクからの全てのＬＯＣＫが終了した時点で対応する処理モジュールがない場合は、アプリケーションタスクをスイッチさせることで、対応する処理モジュールが起動するまでは後続の処理を行わないようにするマルチメディア処理システム。
4. 請求項１記載のマルチメディア処理システムにおいて、
   各処理モジュールを動作させた場合に消費するＣＰＵ使用量、メモリ使用量等の処理モジュール動作環境情報を保持し、処理モジュールが動作するプロセッサの現在のＣＰＵ使用量、メモリ使用量等のプロセッサ環境情報を取得するプロセッサ環境情報取得手段、及び前記プロセッサ環境情報取得手段で取得したプロセッサ環境情報と処理モジュール動作環境情報とを比較して最適なマルチメディア処理モジュールを判定して起動する処理モジュール判定手段を持つマルチメディア処理システム。
5. 請求項１記載のマルチメディア処理システムにおいて、
   ＬＯＣＫ時のマッチングで、２つ以上の処理モジュールの組み合わせで同じ処理ができるものがあった場合に、複数の処理モジュールの輻輳可能性を調査してそれぞれを起動するマルチメディア処理システム。
6. 請求項１記載のマルチメディア処理システムにおいて、
   ＬＯＣＫ時のマッチングで、部分的にマッチングする処理モジュールがあった場合に、そのモジュールを起動して、必要な処理のみを行うマルチメディア処理システム。
7. 請求項１記載のマルチメディア処理システムにおいて、
   ＬＯＣＫ時のマッチングで、無駄な接続があった場合に、その接続を最適化してから対応する処理モジュールのマッチングを行うマルチメディア処理システム。
8. 請求項１記載のマルチメディア処理システムにおいて、
   各ストリームを処理するのに必要な論理モジュール構成を表したストリーム対応論理モジュール構成テーブルを持ち、流し込むストリームのコーデック情報のみを与えることで、対応する構成をストリーム対応論理モジュール構成テーブルにより生成し、処理可能な処理モジュールを判定して起動するマルチメディア処理システム。
9. 請求項１記載のマルチメディア処理システムにおいて、
   実際に書き込まれたストリームを解析するストリーム解析手段を持ち、ストリームを書き込むだけで実際に書き込まれたストリームをストリーム解析手段により解析することで、書き込んだストリームに対応する構成を自動生成して、処理可能な処理モジュールを判定して起動するマルチメディア処理システム。
10. 請求項１記載のマルチメディア処理システムにおいて、
    ＬＯＣＫ時のマッチングにおいて、対応する処理モジュールがそのシステムに存在しないときに、ダウンロードサーバを調べて、対応する処理モジュールがあった場合はダウンロードして実行するマルチメディア処理システム。
11. 請求項１記載のマルチメディア処理システムにおいて、
    ＬＯＣＫ時のマッチングにおいて、対応する処理モジュールがそのシステムに存在する場合でもダウンロードサーバを調べて、対応する別の処理モジュールがあった場合は、ＣＰＵ使用量、メモリ使用量等を比較して、存在する処理モジュールより好条件の場合は、その処理モジュールをダウンロードして実行するマルチメディア処理システム。
12. 請求項８記載のマルチメディア処理システムにおいて、
    対応する処理モジュールがない場合に、コーデック情報をダウンロードサーバに送り、ダウンロードサーバ内で対応する構成を調査して、処理モジュールと構成テーブルをダウンロードする、マルチメディア処理システム。
13. 請求項１記載のマルチメディア処理システムにおいて、
    新しい処理モジュールと処理モジュール構成管理テーブルがダウンロードサーバで追加された場合に、処理モジュールと構成情報をダウンロードすることで、新たな処理モジュールを追加することができるマルチメディア処理システム。
14. 請求項１記載のマルチメディア処理システムにおいて、
    新しい処理モジュールがダウンロードサーバで追加された場合に、処理モジュールの構成を調査するダウンロードサーバ内の構成調査部を実行することで、処理モジュール構成管理テーブルを作成して、ダウンロードするマルチメディア処理システム。
15. 請求項１記載のマルチメディア処理システムにおいて、
    対応する処理モジュールを起動した後、各論理モジュールにコマンドが送信されると、どの処理モジュールにコマンドを送信するかを検索して送信する処理モジュール検索手段を含むマルチメディア処理システム。
16. 請求項１５記載のマルチメディア処理システムにおいて、
    対応する処理モジュールを起動した後、各論理モジュールにコマンドが送信されると、前記対応する処理モジュール検索手段で処理モジュールを検索した後、保持している処理モジュールの情報から、または処理モジュールに問い合わせることにより、送信するのに適したタイミングを判定して送信する送信タイミング判定手段を持つマルチメディア処理システム。
17. 請求項１記載のマルチメディア処理システムにおいて、
    対応する処理モジュールを起動した後、対応する処理モジュールからイベントが上がった場合に、どの論理モジュールへのイベントかを構成情報により判定するイベント振り分け手段を持つマルチメディア処理システム。
    
    

Images