JP2005293381A - データ処理装置およびその方法 - Google Patents

Abstract

【課題】
移植性が高いように一連の処理ポイントへのストリームデータ処理を構成し実行する方法を提供する。
【解決手段】
本方法は、データ処理においてピアモジュールと呼ぶ処理ポイントをリンクモジュールで接続してストリームデータパスを設定し、単一の実行コンテキストでスケジューリングを行うことで、高性能な処理を可能とし、これらをレイヤ構成で実現することで高い移植性、および開発容易性を実現した。
【選択図】 図１

Description

本発明は、特定のオペレーティングシステム（ＯＳ）に依存せず、データを処理する方法に関する。

近年、コンピュータで取り扱われるマルチメディアデータとして、動画、及び音声等が様々な用途で利用されている。例えば、テレビ放送等の動画をリアルタイムに動画コーデックで変換してハードディスクに録画するハードディスクレコーダと呼ばれる機器や、ＤＶＤ等の光ディスクにデジタルデータとして記録されている動画コンテンツデータをビデオディスプレイ装置に表示するプレイヤーなどが広く普及している。一般にこれらのコンテンツ処理では、コンテンツデータを指定されたビットレートで、一定時間内に処理を行わなければならない。また、様々な装置でこれらのマルチメディアコンテンツを利用できるようにするためには、これらの複雑なストリーム処理を実行するプログラムモジュールを容易に開発できることが重要となる。このため、高性能を実現しやすいＯＳのカーネルの中でコンテンツ処理を行うプログラムを実行する方式が存在する。ストリームとは、予め定められた順序で一方向に処理されることが必要なデータ列である。例えば、音声データのデータ列や動画データのデータ列などがある。ストリーム処理はこれらのストリームに含まれるデータを処理することを指す。

一般的なＯＳには、アプリケーションを実行するための空間であるユーザ空間と、ＯＳの機能を実行するための空間であるカーネル空間の２つが存在する。カーネル空間で処理を行う場合は、高速な実行が可能となるが、カーネル空間で実行されるプログラムは、基本的にそのカーネルが実装されているＯＳの仕様に大きく依存する。これは例えば、機能を利用する際に利用するインタフェースがＯＳ毎に異なることや、ＯＳによって機能の利用手順が異なることによる。これはデバイスを利用するためのデバイスドライバがプラットホームに特有となり、流用できないということでも知られている。また、カーネル空間での処理を実行する方法として、フィルタと呼ばれるデータを処理するデバイスドライバを複数連結することでコンテンツ処理を行う方法がある（例えば、特許文献１）。

これは、ユーザ空間で実行されるアプリケーションプログラムからカーネル空間内にフィルタと呼ばれるソフトウェアモジュールを生成し、複数のフィルタの入出力を接続してコンテンツデータの流路を構築した後、アプリケーションプログラムから処理開始、停止などを要求することで、コンテンツの処理を実行する方法である。ここで、フィルタやデバイスドライバはデバイスやデータ形式に特化されたモジュールで、それぞれが入出力や制御のためのインタフェースを持っており、それぞれのフィルタが処理したデータを他のフィルタに渡すことでデータを処理するものである。この方式は、全てのフィルタがＯＳのカーネル部で動作するため高性能を実現できる。しかしながら、該方式では、複数のコンテンツ処理を行った場合の優先処理が考慮されていない。例えば、複数のコンテンツを処理において、録画と再生を同時に行う場合に、録画の優先度を高くしたいという要求が発生することが考えられるが、これに対応することは困難である。

特開平１０−２８３１９５号公報

先に述べたように、従来の方法ではストリームを取り扱うための実装を、性能を保証しやすいドライバとしてＯＳのカーネル空間で実装するものがあった。これはＯＳやハードウェア構成（以下、本組み合わせをプラットホームと呼ぶ）への依存性が高く、プログラムは異なったプラットホームに対応することができず、各プラットホームは、それぞれ固有のコンテンツデータ処理方法を有することとなるため、コンテンツ処理をするプログラムの開発はプラットホーム毎に行う必要が生じ、開発工程の増大を招くという第１の問題があった。

また特許文献１では、コンテンツ処理において管理機能が存在しないので、例えば複数のコンテンツを同時に処理する場合、それぞれの処理の優先度を指定することが不可能であった。例えば、あるデバイスからデータを取得してストレージに記録する処理と、あるデバイスからデータを取得してディスプレイに表示する処理の２つの処理を同時に行う場合、例えば前者の処理を優先的に行いたい場合でも、これらの処理を統括して管理する機能が存在しないので、双方の処理の優先順位を適切に変更することが困難という第２の問題があった。

さらに、上記の場合、複数のコンテンツ処理が独自の実装に基づいて処理を進めた場合に、ハードウェア資源の適切な管理や割り振りがなされていないため、処理に必要なＣＰＵリソースの不足が発生するという第３の問題点もあった。

本発明は、上記課題のうち少なくともひとつの課題を解決するものである。

上記第１の課題を解決すべく、本発明では、様々なプラットホームに対応可能なマルチメディアコンテンツ処理手段を提供する。

本発明ではマルチメディアコンテンツの処理を、プラットホーム毎の差異を吸収して汎用化したインタフェースを上位に提供するレイヤを備えることで、上位のソフトウェアモジュールをプラットホームに依存しない構成を実現する。

上記第２乃至第３の課題を解決すべく、本発明では、複数のストリーム処理を１つの実行コンテキスト、例えば、プロセスやスレッドを用いて実行し、コンテンツ処理それぞれの処理に対してどれだけのリソースを割り当てるかを一元的に管理することで、処理の優先処理やリソースの管理を実現する。

本発明によれば、コンテンツデータを利用するプログラムを、異なったプラットホームで利用することが可能となる。また、複数のコンテンツ処理の実行を管理することが可能となり、使用リソース量の低減を可能とする。

以下に本発明の実施の形態について説明する。

図１を用いて、本発明における処理フローの概要を説明する。これは、動画コンテンツとして、ディスク（１０１）から動画データを取得して、これをディスプレイ（１７１）及びスピーカ（１８１）で再生する処理を示したものである。これらの処理はデバイス（１０１）からデータを取得する処理ポイント（１００）、音声データと映像データを分離する処理ポイント（１２０）、映像を映像デコーダ（１７０）に出力する処理ポイント（１５０）、及び音声を音声デコーダ（１８０）出力する処理ポイント（１６０）からなる。処理ポイントとは、処理フローを実現するプログラム中において所定の処理を実行するために必要な部分である。この処理ポイントにおいて処理を実行するソフトウェアモジュールを、ピアモジュールと呼ぶ。ピアモジュールの詳細な構成については図１６を用いて後述する。さらに、リンクモジュールは、これらピアモジュールを相互に接続し、例えば、リンクモジュール（１１０）はピアモジュール（１００）とピアモジュール（１２０）を接続する。リンクモジュールは接続されたピアモジュールの一方から、もう一方へデータを送出する機能を持つ。これにより、ピアモジュール（１００）が取得したデータがリンクモジュール、や他のピアモジュールを通じて、映像デコーダ（１７０）と、音声デコーダ（１８０）に送られることで、映像がディスプレイ（１７１）に表示され、音声がスピーカ（１８０）から再生される。

