(57)【要約】【課題】  移植性が高いように一連の処理ポイントへのストリームデータ処理を構成し実行する方法を提供する。【解決手段】  本方法は、データ処理においてピアモジュールと呼ぶ処理ポイントをリンクモジュールで接続してストリームデータパスを設定し、単一の実行コンテキストでスケジューリングを行うことで、高性能な処理を可能とし、これらをレイヤ構成で実現することで高い移植性、および開発容易性を実現した。【選択図】      図１
2009116881.tif 000002
【特許請求の範囲】
【請求項１】
データの入力装置とデータの出力装置と各処理モジュールを格納した記憶部と命令を発
行する命令発行部と前記処理モジュールを用いて処理を実行する演算処理部とを有するデ
ータ処理装置におけるデータ処理方法であって、
前記命令発行部から発行された第１の命令に基づき、前記データを処理するのに必要な
少なくとも１以上の処理を特定し、
前記特定された処理に必要な処理モジュールを前記記憶部に生成し、
リンクモジュールを用い前記処理モジュールを接続して、前記処理を実行するための処
理フローを前記記憶部に生成し、
前記命令発行部から発行された第２の命令に基づき、前記入力装置から入力されたデー
タが前記処理フローの開始部に入力されて、前記演算処理部により前記処理フローが実行
され、
前記処理フローが実行された処理結果が前記出力装置から出力されることを特徴とする
データ処理方法。
【請求項２】
請求項１記載のデータ処理方法であって、
前記処理モジュールは、前記入力装置からデータを入力あるいは前記出力装置へデータを
出力するデータアクセスモジュールと、前記データアクセスモジュールを介して入力され
たデータに所定の処理を実行した後に該処理後のデータを他の処理モジュール出力するデ
ータ処理モジュールとを有することを特徴とするデータ処理方法。
【請求項３】
請求項２記載のデータ処理方法であって、
前記データ処理モジュールは、前記リンクモジュールからデータを入力し、所定の処理を
実行後に該実行後のデータを前記データアクセスモジュールに出力する第１の処理部と、
前記データアクセスモジュールから入力されたデータを他の処理モジュール出力する第２
の処理部とを有することを特徴とするデータ処理方法。
【請求項４】
請求項３記載のデータ処理方法であって、
前記データアクセスモジュールは、前記第１の処理部から送信されるデータの入出力要求
を前記入力装置あるいは出力装置へ送信する入出力実行処理部と、前記入出力要求により
取得したデータを前記第２の処理部へ出力する入出力完了処理部とを有することを特徴と
するデータ処理方法。
【請求項５】
請求項３記載のデータ処理方法であって、
データ処理管理モジュールおよび処理の順序を規定したストリームテーブルをさらに有
し、
前記第１の処理部は、
前記命令発行部から通知されたビットレートと当該第１の処理部における処理を行う単位
であるブロックサイズに基づき、当該処理モジュールが次に起動される時刻を算出し、前
記ストリームテーブルに登録することを特徴とするデータ処理方法。
【請求項６】
請求項５記載のデータ処理方法であって、
前記データ処理管理モジュールは、前記ストリームテーブルを参照し、
前記ストリームテーブルに登録された処理を一つの実行コンテキストで実行することを
特徴とするデータ処理方法。
【請求項７】
データ処理装置であって、
データの入力装置と、
データの出力装置と、
処理モジュールと当該処理モジュールを接続するリンクモジュール、およびデータ処理
管理モジュールを格納した記憶部と、
命令を発行する命令発行部と、
前記処理モジュールを用いて処理を実行する演算処理部とを有し、
前記データ処理管理モジュールは、
前記命令発行部から発行された第１の命令に基づき、前記データを処理するのに必要な
少なくとも１以上の処理を特定して、該特定された処理に必要な処理モジュールを前記記
憶部に生成し、
前記リンクモジュールを用い前記処理モジュールを接続して、前記処理を実行するため
の処理フローを前記記憶部に生成し、
前記命令発行部から発行された第２の命令に基づき、前記入力装置からデータを入力し
て前記演算処理部により前記処理フローを実行し、前記処理フローが実行された処理結果
を前記出力装置へ出力することを特徴とするデータ処理装置。
【請求項８】
請求項７記載のデータ処理装置であって、
前記処理モジュールは、前記入力装置からデータを入力あるいは前記出力装置へデータを
出力するデータアクセスモジュールと、前記データアクセスモジュールを介して入力され
たデータに所定の処理を実行した後に該処理後のデータを他の処理モジュール出力するデ
ータ処理モジュールとを有することを特徴とするデータ処理装置。
【請求項９】
請求項８記載のデータ処理装置であって、
前記データ処理モジュールは、前記リンクモジュールからデータを入力し、所定の処理を
実行後に該実行後のデータを前記データアクセスモジュールに出力する第１の処理部と、
前記データアクセスモジュールから入力されたデータを他の処理モジュール出力する第２
の処理部とを有することを特徴とするデータ処理装置。
【請求項１０】
請求項９記載のデータ処理装置であって、
前記データアクセスモジュールは、前記第１の処理部から送信されるデータの入出力要求
を前記入力装置あるいは出力装置へ送信する入出力実行処理部と、前記入出力要求により
取得したデータを前記第２の処理部へ出力する入出力完了処理部とを有することを特徴と
するデータ処理装置。
【請求項１１】
請求項９記載のデータ処理装置であって、
データ処理管理モジュールおよび処理の順序を規定したストリームテーブルをさらに有
し、
前記第１の処理部は、
前記命令発行部から通知されたビットレートと当該第１の処理部における処理を行う単位
であるブロックサイズに基づき、当該処理モジュールが次に起動される時刻を算出し、前
記ストリームテーブルに登録することを特徴とするデータ処理装置。
【請求項１２】
請求項１１記載のデータ処理装置であって、
前記データ処理管理モジュールは、前記ストリームテーブルを参照し、
前記ストリームテーブルに登録された処理を一つの実行コンテキストで実行することを
特徴とするデータ処理装置。
【請求項１３】
命令を発行する命令発行部とデータの入力装置と出力装置とを有する計算機におけるデ
ータ処理プログラムであって、計算機に、
前記命令発行部から発行された第１の命令に基づき、前記データを処理するのに必要な
少なくとも１以上の処理を特定する工程と、
前記特定された処理に必要な処理モジュールを前記記憶部に生成する工程と、
リンクモジュールを用い前記処理モジュールを接続して、前記処理を実行するための処
理フローを前記記憶部に生成する工程と、
前記命令発行部から発行された第２の命令に基づき、前記入力装置から入力されたデー
タが前記処理フローの開始部に入力されて、前記演算処理部により前記処理フローが実行
される工程と、
前記処理フローが実行された処理結果が前記出力装置から出力されること工程とを実行
させるためのデータ処理プログラム。
【請求項１４】
請求項１３記載のデータ処理プログラムであって、
前記処理モジュールは、前記入力装置からデータを入力あるいは前記出力装置へデータを
出力するデータアクセスモジュールと、前記データアクセスモジュールを介して入力され
たデータに所定の処理を実行した後に該処理後のデータを他の処理モジュール出力するデ
ータ処理モジュールとを有することを特徴とするデータ処理プログラム。
【請求項１５】
請求項１４記載のデータ処理プログラムであって、
前記データ処理モジュールは、前記リンクモジュールからデータを入力し、所定の処理を
実行後に該実行後のデータを前記データアクセスモジュールに出力する第１の処理部と、
前記データアクセスモジュールから入力されたデータを他の処理モジュール出力する第２
の処理部とを有することを特徴とするデータ処理プログラム。
【請求項１６】
請求項１５記載のデータ処理プログラムであって、
前記データアクセスモジュールは、前記第１の処理部から送信されるデータの入出力要求
を前記入力装置あるいは出力装置へ送信する入出力実行処理部と、前記入出力要求により
取得したデータを前記第２の処理部へ出力する入出力完了処理部とを有することを特徴と
するデータ処理プログラム。
【請求項１７】
請求項１５記載のデータ処理プログラムであって、
データ処理管理モジュールおよび処理の順序を規定したストリームテーブルをさらに有
し、
前記第１の処理部は、
前記命令発行部から通知されたビットレートと当該第１の処理部における処理を行う単位
であるブロックサイズに基づき、当該処理モジュールが次に起動される時刻を算出し、前
記ストリームテーブルに登録することを特徴とするデータ処理プログラム。
【請求項１８】
請求項１７記載のデータ処理プログラムであって、
前記データ処理管理モジュールは、前記ストリームテーブルを参照し、
前記ストリームテーブルに登録された処理を一つの実行コンテキストで実行することを
特徴とするデータ処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、特定のオペレーティングシステム（ＯＳ）に依存せず、データを処理する方
法に関する。
【背景技術】
【０００２】
近年、コンピュータで取り扱われるマルチメディアデータとして、動画、及び音声等が
様々な用途で利用されている。例えば、テレビ放送等の動画をリアルタイムに動画コーデ
ックで変換してハードディスクに録画するハードディスクレコーダと呼ばれる機器や、Ｄ
ＶＤ等の光ディスクにデジタルデータとして記録されている動画コンテンツデータをビデ
オディスプレイ装置に表示するプレイヤーなどが広く普及している。一般にこれらのコン
テンツ処理では、コンテンツデータを指定されたビットレートで、一定時間内に処理を行
わなければならない。また、様々な装置でこれらのマルチメディアコンテンツを利用でき
るようにするためには、これらの複雑なストリーム処理を実行するプログラムモジュール
を容易に開発できることが重要となる。このため、高性能を実現しやすいＯＳのカーネル
の中でコンテンツ処理を行うプログラムを実行する方式が存在する。ストリームとは、予
め定められた順序で一方向に処理されることが必要なデータ列である。例えば、音声デー
タのデータ列や動画データのデータ列などがある。ストリーム処理はこれらのストリーム
に含まれるデータを処理することを指す。
【０００３】
一般的なＯＳには、アプリケーションを実行するための空間であるユーザ空間と、ＯＳ
の機能を実行するための空間であるカーネル空間の２つが存在する。カーネル空間で処理
を行う場合は、高速な実行が可能となるが、カーネル空間で実行されるプログラムは、基
本的にそのカーネルが実装されているＯＳの仕様に大きく依存する。これは例えば、機能
を利用する際に利用するインタフェースがＯＳ毎に異なることや、ＯＳによって機能の利
用手順が異なることによる。これはデバイスを利用するためのデバイスドライバがプラッ
トホームに特有となり、流用できないということでも知られている。また、カーネル空間
での処理を実行する方法として、フィルタと呼ばれるデータを処理するデバイスドライバ
を複数連結することでコンテンツ処理を行う方法がある（例えば、特許文献１）。
【０００４】
これは、ユーザ空間で実行されるアプリケーションプログラムからカーネル空間内にフ
ィルタと呼ばれるソフトウェアモジュールを生成し、複数のフィルタの入出力を接続して
コンテンツデータの流路を構築した後、アプリケーションプログラムから処理開始、停止
などを要求することで、コンテンツの処理を実行する方法である。ここで、フィルタやデ
バイスドライバはデバイスやデータ形式に特化されたモジュールで、それぞれが入出力や
制御のためのインタフェースを持っており、それぞれのフィルタが処理したデータを他の
フィルタに渡すことでデータを処理するものである。この方式は、全てのフィルタがＯＳ
のカーネル部で動作するため高性能を実現できる。しかしながら、該方式では、複数のコ
ンテンツ処理を行った場合の優先処理が考慮されていない。例えば、複数のコンテンツを
処理において、録画と再生を同時に行う場合に、録画の優先度を高くしたいという要求が
発生することが考えられるが、これに対応することは困難である。
【０００５】
【特許文献１】特開平１０−２８３１９５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
先に述べたように、従来の方法ではストリームを取り扱うための実装を、性能を保証し
やすいドライバとしてＯＳのカーネル空間で実装するものがあった。これはＯＳやハード
ウェア構成（以下、本組み合わせをプラットホームと呼ぶ）への依存性が高く、プログラ
ムは異なったプラットホームに対応することができず、各プラットホームは、それぞれ固
有のコンテンツデータ処理方法を有することとなるため、コンテンツ処理をするプログラ
ムの開発はプラットホーム毎に行う必要が生じ、開発工程の増大を招くという第１の問題
があった。
【０００７】
また特許文献１では、コンテンツ処理において管理機能が存在しないので、例えば複数
のコンテンツを同時に処理する場合、それぞれの処理の優先度を指定することが不可能で
あった。例えば、あるデバイスからデータを取得してストレージに記録する処理と、ある
デバイスからデータを取得してディスプレイに表示する処理の２つの処理を同時に行う場
合、例えば前者の処理を優先的に行いたい場合でも、これらの処理を統括して管理する機
能が存在しないので、双方の処理の優先順位を適切に変更することが困難という第２の問
題があった。
【０００８】
さらに、上記の場合、複数のコンテンツ処理が独自の実装に基づいて処理を進めた場合
に、ハードウェア資源の適切な管理や割り振りがなされていないため、処理に必要なＣＰ
Ｕリソースの不足が発生するという第３の問題点もあった。
【０００９】
本発明は、上記課題のうち少なくともひとつの課題を解決するものである。
【課題を解決するための手段】
【００１０】
上記第１の課題を解決すべく、本発明では、様々なプラットホームに対応可能なマルチ
メディアコンテンツ処理手段を提供する。
【００１１】
本発明ではマルチメディアコンテンツの処理を、プラットホーム毎の差異を吸収して汎
用化したインタフェースを上位に提供するレイヤを備えることで、上位のソフトウェアモ
ジュールをプラットホームに依存しない構成を実現する。
【００１２】
上記第２乃至第３の課題を解決すべく、本発明では、複数のストリーム処理を１つの実
行コンテキスト、例えば、プロセスやスレッドを用いて実行し、コンテンツ処理それぞれ
の処理に対してどれだけのリソースを割り当てるかを一元的に管理することで、処理の優
先処理やリソースの管理を実現する。
【発明の効果】
【００１３】
本発明によれば、コンテンツデータを利用するプログラムを、異なったプラットホーム
で利用することが可能となる。また、複数のコンテンツ処理の実行を管理することが可能
となり、使用リソース量の低減を可能とする。
【発明を実施するための最良の形態】
【００１４】
以下に本発明の実施の形態について説明する。
【実施例１】
【００１５】
図１を用いて、本発明における処理フローの概要を説明する。これは、動画コンテンツ
として、ディスク（１０１）から動画データを取得して、これをディスプレイ（１７１）
及びスピーカ（１８１）で再生する処理を示したものである。これらの処理はデバイス（
１０１）からデータを取得する処理ポイント（１００）、音声データと映像データを分離
する処理ポイント（１２０）、映像を映像デコーダ（１７０）に出力する処理ポイント（
１５０）、及び音声を音声デコーダ（１８０）出力する処理ポイント（１６０）からなる
。処理ポイントとは、処理フローを実現するプログラム中において所定の処理を実行する
ために必要な部分である。この処理ポイントにおいて処理を実行するソフトウェアモジュ
ールを、ピアモジュールと呼ぶ。ピアモジュールの詳細な構成については図１６を用いて
後述する。さらに、リンクモジュールは、これらピアモジュールを相互に接続し、例えば
、リンクモジュール（１１０）はピアモジュール（１００）とピアモジュール（１２０）
を接続する。リンクモジュールは接続されたピアモジュールの一方から、もう一方へデー
タを送出する機能を持つ。これにより、ピアモジュール（１００）が取得したデータがリ
ンクモジュール、や他のピアモジュールを通じて、映像デコーダ（１７０）と、音声デコ
ーダ（１８０）に送られることで、映像がディスプレイ（１７１）に表示され、音声がス
ピーカ（１８０）から再生される。
【００１６】
図２は、本実施例におけるソフトウェア構成を示した図である。本構成（２１０）では
、ピアモジュールを相互に連結させたストリーム処理の制御をするストリームマネジャ（
２３０）、データの変換等を行うデータ処理モジュール（２４１）を管理するデータ処理
モジュールマネジャ（２３０）を備える。ストリームマネジャは、ピアモジュールを管理
、操作するピアモジュールマネジャ（２３１）と、実行スケジュールに従ってピアモジュ
ールの処理を実行するために用いるピアモジュールスケジューラ（２３３）、および、ピ
アモジュールを相互に接続するためのリンクモジュールを記録管理するリンクモジュール
マネージャ（２３２）から構成される。
【００１７】
さらに、ＯＳが持つ機能を利用するためにＯＳが提供するシステムインタフェース（２
８０）を介してメモリ管理、スレッド管理、及び時間操作などのリソース管理機能を利用
するための汎用システムインタフェース（２６０）、デバイスへのアクセスを行いデータ
の取得やデバイスの制御を行うデータアクセスモジュール（２７１）を管理するデータア
クセスモジュールマネジャ（２７０）を備えている。
【００１８】
アプリケーション（２００）は、制御インタフェース（２４０）を用いてストリームマ
ネジャおよびデータ処理モジュールマネジャを制御し、所望のストリーム処理を指示可能
である。指示可能な制御については図５を用いて後述する。
【００１９】
上記汎用システムインタフェース（２６０）およびデータアクセスモジュールマネジャ
（２７０）を含むレイヤによってインタフェースレイヤ（２５０）が形成される。このイ
ンタフェースレイヤはＯＳが提供するシステムインタフェース（２８０）で提供される機
能を、汎用化されたインタフェースで上位のレイヤに提供する。この汎用化されたインタ
フェースは、プラットフォームの差異から生じるプロトコルや命令方式の差異を共通化し
て上位レイヤに提供するものであり、例えば、ネットワーク通信を行う際に利用するソケ
ットインターフェイスが存在する。このインタフェースによって実行される機能はプラッ
トフォームが異なっても同じであるが、これを利用するための手順がプラットホーム毎に
異なる。例えば、Linuxを含む一般的なUnix（登録商標）ではTCPで通信するソケットを作
成する際には、socket関数、bind関数、listen関数、そしてaccept関数を順番に実行すれ
ばよい。一方Windows（登録商標）では、別の仕様に準じた、Linuxとは違った手順が必要
である。これらを、従来のようにアプリケーションプログラム側の処理で対応すると、使
用するプラットホーム毎にプラットホームで手順の異なる処理を全て変更する必要が生じ
する。そこで、汎用インタフェースでは、例えばサーバソケットを指定したポートで作成
するという処理を行うための汎用関数としてmakeServerTCPsockのような汎用化されたイ
ンタフェースを提供する。例えば、Linux用の汎用システムインタフェースでは、このmak
eServerTCPsock関数では前述したLinuxでの手順で処理を実行するようにする。一方Windo
ws版の汎用システムインタフェースでは、Windowsでの手順で処理を実行するようにする
。次に、本願のソフトウェアモジュールをLinuxで利用する場合はLinux用の汎用システム
インタフェースを使い、Windowsで利用する場合はWindows用の汎用システムインタフェー
スを使用する。次に、アプリケーションプログラムでは、ソケットを作成する場合には、
makeServerTCPSockを呼び出せば、該汎用システムインタフェースが、そのプラットホー
ムに応じた手続を実行するので、アプリケーションをプラットホーム毎に変更する必要が
無くなる。このような方法により、プラットホームが提供する機能やデバイスへのアクセ
ス方法を汎用化することが可能になる。このように、異なるプラットホームに図２のソフ
トウェアモジュールを移行した場合、レイヤ（２５０）に含まれるソフトウェアモジュー
ルのうち、プラットホームによって異なる機能や、利用手順などを利用する部分は前述し
たように処理方法の変更が必要だが、これより上位のレイヤ、つまり制御インタフェース
（２２０）、データ処理モジュールマネージャ（２４０）、ストリームマネージャ（２３
０）及びアプリケーション（２００）はプログラムの処理を変更すること無く他のＯＳ上
に移行することが可能となる。
図１６、図１７、および図１８を用いて、図１で説明した処理を、図２の構成でどのよう
にして実現するかを説明する。
【００２０】
図１８は、ストリーム処理の構成を記録するテーブル（２０００）を示したもので、ス
トリームマネージャによって管理される。該テーブルの１つの行が１つのストリーム処理
に該当する。ストリーム処理は、ストリーム処理ＩＤ（２００１）、これを構成するピア
モジュールのピアモジュールＩＤ（２００２）、これを構成するリンクモジュールのリン
クモジュールＩＤ（２００３）、および、ストリーム処理の状態（２００４）からなる。
【００２１】
図１６は、ピアモジュールの構成を記録するテーブル（１８００）を示したもので、ピ
アモジュールマネージャによって管理される。該テーブルの１つの行が１つのピアモジュ
ールに該当する。一つのピアモジュールは、ピアモジュールＩＤ（１８０１）、ストリー
ム処理ＩＤ（１８０２）、データ処理モジュールＩＤ（１８０３）、データアクセスモジ
ュールＩＤ（１８０４）、入力リンクモジュールＩＤ（１８０５）、出力リンクモジュー
ルＩＤ（１８０６）、実行待ちデータオブジェクト行列（１８０７）、及び、後処理待ち
データオブジェクト行列（１８０８）からなる。実行待ちデータオブジェクト行列（１８
０７）および、後処理待ちデータオブジェクト行列（１８０８）はデータを、入出力可能
な行列であり、配列、キュー、ハッシュテーブルあるいはリスト等で実装される。図には
行列がそのテーブル内に存在するか否かを示す例について記載したが、ピアモジュールマ
ネージャ内に行列が存在する場合、その存在するアドレスを列（１８０７）、（１８０８
）で記録してもよい。リンクモジュールＩＤの−１という値は、ピアモジュール（１００
）にリンクモジュールが接続されていないことを示す。
【００２２】
図１７は、リンクモジュールの構成を記録するテーブル（１９００）を示したもので、
リンクモジュールマネージャによって管理される。該テーブルの１つの行が１つのリンク
モジュールに該当する。１つのリンクモジュールは、リンクモジュールＩＤ（１９０１）
、ストリーム処理ＩＤ（１９０２）、始点ピアモジュールＩＤ（１９０３）、終点ピアモ
ジュールＩＤ（１９０４）及びバッファ行列（１９０５）からなる。バッファ行列（１９
０５）はデータを、入出力可能な行列であり、配列、キュー、ハッシュテーブルあるいは
リスト等で実装される。図には行列がそのテーブル内に存在するか否かを示す例について
記載したが、リンクモジュールマネージャ内に行列が存在する場合、その存在するアドレ
スを列（１９０５）に記録してもよい。
【００２３】
図３には、本実施例を実施するために用いられるハードウェア構成が示されている。Ｃ
ＰＵ（３００）、ＲＡＭ（３１０）あるいはＲＯＭ（３２０）等のメモリ、クロック（３
３０）、HDD等のディスク装置（３５０）、コンテンツデータの放送を受信するためのチ
ューナ（３６０）、マルチメディアデータを符号化／復号化するためのマルチメディアコ
ーデックプロセッサ（３７０）、およびスピーカ内蔵のテレビ受信機等のディスプレイ（
３８０）がシステムバス（３４０）により接続されている。なお、図２におけるソフトウ
ェアモジュールは、メモリにロードされＣＰＵで実行される。また、本ハードウェア構成
は、例えば、ＨＤＤレコーダ、ＤＶＤレコーダ、ＰＣ、あるいは監視カメラ等で用いられ
る。
【００２４】
図５に、本実施例のアプリケーションがストリームマネージャ（２３０）へ指示を出す
ために、制御インタフェースに発行する命令の例を示した。図５にはストリームマネージ
ャ（２３０）への命令種別（５０１）とそのパラメタ（５０２）と戻り値（５０３）が定
義されている。これらの制御インタフェースは、例えば本実施例がＣやＣ＋＋等のプログ
ラミング言語で開発された場合は関数やモジュールとして実現されるものである。
【００２５】
なお、上記データアクセスモジュールＩＤ、データ処理モジュールＩＤ、図５で規定し
命令を用いてデータ処理フローを生成し、処理を開始することが可能である。詳細につい
ては、図７を用いて後述する。
【００２６】
図５を用い、データの処理フローを作成、制御する命令について説明する。例えば、ス
トリーム処理生成命令（５００）を実行するとストリーム処理が生成する。具体的には、
一意なストリーム処理ＩＤが割り当てられて、図１８（２０００）の使用されていない１
つの行に、ストリーム処理ＩＤが記録され、ストリーム処理が生成する。その値が戻り値
として返される。ここでは１が、アプリケーションに返されたとする。
【００２７】
次に、アプリケーションは、このストリーム処理ＩＤを用いて、ピアモジュール生成命
令（５２０）を実行すると、ピアモジュールを生成する。具体的には、新たに一意なピア
モジュールＩＤを生成し、図１６（１８００）の使用されていない１つの行に、ピアモジ
ュールＩＤが記録され、パラメタとして渡されたストリーム処理ＩＤを記録し、テーブル
（２０００）にパラメタとして指定されたストリーム処理ＩＤに該当するストリーム処理
のピアモジュールＩＤ（２００２）の欄にピアモジュールＩＤを記録することでピアモジ
ュールを生成する。割り当てられたピアモジュールＩＤは戻り値としてアプリケーション
に返される。ここでは１００が返されたとする。
【００２８】
次いで、同様にして（図１６の１８２０で示される）別のピアモジュール（１２０）を
生成する。該ピアモジュールのモジュールＩＤは１２０とする。次に、リンクモジュール
生成命令（５４０）を用いることで、これらのピアモジュールをリンクモジュールで結合
する。具体的には、新たに一意なリンクモジュールＩＤが割り当てられて、図１７（１９
００）の使用していない１つの行にリンクモジュールＩＤを記録し、始点ピアモジュール
ＩＤ、および終点ピアモジュールＩＤとしては、パラメタとして渡された値がそれぞれ記
録される。例ではそれぞれ、１００と１２０である。次に、表（１８００）のピアモジュ
ールＩＤが１００である行（１８１０）の出力リンクモジュールＩＤに１１０を、次にピ
アモジュールＩＤが１２０である行（１８２０）の入力リンクモジュールＩＤに１１０を
記録する。次に、表（２０００）のストリーム処理ＩＤが１である行（２０１０）のリン
クモジュールＩＤ（２００３）にリンクモジュールＩＤを登録する。これらの処理により
、ピアモジュール間を結合するためのリンクモジュールの生成と設定が終了する。
【００２９】
次に、ピアモジュールでどのような処理を行うかを、データ処理モジュール制御命令（
５６０）と、データアクセス制御命令（５７０）を用いて設定する。データ処理モジュー
ル制御命令（５６０）のパラメタ中のデータ処理モジュールＩＤの詳細については図１４
を用いて、データアクセスモジュール制御命令のパラメタ中のデータアクセスモジュール
ＩＤについては図１３を用いて後述する。例えば、ピアモジュールＩＤが１００のピアモ
ジュールに対して、データアクセスモジュールＩＤが１の処理を割り当てる場合は、デー
タアクセスモジュール制御命令（５７０）を用いる。これにより、表（１８００）のピア
モジュールＩＤが１００の行のデータアクセスモジュールＩＤ（１８０４）にデータアク
セスモジュールＩＤの１が記録される。データ処理モジュールに関しても同様に、データ
処理モジュール制御命令（５６０）を利用して設定する。データ処理モジュールと、デー
タアクセスモジュールの詳細については図４で後述する。
【００３０】
さらに、５８０のデータ処理制御コマンド命令を用いた場合、パラメタ中の「コマンド
」を使用してデータ処理モジュールの制御や設定を行うことが可能である。例えば、ネッ
トワークの処理を行うデータ処理モジュールの場合、「パケットサイズ設定コマンド」を
使って、データ処理モジュールにおけるパケットサイズを変更処理の設定可能である。ま
た、データアクセスモジュール制御命令（５７０）は、例えばファイルからデータを読み
出す場合はそのファイル名を指定したり、ネットワークからデータを入出力する場合はポ
ート番号を指定する際にも使用できる。
【００３１】
データ処理の実行は、開始コマンドや停止コマンドを発行するデータ処理コマンド命令
（５８０）を用いて制御され、ストリーム処理に関係づけられた各ピアモジュールのスケ
ジューリングを制御することができる。これは、ストリーム処理がテーブル（２０００）
にストリーム処理に関係する、リンクモジュールとピアモジュールが登録されているので
、ストリーム処理ＩＤを指定すれば、関係するリンクモジュールとピアモジュールの全て
の設定や動作を変更することが可能である。
【００３２】
アプリケーションはイベント管理命令（５９０）を介してデータ処理モジュール（４０
１）と通信することができ、エラーなどのイベントを渡したり、データ処理を終了させた
りすることができる。データ処理は、ストリーム処理破棄命令（５１０）によって破棄、
終了したり、ピアモジュール破棄命令もしくはリンクモジュール破棄命令（５３０、５５
０）をそれぞれ使って選択的に破棄することもできる。この場合の破棄とは登録されてい
るテーブルの内容を消去が該当する。
【００３３】
図１３にデータアクセスモジュールＩＤとそのデータアクセスモジュールの対応を管理
するテーブル（１３００）を示した。該テーブルはデータアクセスモジュールマネージャ
（２７０）内に存在する。該テーブル（１３００）にはデータアクセスモジュールＩＤ（
１３０１）と、これに対応する入出力実行処理部へのアドレス（１３０２）と、入出力完
了処理部へのアドレス（１３０３）、及びその機能概要の記述（１３０４、１３０５）が
記録されている。図に示した例では、データアクセスモジュールＩＤが１の場合は（１３
１０）、０ｘＦ９８００００００番地に存在する「ハードディスクへのデータ読込要求発
行」する機能を有する入出力実行処理部と、０ｘＦ９８０８０００番地に存在する「ハー
ドディスクからのデータの取得」する機能を有する入出力完了処理部が記録されている。
【００３４】
データアクセスモジュールＩＤとそのモジュールが実際に行う処理の対応については、
例えば、マニュアル等に記載されており、使用者は必要な機能を実現するデータアクセス
モジュールＩＤを得る。あるいは、機能の欄（１３０４、１３０５）に記述されている内
容から必要なものを選択する。
【００３５】
図１４にはデータ処理モジュールＩＤとそのデータ処理モジュールの対応を管理するテ
ーブルを示した。該テーブルはデータ処理モジュールマネージャ（２４０）内に存在する
。該テーブル（１５００）にはデータ処理モジュールＩＤ（１５０１）と、これに対応す
る前処理部へのアドレス（１５０２）と、後処理部へのアドレス（１５０３）、及びそれ
ら機能の記述が記録されている。図に示した例では、データ処理モジュールＩＤが１００
の場合は（１５１０）、０ｘＦＡ８００００００番地に存在する「指定されたファイルの
読込を指示。次のスケジューリング時間を指定」する機能を有する前処理部と、０ｘＦＡ
８０８０００番地に存在する「取得したデータを出力リンクに出力」する機能を有する後
処理部が記録されている。データ処理モジュールＩＤとそのモジュールが実際に行う処理
の対応については、例えばマニュアルに記載されており、使用者は必要な機能を実現する
データ処理モジュールＩＤを得る。あるいは、機能の欄（１５０４、１５０５）に記述さ
れている内容から必要なものを選択する。
【００３６】
図１５に、図１で示したデータ処理を行うために、アプリケーションが図５で示した命
令を利用して、ピアモジュールとリンクモジュールを結合しデータ処理プログラムを構築
する手順を示した。
【００３７】
最初に、アプリケーションはストリーム処理生成命令（５００）を利用してデータ処理
フローを生成し（ステップ１５００）、ストリーム処理ＩＤを得る。
【００３８】
次に、該ストリーム処理ＩＤを使用して、ファイル読出しピアモジュールを、ピアモジ
ュール生成命令（５２０）を利用して生成し、ピアモジュールＩＤを得る。次にファイル
読み出しピアモジュールにデータ処理モジュールをデータ処理モジュール制御命令（５６
０）にデータ処理モジュールＩＤを用いて割り当て（ステップ１５１１）、データアクセ
スモジュールをデータアクセスモジュール制御命令（５７０）にデータアクセスモジュー
ルＩＤを用いて割り当てる（ステップ１５１２）。同様に、マルチプレクサピアモジュー
ルを作成し（ステップ１５２０）、データ処理モジュールを割り当てる（ステップ１５２
１）。以下、同様にして、映像ピアモジュールを作成し（ステップ１５３０）、データ処
理モジュールと、データアクセスモジュールの割当を行い（ステップ１５３１，１５３２
）、音声ピアモジュールを作成し（ステップ１５４０）、データ処理モジュールと、デー
タアクセスモジュールを割り当てる（ステップ１５４１，１５４２）。次に、ファイル読
み出しピアモジュールからマルチプレクサピアモジュールを接続するリンクモジュールを
リンクモジュール生成命令（５４０）を使用して作成し（ステップ１５５０）リンクモジ
ュールＩＤを得、同様にマルチプレクサピアモジュールから映像ピアモジュールを接続す
るリンクモジュール、音声ピアを接続するリンクモジュールを作成する（ステップ１５６
０，１５７０）。このようにアプリケーションから処理することで、使用するピアモジュ
ールが相互に関係づけられ、処理に使用するデータ処理モジュールとデータアクセスモジ
ュールが割り当てられる。
【００３９】
このように、ピアモジュール、リンクモジュール等の生成、設定は、アプリケーション
が制御命令を経由して行う。アプリケーションから実行される命令に基づき、必要なピア
モジュールを生成し、リンクモジュールを用いてこれらのピアモジュールを接続してデー
タ処理フローを作成した上で、ビットレートなどの処理に必要な情報、処理に必要なデー
タアクセスモジュール及びデータ処理モジュールをピアモジュールに設定し、データ処理
の開始を指示することで、所定の処理を実行することが可能となる。
【００４０】
このような機能が提供されることで、ストリーム処理を行うアプリケーションの記述は
大幅に削減される。なぜなら、ストリーム処理は定められたビットレートでデータを処理
することが重要なリアルタイム性が高い処理であるため、そのような処理を実現するプロ
グラムの開発はプラットホームが提供する機能例えば時間管理等を使い、ＣＰＵ時間を一
部の処理が占有し処理の流れが滞らないようにする等の高度なスケジューリング技術が必
要となるが、本実施例の手法を用いれば、スケジューリングはストリームマネージャが行
うため、ストリームマネージャを利用するアプリケーションは、ピアモジュールの生成と
、リンクモジュールを関係づけ、必要なデータアクセスモジュールとデータ処理モジュー
ルを作成し、これをピアモジュールに関係づければよく、上記のスケジューリング機能に
ついては実装する必要が無いからである。
【００４１】
またこれらのモジュールはストリームマネージャが提供するプラットホームに非依存の
インタフェースを利用するだけで良いのでアプリケーションは、どのようなプラットホー
ムでも変更せずに利用することが可能となる。
【００４２】
図４は図１６を用いて説明したピアモジュールの論理的な構成を示した図である。ピア
モジュール（４００）は、データフォーマットに依存したデータ処理を実行するデータ処
理モジュール（４０１）と、ＯＳのシステムインタフェース（２８０）を介し、特定のハ
ードウェア装置を用いデータ処理を実行するデータアクセスモジュール（４０５）を備え
る。ピアモジュールは、ストリームマネージャ内でピアモジュール固有の識別子（ピアモ
ジュールＩＤ）で識別される。
【００４３】
データ処理モジュール（４０１）は固有の識別子（データ処理モジュールＩＤ）で識別
され、さらに前処理部（４０２）と後処理部（４０３）を備える。どのピアモジュールに
どのデータ処理モジュールが関係づけられているかはテーブル（１８００）の列（１８０
３）に記録されている。データアクセスモジュール（４０５）も、固有の識別子（データ
アクセスモジュールＩＤ）で識別され、入出力実行処理部（４０６）と入出力完了処理部
（４０７）を備える。どのピアモジュールにどのデータアクセスモジュールが関係づけら
れているかはテーブル（１８００）の列（１８０４）に記録されている。
【００４４】
ピアモジュールは、リンクモジュール（４１０、４２０）で、他のピアモジュールと連
結される。リンクモジュールは、バッファ行列（４１１）を備える。リンクモジュール（
４１０）がデータ処理モジュールの入力側に接続される場合は、該リンクモジュール内の
バッファに格納されるデータは、データ処理モジュールの前処理部へ出力可能である。デ
ータ処理モジュールの出力側に接続される出力リンクモジュール（４２０）の場合には、
該リンクモジュール内のバッファに格納されるデータは、データ処理モジュールの後処理
部から入力可能である。
【００４５】
例えば、他のピアモジュールで処理されたデータがバッファに書き込まれて入力リンク
モジュール（４１０）に入力される。このデータは前処理部（４０２）が受け取り、該前
処理部によって、データオブジェクト（４０８）に変換されて、実行待ちデータオブジェ
クト行列（４１２）に入れられる。これをデータアクセスモジュール（４０５）が取得し
、処理する。データオブジェクト（４０８）の詳細については図１２を用いて後述する。
【００４６】
データアクセスモジュールは、ＯＳ内のシステムインタフェース（２８０）を介してデ
バイスドライバ（４３０）にアクセスし、ハードウェアデバイス（４４０）とデータの入
出力を行う。データアクセスモジュールの入出力実行処理部（４０６）は、データの入出
力要求、あるいは前処理部から渡されたデータに対する処理を行う。処理としては、例え
ば、ハードウェアデバイス（４４０）に格納されたファイルの読込などの指示や、データ
オブジェクト中のデータ（４０８）の暗号処理用ハードウェアにおける暗号化処理の指示
等のデータ変換処理等が考えられる。処理結果は、入出力完了処理部（４０７）が取得し
、データオブジェクト（４０９）として、後処理待ち処理オブジェクト行列（４１３）に
入力する。後処理部は後処理待ち処理オブジェクト行列（４１３）から取り出したデータ
オブジェクト中のデータを出力リンクモジュール（４０２）に出力して、ピアモジュール
のデータ処理を終える。
【００４７】
これらの動作は、ピアモジュールスケジューラ（２３３）が、テーブル（１８００）と
テーブル（１９００）を参照しながら実行する。実行のタイミングは図１１のスケジュー
リングテーブル（１１００）に記された情報に従って実行する。図１１の詳細は後述する
。
【００４８】
また、ピアモジュールは一つ以上の入力リンクモジュールならびに一つ以上の出力リン
クモジュールに連結され、該リンクモジュールを介して２つ以上のピアモジュールが連結
されることで一連のデータ処理フローを実現することができる。これにより、複数のピア
モジュールからのデータを単一のピアモジュールに集めて複数のデータを多重化したり、
単一のデータフローを複数の異なるピアモジュールへ送出することも可能である。これは
、例えば、図１で示したような多重化されたデータの分離、あるいは複数のデータの多重
化などに利用できる。
【００４９】
データアクセスモジュールの入出力処理実行部（４０６）、及び入出力完了処理部（４
０７）はプラットホームに備えられたハードウェアデバイスが異なるとその実現方式が変
わり得る。該データアクセスモジュールを修正することで、データアクセスモジュールよ
りも上位レイヤのモジュールは、システムインタフェースに依存せずに、処理を実行する
ことが可能となる。
【００５０】
図１２にデータオブジェクトの構成を示した。データオブジェクト（１２００）は、デ
ータリスト（１２１０）、コマンドコード（１２１２）及びコマンド引数（１２１３）か
らなる。データリストはさらに、データへのアドレス（１２２１）とデータのサイズ（１
２２２）がリストとして格納されている。データオブジェクトは、処理すべきデータをデ
ータリスト（１２１０）で保持し、さらにそのデータに対するコマンド（１２１１）とパ
ラメタ（１２１３）が記録されたものである。必ずしもコマンドとデータが対になって記
録されている必要は無く、データは空で、コマンドだけが格納されていても良いし、逆に
データだけが格納されていても良い。
【００５１】
図１１にピアモジュールスケジューラ内のスケジュールテーブルの構成を示した。スケ
ジュールテーブル（１１００）はピアモジュールスケジューラがどのピアモジュールをい
つ実行するかを管理する。該テーブルには、スケジュール時刻（１１０１）とピアモジュ
ールＩＤ（１１０２）を項目として有している。ここで、テーブル（１１００）中のスケ
ジュール時刻とは、あるピアモジュールに関連付けられたデータアクセスモジュールとデ
ータ処理モジュールの処理を、次に実行する予約時刻のことである。また、スケジュール
とは複数の処理を行わなければならない場合、どのような順番でどの処理をいつ行うかを
決定し、記録することである。またスケジュール実行、あるいはスケジューリングとは、
予め定められたスケジュールに従って処理を実行することを指す。
【００５２】
図１１の例では、例えば時刻２５０ミリ秒においてピアモジュールＩＤが１０および１
３のピアモジュールが実行されることが行１１１０、１１２０に示されている。つまり、
同一の時刻に実行されるべきピアモジュールが複数存在しても良い。ただし、スケジュー
ル時間は同一時間であっても、実際の処理は、一方の処理が完了した直後にもう一方の処
理が行われてもよい。
【００５３】
本実施例では、該スケジュールテーブルに記録された内容に準じて処理を実行するのは
、ピアモジュールスケジューラである。つまり、上述した処理は前述のタイミングで、ピ
アモジュールスケジューラがテーブル（１８００）、テーブル（１９００）、およびテー
ブル（２０００）を参照しながら必要な処理を順次行う。つまり、各ピアモジュールのデ
ータ処理モジュールとデータアクセスモジュールの処理はピアモジュールスケジューラが
実行する。これは言い換えれば、スレッドのような一つの実行コンテキストで、ピアモジ
ュールピアモジュールスケジューラの処理、前処理部、後処理部、入出力実行処理部、及
び入出力完了処理部の処理を行うということである。
【００５４】
ピアモジュールスケジューラは、例えば、定期的に起動され、該テーブルを参照し、現
在の時刻と比較してそれよりも以前のスケジュール時刻が設定されたピアモジュールがあ
れば、このピアモジュールの処理を行い、必要があればテーブル（１１００）を更新し、
次の起動を待つ。
【００５５】
ピアモジュールの実行手順について、図６を用いて説明する。
【００５６】
まず、ピアモジュールスケジューラは、既に処理が開始されているストリーム処理が存
在するかどうかをストリームテーブル（２０００）の列（２００４）を参照して確認する
（ステップ６００）。開始されているストリーム処理が存在しない場合、新たにストリー
ム処理が実行されるまで待つ（ステップ６０１）。開始されたストリーム処理が存在する
場合は、スケジュールテーブル（１１１０）を参照し、現在時刻を起点にして最も早く実
行されるスケジュール時刻まで待つ（ステップ６０３）。時刻を待つ方式は、時計を周期
的に見て判断しても良いし、指定時間だけ実行を停止する機能を使用しても良いし、時間
割込の利用できるプラットホームであればこれを利用しても良い。ストリーム処理が開始
された直後は、まだピアモジュールによって処理開始時刻がスケジュールマネージャに予
約されていないので、そのストリーム処理を構成するピアモジュールのスケジュール時刻
として現在の時刻を、ストリームマネージャが登録することで最初の実行が行われるよう
にする。待機動作が完了すると、スケジュールテーブル（１１００）のピアモジュールＩ
Ｄ（１１０２）に記載されたピアモジュールのデータ処理モジュールの前処理部をピアモ
ジュールスケジューラが実行する（ステップ６０４）。この実行処理において、前処理部
は、入力リンクモジュールにデータが存在しているかを確認し、存在すればこれをデータ
オブジェクトに変換し、実行待ちデータオブジェクト行列（４１２）に入力する。あるい
は図１のデータをハードディスクから読み出すピアモジュールのような、ストリーム処理
の始点となるピアモジュールでは、データの読み出し要求をデータオブジェクトとして該
行列に入力する。
【００５７】
次に、自モジュールが次にスケジュールされるべき時刻を算出し、ピアモジュールスケ
ジューラに該時刻を登録する（ステップ６０５）。次のスケジュール時間を前処理部（４
０２）が定める理由は、リンクモジュール（４１０）から得られたデータ（４１１）のサ
イズ等、処理に必要な時間を算出できるのが前処理部だからである。例えば図１のピアモ
ジュール（１００）のようなファイルを読み出すピアモジュールに、例えばビットレート
が１秒当たり１０２４キロバイトで、一度に読み込むデータブロックのサイズが２５６キ
ロバイトに設定されていたとする。この指定はデータ処理コマンド命令（５８０）を使用
してアプリケーションから指定される。このような場合、ファイルの読込のピアはであっ
たとすると、（一度に読み込むデータブロックサイズ）／（ビットレート）で定められる
値で読込の時間間隔が決定できる。例えば、毎秒１０２４キロバイトでブロックサイズが
２５６キロバイトであるなら、読込は０．２５秒毎で行えば指定されたビットレートが実
現できることが判る。つまり、２５６キロバイトのデータ要求を前処理部が入出力処理部
に行った後は、次の処理は０．２５秒後に行えば良いことになるので、次回のスケジュー
リング時間は２５０ミリ秒後と定まる。
【００５８】
それよりも下流にあるピアモジュール、図１０におけるデマルチプレクサピアモジュー
ルや映像ピアモジュールにおいては、これらのスケジューリング時間は、同様な方法で設
定されたビットレートとリンクモジュール経由で得られたデータのサイズから決めても良
いが、比較的短い時間をスケジューリング時間に設定しで、頻繁に実行された方が良い。
なぜならば、データのビットレートは最上流のファイル読み出しピアが前述の方法で制御
しているので、それより下位のピアモジュールでは、特にビットレートを制御せずに、デ
ータが入力リンクオブジェクトに入力されたら、これをすぐに取り出して処理を行い、出
力リンクモジュールに出力すれば、定められたビットレートが実現できるからである。こ
の場合、下流のピアオブジェクトでは、処理の遅延が起ってビットレートが低下しないよ
うにするために、頻繁にリンクオブジェクトにデータが入力されたかを確認する方が良い
。このためには、スケジューリング時間は小さな値を予約するべきである。
【００５９】
前処理部からデータアクセスモジュールにデータオブジェクトが出力された場合（ステ
ップ６０６）、ピアモジュールスケジューラが、該データオブジェクトに指示された処理
を開始するためにデータアクセスモジュールの入出力実行処理部を実行する（ステップ６
０７）これは例えば、データの加工や取得をハードウェアデバイスに要求する作業が該当
する。
【００６０】
実行待ちデータオブジェクト行列にデータアクセスモジュールが無く、かつデータアク
セスモジュールからデータオブジェクトが新たに後処理待ちデータ処理行列に出力されて
いない場合、ピアモジュールスケジューラはステップ６１１に進む（ステップ６０８）。
【００６１】
以前に実行された入出力実行処理部の処理が終了して、処理結果としてのデータが存在
する場合、これは、例えば、ハードウェアデバイスに要求していたデータ加工や取得処理
が終了して、その結果としてのデータが存在する場合は、データアクセスモジュールの入
出力完了処理部をピアモジュールスケジューラが実行し（ステップ６０９）、該データを
データオブジェクトとして後処理待ちデータオブジェクト行列（４１３）に入力する（ス
テップ６１０）。データオブジェクトが後処理待ちデータオブジェクト行列（４１３）に
有る場合、ピアモジュールスケジューラが後処理部を実行し、出力リンクモジュールにデ
ータオブジェクト中のデータリストのみを渡す。後処理部の処理が完了した場合、ピアモ
ジュールスケジューラは次のピアモジュールのスケジュールのために開始状態に戻る。
【００６２】
本実行方式では、例えば複数のストリーム処理実行する場合も、各ストリーム処理に存
在するピアモジュールの処理は、ピアモジュールスケジューラの一つの実行コンテキスト
で行うことが可能である。ここで、実行コンテキストとはプログラムを実行する場合に必
要となる情報を持った実行単位のことで、スレッドなどがこれに相当する。なぜならば、
前述した方法を用いることで、例え複数のストリーム処理であっても、各ピアモジュール
の処理をスケジューリングする時刻がそれぞれのピアモジュールから指定されているので
、その時間にピアモジュールスケジューラが実行すれば良いからである。このように１つ
の実行コンテキストで処理すると、複数の実行コンテキストで複数のストリーム処理を処
理したときに生じる同期化処理を行う必要がない。このデバイスへのアクセスを排他的に
行うための同期化処理は負荷が高いため、この処理を省くことでストリーム処理の性能低
下を防止できる。
【００６３】
また、本方式では例えば、実行優先度を上げるのであれば、ピアモジュールの前処理部
で決定するピアモジュールの予約時間をより短くすれば、そのピアモジュールの処理がよ
り早くスケジューリングされることになり、より多くのＣＰＵ時間が該ピアモジュールの
処理に使われることになる。また、複数処理を実行する場合、上記した予約時間を調整す
ることで、それぞれの処理の優先度を指定することが可能となる。例えば、あるデバイス
からデータを取得してストレージに記録する処理と、あるデバイスからデータを取得して
ディスプレイに表示する処理の２つの処理を同時に行う場合、前者の処理の予約時間を短
く設定すれば、記録処理の優先順位を高く設定することが可能となる。
【００６４】
また、複数のデータ処理を１つの実行コンテキストで実行することで、複数の実行コン
テキストに複数のバッファを割り当てる必要が無くなり、また複数コンテキストの並列実
行時に用いられるセマフォのような、複数の実行コンテキストで一つのリソースを利用す
る際に、排他的なアクセスを保証する仕組みである同期機能を用いる必要が無くなり、使
用リソースの低減が可能となる。
【００６５】
また、一つのコンテキストで処理を実行することにより、ピアモジュールスケジューラ
（２３３）は効率のよいスケジューリングを設定することが可能となる。なぜなら、従来
のスケジューリング方式、例えばラウンドロビン方式等では、一定時間毎に無条件に処理
を切り変えるので、処理が必要無い場合でもスケジューリングされてしまうことがあった
り、処理が必要な場合にスケジューリングされないことがあり、リアルタイム性が低下し
、無駄なＣＰＵ時間を消費することになっていた。一方、本方式では、次処理に必要な時
間を算出し、その必要な時間をスケジューリングテーブルに登録してスケジューリングを
行うので余計なスケジューリングが行われず、従来のラウンドロビン方式等における冗長
時間に割り当てられていたＣＰＵ処理を別の処理に振り当てることが可能になるため、全
体としてプラットフォームのリソースの一つであるＣＰＵ時間の使用効率が向上し、さら
に処理の必要な時刻には正しくスケジューリングされるので、リアルタイム性を向上する
ことが可能となる。
【００６６】
図７に、本実施例による、ピアモジュール、リンクモジュール、及びピアモジュールス
ケジューラを使ったデータ処理の一例として、音声と映像が多重化されて記録されている
ファイルをハードディスクから読み込み、これを再び分離して、ディスプレイ、並びにス
ピーカから動画として再生する場合のデータフローについて説明する。音声と映像を多重
化して記録する方式としては、MPEG(Motion Picture Expert Group)等がある。該処理に
おいてファイル読み出しピアモジュール（７００）はデマルチプレクサピアモジュール（
７３０）とリンクモジュール（７２０）で結合され、デマルチプレクサピアモジュール（
７３０）と映像ピアモジュール（７６０）はリンクモジュール（７４０）で接続され、さ
らに音声ピアモジュール（７８０）がリンクモジュール（７５０）で接続されている。
【００６７】
まず、ファイル読み出しピアモジュールはシステムインタフェース（７０９）とデバイ
スドライバ（７１０）を通してハードディスクにアクセスし、データを取得する。デマル
チプレクサピアモジュール（７３０）は、取得したデータの多重化を解除する。この処理
によって得られた映像データは映像ピアモジュール（７６０）に送られてデバイスドライ
バ（７６９）を通してハードウェア映像デコーダ（７７０）に送られ、音声データは音声
ピアモジュール（７８０）に送られてデバイスドライバ（７８９）を通して、ハードウェ
ア音声デコーダ（７９０）に送られて再生される。
【００６８】
図１０には、図７で示した処理例における詳細な構成を示した。これを用いて、処理手
順について説明する。
【００６９】
まず、ピアモジュールスケジューラが、ファイル読み出しピアモジュールのデータ処理
モジュールの実行を開始する。データ処理モジュール（７０１）であるファイル読み出し
モジュールの前処理部（７０２）はデータアクセスモジュール（７０４）であるファイル
アクセスモジュールの入出力実行処理部（７０５）へのファイル読出し入出力処理である
データオブジェクト（７０７）を入出力待ちデータオブジェクト行列に入力することで要
求する。この読出し処理は入出力処理部（７０５）によってシステムインタフェース（７
０９）と記憶装置用アダプタデバイスドライバ（７１０）を経由して処理される。さらに
、当該処理の実行以前に実行された読み込み処理が完了したかどうかを、ピアモジュール
スケジューラがチェックし、処理が完了していれば入出力完了処理部（７０６）が実行さ
れ、該データをデータオブジェクト（７０８）にして後処理待ちデータオブジェクト待ち
行列に入れる。
【００７０】
次に、後処理部（７０３）が実行されると、後処理待ちデータオブジェクト行列に格納
されたデータオブジェクト（７０８）を取得し、該データオブジェクト内のデータリスト
がリンクモジュール（７２０）のバッファ内の待ち行列に入力される。
【００７１】
なお、これらの処理において、各処理は以下のように検索される。ファイル読出しピア
モジュールのピアＩＤは１００であるので、ピアモジュールスケジューラはこの値から、
テーブル（１８００）を参照し、データ処理モジュールとして割り当てられているデータ
処理モジュールＩＤを得る。図１６の例では該番号は１００である。次にテーブル（１５
００）を参照して、データ処理モジュールＩＤが１００の行を検索する。これにより、実
行すべき前処理部が０ｘＦＡ８０００００番地に、実行すべき後処理部が０ｘＦＡ８０８
０００番地に存在することがわかるので、これらを実行する。この場合、本アドレスに格
納されている前処理部の処理の内容は、指定されたファイルの読込を指示した後、次のス
ケジューリング時間を指定する処理であり、後処理部の処理の内容は取得したデータを出
力リンクに出力する処理である。同様にデータアクセスモジュールに関しては、テーブル
（１８００）を参照し、データアクセスモジュールとして割り当てられているデータアク
セスモジュールＩＤを得る。図１６の例では該番号は１である。次にテーブル（１３００
）を参照して、データアクセスモジュールＩＤが１の行を検索する。これにより、実行す
べき入出力実行処理部のアドレスと、入出力完了処理部のアドレスを得て、これらを実行
する。この場合、本アドレスに格納されている入出力実行処理部の処理の内容は、ハード
ディスクへのデータ読込要求発行であり、入出力完了処理部の処理の内容はハードディス
クからのデータの取得処理である。
【００７２】
デマルチプレクサピアモジュール（７３０）のデマルチプレクサ処理モジュール（７３
１）がピアモジュールスケジューラによって実行されると、前処理部（７３２）が実行さ
れ、リンクモジュール（７２０）の待ち行列（７２１）からデータリストを取り出す。待
ち行列にデータが無い場合、前処理部は処理を終了して、後処理部の処理に移る。
【００７３】
なお、上記の前処理部における処理は、データ処理フローにおいて始点から２つ目以降
に接続されたピアモジュールの処理において同様である。また、全てのピアモジュールの
前処理部は、処理を終了する前に、次に自身が実行されるべき時間を予約する。この予約
時間は、該ストリーム処理のビットレートや、要求されるリアルタイム性に依存する。例
えば、高いビットレートのデータ処理、あるいは高いリアルタイム性が要求される処理の
場合は、データを迅速に処理して次のピアモジュールに渡さなければならないので、入力
リンクモジュールのバッファにデータが格納されているか否かの確認を頻繁に行う必要が
ある。逆にビットレートが低ければ、比較的間隔を開けてチェックすることができる。
【００７４】
該デマルチプレクサピアモジュールの処理はデータフォーマットの変換であり、プログ
ラムで実行することで処理可能であり、ＨＤＤ等のＩ／Ｏ系のハードウェアにアクセスす
る必要がないためデータアクセスモジュールが定義する必要はなく、前処理部で処理後の
データは後処理部（７３３）に渡される。この場合のデータフォーマットの変換処理は、
与えられたデータを予めマルチプレクサピアモジュールの前処理部（７３２）が解析し、
その結果を２つの音声バッファと映像バッファに書き込む処理となる。後処理部は、映像
バッファから映像データを取り出し、リンクモジュール（７４０）の待ち行列（７４１）
に入力し、同様に音声バッファから音声データを取り出しリンクモジュール（７５０）の
待ち行列（７５１）に入力する。
【００７５】
次に、映像ピアモジュール（７６０）のデータ処理モジュールである映像書き込みモジ
ュール（７６１）の前処理部（７６２）が実行されると、待ち行列（７４１）に待機して
いるデータリストが取り出される。アプリケーションがデータ処理モジュール制御命令（
５６０）を用いて定めたビットレートに応じて、映像デコーダアクセスモジュール（７６
４）にデータを送り、入出力実行処理部（７６５）によって、該データはハードウェア映
像デコーダ（７７０）のデバイスドライバ（７６９）に出力され、ハードウェア映像デコ
ーダ（７７０）に出力され、その結果として映像が出力される。出力が完了したデータは
データアクセスモジュールである映像デコーダアクセスモジュールの入出力完了処理部（
７６６）によって検出され、データオブジェクト（７６８）として終了処理待ちデータオ
ブジェクト行列に入れられる。映像ピアモジュールはデータ処理の末端であり、出力リン
クモジュールが無いので、デバイスに書き込まれた映像データは後処理部（７６３）によ
り破棄される。
【００７６】
音声ピアモジュール（７８０）における処理も先に説明した映像ピアにおける処理と同
様である。音声ピアのデータ処理モジュールである音声書き込みモジュール（７８１）の
前処理部（７８２）が実行され、待ち行列（７５１）内に待機している音声データリスト
が取り出される。取り出されたデータのビットレートに応じて、データアクセスモジュー
ルである音声デコーダアクセスモジュール（７８４）に送られ、入出力実行処理部（７８
５）によって処理が開始される。音声データは、デバイスドライバ（７８９）を通じてハ
ードウェア音声デコーダ（７９０）に送られ、再生される。出力が完了したデータはデー
タアクセスモジュールの入出力完了処理部（７８６）によって検出され、完了したデータ
はデータオブジェクト（７８８）として後処理待ちデータオブジェクト行列に入れられ、
その後、後処理部（７８３）によって破棄される。
【００７７】
図８は、図２の構成をユーザ空間で実装した例を示している。ユーザ空間で実装する場
合、全てのモジュールがユーザ空間上で実装されるので、開発が容易という効果がある。
なぜなら、アプリケーションプログラムを開発する際に利用される開発ツール、例えばデ
バッガ等が使用できる上に、ＯＳの提供するメモリ管理機能を利用できるので他のアプリ
ケーションからの干渉を防止でき、信頼性、可用性を高めることが可能だからである。
【００７８】
図９は、図２の構成の大部分をＯＳで構成した例を示している。例えば、カーネル空間
で実装する構成の場合、ＯＳ内のモジュールがアプリケーションプログラムより優先的に
実行が行わるＯＳでは、ユーザ空間で実装されるよりも、性能で有利になる。特に、リア
ルタイム性が必要となる高ビットレートでのコンテンツ処理を行う場合には特に有効と考
えられる。
【００７９】
この２つの構成において、プラットホーム依存となるのは汎用システムインタフェース
（９２０，９３１）、及びデータアクセスモジュールマネージャ（９３２）であり、これ
以外の本実施例に属するプログラムモジュールはプラットホームに依存しない。なぜなら
ば、ハードウェアやＯＳの相違により異なるＯＳの機能利用手順や、デバイスのアクセス
方法の差異を該モジュールが吸収して、該モジュール提供する汎用化されたインタフェー
スを利用することでフラットホームが提供する機能を利用することが可能だからである。
【００８０】
なお、いずれの構成を採用するかは、用途、ハードウェア構成、及び開発工数などを考
慮して決められるべきである。例えば、ＣＰＵの性能が低いプラットホームでの実装、あ
るいは高い性能が要求される場合は、デバッグなどは多少困難になるが、高性能を実現す
ることが比較的容易な図９のカーネル空間での実装が考えられる。逆に、ＣＰＵが十分に
早くメモリ等の実行リソースが十分に利用できる場合や、高性能が要求されない場合等は
、実装が容易な図８のユーザ空間のような構成とすることが考えられる。
【産業上の利用可能性】
【００８１】
本技術は、例えば動画や音声処理等のストリーミング処理に利用可能である。例えば、
放送機器、受信機、録画・録音機器、及び監視カメラなどに適用可能である。
【図面の簡単な説明】
【００８２】
【図１】処理ポイント間のデータフローとして構成されたデータ処理の処理フローを示した構成図
【図２】本実施例の要素の全体構成を示した構成図
【図３】ハードウェア構成を示した構成図
【図４】本実施例の処理ポイントの定義を示した構成図
【図５】本実施例の制御インタフェースを示した図
【図６】本実施例の処理ポイントのスケジューリング機能の処理ステップを示したフローチャート
【図７】記憶装置に記憶されハードウェアデコーダを用いて復号化された映像フィルタを提示するためのデータ処理のフローの例を示した構成概要図
【図８】オペレーティングシステムのアプリケーションレベルで実行させるための本実施例の実装形態例を示した構成図
【図９】オペレーティングシステムのカーネルレベルで実行させるための本実施例の実装形態例を示した構成図
【図１０】記憶装置に記憶されハードウェアデコーダを用いて復号化された映像フィルタを提示するためのデータ処理のフローの例を示した構成図
【図１１】スケジュール時間を管理するテーブルの構成を示した図
【図１２】データオブジェクトの構成を示した図
【図１３】データアクセスモジュールＩＤとデータアクセスモジュール管理情報のアドレスの対応を管理するテーブルの構成を示した図
【図１４】データ処理モジュールＩＤとデータ処理モジュール管理情報のアドレスの対応を管理するテーブルの構成を示した図
【図１５】ストリーム処理を構築する手順を示したフロー
【図１６】ピアモジュールの構成を示した図
【図１７】リンクモジュールの構成を示した図
【図１８】ストリーム処理の構成を示した図
【符号の説明】
【００８３】
１００  カメラ、１１０  マイクロフォン、１２０  データを取り出すステップ、１２１
カメラを使って映像データにアクセスするポイント、１２２  マイクロフォンを使って
音声データにアクセスするポイント、１３０  映像データと音声データを同期させ多重化
するステップ、１３１  単一の処理ポイント、１４０  データを提示するステップ、１４
１  単一の処理ポイント、１５０  データを記録するステップ、１６０  ハードウェアデ
ータデコーダ、１７０  ディスプレイ、１８０  スピーカ、１９０  記憶装置
【図１】
2009116881.tif 000003
【図２】
2009116881.tif 000004
【図３】
2009116881.tif 000005
【図４】
2009116881.tif 000006
【図５】
2009116881.tif 000007
【図６】
2009116881.tif 000008
【図７】
2009116881.tif 000009
【図８】
2009116881.tif 000010
【図９】
2009116881.tif 000011
【図１０】
2009116881.tif 000012
【図１１】
2009116881.tif 000013
【図１２】
2009116881.tif 000014
【図１３】
2009116881.tif 000015
【図１４】
2009116881.tif 000016
【図１５】
2009116881.tif 000017
【図１６】
2009116881.tif 000018
【図１７】
2009116881.tif 000019
【図１８】
2009116881.tif 000020
【手続補正書】
【提出日】平成20年12月1日(2008.12.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
演算処理部と記憶部とを有するデータ処理装置がデータ処理を実行するデータ処理方法であって、
前記演算処理部は、データ処理を行う第１の処理モジュールと、前記第１の処理モジュールと接続された第２の処理モジュールを生成し、
前記第１の処理モジュールは、前記第１の処理モジュールが実行されるタイミングを、前記第２の処理モジュールから前記第１の処理モジュールへ入力されたデータから算出して前記記憶部に記憶し、
前記演算処理部は、前記記憶部に記憶されたタイミングに基づいて、前記第１の処理モジュールを実行することを特徴とするデータ処理方法。
【請求項２】
請求項１記載のデータ処理方法であって、
前記第１の処理モジュールと前記第２の処理モジュールは、前記第１の処理モジュールと前記第２の処理モジュールの間のリンクモジュールを介して接続され、１つの処理フローを構成することを特徴とするデータ処理方法。
【請求項３】
請求項１または２記載のデータ処理方法であって、
前記記憶部に記憶された、第１の処理モジュールが実行されるタイミングは、前記第１の処理モジュールが次に実行されるタイミングであることを特徴とするデータ処理方法。
【請求項４】
請求項１から３の何れかに記載のデータ処理方法であって、
前記記憶部は、前記第１の処理モジュールが実行されるタイミングと、前記第２の処理モジュールが実行されるタイミングとを、テーブルとして記憶することを特徴とするデータ処理方法。
【請求項５】
請求項４記載のデータ処理方法であって、
前記演算処理部は、前記テーブルに記憶されたタイミングに基づいて、前記第１の処理モジュールと前記第２の処理モジュールとを１つの実行コンテキストとして実行することを特徴とするデータ処理方法。
【請求項６】
請求項１から５の何れかに記載のデータ処理方法であって、
前記第１の処理モジュールは、前記第１の処理モジュールへデータを入力するときのビットレートと、前記第１の処理モジュールが処理を行う単位であるブロックサイズに基づいて前記タイミングを算出することを特徴とするデータ処理方法。
【請求項７】
請求項１から６の何れかに記載のデータ処理方法であって、
前記第１の処理モジュールは、前記リンクモジュールから入力されたデータを処理する第１の処理部と、前記第１の処理部が処理したデータを処理する第２の処理部とを備え、
前記第１の処理部が、前記第１の処理モジュールが実行されるタイミングを、前記リンクモジュールを介して前記第１の処理モジュールへ入力されたデータから算出することを特徴とするデータ処理方法。
【請求項８】
演算処理部と記憶部とを有するデータ処理装置がデータ処理を実行するデータ処理方法であって、
前記演算処理部は、データ処理を行う第１の処理モジュールと、前記第１の処理モジュールへデータからみて上流側に接続された第２の処理モジュールと、前記第１の処理モジュールからみて下流側に接続された第３の処理モジュールを生成し、
前記第１の処理モジュールは、前記第１の処理モジュールが実行されるタイミングを、前記第２の処理モジュールから前記第１の処理モジュールへ入力されたデータから算出して前記記憶部に記憶し、
前記第３の処理モジュールは、前記第３の処理モジュールが実行されるタイミングを、前記第１の処理モジュールから前記第３の処理モジュールへ入力されたデータから算出して前記記憶部に記憶し、
前記演算処理部は、前記記憶部に記憶されたタイミングに基づいて、前記第１の処理モジュールと前記第３の処理モジュールとを実行することを特徴とするデータ処理方法。
【請求項９】
請求項８記載のデータ処理方法であって、
前記第１の処理モジュールと前記第２の処理モジュールは、前記第１の処理モジュールと前記第２の処理モジュールの間のリンクモジュールを介して接続され、
前記第１の処理モジュールと前記第３の処理モジュールは、前記第１の処理モジュールと前記第３の処理モジュールの間のリンクモジュールを介して接続され、
前記第１の処理モジュール、前記第２の処理モジュールおよび前記第３の処理モジュールが１つの処理フローを構成することを特徴とするデータ処理方法。
【請求項１０】
請求項８または９記載のデータ処理方法であって、
前記記憶部に記憶された、第１の処理モジュールが実行されるタイミングは、前記第１の処理モジュールが次に実行されるタイミングであり、
前記記憶部に記憶された、第３の処理モジュールが実行されるタイミングは、前記第３の処理モジュールが次に実行されるタイミングであることを特徴とするデータ処理方法。
【請求項１１】
請求項８から１０の何れかに記載のデータ処理方法であって、
前記記憶部は、前記第１の処理モジュールが実行されるタイミングと、前記第２の処理モジュールが実行されるタイミングと、前記第３の処理モジュールが実行されるタイミングとを、テーブルとして記憶することを特徴とするデータ処理方法。
【請求項１２】
請求項８から１１の何れかに記載のデータ処理方法であって、
前記第１の処理モジュールは、前記第１の処理モジュールへデータを入力するときのビットレートと、前記第１の処理モジュールが処理を行う単位であるブロックサイズに基づいて前記タイミングを算出し、
前記第３の処理モジュールは、前記第３の処理モジュールへデータを入力するときのビットレートと、前記第３の処理モジュールが処理を行う単位であるブロックサイズに基づいて前記タイミングを算出することを特徴とするデータ処理方法。
【請求項１３】
請求項８から１２の何れかに記載のデータ処理方法であって、
前記第３の処理モジュールのスケジューリング時間は、前記第１のスケジューリング時間よりも小さいことを特徴とするデータ処理方法。
【請求項１４】
請求項８から１３の何れかに記載のデータ処理方法であって、
前記第１の処理モジュールは、前記第２の処理モジュールから入力されたデータを処理する第１の処理部と、前記第１の処理部が処理したデータを前記第３のモジュールへ出力する第２の処理部とを備え、
前記第１の処理部は、前記第１の処理モジュールが実行されるタイミングを、前記第２の処理モジュールから前記第１の処理モジュールへ入力されたデータから算出することを特徴とするデータ処理方法。
【請求項１５】
請求項１４記載のデータ処理方法であって、
前記第３の処理モジュールは、前記第１の処理モジュールから入力されたデータを処理する第３の処理部と、前記第３の処理部が処理したデータを処理する第４の処理部とを備え、
前記第３の処理部は、前記第３の処理モジュールが実行されるタイミングを、前記第１の処理モジュールから前記第３の処理モジュールへ入力されたデータから算出することを特徴とするデータ処理方法。
【請求項１６】
請求項１１から１５の何れかに記載のデータ処理方法であって、
前記演算処理部は、前記テーブルに記憶されたタイミングに基づいて、前記第１の処理モジュール、前記第２の処理モジュールおよび前記第３の処理モジュールを１つの実行コンテキストとして実行することを特徴とするデータ処理方法。
【請求項１７】
請求項１６記載のデータ処理方法であって、
前記演算処理部は、前記１つの実行コンテキストで１つのストリーム処理を処理し、前記１つの実行コンテキストとは異なる他の実行コンテキストで前記１つのストリーム処理とは異なる他の実行コンテキストを、前記１つのストリーム処理と並行して処理することを特徴とするデータ処理方法。
【請求項１８】
請求項１７記載のデータ処理方法であって、
前記演算処理部は、前記１つのストリーム処理と前記他のストリーム処理とを、同期化処理を行うことなく並行して処理することを特徴とするデータ処理方法。
【請求項１９】
請求項１７または１８記載のデータ処理方法であって、
前記演算処理部は、前記１つのストリーム処理が記録処理であり、前記他のストリーム処理が再生処理である場合には、前記記録処理を優先して実行することを特徴とするデータ処理方法。
【請求項２０】
請求項１９記載のデータ処理方法であって、
前記演算処理部は、前記１つのストリーム処理が記録処理であり、前記他のストリーム処理が再生処理である場合には、前記記録処理の予約時間を前記再生処理の予約時間よりも短く設定することを特徴とするデータ処理方法。
【請求項２１】
データ処理を実行するデータ処理装置であって、
データ処理を行う第１の処理モジュールと、前記第１の処理モジュールと接続された第２の処理モジュールを生成する演算処理部と、
前記第１の処理モジュールが実行されるタイミングを記憶する記憶部と、を備え、
前記演算処理部は、第１の処理モジュールが実行されるタイミングを、前記第２の処理モジュールから前記第１の処理モジュールへ入力されたデータから算出するように前記第１の処理モジュールを実行して前記記憶部に記憶し、
前記演算処理部は、前記記憶部に記憶されたタイミングに基づいて、前記第１の処理モジュールを実行することを特徴とするデータ処理装置。
【請求項２２】
請求項２１記載のデータ処理を実行するデータ処理装置であって、
前記第１の処理モジュールと前記第２の処理モジュールは、前記第１の処理モジュールと前記第２の処理モジュールの間のリンクモジュールを介して接続され、１つの処理フローを構成することを特徴とするデータ処理装置。
【請求項２３】
請求項２１または２２記載のデータ処理装置であって、
前記記憶部に記憶された、第１の処理モジュールが実行されるタイミングは、前記第１の処理モジュールが次に実行されるタイミングであることを特徴とするデータ処理装置。
【請求項２４】
請求項２１から２３の何れかに記載のデータ処理装置であって、
前記記憶部は、前記第１の処理モジュールが実行されるタイミングと、前記第２の処理モジュールが実行されるタイミングとを、テーブルとして記憶することを特徴とするデータ処理装置。
【請求項２５】
請求項２４記載のデータ処理装置であって、
前記演算処理部は、前記テーブルに記憶されたタイミングに基づいて、前記第１の処理モジュールと前記第２の処理モジュールとを１つの実行コンテキストとして実行することを特徴とするデータ処理装置。
【請求項２６】
請求項２１から２５の何れかに記載のデータ処理装置であって、
前記第１の処理モジュールは、前記第１の処理モジュールへデータを入力するときのビットレートと、前記第１の処理モジュールが処理を行う単位であるブロックサイズに基づいて前記タイミングを算出することを特徴とするデータ処理装置。
【請求項２７】
請求項２１から２６の何れかに記載のデータ処理装置であって、
前記第１の処理モジュールは、前記リンクモジュールから入力されたデータを処理する第１の処理部と、前記第１の処理部が処理したデータを処理する第２の処理部とを備え、
前記第１の処理部が、前記第１の処理モジュールが実行されるタイミングを、前記リンクモジュールを介して前記第１の処理モジュールへ入力されたデータから算出することを特徴とするデータ処理装置。
【請求項２８】
データ処理を実行するデータ処理装置であって、
データ処理を行う第１の処理モジュールと、前記第１の処理モジュールからみて上流側に接続された第２の処理モジュールと、前記第１の処理モジュールからみて下流側に接続された第３の処理モジュールを生成する演算処理部と、
前記第１の処理モジュールと前記第３の処理モジュールとが実行されるタイミングを記憶する記憶部と、を備え、
前記演算処理部は、前記第１の処理モジュールが実行されるタイミングを、前記第２の処理モジュールから前記第１の処理モジュールへ入力されたデータから算出するように前記第１の処理モジュールを実行して前記記憶部に記憶し、前記第３の処理モジュールが実行されるタイミングを、前記第１の処理モジュールから前記第３の処理モジュールへ入力されたデータから算出するように前記第３の処理モジュールを実行して前記記憶部に記憶し、
前記演算処理部は、前記記憶部に記憶されたタイミングに基づいて、前記第１の処理モジュールと前記第３の処理モジュールとを実行することを特徴とするデータ処理装置。
【請求項２９】
請求項２８記載のデータ処理装置であって、
前記第１の処理モジュールと前記第２の処理モジュールは、前記第１の処理モジュールと前記第２の処理モジュールの間のリンクモジュールを介して接続され、
前記第１の処理モジュールと前記第３の処理モジュールは、前記第１の処理モジュールと前記第３の処理モジュールの間のリンクモジュールを介して接続され、
前記第１の処理モジュール、前記第２の処理モジュールおよび前記第３の処理モジュールが１つの処理フローを構成することを特徴とするデータ処理装置。
【請求項３０】
請求項２８または２９記載のデータ処理装置であって、
前記記憶部に記憶された、第１の処理モジュールが実行されるタイミングは、前記第１の処理モジュールが次に実行されるタイミングであり、
前記記憶部に記憶された、第３の処理モジュールが実行されるタイミングは、前記第３の処理モジュールが次に実行されるタイミングであることを特徴とするデータ処理装置。
【請求項３１】
請求項２８から３０の何れかに記載のデータ処理装置であって、
前記記憶部は、前記第１の処理モジュールが実行されるタイミングと、前記第２の処理モジュールが実行されるタイミングと、前記第３の処理モジュールが実行されるタイミングとを、テーブルとして記憶することを特徴とするデータ処理装置。
【請求項３２】
請求項２８から３１の何れかに記載のデータ処理装置であって、
前記第１の処理モジュールは、前記第１の処理モジュールへデータを入力するビットレートと、前記第１の処理モジュールが処理を行う単位であるブロックサイズに基づいて前記タイミングを算出し、
前記第３の処理モジュールは、前記第３の処理モジュールへデータを入力するビットレートと、前記第３の処理モジュールが処理を行う単位であるブロックサイズに基づいて前記タイミングを算出することを特徴とするデータ処理装置。
【請求項３３】
請求項２８から３２の何れかに記載のデータ処理装置であって、
前記第３の処理モジュールのスケジューリング時間は、前記第１のスケジューリング時間よりも小さいことを特徴とするデータ処理装置。
【請求項３４】
請求項２８から３３の何れかに記載のデータ処理装置であって、
前記第１の処理モジュールは、前記第２の処理モジュールから入力されたデータを処理する第１の処理部と、前記第１の処理部が処理したデータを前記第３の処理モジュールへ出力する第２の処理部とを備え、
前記第１の処理部は、前記第１の処理モジュールが実行されるタイミングを、前記第２の処理モジュールから前記第１の処理モジュールへ入力されたデータから算出することを特徴とするデータ処理装置。
【請求項３５】
請求項２８から３４の何れかに記載のデータ処理装置であって、
前記第３の処理モジュールは、前記第１の処理モジュールから入力されたデータを処理する第３の処理部と、前記第３の処理部が処理したデータを処理する第４の処理部とを備え、
前記第３の処理部は、前記第３の処理モジュールが実行されるタイミングを、前記第１の処理モジュールから前記第３の処理モジュールへ入力されたデータから算出することを特徴とするデータ処理装置。
【請求項３６】
請求項３１から３５の何れかに記載のデータ処理装置であって、
前記演算処理部は、前記テーブルに記憶されたタイミングに基づいて、前記第１の処理モジュール、前記第２の処理モジュールおよび前記第３の処理モジュールを１つの実行コンテキストとして実行することを特徴とするデータ処理装置。
【請求項３７】
請求項２８から３６の何れかに記載のデータ処理装置であって、
前記演算処理部は、前記１つの実行コンテキストで１つのストリーム処理を処理し、前記１つの実行コンテキストとは異なる他の実行コンテキストで前記１つのストリーム処理とは異なる他の実行コンテキストを、前記１つのストリーム処理と並行して処理することを特徴とするデータ処理装置。
【請求項３８】
請求項３７記載のデータ処理装置であって、
前記演算処理部は、前記１つのストリーム処理と前記他のストリーム処理とを、同期化処理を行うことなく並行して処理することを特徴とするデータ処理装置。
【請求項３９】
請求項３７または３８記載のデータ処理装置であって、
前記演算処理部は、前記１つのストリーム処理が記録処理であり、前記他のストリーム処理が再生処理である場合には、前記記録処理を優先して実行することを特徴とするデータ処理装置。
【請求項４０】
請求項３９記載のデータ処理装置であって、
前記演算処理部は、前記１つのストリーム処理が記録処理であり、前記他のストリーム処理が再生処理である場合には、前記記録処理の予約時間を前記再生処理の予約時間よりも短く設定することを特徴とするデータ処理装置。