図２は、本実施例におけるソフトウェア構成を示した図である。本構成（２１０）では、ピアモジュールを相互に連結させたストリーム処理の制御をするストリームマネジャ（２３０）、データの変換等を行うデータ処理モジュール（２４１）を管理するデータ処理モジュールマネジャ（２３０）を備える。ストリームマネジャは、ピアモジュールを管理、操作するピアモジュールマネジャ（２３１）と、実行スケジュールに従ってピアモジュールの処理を実行するために用いるピアモジュールスケジューラ（２３３）、および、ピアモジュールを相互に接続するためのリンクモジュールを記録管理するリンクモジュールマネージャ（２３２）から構成される。

さらに、ＯＳが持つ機能を利用するためにＯＳが提供するシステムインタフェース（２８０）を介してメモリ管理、スレッド管理、及び時間操作などのリソース管理機能を利用するための汎用システムインタフェース（２６０）、デバイスへのアクセスを行いデータの取得やデバイスの制御を行うデータアクセスモジュール（２７１）を管理するデータアクセスモジュールマネジャ（２７０）を備えている。

アプリケーション（２００）は、制御インタフェース（２４０）を用いてストリームマネジャおよびデータ処理モジュールマネジャを制御し、所望のストリーム処理を指示可能である。指示可能な制御については図５を用いて後述する。

上記汎用システムインタフェース（２６０）およびデータアクセスモジュールマネジャ（２７０）を含むレイヤによってインタフェースレイヤ（２５０）が形成される。このインタフェースレイヤはＯＳが提供するシステムインタフェース（２８０）で提供される機能を、汎用化されたインタフェースで上位のレイヤに提供する。この汎用化されたインタフェースは、プラットフォームの差異から生じるプロトコルや命令方式の差異を共通化して上位レイヤに提供するものであり、例えば、ネットワーク通信を行う際に利用するソケットインターフェイスが存在する。このインタフェースによって実行される機能はプラットフォームが異なっても同じであるが、これを利用するための手順がプラットホーム毎に異なる。例えば、Linuxを含む一般的なUnix（登録商標）ではTCPで通信するソケットを作成する際には、socket関数、bind関数、listen関数、そしてaccept関数を順番に実行すればよい。一方Windows（登録商標）では、別の仕様に準じた、Linuxとは違った手順が必要である。これらを、従来のようにアプリケーションプログラム側の処理で対応すると、使用するプラットホーム毎にプラットホームで手順の異なる処理を全て変更する必要が生じする。そこで、汎用インタフェースでは、例えばサーバソケットを指定したポートで作成するという処理を行うための汎用関数としてmakeServerTCPsockのような汎用化されたインタフェースを提供する。例えば、Linux用の汎用システムインタフェースでは、このmakeServerTCPsock関数では前述したLinuxでの手順で処理を実行するようにする。一方Windows版の汎用システムインタフェースでは、Windowsでの手順で処理を実行するようにする。次に、本願のソフトウェアモジュールをLinuxで利用する場合はLinux用の汎用システムインタフェースを使い、Windowsで利用する場合はWindows用の汎用システムインタフェースを使用する。次に、アプリケーションプログラムでは、ソケットを作成する場合には、makeServerTCPSockを呼び出せば、該汎用システムインタフェースが、そのプラットホームに応じた手続を実行するので、アプリケーションをプラットホーム毎に変更する必要が無くなる。このような方法により、プラットホームが提供する機能やデバイスへのアクセス方法を汎用化することが可能になる。このように、異なるプラットホームに図２のソフトウェアモジュールを移行した場合、レイヤ（２５０）に含まれるソフトウェアモジュールのうち、プラットホームによって異なる機能や、利用手順などを利用する部分は前述したように処理方法の変更が必要だが、これより上位のレイヤ、つまり制御インタフェース（２２０）、データ処理モジュールマネージャ（２４０）、ストリームマネージャ（２３０）及びアプリケーション（２００）はプログラムの処理を変更すること無く他のＯＳ上に移行することが可能となる。
図１６、図１７、および図１８を用いて、図１で説明した処理を、図２の構成でどのようにして実現するかを説明する。

図１８は、ストリーム処理の構成を記録するテーブル（２０００）を示したもので、ストリームマネージャによって管理される。該テーブルの１つの行が１つのストリーム処理に該当する。ストリーム処理は、ストリーム処理ＩＤ（２００１）、これを構成するピアモジュールのピアモジュールＩＤ（２００２）、これを構成するリンクモジュールのリンクモジュールＩＤ（２００３）、および、ストリーム処理の状態（２００４）からなる。

図１６は、ピアモジュールの構成を記録するテーブル（１８００）を示したもので、ピアモジュールマネージャによって管理される。該テーブルの１つの行が１つのピアモジュールに該当する。一つのピアモジュールは、ピアモジュールＩＤ（１８０１）、ストリーム処理ＩＤ（１８０２）、データ処理モジュールＩＤ（１８０３）、データアクセスモジュールＩＤ（１８０４）、入力リンクモジュールＩＤ（１８０５）、出力リンクモジュールＩＤ（１８０６）、実行待ちデータオブジェクト行列（１８０７）、及び、後処理待ちデータオブジェクト行列（１８０８）からなる。実行待ちデータオブジェクト行列（１８０７）および、後処理待ちデータオブジェクト行列（１８０８）はデータを、入出力可能な行列であり、配列、キュー、ハッシュテーブルあるいはリスト等で実装される。図には行列がそのテーブル内に存在するか否かを示す例について記載したが、ピアモジュールマネージャ内に行列が存在する場合、その存在するアドレスを列（１８０７）、（１８０８）で記録してもよい。リンクモジュールＩＤの−１という値は、ピアモジュール（１００）にリンクモジュールが接続されていないことを示す。

図１７は、リンクモジュールの構成を記録するテーブル（１９００）を示したもので、リンクモジュールマネージャによって管理される。該テーブルの１つの行が１つのリンクモジュールに該当する。１つのリンクモジュールは、リンクモジュールＩＤ（１９０１）、ストリーム処理ＩＤ（１９０２）、始点ピアモジュールＩＤ（１９０３）、終点ピアモジュールＩＤ（１９０４）及びバッファ行列（１９０５）からなる。バッファ行列（１９０５）はデータを、入出力可能な行列であり、配列、キュー、ハッシュテーブルあるいはリスト等で実装される。図には行列がそのテーブル内に存在するか否かを示す例について記載したが、リンクモジュールマネージャ内に行列が存在する場合、その存在するアドレスを列（１９０５）に記録してもよい。

図３には、本実施例を実施するために用いられるハードウェア構成が示されている。ＣＰＵ（３００）、ＲＡＭ（３１０）あるいはＲＯＭ（３２０）等のメモリ、クロック（３３０）、HDD等のディスク装置（３５０）、コンテンツデータの放送を受信するためのチューナ（３６０）、マルチメディアデータを符号化／復号化するためのマルチメディアコーデックプロセッサ（３７０）、およびスピーカ内蔵のテレビ受信機等のディスプレイ（３８０）がシステムバス（３４０）により接続されている。なお、図２におけるソフトウェアモジュールは、メモリにロードされＣＰＵで実行される。また、本ハードウェア構成は、例えば、ＨＤＤレコーダ、ＤＶＤレコーダ、ＰＣ、あるいは監視カメラ等で用いられる。

図５に、本実施例のアプリケーションがストリームマネージャ（２３０）へ指示を出すために、制御インタフェースに発行する命令の例を示した。図５にはストリームマネージャ（２３０）への命令種別（５０１）とそのパラメタ（５０２）と戻り値（５０３）が定義されている。これらの制御インタフェースは、例えば本実施例がＣやＣ＋＋等のプログラミング言語で開発された場合は関数やモジュールとして実現されるものである。

なお、上記データアクセスモジュールＩＤ、データ処理モジュールＩＤ、図５で規定し命令を用いてデータ処理フローを生成し、処理を開始することが可能である。詳細については、図７を用いて後述する。

図５を用い、データの処理フローを作成、制御する命令について説明する。例えば、ストリーム処理生成命令（５００）を実行するとストリーム処理が生成する。具体的には、一意なストリーム処理ＩＤが割り当てられて、図１８（２０００）の使用されていない１つの行に、ストリーム処理ＩＤが記録され、ストリーム処理が生成する。その値が戻り値として返される。ここでは１が、アプリケーションに返されたとする。

次に、アプリケーションは、このストリーム処理ＩＤを用いて、ピアモジュール生成命令（５２０）を実行すると、ピアモジュールを生成する。具体的には、新たに一意なピアモジュールＩＤを生成し、図１６（１８００）の使用されていない１つの行に、ピアモジュールＩＤが記録され、パラメタとして渡されたストリーム処理ＩＤを記録し、テーブル（２０００）にパラメタとして指定されたストリーム処理ＩＤに該当するストリーム処理のピアモジュールＩＤ（２００２）の欄にピアモジュールＩＤを記録することでピアモジュールを生成する。割り当てられたピアモジュールＩＤは戻り値としてアプリケーションに返される。ここでは１００が返されたとする。

次いで、同様にして（図１６の１８２０で示される）別のピアモジュール（１２０）を生成する。該ピアモジュールのモジュールＩＤは１２０とする。次に、リンクモジュール生成命令（５４０）を用いることで、これらのピアモジュールをリンクモジュールで結合する。具体的には、新たに一意なリンクモジュールＩＤが割り当てられて、図１７（１９００）の使用していない１つの行にリンクモジュールＩＤを記録し、始点ピアモジュールＩＤ、および終点ピアモジュールＩＤとしては、パラメタとして渡された値がそれぞれ記録される。例ではそれぞれ、１００と１２０である。次に、表（１８００）のピアモジュールＩＤが１００である行（１８１０）の出力リンクモジュールＩＤに１１０を、次にピアモジュールＩＤが１２０である行（１８２０）の入力リンクモジュールＩＤに１１０を記録する。次に、表（２０００）のストリーム処理ＩＤが１である行（２０１０）のリンクモジュールＩＤ（２００３）にリンクモジュールＩＤを登録する。これらの処理により、ピアモジュール間を結合するためのリンクモジュールの生成と設定が終了する。

次に、ピアモジュールでどのような処理を行うかを、データ処理モジュール制御命令（５６０）と、データアクセス制御命令（５７０）を用いて設定する。データ処理モジュール制御命令（５６０）のパラメタ中のデータ処理モジュールＩＤの詳細については図１４を用いて、データアクセスモジュール制御命令のパラメタ中のデータアクセスモジュールＩＤについては図１３を用いて後述する。例えば、ピアモジュールＩＤが１００のピアモジュールに対して、データアクセスモジュールＩＤが１の処理を割り当てる場合は、データアクセスモジュール制御命令（５７０）を用いる。これにより、表（１８００）のピアモジュールＩＤが１００の行のデータアクセスモジュールＩＤ（１８０４）にデータアクセスモジュールＩＤの１が記録される。データ処理モジュールに関しても同様に、データ処理モジュール制御命令（５６０）を利用して設定する。データ処理モジュールと、データアクセスモジュールの詳細については図４で後述する。

さらに、５８０のデータ処理制御コマンド命令を用いた場合、パラメタ中の「コマンド」を使用してデータ処理モジュールの制御や設定を行うことが可能である。例えば、ネットワークの処理を行うデータ処理モジュールの場合、「パケットサイズ設定コマンド」を使って、データ処理モジュールにおけるパケットサイズを変更処理の設定可能である。また、データアクセスモジュール制御命令（５７０）は、例えばファイルからデータを読み出す場合はそのファイル名を指定したり、ネットワークからデータを入出力する場合はポート番号を指定する際にも使用できる。

データ処理の実行は、開始コマンドや停止コマンドを発行するデータ処理コマンド命令（５８０）を用いて制御され、ストリーム処理に関係づけられた各ピアモジュールのスケジューリングを制御することができる。これは、ストリーム処理がテーブル（２０００）にストリーム処理に関係する、リンクモジュールとピアモジュールが登録されているので、ストリーム処理ＩＤを指定すれば、関係するリンクモジュールとピアモジュールの全ての設定や動作を変更することが可能である。

アプリケーションはイベント管理命令（５９０）を介してデータ処理モジュール（４０１）と通信することができ、エラーなどのイベントを渡したり、データ処理を終了させたりすることができる。データ処理は、ストリーム処理破棄命令（５１０）によって破棄、終了したり、ピアモジュール破棄命令もしくはリンクモジュール破棄命令（５３０、５５０）をそれぞれ使って選択的に破棄することもできる。この場合の破棄とは登録されているテーブルの内容を消去が該当する。

図１３にデータアクセスモジュールＩＤとそのデータアクセスモジュールの対応を管理するテーブル（１３００）を示した。該テーブルはデータアクセスモジュールマネージャ（２７０）内に存在する。該テーブル（１３００）にはデータアクセスモジュールＩＤ（１３０１）と、これに対応する入出力実行処理部へのアドレス（１３０２）と、入出力完了処理部へのアドレス（１３０３）、及びその機能概要の記述（１３０４、１３０５）が記録されている。図に示した例では、データアクセスモジュールＩＤが１の場合は（１３１０）、０ｘＦ９８００００００番地に存在する「ハードディスクへのデータ読込要求発行」する機能を有する入出力実行処理部と、０ｘＦ９８０８０００番地に存在する「ハードディスクからのデータの取得」する機能を有する入出力完了処理部が記録されている。

データアクセスモジュールＩＤとそのモジュールが実際に行う処理の対応については、例えば、マニュアル等に記載されており、使用者は必要な機能を実現するデータアクセスモジュールＩＤを得る。あるいは、機能の欄（１３０４、１３０５）に記述されている内容から必要なものを選択する。

図１４にはデータ処理モジュールＩＤとそのデータ処理モジュールの対応を管理するテーブルを示した。該テーブルはデータ処理モジュールマネージャ（２４０）内に存在する。該テーブル（１５００）にはデータ処理モジュールＩＤ（１５０１）と、これに対応する前処理部へのアドレス（１５０２）と、後処理部へのアドレス（１５０３）、及びそれら機能の記述が記録されている。図に示した例では、データ処理モジュールＩＤが１００の場合は（１５１０）、０ｘＦＡ８００００００番地に存在する「指定されたファイルの読込を指示。次のスケジューリング時間を指定」する機能を有する前処理部と、０ｘＦＡ８０８０００番地に存在する「取得したデータを出力リンクに出力」する機能を有する後処理部が記録されている。データ処理モジュールＩＤとそのモジュールが実際に行う処理の対応については、例えばマニュアルに記載されており、使用者は必要な機能を実現するデータ処理モジュールＩＤを得る。あるいは、機能の欄（１５０４、１５０５）に記述されている内容から必要なものを選択する。

図１５に、図１で示したデータ処理を行うために、アプリケーションが図５で示した命令を利用して、ピアモジュールとリンクモジュールを結合しデータ処理プログラムを構築する手順を示した。

最初に、アプリケーションはストリーム処理生成命令（５００）を利用してデータ処理フローを生成し（ステップ１５００）、ストリーム処理ＩＤを得る。

次に、該ストリーム処理ＩＤを使用して、ファイル読出しピアモジュールを、ピアモジュール生成命令（５２０）を利用して生成し、ピアモジュールＩＤを得る。次にファイル読み出しピアモジュールにデータ処理モジュールをデータ処理モジュール制御命令（５６０）にデータ処理モジュールＩＤを用いて割り当て（ステップ１５１１）、データアクセスモジュールをデータアクセスモジュール制御命令（５７０）にデータアクセスモジュールＩＤを用いて割り当てる（ステップ１５１２）。同様に、マルチプレクサピアモジュールを作成し（ステップ１５２０）、データ処理モジュールを割り当てる（ステップ１５２１）。以下、同様にして、映像ピアモジュールを作成し（ステップ１５３０）、データ処理モジュールと、データアクセスモジュールの割当を行い（ステップ１５３１，１５３２）、音声ピアモジュールを作成し（ステップ１５４０）、データ処理モジュールと、データアクセスモジュールを割り当てる（ステップ１５４１，１５４２）。次に、ファイル読み出しピアモジュールからマルチプレクサピアモジュールを接続するリンクモジュールをリンクモジュール生成命令（５４０）を使用して作成し（ステップ１５５０）リンクモジュールＩＤを得、同様にマルチプレクサピアモジュールから映像ピアモジュールを接続するリンクモジュール、音声ピアを接続するリンクモジュールを作成する（ステップ１５６０，１５７０）。このようにアプリケーションから処理することで、使用するピアモジュールが相互に関係づけられ、処理に使用するデータ処理モジュールとデータアクセスモジュールが割り当てられる。

このように、ピアモジュール、リンクモジュール等の生成、設定は、アプリケーションが制御命令を経由して行う。アプリケーションから実行される命令に基づき、必要なピアモジュールを生成し、リンクモジュールを用いてこれらのピアモジュールを接続してデータ処理フローを作成した上で、ビットレートなどの処理に必要な情報、処理に必要なデータアクセスモジュール及びデータ処理モジュールをピアモジュールに設定し、データ処理の開始を指示することで、所定の処理を実行することが可能となる。

このような機能が提供されることで、ストリーム処理を行うアプリケーションの記述は大幅に削減される。なぜなら、ストリーム処理は定められたビットレートでデータを処理することが重要なリアルタイム性が高い処理であるため、そのような処理を実現するプログラムの開発はプラットホームが提供する機能例えば時間管理等を使い、ＣＰＵ時間を一部の処理が占有し処理の流れが滞らないようにする等の高度なスケジューリング技術が必要となるが、本実施例の手法を用いれば、スケジューリングはストリームマネージャが行うため、ストリームマネージャを利用するアプリケーションは、ピアモジュールの生成と、リンクモジュールを関係づけ、必要なデータアクセスモジュールとデータ処理モジュールを作成し、これをピアモジュールに関係づければよく、上記のスケジューリング機能については実装する必要が無いからである。

またこれらのモジュールはストリームマネージャが提供するプラットホームに非依存のインタフェースを利用するだけで良いのでアプリケーションは、どのようなプラットホームでも変更せずに利用することが可能となる。

図４は図１６を用いて説明したピアモジュールの論理的な構成を示した図である。ピアモジュール（４００）は、データフォーマットに依存したデータ処理を実行するデータ処理モジュール（４０１）と、ＯＳのシステムインタフェース（２８０）を介し、特定のハードウェア装置を用いデータ処理を実行するデータアクセスモジュール（４０５）を備える。ピアモジュールは、ストリームマネージャ内でピアモジュール固有の識別子（ピアモジュールＩＤ）で識別される。

データ処理モジュール（４０１）は固有の識別子（データ処理モジュールＩＤ）で識別され、さらに前処理部（４０２）と後処理部（４０３）を備える。どのピアモジュールにどのデータ処理モジュールが関係づけられているかはテーブル（１８００）の列（１８０３）に記録されている。データアクセスモジュール（４０５）も、固有の識別子（データアクセスモジュールＩＤ）で識別され、入出力実行処理部（４０６）と入出力完了処理部（４０７）を備える。どのピアモジュールにどのデータアクセスモジュールが関係づけられているかはテーブル（１８００）の列（１８０４）に記録されている。

ピアモジュールは、リンクモジュール（４１０、４２０）で、他のピアモジュールと連結される。リンクモジュールは、バッファ行列（４１１）を備える。リンクモジュール（４１０）がデータ処理モジュールの入力側に接続される場合は、該リンクモジュール内のバッファに格納されるデータは、データ処理モジュールの前処理部へ出力可能である。データ処理モジュールの出力側に接続される出力リンクモジュール（４２０）の場合には、該リンクモジュール内のバッファに格納されるデータは、データ処理モジュールの後処理部から入力可能である。

例えば、他のピアモジュールで処理されたデータがバッファに書き込まれて入力リンクモジュール（４１０）に入力される。このデータは前処理部（４０２）が受け取り、該前処理部によって、データオブジェクト（４０８）に変換されて、実行待ちデータオブジェクト行列（４１２）に入れられる。これをデータアクセスモジュール（４０５）が取得し、処理する。データオブジェクト（４０８）の詳細については図１２を用いて後述する。

データアクセスモジュールは、ＯＳ内のシステムインタフェース（２８０）を介してデバイスドライバ（４３０）にアクセスし、ハードウェアデバイス（４４０）とデータの入出力を行う。データアクセスモジュールの入出力実行処理部（４０６）は、データの入出力要求、あるいは前処理部から渡されたデータに対する処理を行う。処理としては、例えば、ハードウェアデバイス（４４０）に格納されたファイルの読込などの指示や、データオブジェクト中のデータ（４０８）の暗号処理用ハードウェアにおける暗号化処理の指示等のデータ変換処理等が考えられる。処理結果は、入出力完了処理部（４０７）が取得し、データオブジェクト（４０９）として、後処理待ち処理オブジェクト行列（４１３）に入力する。後処理部は後処理待ち処理オブジェクト行列（４１３）から取り出したデータオブジェクト中のデータを出力リンクモジュール（４０２）に出力して、ピアモジュールのデータ処理を終える。

これらの動作は、ピアモジュールスケジューラ（２３３）が、テーブル（１８００）とテーブル（１９００）を参照しながら実行する。実行のタイミングは図１１のスケジューリングテーブル（１１００）に記された情報に従って実行する。図１１の詳細は後述する。

また、ピアモジュールは一つ以上の入力リンクモジュールならびに一つ以上の出力リンクモジュールに連結され、該リンクモジュールを介して２つ以上のピアモジュールが連結されることで一連のデータ処理フローを実現することができる。これにより、複数のピアモジュールからのデータを単一のピアモジュールに集めて複数のデータを多重化したり、単一のデータフローを複数の異なるピアモジュールへ送出することも可能である。これは、例えば、図１で示したような多重化されたデータの分離、あるいは複数のデータの多重化などに利用できる。

データアクセスモジュールの入出力処理実行部（４０６）、及び入出力完了処理部（４０７）はプラットホームに備えられたハードウェアデバイスが異なるとその実現方式が変わり得る。該データアクセスモジュールを修正することで、データアクセスモジュールよりも上位レイヤのモジュールは、システムインタフェースに依存せずに、処理を実行することが可能となる。

図１２にデータオブジェクトの構成を示した。データオブジェクト（１２００）は、データリスト（１２１０）、コマンドコード（１２１２）及びコマンド引数（１２１３）からなる。データリストはさらに、データへのアドレス（１２２１）とデータのサイズ（１２２２）がリストとして格納されている。データオブジェクトは、処理すべきデータをデータリスト（１２１０）で保持し、さらにそのデータに対するコマンド（１２１１）とパラメタ（１２１３）が記録されたものである。必ずしもコマンドとデータが対になって記録されている必要は無く、データは空で、コマンドだけが格納されていても良いし、逆にデータだけが格納されていても良い。

図１１にピアモジュールスケジューラ内のスケジュールテーブルの構成を示した。スケジュールテーブル（１１００）はピアモジュールスケジューラがどのピアモジュールをいつ実行するかを管理する。該テーブルには、スケジュール時刻（１１０１）とピアモジュールＩＤ（１１０２）を項目として有している。ここで、テーブル（１１００）中のスケジュール時刻とは、あるピアモジュールに関連付けられたデータアクセスモジュールとデータ処理モジュールの処理を、次に実行する予約時刻のことである。また、スケジュールとは複数の処理を行わなければならない場合、どのような順番でどの処理をいつ行うかを決定し、記録することである。またスケジュール実行、あるいはスケジューリングとは、予め定められたスケジュールに従って処理を実行することを指す。

図１１の例では、例えば時刻２５０ミリ秒においてピアモジュールＩＤが１０および１３のピアモジュールが実行されることが行１１１０、１１２０に示されている。つまり、同一の時刻に実行されるべきピアモジュールが複数存在しても良い。ただし、スケジュール時間は同一時間であっても、実際の処理は、一方の処理が完了した直後にもう一方の処理が行われてもよい。

本実施例では、該スケジュールテーブルに記録された内容に準じて処理を実行するのは、ピアモジュールスケジューラである。つまり、上述した処理は前述のタイミングで、ピアモジュールスケジューラがテーブル（１８００）、テーブル（１９００）、およびテーブル（２０００）を参照しながら必要な処理を順次行う。つまり、各ピアモジュールのデータ処理モジュールとデータアクセスモジュールの処理はピアモジュールスケジューラが実行する。これは言い換えれば、スレッドのような一つの実行コンテキストで、ピアモジュールピアモジュールスケジューラの処理、前処理部、後処理部、入出力実行処理部、及び入出力完了処理部の処理を行うということである。

ピアモジュールスケジューラは、例えば、定期的に起動され、該テーブルを参照し、現在の時刻と比較してそれよりも以前のスケジュール時刻が設定されたピアモジュールがあれば、このピアモジュールの処理を行い、必要があればテーブル（１１００）を更新し、次の起動を待つ。

ピアモジュールの実行手順について、図６を用いて説明する。

まず、ピアモジュールスケジューラは、既に処理が開始されているストリーム処理が存在するかどうかをストリームテーブル（２０００）の列（２００４）を参照して確認する（ステップ６００）。開始されているストリーム処理が存在しない場合、新たにストリーム処理が実行されるまで待つ（ステップ６０１）。開始されたストリーム処理が存在する場合は、スケジュールテーブル（１１１０）を参照し、現在時刻を起点にして最も早く実行されるスケジュール時刻まで待つ（ステップ６０３）。時刻を待つ方式は、時計を周期的に見て判断しても良いし、指定時間だけ実行を停止する機能を使用しても良いし、時間割込の利用できるプラットホームであればこれを利用しても良い。ストリーム処理が開始された直後は、まだピアモジュールによって処理開始時刻がスケジュールマネージャに予約されていないので、そのストリーム処理を構成するピアモジュールのスケジュール時刻として現在の時刻を、ストリームマネージャが登録することで最初の実行が行われるようにする。待機動作が完了すると、スケジュールテーブル（１１００）のピアモジュールＩＤ（１１０２）に記載されたピアモジュールのデータ処理モジュールの前処理部をピアモジュールスケジューラが実行する（ステップ６０４）。この実行処理において、前処理部は、入力リンクモジュールにデータが存在しているかを確認し、存在すればこれをデータオブジェクトに変換し、実行待ちデータオブジェクト行列（４１２）に入力する。あるいは図１のデータをハードディスクから読み出すピアモジュールのような、ストリーム処理の始点となるピアモジュールでは、データの読み出し要求をデータオブジェクトとして該行列に入力する。

次に、自モジュールが次にスケジュールされるべき時刻を算出し、ピアモジュールスケジューラに該時刻を登録する（ステップ６０５）。次のスケジュール時間を前処理部（４０２）が定める理由は、リンクモジュール（４１０）から得られたデータ（４１１）のサイズ等、処理に必要な時間を算出できるのが前処理部だからである。例えば図１のピアモジュール（１００）のようなファイルを読み出すピアモジュールに、例えばビットレートが１秒当たり１０２４キロバイトで、一度に読み込むデータブロックのサイズが２５６キロバイトに設定されていたとする。この指定はデータ処理コマンド命令（５８０）を使用してアプリケーションから指定される。このような場合、ファイルの読込のピアはであったとすると、（一度に読み込むデータブロックサイズ）／（ビットレート）で定められる値で読込の時間間隔が決定できる。例えば、毎秒１０２４キロバイトでブロックサイズが２５６キロバイトであるなら、読込は０．２５秒毎で行えば指定されたビットレートが実現できることが判る。つまり、２５６キロバイトのデータ要求を前処理部が入出力処理部に行った後は、次の処理は０．２５秒後に行えば良いことになるので、次回のスケジューリング時間は２５０ミリ秒後と定まる。

それよりも下流にあるピアモジュール、図１０におけるデマルチプレクサピアモジュールや映像ピアモジュールにおいては、これらのスケジューリング時間は、同様な方法で設定されたビットレートとリンクモジュール経由で得られたデータのサイズから決めても良いが、比較的短い時間をスケジューリング時間に設定しで、頻繁に実行された方が良い。なぜならば、データのビットレートは最上流のファイル読み出しピアが前述の方法で制御しているので、それより下位のピアモジュールでは、特にビットレートを制御せずに、データが入力リンクオブジェクトに入力されたら、これをすぐに取り出して処理を行い、出力リンクモジュールに出力すれば、定められたビットレートが実現できるからである。この場合、下流のピアオブジェクトでは、処理の遅延が起ってビットレートが低下しないようにするために、頻繁にリンクオブジェクトにデータが入力されたかを確認する方が良い。このためには、スケジューリング時間は小さな値を予約するべきである。

前処理部からデータアクセスモジュールにデータオブジェクトが出力された場合（ステップ６０６）、ピアモジュールスケジューラが、該データオブジェクトに指示された処理を開始するためにデータアクセスモジュールの入出力実行処理部を実行する（ステップ６０７）これは例えば、データの加工や取得をハードウェアデバイスに要求する作業が該当する。

実行待ちデータオブジェクト行列にデータアクセスモジュールが無く、かつデータアクセスモジュールからデータオブジェクトが新たに後処理待ちデータ処理行列に出力されていない場合、ピアモジュールスケジューラはステップ６１１に進む（ステップ６０８）。

以前に実行された入出力実行処理部の処理が終了して、処理結果としてのデータが存在する場合、これは、例えば、ハードウェアデバイスに要求していたデータ加工や取得処理が終了して、その結果としてのデータが存在する場合は、データアクセスモジュールの入出力完了処理部をピアモジュールスケジューラが実行し（ステップ６０９）、該データをデータオブジェクトとして後処理待ちデータオブジェクト行列（４１３）に入力する（ステップ６１０）。データオブジェクトが後処理待ちデータオブジェクト行列（４１３）に有る場合、ピアモジュールスケジューラが後処理部を実行し、出力リンクモジュールにデータオブジェクト中のデータリストのみを渡す。後処理部の処理が完了した場合、ピアモジュールスケジューラは次のピアモジュールのスケジュールのために開始状態に戻る。

本実行方式では、例えば複数のストリーム処理実行する場合も、各ストリーム処理に存在するピアモジュールの処理は、ピアモジュールスケジューラの一つの実行コンテキストで行うことが可能である。ここで、実行コンテキストとはプログラムを実行する場合に必要となる情報を持った実行単位のことで、スレッドなどがこれに相当する。なぜならば、前述した方法を用いることで、例え複数のストリーム処理であっても、各ピアモジュールの処理をスケジューリングする時刻がそれぞれのピアモジュールから指定されているので、その時間にピアモジュールスケジューラが実行すれば良いからである。このように１つの実行コンテキストで処理すると、複数の実行コンテキストで複数のストリーム処理を処理したときに生じる同期化処理を行う必要がない。このデバイスへのアクセスを排他的に行うための同期化処理は負荷が高いため、この処理を省くことでストリーム処理の性能低下を防止できる。

また、本方式では例えば、実行優先度を上げるのであれば、ピアモジュールの前処理部で決定するピアモジュールの予約時間をより短くすれば、そのピアモジュールの処理がより早くスケジューリングされることになり、より多くのＣＰＵ時間が該ピアモジュールの処理に使われることになる。また、複数処理を実行する場合、上記した予約時間を調整することで、それぞれの処理の優先度を指定することが可能となる。例えば、あるデバイスからデータを取得してストレージに記録する処理と、あるデバイスからデータを取得してディスプレイに表示する処理の２つの処理を同時に行う場合、前者の処理の予約時間を短く設定すれば、記録処理の優先順位を高く設定することが可能となる。

また、複数のデータ処理を１つの実行コンテキストで実行することで、複数の実行コンテキストに複数のバッファを割り当てる必要が無くなり、また複数コンテキストの並列実行時に用いられるセマフォのような、複数の実行コンテキストで一つのリソースを利用する際に、排他的なアクセスを保証する仕組みである同期機能を用いる必要が無くなり、使用リソースの低減が可能となる。

また、一つのコンテキストで処理を実行することにより、ピアモジュールスケジューラ（２３３）は効率のよいスケジューリングを設定することが可能となる。なぜなら、従来のスケジューリング方式、例えばラウンドロビン方式等では、一定時間毎に無条件に処理を切り変えるので、処理が必要無い場合でもスケジューリングされてしまうことがあったり、処理が必要な場合にスケジューリングされないことがあり、リアルタイム性が低下し、無駄なＣＰＵ時間を消費することになっていた。一方、本方式では、次処理に必要な時間を算出し、その必要な時間をスケジューリングテーブルに登録してスケジューリングを行うので余計なスケジューリングが行われず、従来のラウンドロビン方式等における冗長時間に割り当てられていたＣＰＵ処理を別の処理に振り当てることが可能になるため、全体としてプラットフォームのリソースの一つであるＣＰＵ時間の使用効率が向上し、さらに処理の必要な時刻には正しくスケジューリングされるので、リアルタイム性を向上することが可能となる。

図７に、本実施例による、ピアモジュール、リンクモジュール、及びピアモジュールスケジューラを使ったデータ処理の一例として、音声と映像が多重化されて記録されているファイルをハードディスクから読み込み、これを再び分離して、ディスプレイ、並びにスピーカから動画として再生する場合のデータフローについて説明する。音声と映像を多重化して記録する方式としては、MPEG(Motion Picture Expert Group)等がある。該処理においてファイル読み出しピアモジュール（７００）はデマルチプレクサピアモジュール（７３０）とリンクモジュール（７２０）で結合され、デマルチプレクサピアモジュール（７３０）と映像ピアモジュール（７６０）はリンクモジュール（７４０）で接続され、さらに音声ピアモジュール（７８０）がリンクモジュール（７５０）で接続されている。

まず、ファイル読み出しピアモジュールはシステムインタフェース（７０９）とデバイスドライバ（７１０）を通してハードディスクにアクセスし、データを取得する。デマルチプレクサピアモジュール（７３０）は、取得したデータの多重化を解除する。この処理によって得られた映像データは映像ピアモジュール（７６０）に送られてデバイスドライバ（７６９）を通してハードウェア映像デコーダ（７７０）に送られ、音声データは音声ピアモジュール（７８０）に送られてデバイスドライバ（７８９）を通して、ハードウェア音声デコーダ（７９０）に送られて再生される。

図１０には、図７で示した処理例における詳細な構成を示した。これを用いて、処理手順について説明する。

まず、ピアモジュールスケジューラが、ファイル読み出しピアモジュールのデータ処理モジュールの実行を開始する。データ処理モジュール（７０１）であるファイル読み出しモジュールの前処理部（７０２）はデータアクセスモジュール（７０４）であるファイルアクセスモジュールの入出力実行処理部（７０５）へのファイル読出し入出力処理であるデータオブジェクト（７０７）を入出力待ちデータオブジェクト行列に入力することで要求する。この読出し処理は入出力処理部（７０５）によってシステムインタフェース（７０９）と記憶装置用アダプタデバイスドライバ（７１０）を経由して処理される。さらに、当該処理の実行以前に実行された読み込み処理が完了したかどうかを、ピアモジュールスケジューラがチェックし、処理が完了していれば入出力完了処理部（７０６）が実行され、該データをデータオブジェクト（７０８）にして後処理待ちデータオブジェクト待ち行列に入れる。

次に、後処理部（７０３）が実行されると、後処理待ちデータオブジェクト行列に格納されたデータオブジェクト（７０８）を取得し、該データオブジェクト内のデータリストがリンクモジュール（７２０）のバッファ内の待ち行列に入力される。

なお、これらの処理において、各処理は以下のように検索される。ファイル読出しピアモジュールのピアＩＤは１００であるので、ピアモジュールスケジューラはこの値から、テーブル（１８００）を参照し、データ処理モジュールとして割り当てられているデータ処理モジュールＩＤを得る。図１６の例では該番号は１００である。次にテーブル（１５００）を参照して、データ処理モジュールＩＤが１００の行を検索する。これにより、実行すべき前処理部が０ｘＦＡ８０００００番地に、実行すべき後処理部が０ｘＦＡ８０８０００番地に存在することがわかるので、これらを実行する。この場合、本アドレスに格納されている前処理部の処理の内容は、指定されたファイルの読込を指示した後、次のスケジューリング時間を指定する処理であり、後処理部の処理の内容は取得したデータを出力リンクに出力する処理である。同様にデータアクセスモジュールに関しては、テーブル（１８００）を参照し、データアクセスモジュールとして割り当てられているデータアクセスモジュールＩＤを得る。図１６の例では該番号は１である。次にテーブル（１３００）を参照して、データアクセスモジュールＩＤが１の行を検索する。これにより、実行すべき入出力実行処理部のアドレスと、入出力完了処理部のアドレスを得て、これらを実行する。この場合、本アドレスに格納されている入出力実行処理部の処理の内容は、ハードディスクへのデータ読込要求発行であり、入出力完了処理部の処理の内容はハードディスクからのデータの取得処理である。

デマルチプレクサピアモジュール（７３０）のデマルチプレクサ処理モジュール（７３１）がピアモジュールスケジューラによって実行されると、前処理部（７３２）が実行され、リンクモジュール（７２０）の待ち行列（７２１）からデータリストを取り出す。待ち行列にデータが無い場合、前処理部は処理を終了して、後処理部の処理に移る。

なお、上記の前処理部における処理は、データ処理フローにおいて始点から２つ目以降に接続されたピアモジュールの処理において同様である。また、全てのピアモジュールの前処理部は、処理を終了する前に、次に自身が実行されるべき時間を予約する。この予約時間は、該ストリーム処理のビットレートや、要求されるリアルタイム性に依存する。例えば、高いビットレートのデータ処理、あるいは高いリアルタイム性が要求される処理の場合は、データを迅速に処理して次のピアモジュールに渡さなければならないので、入力リンクモジュールのバッファにデータが格納されているか否かの確認を頻繁に行う必要がある。逆にビットレートが低ければ、比較的間隔を開けてチェックすることができる。

該デマルチプレクサピアモジュールの処理はデータフォーマットの変換であり、プログラムで実行することで処理可能であり、ＨＤＤ等のＩ／Ｏ系のハードウェアにアクセスする必要がないためデータアクセスモジュールが定義する必要はなく、前処理部で処理後のデータは後処理部（７３３）に渡される。この場合のデータフォーマットの変換処理は、与えられたデータを予めマルチプレクサピアモジュールの前処理部（７３２）が解析し、その結果を２つの音声バッファと映像バッファに書き込む処理となる。後処理部は、映像バッファから映像データを取り出し、リンクモジュール（７４０）の待ち行列（７４１）に入力し、同様に音声バッファから音声データを取り出しリンクモジュール（７５０）の待ち行列（７５１）に入力する。

次に、映像ピアモジュール（７６０）のデータ処理モジュールである映像書き込みモジュール（７６１）の前処理部（７６２）が実行されると、待ち行列（７４１）に待機しているデータリストが取り出される。アプリケーションがデータ処理モジュール制御命令（５６０）を用いて定めたビットレートに応じて、映像デコーダアクセスモジュール（７６４）にデータを送り、入出力実行処理部（７６５）によって、該データはハードウェア映像デコーダ（７７０）のデバイスドライバ（７６９）に出力され、ハードウェア映像デコーダ（７７０）に出力され、その結果として映像が出力される。出力が完了したデータはデータアクセスモジュールである映像デコーダアクセスモジュールの入出力完了処理部（７６６）によって検出され、データオブジェクト（７６８）として終了処理待ちデータオブジェクト行列に入れられる。映像ピアモジュールはデータ処理の末端であり、出力リンクモジュールが無いので、デバイスに書き込まれた映像データは後処理部（７６３）により破棄される。

音声ピアモジュール（７８０）における処理も先に説明した映像ピアにおける処理と同様である。音声ピアのデータ処理モジュールである音声書き込みモジュール（７８１）の前処理部（７８２）が実行され、待ち行列（７５１）内に待機している音声データリストが取り出される。取り出されたデータのビットレートに応じて、データアクセスモジュールである音声デコーダアクセスモジュール（７８４）に送られ、入出力実行処理部（７８５）によって処理が開始される。音声データは、デバイスドライバ（７８９）を通じてハードウェア音声デコーダ（７９０）に送られ、再生される。出力が完了したデータはデータアクセスモジュールの入出力完了処理部（７８６）によって検出され、完了したデータはデータオブジェクト（７８８）として後処理待ちデータオブジェクト行列に入れられ、その後、後処理部（７８３）によって破棄される。

図８は、図２の構成をユーザ空間で実装した例を示している。ユーザ空間で実装する場合、全てのモジュールがユーザ空間上で実装されるので、開発が容易という効果がある。なぜなら、アプリケーションプログラムを開発する際に利用される開発ツール、例えばデバッガ等が使用できる上に、ＯＳの提供するメモリ管理機能を利用できるので他のアプリケーションからの干渉を防止でき、信頼性、可用性を高めることが可能だからである。

図９は、図２の構成の大部分をＯＳで構成した例を示している。例えば、カーネル空間で実装する構成の場合、ＯＳ内のモジュールがアプリケーションプログラムより優先的に実行が行わるＯＳでは、ユーザ空間で実装されるよりも、性能で有利になる。特に、リアルタイム性が必要となる高ビットレートでのコンテンツ処理を行う場合には特に有効と考えられる。

この２つの構成において、プラットホーム依存となるのは汎用システムインタフェース（９２０，９３１）、及びデータアクセスモジュールマネージャ（９３２）であり、これ以外の本実施例に属するプログラムモジュールはプラットホームに依存しない。なぜならば、ハードウェアやＯＳの相違により異なるＯＳの機能利用手順や、デバイスのアクセス方法の差異を該モジュールが吸収して、該モジュール提供する汎用化されたインタフェースを利用することでフラットホームが提供する機能を利用することが可能だからである。

なお、いずれの構成を採用するかは、用途、ハードウェア構成、及び開発工数などを考慮して決められるべきである。例えば、ＣＰＵの性能が低いプラットホームでの実装、あるいは高い性能が要求される場合は、デバッグなどは多少困難になるが、高性能を実現することが比較的容易な図９のカーネル空間での実装が考えられる。逆に、ＣＰＵが十分に早くメモリ等の実行リソースが十分に利用できる場合や、高性能が要求されない場合等は、実装が容易な図８のユーザ空間のような構成とすることが考えられる。

本技術は、例えば動画や音声処理等のストリーミング処理に利用可能である。例えば、放送機器、受信機、録画・録音機器、及び監視カメラなどに適用可能である。

処理ポイント間のデータフローとして構成されたデータ処理の処理フローを示した構成図 本実施例の要素の全体構成を示した構成図 ハードウェア構成を示した構成図 本実施例の処理ポイントの定義を示した構成図 本実施例の制御インタフェースを示した図 本実施例の処理ポイントのスケジューリング機能の処理ステップを示したフローチャート 記憶装置に記憶されハードウェアデコーダを用いて復号化された映像フィルタを提示するためのデータ処理のフローの例を示した構成概要図 オペレーティングシステムのアプリケーションレベルで実行させるための本実施例の実装形態例を示した構成図 オペレーティングシステムのカーネルレベルで実行させるための本実施例の実装形態例を示した構成図 記憶装置に記憶されハードウェアデコーダを用いて復号化された映像フィルタを提示するためのデータ処理のフローの例を示した構成図 スケジュール時間を管理するテーブルの構成を示した図 データオブジェクトの構成を示した図 データアクセスモジュールＩＤとデータアクセスモジュール管理情報のアドレスの対応を管理するテーブルの構成を示した図 データ処理モジュールＩＤとデータ処理モジュール管理情報のアドレスの対応を管理するテーブルの構成を示した図 ストリーム処理を構築する手順を示したフロー ピアモジュールの構成を示した図 リンクモジュールの構成を示した図 ストリーム処理の構成を示した図

符号の説明

１００ カメラ、１１０ マイクロフォン、１２０ データを取り出すステップ、１２１ カメラを使って映像データにアクセスするポイント、１２２ マイクロフォンを使って音声データにアクセスするポイント、１３０ 映像データと音声データを同期させ多重化するステップ、１３１ 単一の処理ポイント、１４０ データを提示するステップ、１４１ 単一の処理ポイント、１５０ データを記録するステップ、１６０ ハードウェアデータデコーダ、１７０ ディスプレイ、１８０ スピーカ、１９０ 記憶装置

Claims (18)

1. データの入力装置とデータの出力装置と各処理モジュールを格納した記憶部と命令を発行する命令発行部と前記処理モジュールを用いて処理を実行する演算処理部とを有するデータ処理装置におけるデータ処理方法であって、
   前記命令発行部から発行された第１の命令に基づき、前記データを処理するのに必要な少なくとも１以上の処理を特定し、
   前記特定された処理に必要な処理モジュールを前記記憶部に生成し、
   リンクモジュールを用い前記処理モジュールを接続して、前記処理を実行するための処理フローを前記記憶部に生成し、
   前記命令発行部から発行された第２の命令に基づき、前記入力装置から入力されたデータが前記処理フローの開始部に入力されて、前記演算処理部により前記処理フローが実行され、
   前記処理フローが実行された処理結果が前記出力装置から出力されることを特徴とするデータ処理方法。
2. 請求項１記載のデータ処理方法であって、
   前記処理モジュールは、前記入力装置からデータを入力あるいは前記出力装置へデータを出力するデータアクセスモジュールと、前記データアクセスモジュールを介して入力されたデータに所定の処理を実行した後に該処理後のデータを他の処理モジュール出力するデータ処理モジュールとを有することを特徴とするデータ処理方法。
3. 請求項２記載のデータ処理方法であって、
   前記データ処理モジュールは、前記リンクモジュールからデータを入力し、所定の処理を実行後に該実行後のデータを前記データアクセスモジュールに出力する第１の処理部と、前記データアクセスモジュールから入力されたデータを他の処理モジュール出力する第２の処理部とを有することを特徴とするデータ処理方法。
4. 請求項３記載のデータ処理方法であって、
   前記データアクセスモジュールは、前記第１の処理部から送信されるデータの入出力要求を前記入力装置あるいは出力装置へ送信する入出力実行処理部と、前記入出力要求により取得したデータを前記第２の処理部へ出力する入出力完了処理部とを有することを特徴とするデータ処理方法。
5. 請求項３記載のデータ処理方法であって、
   データ処理管理モジュールおよび処理の順序を規定したストリームテーブルをさらに有し、
   前記第１の処理部は、
   前記命令発行部から通知されたビットレートと当該第１の処理部における処理を行う単位であるブロックサイズに基づき、当該処理モジュールが次に起動される時刻を算出し、前記ストリームテーブルに登録することを特徴とするデータ処理方法。
6. 請求項５記載のデータ処理方法であって、
   前記データ処理管理モジュールは、前記ストリームテーブルを参照し、
   前記ストリームテーブルに登録された処理を一つの実行コンテキストで実行することを特徴とするデータ処理方法。
7. データ処理装置であって、
   データの入力装置と、
   データの出力装置と、
   処理モジュールと当該処理モジュールを接続するリンクモジュール、およびデータ処理管理モジュールを格納した記憶部と、
   命令を発行する命令発行部と、
   前記処理モジュールを用いて処理を実行する演算処理部とを有し、
   前記データ処理管理モジュールは、
   前記命令発行部から発行された第１の命令に基づき、前記データを処理するのに必要な少なくとも１以上の処理を特定して、該特定された処理に必要な処理モジュールを前記記憶部に生成し、
   前記リンクモジュールを用い前記処理モジュールを接続して、前記処理を実行するための処理フローを前記記憶部に生成し、
   前記命令発行部から発行された第２の命令に基づき、前記入力装置からデータを入力して前記演算処理部により前記処理フローを実行し、前記処理フローが実行された処理結果を前記出力装置へ出力することを特徴とするデータ処理装置。
8. 請求項７記載のデータ処理装置であって、
   前記処理モジュールは、前記入力装置からデータを入力あるいは前記出力装置へデータを出力するデータアクセスモジュールと、前記データアクセスモジュールを介して入力されたデータに所定の処理を実行した後に該処理後のデータを他の処理モジュール出力するデータ処理モジュールとを有することを特徴とするデータ処理装置。
9. 請求項８記載のデータ処理装置であって、
   前記データ処理モジュールは、前記リンクモジュールからデータを入力し、所定の処理を実行後に該実行後のデータを前記データアクセスモジュールに出力する第１の処理部と、前記データアクセスモジュールから入力されたデータを他の処理モジュール出力する第２の処理部とを有することを特徴とするデータ処理装置。
10. 請求項９記載のデータ処理装置であって、
    前記データアクセスモジュールは、前記第１の処理部から送信されるデータの入出力要求を前記入力装置あるいは出力装置へ送信する入出力実行処理部と、前記入出力要求により取得したデータを前記第２の処理部へ出力する入出力完了処理部とを有することを特徴とするデータ処理装置。
11. 請求項９記載のデータ処理装置であって、
    データ処理管理モジュールおよび処理の順序を規定したストリームテーブルをさらに有し、
    前記第１の処理部は、
    前記命令発行部から通知されたビットレートと当該第１の処理部における処理を行う単位であるブロックサイズに基づき、当該処理モジュールが次に起動される時刻を算出し、前記ストリームテーブルに登録することを特徴とするデータ処理装置。
12. 請求項１１記載のデータ処理装置であって、
    前記データ処理管理モジュールは、前記ストリームテーブルを参照し、
    前記ストリームテーブルに登録された処理を一つの実行コンテキストで実行することを特徴とするデータ処理装置。
13. 命令を発行する命令発行部とデータの入力装置と出力装置とを有する計算機におけるデータ処理プログラムであって、計算機に、
    前記命令発行部から発行された第１の命令に基づき、前記データを処理するのに必要な少なくとも１以上の処理を特定する工程と、
    前記特定された処理に必要な処理モジュールを前記記憶部に生成する工程と、
    リンクモジュールを用い前記処理モジュールを接続して、前記処理を実行するための処理フローを前記記憶部に生成する工程と、
    前記命令発行部から発行された第２の命令に基づき、前記入力装置から入力されたデータが前記処理フローの開始部に入力されて、前記演算処理部により前記処理フローが実行される工程と、
    前記処理フローが実行された処理結果が前記出力装置から出力されること工程とを実行させるためのデータ処理プログラム。
14. 請求項１３記載のデータ処理プログラムであって、
    前記処理モジュールは、前記入力装置からデータを入力あるいは前記出力装置へデータを出力するデータアクセスモジュールと、前記データアクセスモジュールを介して入力されたデータに所定の処理を実行した後に該処理後のデータを他の処理モジュール出力するデータ処理モジュールとを有することを特徴とするデータ処理プログラム。
15. 請求項１４記載のデータ処理プログラムであって、
    前記データ処理モジュールは、前記リンクモジュールからデータを入力し、所定の処理を実行後に該実行後のデータを前記データアクセスモジュールに出力する第１の処理部と、前記データアクセスモジュールから入力されたデータを他の処理モジュール出力する第２の処理部とを有することを特徴とするデータ処理プログラム。
16. 請求項１５記載のデータ処理プログラムであって、
    前記データアクセスモジュールは、前記第１の処理部から送信されるデータの入出力要求を前記入力装置あるいは出力装置へ送信する入出力実行処理部と、前記入出力要求により取得したデータを前記第２の処理部へ出力する入出力完了処理部とを有することを特徴とするデータ処理プログラム。
17. 請求項１５記載のデータ処理プログラムであって、
    データ処理管理モジュールおよび処理の順序を規定したストリームテーブルをさらに有し、
    前記第１の処理部は、
    前記命令発行部から通知されたビットレートと当該第１の処理部における処理を行う単位であるブロックサイズに基づき、当該処理モジュールが次に起動される時刻を算出し、前記ストリームテーブルに登録することを特徴とするデータ処理プログラム。
18. 請求項１７記載のデータ処理プログラムであって、
    前記データ処理管理モジュールは、前記ストリームテーブルを参照し、
    前記ストリームテーブルに登録された処理を一つの実行コンテキストで実行することを特徴とするデータ処理プログラム。
    

Images