JP2006350828A - ストリーム制御装置 - Google Patents

Abstract

【課題】 従来のシステム構成においても、ＣＰＵや高性能の専用ハードウェアを必要とせず、複数のストリームに対する処理時間の効率を低下させることなく、複数のオーディオやビデオストリームを高効率でかつ精度よく記録することができるストリーム制御装置を提供する。
【解決手段】 ストリーム制御装置１００は、データ転送通知の競合を無くし、ＣＰＵ上で実行されるストリーム処理が待ち状態になることを防ぐために、（ａ）ストリーム処理に優先度を付与するストリーム管理部１０７、（ｂ）ストリーム処理の優先度を基に、ストリーム処理の起動時刻がマスタ処理から一意の順序になるように、データ転送通知を再スケジューリングするイベント管理部１０６を備える。
【選択図】 図２

Description

本発明は、カメラ、ＴＶチューナー、ネットワーク等を介して入力される音声、映像データから構成される多種フォーマットのストリームデータを複数同時に処理するマルチエンコードシステム等に利用されるストリーム制御装置に関する。

近年、情報圧縮技術や通信技術の進歩によってストリームのフォーマットは多様化し、複数のストリームを１つのシステムで扱うような技術が発達している。ＤＳＰ（Digital Signal Processor）のような複数のストリームを並列処理できる専用プロセッサも進歩し、ＣＰＵ（Central Processor Unit）とＤＳＰで構成されるシステムも多く見受けられる。

例えば、複数のエンコーダ（例えば、ＤＳＰなど。）とＣＰＵで構成されるシステムにおいて、カメラやＴＶチューナーから入力されるストリームをＨＤＤ（Hard Disk Drive）やＳＤ（Secure Digital）メモリカード等のメディアに記録する場合、ファイルシステムを介して行われるのが一般的である。このような処理をＣＰＵ側のソフトウェアで行った場合、その処理時間はストリームの時間的制約に対して大きな割合を占める。汎用的なＣＰＵ上では商用のリアルタイムＯＳ（Operating System）が利用され、ベストエフォート型のスケジューリングが行われる。従って複数のストリームを扱う場合、ＣＰＵに対する処理負荷が高くなり、結果としてリアルタイム性に影響を及ぼす場合がある。

これに対して、ストリームを複数処理する場合において、ＣＰＵの負荷を低減する方法として、特許文献１のような装置があり、ＣＰＵ性能に依存せずに複数のストリームを処理できるが、ＣＰＵ以外のハードウェアが別途必要となる。

ここでＣＰＵとして利用される汎用的なプロセッサの進歩はめざましく、コストも安価である。また、リアルタイムＯＳのソフトウェア資産は豊富であり、ファイルシステム等の処理も数多くサポートされる。従って、ストリームの記録処理においてＣＰＵ側へ処理を分散することは非常に有効である。

ただし、ＣＰＵの処理性能が向上した場合でも、上記のようなリアルタイムＯＳを利用したシステムで複数のストリームを扱う場合は、以下のようなことに気をつける必要がある。

ＣＰＵ側でエンコードデータを扱う場合には、エンコードされたストリームのデータ量を知る必要がある。これに対して、データ量を正確に知る方法としてエンコーダと通信を行う方法が利用される。具体的には、ある一定量のストリームがエンコードされ、ＣＰＵからアクセス可能な領域へ転送が完了するとエンコーダからＣＰＵにデータ転送通知のイベントが報告される。

また、エンコーダの開始時刻はユーザからのランダムな要求によって決まり、開始時刻に対してエンコーダからのデータ転送通知の時刻も決定される。さらに、データ転送通知が報告される間隔はビットレートによって異なるため、複数のストリームを扱う場合、これらの非同期なデータ転送通知はＣＰＵ上で競合する。この現象は扱うストリームが増える程、顕著となる。

図３９（ａ）のような従来のシステム構成では複数のエンコーダからの非同期な要求をリアルタイムＯＳで受け、これらの通知を利用してストリーム処理の起動を行う。この場合データ転送通知が競合した際のストリーム処理は図３９（ｂ）のように待ち状態を引き起こし、待たされたストリーム処理は結果としてエンコーダへのデータ転送がデッドライン時刻を越えてしまう可能性がある。デッドライン時刻はデータ転送通知があった時刻から決定されるため、このような構成におけるリアルタイムＯＳでのスケジューリングでは回避することはできない。

データ転送通知のようなイベントの競合を回避するための方法として、特許文献２のような装置があり、デコード時におけるデータ競合を回避している。デコードにおいてはユーザからの開始時刻を遅らせて、かつデコーダへ転送するデータ量をビットレートに合わせて設定することでイベントの通知時刻を再スケジューリングしている。
特開２００１−４５０２５号公報 特願２００４−１８０３６３号公報

しかしながら、エンコードにおいてはデコードと同じ方法でイベントの競合を回避することができない。なぜなら、ユーザからストリームの記録が開始された場合に、カメラやＴＶチューナーから入力されたストリームデータはエンコード前のバッファに蓄積され、エンコードの開始を遅らせるとエンコード前のバッファに蓄積された記録データは上書きされてしまう可能性があり、記録開始した直後のストリームデータを保証することができない。

また、デコード時にはデコーダへ転送するデータ量をビットレートによって可変に設定することで、デコーダからのデータ要求イベントの時刻を制御することができたが、エンコーダからのデータ転送通知イベントはエンコード後のデータを蓄積するバッファの大きさとビットレートによって、常に一定間隔である。

そこで、本発明は前記問題に鑑みてなされたものであり、従来のシステム構成においても、ＣＰＵや高性能の専用ハードウェアを必要とせず、複数のストリームに対する処理時間の効率を低下させることなく、複数のオーディオやビデオストリームを高効率でかつ精度よく記録することができるストリーム制御装置を提供することを目的とする。

上記の課題を解決するために、本発明に係るストリーム制御装置は、（ａ）ストリームをエンコードするエンコーダを複数有し、エンコード後のストリームデータを外部記憶装置に転送するストリーム処理をエンコーダ毎に起動するストリーム制御装置であって、（ｂ）ストリーム処理に付与される優先度、前記ストリーム処理に割り当てられる処理時間、および前記ストリーム処理に設定された起動周期がストリーム処理毎に登録されるストリーム管理テーブルを保持するストリーム管理テーブル保持手段と、（ｃ）前記ストリーム管理テーブルに登録されている中で最も優先度の高いストリーム処理を基準となるストリーム処理に設定し、前記ストリーム管理テーブルに登録されている全てのストリーム処理が前記基準となるストリーム処理の起動周期内に逐次処理される条件で、前記ストリーム管理テーブルに登録予定のストリーム処理に処理時間を割り当てるストリーム管理手段と、（ｄ）前記基準となるストリーム処理の起動周期内に前記基準となるストリーム処理から優先度順で逐次処理される条件で、各ストリーム処理に割り当てられた処理時間を割り当て直すイベント管理手段とを備えることとする。

これによって、複数のストリームを記録する際、ファイルシステムのような比較的ストリームの時間的制約に対して大きな割合を占める処理であっても、ストリーム管理手段で割り当てられた処理時間を、イベント管理手段で割り当て直すことで、エンコーダからのイベント競合を回避して、ＣＰＵで実行されるストリーム処理が待ち状態になることを防ぐことができる。

なお、本発明は、ストリーム制御装置として実現されるだけではなく、ストリーム制御装置を制御する方法（以下、ストリーム制御方法と呼称する。）、ストリーム制御方法をコンピュータシステムなどに実行させるプログラム（以下、ストリーム制御プログラムと呼称する。）、ストリーム制御プログラムを記録した記録媒体などとして実現されるとしてもよい。

以上のように本発明に係るストリーム制御装置によれば、複数のストリームを記録する際、ファイルシステムのような比較的ストリームの時間的制約に対して大きな割合を占める処理であっても、処理の起動時間をスケジューリングすることでエンコーダからのイベント競合を回避して、ＣＰＵで実行されるストリーム処理が待ち状態になることを防ぐことができる。従来のシステム構成においても、ＣＰＵや専用のハードウェアを必要とせず、複数のストリームに対する処理時間の効率を低下させることなく、複数のオーディオやビデオストリームを高効率でかつ精度よく記録することができる。

（実施の形態１）
以下、本発明に係る実施の形態１について、図面を参照しながら説明する。

図１は、実施の形態１におけるストリーム制御装置のシステム構成を示す図である。
図１に示されるように、ストリーム制御装置１００は、ストリーム管理部１０７で割り当てられたストリーム処理の処理時間を、イベント管理部１０６で割り当て直すことを特徴とする。ここでは、一例として、ストリーム制御装置１００は、ＣＰＵ１１、データ転送装置１２、外部ＩＯ装置１３、エンコーダ１４、エンコード後のデータを一時的に蓄積する内部バッファ１５、ストリーム処理部１０９、イベント管理部１０６、ストリーム管理部１０７、ストリーム管理テーブル保持部１０８で構成される。

そして、ストリームの記録処理が開始されると、エンコーダ１４によってエンコード処理が開始され、エンコーダ１４の内部バッファ１５にエンコードデータが蓄積される。このエンコードデータは周期的にデータ転送装置１２によって、記憶装置１０に転送され、ある一定量のエンコードデータが記憶装置１０に転送されるとエンコーダ１４からデータ転送通知が行われる。ストリーム処理部１０９はＣＰＵ１１上で動作するソフトウェア処理であって、一定量のエンコードデータが記憶装置１０に蓄積されたことを検出すると、記憶装置１０に蓄積されたエンコードデータを外部ＩＯ装置１３に接続されるＨＤＤ等の外部記憶装置（不図示）へ記録するために必要なストリーム処理（例えばファイルシステムに関する処理）を行った後、外部記憶装置へ記録を行う。なお、データ転送通知はデータ転送装置１２によって行う構成であってもよい。

ストリーム管理部１０７は、エンコーダ１４の開始及び終了要求と、エンコードの開始が要求されたストリームに関わる情報を入力とし、起動されている全てのストリーム処理を管理するためのストリーム管理テーブル１８０を生成し、エンコードの開始要求を受けたストリーム処理部１０９の処理時間が既に実行されているストリーム処理部１０９の起動時間を予測して、エンコーダ１４の内部バッファ１５がオーバーフローすることを検出する機能を備える。

イベント管理部１０６は、エンコーダ１４からのデータ転送通知と、ストリーム管理テーブル１８０で管理されるストリーム管理情報を入力とし、複数のエンコーダ１４からの非同期なデータ転送通知をストリーム管理テーブル１８０に登録されている優先度に従って、一意の順序及び間隔で通知されるように再スケジューリングする機能を備える。

ストリーム処理部１０９はイベント管理部１０６によって再スケジューリングされたデータ転送に対して、イベント通知（起動要求）が入力されると、ストリーム処理を開始する。

ストリーム処理部１０９におけるストリーム処理とは、記憶装置１０に蓄積されているエンコードデータを必要なフォーマットに変換し、外部ＩＯ装置１３に接続されるＨＤＤ、ＳＤメモリカード等の外部記憶装置に記録することである（以下、ストリーム処理）。

図２は、ストリーム管理テーブル保持部１０８で保持されているストリーム管理テーブル１８０の構造を示す図である。

図２に示されるように、ストリームＩＤと関連付けられるストリーム処理部１０９の１サイクル当たりの処理時間とビットレート、さらにデータ転送通知周期がストリーム管理情報として管理される。データ転送通知の周期は、あるデータ転送通知時刻から次のデータ転送通知時刻までの時間差、つまりエンコーダ１４のエンコードデータが設定した任意のデータ量だけ記憶装置１０へ転送されるまでの時間量であり、設定したデータ量とビットレートで求まる。

図３は、本発明の実施の形態１の処理ブロック図を示す。
図３に示されるように、ストリーム制御装置１００は、エンコーダ１４、エンコード後のデータを蓄積する記憶装置１０、データ転送装置１２、ストリーム管理部１０７、ストリーム管理テーブル１０８、イベント管理部１０６、アプリケーションプログラム実行部１１０、ストリーム処理部１０９、外部ＩＯ装置１３、ＡＶ入力装置１６などで構成される。

アプリケーションプログラム実行部１１０は、ユーザからの記録開始及び終了要求を入力とし、ＡＶ入力装置１６を介して接続されるカメラ、ＴＶチューナー等の機器を制御することで、オーディオやビデオ等のストリームをエンコーダ１４へ供給する。

さらに、アプリケーションプログラム実行部１１０は、ストリーム管理部１０７へ記録開始及び終了要求と記録ストリームに関する情報を通知する。

記録開始時にストリーム管理部１０７は、アプリケーションプログラム実行部１１０からの記録開始要求とストリーム情報を入力とし、ストリーム情報に含まれるストリーム処理部１０９の処理時間から、既に実行されているストリーム処理の処理時間と処理の起動周期を利用して記録処理が開始可能か判定を行う。記録処理が開始可能な場合、ストリーム処理に優先度と識別子を付与して、エンコーダ１４にエンコード処理の開始要求を行い、開始されたストリーム管理情報をストリーム管理テーブル１８０へ登録する。記録ストリームのビットレートや記録フォーマット等の設定値はエンコード開始要求に含まれる。さらにイベント管理部１０６へ開始通知を行い、開始通知を受けたイベント管理部１０６はストリーム管理テーブル１８０からストリーム管理情報を取得する。

記録処理中の動作として、イベント管理部１０６は、エンコーダ１４からのデータ転送通知を受けると、ストリーム管理テーブル１８０から取得したストリーム管理情報を利用して、最も優先度の高いストリーム処理を基準となるストリーム処理（以下、マスタ処理と呼称する。）に設定する。そして、以降このマスタ処理を基準にその他のストリーム処理が優先度順に逐次処理されるように、ストリーム処理部１０９の起動順序をスケジューリングする。ストリーム処理部１０９は、イベント管理部１０６からデータ転送通知を受け、データ転送通知の情報に含まれる処理時間の間、記憶装置１０に蓄積されたエンコードデータを外部ＩＯ装置１３へ接続される記憶装置に記録するための処理を行う。

エンコーダ１４では処理が開始されると内部バッファ１５にエンコードされたデータが蓄積され、内部バッファ１５のデータ量が一定量を越えるとデータ転送装置１２を起動し、エンコードデータを記憶装置１０へ転送する。エンコーダ１４は一定量のエンコードデータを記憶装置１０へ転送するとデータ転送通知をイベント管理部１０６へ出力する。エンコーダ１４から記憶装置１０へ転送するデータ量、およびエンコーダ１４がデータ転送通知を出力するためのデータ量は記録開始前にエンコーダ１４へ設定されているものとする。

記録終了時にストリーム管理部１０７はアプリケーションプログラム実行部１１０からの記録終了要求を入力とし、エンコーダ１４に記録終了要求を通知し、終了されたストリーム管理情報をストリーム管理テーブル１８０から削除する。エンコーダ１４は終了要求を受理するとエンコード処理を停止し、ストリームの終端符号を付与したエンコードデータを記憶装置１０へ転送する。

ストリーム処理部１０９はストリームの終端符号を検出し、外部記憶装置に全てのストリームデータを記録し終えると、イベント管理部１０６へストリーム処理の終了通知を行う。イベント管理部１０６は、ストリーム処理部１０９から終了通知を受理するとテーブル情報から終了したストリーム情報を削除し、処理を終了する。

図４は、ストリーム管理部１０７のフローチャートを示す図である。
図４に示されるように、アプリケーションプログラム実行部１１０からの記録開始要求を検出した場合（Ｓ４００）、後述するストリーム管理テーブル１８０に登録されているストリーム管理情報を確認することで、既に開始されているストリーム処理が存在しているか判定を行う（Ｓ４０１）。ストリーム管理情報が存在しない場合、エンコーダ１４にエンコード開始要求を行いエンコード処理を開始する（Ｓ４０５）。エンコードが開始されたストリームに対して、ストリームを一意に扱うためのストリームＩＤ及び優先度を登録順に付加し、このＩＤを元にストリーム管理テーブル１８０を作成する（Ｓ４０６）。さらに、イベント管理部１０６へ記録処理を開始したことを通知する（Ｓ４０７）。

既に開始されているストリーム処理が存在する場合、ストリーム管理テーブル１８０から全てのストリーム処理の情報を取得し（Ｓ４０２）、アプリケーションプログラム実行部１１０から取得したストリーム情報とストリーム管理テーブル１８０の情報から後述するストリームチェック処理を行う（Ｓ４０３）。ストリームチェック処理によって、開始要求がなされたストリーム処理が、既に開始されているストリーム処理の開始時刻を遅らせ、外部記憶装置へ記録するデータの保証ができないと判定された場合（Ｓ４０４）、エンコード処理は開始せずに処理を終了する。ストリーム処理を開始しても他のストリーム処理へ影響しないと判定された場合（Ｓ４０４）、エンコーダ１４にエンコード開始要求を行いエンコード処理を開始する（Ｓ４０５）。エンコードが開始されたストリームに対して、ストリームＩＤ及び優先度を付加し、ストリーム管理テーブル１８０にストリーム管理情報を登録する（Ｓ４０６）。最後にイベント管理部１０６へ記録処理を開始したことを通知する（Ｓ４０７）。

ストリームチェック処理（Ｓ４０３）では、開始されるストリーム処理の１サイクル当たりの処理時間と既に実行されているストリーム処理時間との合計時間が、マスタのストリーム処理のデータ転送通知周期を越えないか判定する処理である。

もし、この時間を越えた場合にストリーム処理を開始すると、ストリーム処理部１０９の起動時刻が遅れ、記憶装置１０のエンコードデータを外部記憶装置へ記録する前に、エンコーダ１４の内部バッファ１５、または記憶装置１０のエンコードデータを蓄積する領域がオーバーフローすることを意味する。

ストリーム管理テーブル１８０では常時ストリーム処理を追加するための空き時間が管理されており、この時間以内であれば、ストリーム処理の追加が可能である。空き時間はマスタのストリーム処理の起動周期と、既に実行されている全てのストリーム処理の合計時間を差し引いた時間（１式）である。なお、システムによってストリーム処理をタスクで分割して行うような場合は、割り込み応答時間やタスク切り替え時間が大きければストリーム処理時間に含めて空き時間を補正してもよい。

空き時間 ＝ 優先度１の処理の起動周期 − Σ（ ストリーム処理の処理時間 ）・・・（１式）
アプリケーションプログラム実行部１１０からの記録終了要求を検出した場合（Ｓ４００）、エンコーダ１４にエンコード終了要求を行い、エンコード処理を終了する（Ｓ４０８）。

図５、図６は、イベント管理部１０６のフローチャートを示す図である。
まず、図５に示されるように、イベント管理部１０６は、ストリーム管理部１０７から開始通知、およびストリーム処理部１０９から終了通知を受けた場合の処理であり、開始及び終了通知を受けた場合（Ｓ６００）、後述するデータ転送通知を受理した場合に行われるストリーム処理が起動されているか判定を行う（Ｓ６０１）。ストリーム処理が起動されている場合（Ｓ６０２）、ストリーム処理中にスケジューリングが情報を更新しないために、ストリーム処理が終了するまで待ち（Ｓ６０２）、以降の処理を行う（Ｓ６０３〜Ｓ６０７）。

ストリーム管理部１０７から開始通知を受けた場合、ストリーム管理テーブル１８０から最新のストリーム管理情報を取得し（Ｓ６０４）、処理を終える。

ストリーム処理部１０９から終了通知を受けた場合、ストリーム管理テーブル１８０から処理が終了したストリームに対応するＩＤをもとにストリーム管理情報を削除する（Ｓ６０５）。この終了通知がマスタのストリーム処理の通知であるか判定を行い（Ｓ６０６）、マスタのストリーム処理の場合、ストリーム管理テーブル１８０の優先度を更新する（Ｓ６０７）。なお、実施の形態１ではストリーム管理テーブル１８０からストリーム管理情報を削除する処理をイベント管理部１０６でおこなっているが、イベント管理部１０６からストリーム管理部１０７へ削除要求を行い、ストリーム管理部１０７側でストリーム管理情報の削除を行ってもよい。

さらに、図６に示されるように、イベント管理部１０６は、エンコーダ１４からデータ転送通知を受理した場合の処理であり、エンコーダ１４からデータ転送通知を受理した場合、データ転送通知がマスタのストリーム処理に対する通知か判定を行い（Ｓ７００）、マスタのストリーム処理に対するデータ転送通知でなければ処理を終了する。データ転送通知がマスタのストリーム処理に対する通知の場合（Ｓ７００）、ストリーム処理部１０９にデータ転送通知を行う（Ｓ７０１）。データ転送通知の付加情報としてストリーム管理テーブル１８０で管理されるストリーム処理の処理時間を通知し、ストリーム処理部１０９は、この処理時間だけ記憶装置１０に蓄積されているエンコードデータを外部記憶装置へ記録する。ストリーム管理テーブル１８０にさらにストリーム処理が登録されている場合（Ｓ７０２）、ストリーム管理テーブル１８０のストリーム処理時間を利用してタイマを起動し、起動中のストリーム処理部１０９が終了することを待つ（Ｓ７０３）。タイマ満了後、ストリーム処理部１０９にデータ転送通知を行うことで次のストリーム処理を開始する（Ｓ７０１）。ストリーム管理テーブル１８０に登録されている全てのストリームに対して、上記の処理（Ｓ７０１〜Ｓ７０３）を繰り返して処理を終了する。

このように、本実施の形態におけるストリーム制御装置１００によれば、イベント管理部１０６によりＣＰＵ１１上で動作するストリーム処理部１０９はストリームに付与された優先度に従って図７のように順次起動されるため、複数のエンコーダ１４からの非同期なデータ転送通知に対してストリーム処理の開始が競合するケースが無くなり、例えば、リアルタイムＯＳにおけるタスクの優先度でストリーム処理に待ちが発生することを防ぐことができ、結果として複数のエンコーダ１４に対して内部バッファ１５または記憶装置１０におけるエンコードデータの領域がオーバーフローする以前に記憶装置１０のデータを外部記憶装置へ記録することを保証できる。また、図７のようにストリーム処理を連続で起動した場合、ストリーム処理を行っていない空き時間を連続した時間で管理できるため、ストリーム管理部１０７により、ストリーム処理を開始した場合に、この処理時間が空き時間以内に収まれば、全てのストリーム処理において、エンコーダ１４でエンコードされたストリームデータを外部記憶装置へ記録することが保証できる。

（実施の形態２）
次に、本発明に係る実施の形態２について、図面を参照しながら説明する。

本実施の形態におけるストリーム制御装置のハードウェア構成は、実施の形態１におけるストリーム制御装置のハードウェア構成と同様である。しかし、機能構成において、図８に示されるように、イベント管理部１０６、ストリーム管理部１０７、およびストリーム管理テーブル保持部１０８の代わりに、イベント管理部２０６、ストリーム管理部２０７、およびストリーム管理テーブル保持部２０８を備える点が異なる。そして、ストリーム管理テーブル１８０の構成要素を変更し、イベント管理部１０６とストリーム管理部１０７に帯域制御処理を追加することで、イベント管理部１０６とストリーム管理部１０７の処理制御フローを変更したことを特徴とする。

なお、実施の形態１におけるストリーム制御装置１００によれば、図９（ａ）で示されるように、ビットレートが異なるストリームを複数扱う場合、マスタのストリーム処理を１サイクル行う間にマスタ以外のストリーム処理を複数回行うことができないため、エンコーダ１４の内部バッファ１５もしくは記憶装置１０におけるエンコードデータの蓄積領域がオーバーフローする。

例えば、マスタのストリーム処理Ａのビットレートがマスタではないストリーム処理Ｂの３倍のビットレートの場合、ストリーム処理Ａに対するストリーム処理部１０９を１回起動する間に、ストリーム処理Ｂに対するストリーム処理部１０９を３回起動しなければならない。

しかし、本実施の形態におけるストリーム制御装置によれば、この点が改善される。
具体的には、ストリーム管理部２０７においてストリームのビットレートを利用して、最も大きなビットレートから優先度を割り当てる処理を追加し、さらに、ストリーム管理部２０７は最も大きなビットレートを基準として、ビットレートの比率からストリーム処理部１０９の処理時間を動的に割り当てる。イベント管理部２０６は、この処理時間をもとにスケジューリングを行うことでビットレートが異なる複数のストリームを記録することができる。

以上の点を踏まえて、本実施の形態におけるストリーム制御装置ついて説明する。なお、実施の形態１におけるストリーム制御装置と同一の構成については、同一の参照符号を付して説明を省略する。

図１０は、実施の形態２におけるストリーム管理テーブル保持部２０８で保持されているストリーム管理テーブル２８０の構成図である。

図１０に示されるように、ストリーム管理テーブル２８０には、実施の形態１におけるストリーム管理テーブル１８０に対して初期値とは別に処理時間が設定される領域が追加されている。

図１１は、実施の形態２におけるストリーム管理部２０７のフローチャートを示す図である。

なお、実施の形態１におけるストリーム管理部１０７の制御フロー（図３参照。）と比べて、下記の点が異なる。

図１１に示されるように、ストリーム管理部２０７は、アプリケーションプログラム実行部１１０によって開始が要求されたストリーム処理のビットレートとストリーム管理テーブル保持部２０８で保持されているストリーム管理テーブルのストリームのビットレートを比較し、開始要求されたストリーム処理のビットレートが大きい場合（Ｓ１０００）、開始要求されたストリーム処理を一時的にマスタ処理として扱い、ストリーム処理部１０９の処理時間を一時的に設定したマスタのストリーム処理に対する処理時間を基準として再計算する（Ｓ１００１）。マスタ以外のストリーム処理の処理時間はマスタのストリーム処理の処理時間とビットレートから（２式）で求まる。

優先度Ｎのストリーム処理時間 ＝ 優先度１の処理の処理時間 × （ 優先度１の処理のビットレート ／ 優先度Ｎのストリーム処理時間 ）・・・（２式）
再計算されたストリーム処理時間を利用して、ストリームチェック処理を行い（Ｓ４０３）、ストリーム処理が開始できる場合、ストリーム管理テーブル２８０へ対応するストリーム管理情報を登録する。また、マスタ以外のストリーム処理についても記録ビットレートの大きさから優先度を決定し、ストリーム管理情報を登録する（Ｓ１００２）。マスタのストリーム処理が変更された場合（Ｓ１００３）、再計算したストリーム処理時間をストリーム管理テーブル２８０へ更新し（Ｓ１００４）、このストリーム処理時間をスケジューリングに反映するために、イベント管理部１０６へ記録開始通知を行い（Ｓ４０７）、処理を終了する。

図１２は、実施の形態２におけるイベント管理部２０６のフローチャートを示す図である。

なお、実施の形態１におけるイベント管理部１０６の制御フローと比べて（図６参照。）、下記の点が異なる。

図１２に示されるように、イベント管理部２０６は、ストリーム処理部１０９から、ストリーム処理の終了通知を受けると、ストリーム管理テーブル１８０からストリーム管理情報が削除される（Ｓ６０１〜６０７）。マスタのストリーム処理に対するストリーム管理情報が削除された場合、ストリーム管理テーブル２８０の処理時間を新しいマスタ処理に対して再計算する（Ｓ１１００）。

再計算した処理時間は、ストリーム管理テーブル２８０で初期値と別に登録され、スケジューリングには全て計算後の値が利用される。マスタ処理が削除された後、初期値を利用して再びストリーム処理部１０９の処理時間が再計算される。

このように、本実施の形態におけるストリーム制御装置２００によれば、ストリーム管理部１０７によってストリームの記録ビットレートからストリーム処理部１０９の優先度を決定し、マスタのストリーム処理部１０９に対する処理時間を基準とし、その他のストリーム処理部１０９の処理時間を決定し、さらに、イベント管理部２０６において再計算された優先度と処理時間に従って、ストリーム処理部１０９を再スケジューリングすることで、記録ビットレートに差があるストリーム処理を複数扱う場合であっても、図９（ｂ）に示されるように、全てのストリーム処理において、エンコーダ１４でエンコードされたストリームデータを外部記憶装置へ記録することが保証できる。

（実施の形態３）
次に、本発明に係る実施の形態３について、図面を参照しながら説明する。

本実施の形態におけるストリーム制御装置のハードウェア構成は、実施の形態２におけるストリーム制御装置のハードウェア構成と同様である。しかし、機能構成において、図１３に示されるように、イベント管理部２０６、ストリーム管理部２０７、ストリーム管理テーブル保持部２０８、およびアプリケーションプログラム実行部１１０の代わりに、イベント管理部３０６、ストリーム管理部３０７、ストリーム管理テーブル保持部３０８、およびアプリケーションプログラム実行部３１０を備える点が異なる。そして、ストリーム管理テーブル２８０の構成要素に前処理と後処理の領域を追加し、さらに、アプリケーションプログラム実行部１１０からストリーム管理部２０７へ前処理と後処理の入力を追加し、イベント管理部２０６に前処理と後処理のスケジューリング処理を追加することで、イベント管理部２０６の処理制御フローを変更したことを特徴とする。

なお、実施の形態２におけるストリーム制御装置２００において、記憶装置１０に蓄積されたエンコードデータを外部記憶装置へ記録するストリーム処理部の前後に、ある一定の処理が必要な場合、その処理を含めた記録処理の保証ができなかった。

例えば、ストリーム処理Ａを起動する前に暗号化を行い、ストリーム処理Ｂの記録終了後、ストリームデータが外部記憶装置へ正しく記録されているかチェックを行うような動作を追加した場合、これらのストリームに依存した処理の処理時間はスケジューリングに含まれないため、スケジューリングの整合性がとれなくなり、結果としてストリームデータを外部記憶装置を記録することが保証できなくなる。

しかし、本実施の形態におけるストリーム制御装置によれば、この点が改善される。
具体的には、図１４に示されるように、ストリーム管理テーブル保持部３０８で保持されているストリーム管理テーブル３８０において前処理時間、後処理時間の領域を追加し、ストリーム処理時間へこれらの処理時間を付加してスケジューリングを行うことで、前後の処理を含めた形でストリームデータを外部記憶装置へ記録することが保証できる。

以上の点を踏まえて、本実施の形態について説明する。なお、実施の形態２におけるストリーム制御装置の構成と同一の構成については、同一の参照符号を付して説明を省略する。

図１４は、実施の形態３におけるストリーム管理テーブル保持部３０８で保持されているストリーム管理テーブル３８０の構成図である。

図１４に示されるように、ストリーム管理テーブル３８０には、実施の形態２におけるストリーム管理テーブル２８０に対して前処理時間と後処理時間を設定する領域が追加されている。

なお、本実施の形態におけるストリーム管理部３０７の制御フローは、実施の形態２におけるストリーム管理部２０７の制御フロー（図３参照。）と同じであるが、アプリケーションプログラム実行部３１０から取得したストリーム情報には前処理と後処理に情報が含まれており、ストリームチェック処理では空き時間は（３式）のように前処理時間、後処理時間を含めて計算される。

空き時間 ＝ 優先度１の処理の起動周期 − Σ（ ストリーム処理の処理時間 ＋ 前処理時間 ＋ 後処理時間）・・・（３式）
図１５は、実施の形態３におけるイベント管理部３０６のフローチャートを示す図である。

なお、イベント管理部３０６は、ストリーム管理テーブル３８０に登録されているストリーム処理のうち、優先度の高い方を第１のストリーム処理とし、優先度の低い方を第２のストリーム処理とした場合において、ストリーム処理時間に基づいて、第１のストリーム処理の終了時刻に、第２のストリーム処理の開始時刻を同期させることとする。

なお、実施の形態２におけるイベント管理部２０６の制御フロー（図６参照。）と比べて、下記の点が異なる。

図１５に示されるように、イベント管理部３０６は、エンコーダ１４から、マスタ処理のデータ転送通知を受けると、ストリーム管理テーブル３８０のストリーム管理情報をもとに前処理時間待ち（Ｓ１３００）、その後ストリーム処理部１０９へデータ転送通知を行う（Ｓ７０１）。ストリーム処理完了後、さらに、後処理の時間を待ち（Ｓ１３０１）、次のストリームに対するスケジューリング処理を行う。ストリーム処理部１０９の起動は、前処理時間だけ待たされることになるため、記憶装置１０においてエンコードデータを蓄積する領域の大きさを前処理の時間によって可変とすることが望ましい。

なお、前処理、後処理を毎回行う必要が無い場合は、必要な時にアプリケーションプログラム実行部３１０からストリーム管理テーブル３８０を更新する形でもよい。

このように、本実施の形態におけるストリーム制御装置３００によれば、ストリーム管理テーブル３８０において前処理、後処理の領域を追加し、イベント管理部３０６およびストリーム管理部３０７において前処理と後処理をストリーム処理時間に含めてスケジューリングを行えば、図１６のように前後の処理を含めた形でストリームデータを外部記憶装置へ記録することが保証できる。

（実施の形態４）
次に、本発明に係る実施の形態４について、図面を参照しながら説明する。

本実施の形態におけるストリーム制御装置のハードウェア構成は、実施の形態３におけるストリーム制御装置のハードウェア構成と同様である。しかし、機能構成において、図１７に示されるように、ストリーム管理部３０７、ストリーム管理テーブル保持部３０８、およびアプリケーションプログラム実行部３１０の代わりに、ストリーム管理部４０７、ストリーム管理テーブル保持部４０８、およびアプリケーションプログラム実行部４１０などを備える。そして、ストリーム管理テーブル３８０の構成要素に予約処理時間の領域を追加し、さらに、アプリケーションプログラム実行部３１０からストリーム管理部３０７へ予約時間の入力を追加したことを特徴とする。

なお、実施の形態３において、記憶装置１０に蓄積されたエンコードデータを外部記憶装置へ記録するストリーム処理の他に、ある一定周期の処理が必要な場合、ストリーム処理の保証しかできなかった。

例えば、ストリーム処理Ａを行う一方で、ネットワークの送受信処理を行う場合、ネットワークに対する通信帯域を保証することができない。

しかし、本実施の形態におけるストリーム制御装置によれば、この点が改善される。
具体的には、図１８に示されるように、ストリーム管理テーブル保持部４０８で保持されているストリーム管理テーブル４８０において予約時間を追加し、ストリーム処理時間へ予約時間を付加してスケジューリングを行うことでストリームデータを外部記憶装置へ記録することに加え、予約した時間内の処理も保証できる。

以上の点を踏まえて、本実施の形態におけるストリーム制御装置ついて説明する。なお、実施の形態３におけるストリーム制御装置３００と同一の構成については、同一の参照符号を付して説明を省略する。

図１８は、実施の形態４におけるストリーム管理テーブル保持部４０８で保持されているストリーム管理テーブル４８０の構成図である。

図１８に示されるように、ストリーム管理テーブル４８０には、実施の形態３におけるストリーム管理テーブル３８０に対して予約処理の時間を設定する領域が追加されている。

また、本実施の形態におけるストリーム管理部４０７の制御フローは、実施の形態３におけるストリーム管理部３０７の制御フロー（図３参照。）と同じであるが、アプリケーションプログラム実行部４１０から設定された予約処理の時間により、ストリームチェック処理では空き時間は（４式）のように予約時間を含めて計算される。

空き時間 ＝ 優先度１の処理の起動周期 − Σ（ ストリーム処理の処理時間 ＋ 予約時間）・・・（４式）
また、はじめに設定されたデフォルトの予約処理時間はマスタのストリーム処理に対する起動周期を基準として、（５式）のように再計算されてスケジューリングに利用される。

予約処理時間 ＝ デフォルトの予約処理時間 ＊ （ 予約処理の起動周期 ／ 優先度１の処理の起動周期 ）・・・（５式）
なお、予約処理の起動時間をストリーム処理の終了時刻に同期させるために、イベント管理部３０６のフローチャート（図１５参照。）において、ストリーム処理を全て行った後（Ｓ７０２）、終了通知を予約時間に割り当てた処理モジュールへ行い処理を起動してもよい。

このように、本実施の形態におけるストリーム制御装置４００によれば、ストリーム管理テーブル４８０において予約処理時間の領域を追加し、ストリーム管理部１０７において予約処理時間をストリーム処理時間に含めてスケジューリングを行えば、図１９のようにストリームデータを外部記憶装置へ記録することに加え、ストリーム処理以外の周期処理についても保証することができる。

（実施の形態５）
次に、本発明に係る実施の形態５について、図面を参照しながら説明する。

本実施の形態におけるストリーム制御装置のハードウェア構成は、実施の形態４におけるストリーム制御装置のハードウェア構成と同様である。しかし、機能構成において、図２０に示されるように、ストリーム管理部４０７、およびアプリケーションプログラム実行部４１０の代わりに、ストリーム管理部５０７、およびアプリケーションプログラム実行部５１０を備える点が異なる。そして、ストリーム管理部４０７からアプリケーションプログラム実行部４１０に対するアラーム通知処理を追加することで、ストリーム管理部４０７の処理制御フローを変更したことを特徴とする。

なお、実施の形態４におけるストリーム制御装置４００において、ストリーム管理部４０７で空き時間不足によりストリーム処理が開始できなかった場合、アプリケーションプログラム実行部４１０は不足している空き時間を正確に知ることができなかった。

例えば、ストリーム処理Ｃの開始に失敗した後、ストリーム処理Ｂを終了し、再びストリーム処理Ｃを開始してもストリーム処理Ｃを開始できるか保証することができない。

しかし、本実施の形態におけるストリーム制御装置によれば、この点が改善される。
以上の点を踏まえて、本実施の形態におけるストリーム制御装置について説明する。なお、実施の形態４におけるストリーム制御装置４００の構成と同一の構成については、同一の参照符号を付して説明を省略する。

図２１は、実施の形態５におけるストリーム管理部５０７のフローチャートを示す図である。

なお、実施の形態４におけるストリーム管理部４０７の制御フロー（図１０参照。）と比べて、下記の点が異なる。

図２１に示されるように、ストリーム管理部５０７は、アプリケーションプログラム実行部５１０から、記録処理の開始要求を受けると、ストリームチェック処理（Ｓ４０３）でストリーム処理が開始可能か判定を行う。空き時間不足でストリーム処理が開始できない場合（Ｓ４０４）、アラーム情報として足りない時間を、アプリケーションプログラム実行部５１０へ通知する（Ｓ１８００）。これによって、アプリケーションプログラム実行部５１０は、通知された時間情報をもとにストリーム処理の追加、削除を行うことが可能となる。

このように、本実施の形態におけるストリーム制御装置５００によれば、ストリーム管理部５０７においてアプリケーションプログラム実行部５１０に対してアラーム情報を通知する処理を追加することで、アプリケーションプログラム実行部５１０は、ストリーム処理のための空き時間を正確に知ることができ、ストリーム処理を追加する前に開始できるか判定可能になる。

なお、アラーム情報を通知する代わりに、ストリーム管理テーブル４８０が更新されたタイミングで空き時間をアプリケーションプログラム実行部５１０に通知する方法であってもよい。

（実施の形態６）
次に、本発明に係る実施の形態６について図面を参照しながら説明する。

本実施の形態におけるストリーム制御装置のハードウェア構成は、実施の形態５におけるストリーム制御装置５００のハードウェア構成と同様である。しかし、機能構成において、図２２に示されるように、ストリーム管理部５０７の代わりに、ストリーム管理部６０７を備える点が異なる。そして、ストリーム管理部５０７にストリームの記録ビットレートを再計算する処理を追加することで、ストリーム管理部５０７の処理制御フローを変更したことを特徴とする。

なお、実施の形態５におけるストリーム制御装置５００において、ストリーム管理部５０７で空き時間不足によりストリーム処理が開始できなかった場合、開始できなかったストリーム処理は、実行中のストリームを削除しなければ開始できなかった。

しかし、本実施の形態におけるストリーム制御装置によれば、この点が改善される。
以上の点を踏まえて、本実施の形態におけるストリーム制御装置について説明する。なお、実施の形態５におけるストリーム制御装置５００の構成と同一の構成については、同一の参照符号を付して説明を省略する。

図２３は、実施の形態６におけるストリーム管理部６０７のフローチャートを示す図である。

なお、実施の形態５におけるストリーム管理部５０７の制御フロー（図２１参照。）と比べて、下記の点が異なる。

図２３に示されるように、ストリーム管理部６０７は、アプリケーションプログラム実行部５１０から、記録処理の開始要求を受けると、ストリームチェック処理（Ｓ４０３）でストリーム処理が開始可能か判定を行う。空き時間不足でストリーム処理が開始できない場合（Ｓ４０４）、開始するストリーム処理の処理時間が、空き時間に収まるようにビットレートを計算する（Ｓ１９００）。デフォルトのビットレートに対して、実際にエンコーダ１４に設定するビットレートは（６式）のように空き時間とストリーム処理時間の比率で計算される。

優先度Ｎのビットレート ＝ 優先度Ｎのデフォルトのビットレート ＊ （ 空き時間 ／ 優先度Ｎのストリーム処理時間 ）・・・（６式）
そして、ストリーム管理部６０７は、エンコーダ１４が計算後のビットレート以下の設定値をサポートしている場合（Ｓ１９０１）、ストリーム処理を開始する。サポートしていない場合は、アラームを通知して処理を終了する。

このように、本実施の形態におけるストリーム制御装置６００によれば、ストリーム管理部６０７において、記録ビットレートを再計算する処理を追加をすることで、空き時間不足で開始できかったストリーム処理を保証できる。

なお、ユーザとインタラクティブに記録ビットレートを決定するために、実施の形態５のようにアラーム情報を通知し、アプリケーションプログラム実行部５１０で記録ビットレートを再計算する方法であってもよい。

（実施の形態７）
次に、本発明に係る実施の形態７について、図面を参照しながら説明する。

本実施の形態におけるストリーム制御装置のハードウェア構成は、実施の形態６におけるストリーム制御装置６００のハードウェア構成と同様である。しかし、機能構成において、図２４に示されるように、イベント管理部３０６、ストリーム管理部６０７、およびアプリケーションプログラム実行部５１０の代わりに、イベント管理部７０６、ストリーム管理部７０７、およびアプリケーションプログラム実行部７１０を備える点が異なる。そして、アプリケーションプログラム実行部５１０からストリーム管理部６０７へストリーム処理に対してビットレート変更通知を追加し、ストリーム管理部６０７にビットレート変更処理を追加することで、ストリーム管理部６０７の処理制御フローを変更したことを特徴とする。

なお、実施の形態６におけるストリーム制御装置６００によれば、一度開始されたストリーム処理を保証するように動作する。従って、あるビットレートのストリーム処理が開始されると、これに続いて開始されるストリーム処理は指定したビットレートで記録することを保証することができない。

例えば、ユーザが高い優先度で記録したいストリームがあった場合、空き時間がなければ、実行中のストリーム処理を削除するか、ビットレートを下げて記録を開始することしかできない。

しかし、本実施の形態におけるストリーム制御装置によれば、この点が改善される。
以上の点を踏まえて、本実施の形態におけるストリーム制御装置について説明する。なお、実施の形態６におけるストリーム制御装置６００の構成と同一の構成については、同一の参照符号を付して説明を省略する。

図２５は、実施の形態７におけるストリーム管理部７０７のフローチャートを示す図である。

なお、実施の形態６におけるストリーム管理部６０７の制御フロー（図２１参照。）と比べて、アプリケーションプログラム実行部６１０から開始および終了要求を受けた場合の制御フローは同じである。

しかし、図２５に示されるように、ストリーム管理部７０７は、アプリケーションプログラム実行部７１０からビットレートの変更通知を受けると（Ｓ２０００）、ビットレートが変更されたストリーム処理の処理時間を再計算する（Ｓ２００１）。

ここで、ビットレート変更時の処理時間の計算方法については、実施の形態５における計算方法と同様（Ｓ１９００）である。

そして、処理時間計算後、ストリームチェック処理（Ｓ４０３）を行い、マスタ処理のストリーム処理に対するビットレートが変更された場合、次にビットレートが高いストリーム処理をマスタ処理として、ストリームチェック処理を行う。

ストリーム処理のビットレートを変更しても他のストリーム処理へ影響しないと判定された場合（Ｓ４０４）、エンコーダ１４のビットレート設定を変更する（Ｓ２００２）。

さらに、ビットレート変更後のストリーム処理時間、および優先度をストリーム管理テーブル４８０に登録する（Ｓ２００３）。最後に、イベント管理部７０６で実施されるスケジューリングにストリーム管理テーブル４８０の情報を反映するためにイベント管理部７０６へストリーム処理の開始通知を行い（Ｓ４０７）処理を終了する。

このように、本実施の形態におけるストリーム制御装置７００によれば、ストリーム管理部７０７において、記録ストリームのビットレートを変更する処理を追加することで、ユーザからストリーム処理の優先度を変更することができる。従って空き時間が足りない場合に、ストリーム処理を削除するだけではなく、ビットレートを変更することで空き時間を作り、新たにストリーム処理を追加するという選択肢をユーザに持たせることができる。

（実施の形態８）
次に、本発明に係る実施の形態８について、図面を参照しながら説明する。

本実施の形態におけるストリーム制御装置のハードウェア構成は、実施の形態１におけるストリーム制御装置のハードウェア構成と同様である。しかし、機能構成において、図２６に示されるように、ストリーム管理部１０７、ストリーム管理テーブル保持部１０８の代わりに、ストリーム管理部８０７、ストリーム管理テーブル保持部８０８を備える点が異なる。そして、ストリーム管理テーブル１０８の構成要素に属性フラグと対応ＩＤの情報を追加し、イベント管理部１０６とストリーム管理部１０７に可変ビットストリーム（ＶＢＲ）制御処理を追加することで、イベント管理部１０６とストリーム管理部１０７の処理制御フローを変更したことを特徴とする。

なお、実施の形態１におけるストリーム制御装置１００によれば、ストリーム管理テーブル１８０に登録されるストリーム情報は全て固定ビットレート（ＣＢＲ）のストリームとして登録されていた。この場合、ＡＶ入力装置１１１から入力される画像に応じてストリームのビットレートが変更される可変ビットレート（ＶＢＲ）のストリームを取り扱うことができず、変動分のデータが蓄積し、バッファのオーバーフローが発生する。

しかし、本実施の形態におけるストリーム制御装置によれば、この点が改善される。
以上の点を踏まえて、本実施の形態におけるストリーム制御装置について説明する。なお、実施の形態１におけるストリーム制御装置１００の構成と同一の構成については、同一の参照符号を付して説明を省略する。

図２７は、実施の形態８におけるストリーム管理テーブル保持部８０８で保持されているストリーム管理テーブル８８０の構造を示す図である。

図２７に示されるように、ストリーム管理テーブル８８０には、実施の形態１におけるストリーム管理テーブル１８０（図４参照。）の情報に加え、属性フラグ、および対応ＩＤの管理を行っている。

属性フラグは、可変ビットレートストリーム（ＶＢＲ）であるか、固定ビットレートストリーム（ＣＢＲ）であるか、ＶＢＲのサブストリーム（ＶＢＲ−ＳＵＢ）の情報が登録される。また、対応ＩＤは、ストリーム情報とサブストリームの関連を示すために用いるものである。

図２７では、ストリームＩＤ１のストリームとストリームＩＤ２のストリームの対応関係を示すためにストリームＩＤ１のＶＢＲストリームの対応ＩＤに２、ストリームＩＤ２のＶＢＲサブストリーム情報の対応ＩＤに１が登録されている。また、サブストリーム情報が登録される際に、ビットレート、起動周期、処理時間が不要な情報として登録せずに、処理時間が０として登録されている。

図２８は、実施の形態８におけるストリーム管理部８０７のフローチャートを示す図である。

なお、実施の形態１におけるストリーム管理部１０７の制御フロー（図３参照。）と比べると、Ｓ２１００、Ｓ２１０１の処理を追加したものであり、固定ビットレートと可変ビットレートの判別を行うステップを備えることにより、可変ビットレートストリームの処理を可能としている。

なお、属性フラグは、ステップＳ４０６の処理においてストリーム情報として登録される。また、対応ＩＤは、ステップＳ２１０１の処理においてサブストリーム情報として登録される。

なお、ステップＳ２１０１の処理において、サブストリーム情報が登録される際に、ビットレート、起動周期、処理時間が不要な情報として登録せずに、処理時間が０として登録される。

図２８に示されるように、ストリーム管理部８０７は、アプリケーションプログラム実行部１１０からの記録開始要求を検出し、ストリーム管理テーブル８８０にストリーム情報を登録（Ｓ４０６）した後、ＶＢＲのストリームであるかどうかストリームの判別を行う（Ｓ２１００）。ＶＢＲのストリームでない場合は終了処理を行い、ＶＢＲのストリームである場合には、そのストリーム情報に対応したＶＢＲサブストリーム情報をストリーム管理テーブルに追加する（Ｓ２１０１）。

図２９、図３０は、実施の形態８におけるイベント管理部８０６のフローチャートを示す図である。

なお、実施の形態１におけるイベント管理部１０６の制御フロー（図５、図６参照。）と比べると、ステップＳ２３００、Ｓ２３０１、Ｓ２４００〜Ｓ２４０２の処理を追加したものである。

図２９に示されるように、イベント管理部８０６は、ストリーム処理部１０９から終了通知を受け、ストリーム管理テーブル８８０からストリーム管理情報を削除（Ｓ６０５）した後、ＶＢＲのストリームであるかどうかストリームの判別を行う（Ｓ２３００）。ＶＢＲのストリームである場合には、対応ＩＤを参照し、ステップＳ６０５の処理において削除したストリームに対応したサブストリーム情報をストリーム管理テーブルから削除する（Ｓ２３０１）。

さらに、図３０に示されるように、イベント管理部８０６は、エンコーダ１４からデータ転送通知を受理した場合の処理であり、起動中のストリーム処理部１０９が終了することを待つ処理（Ｓ７０３）を行い、タイマ満了後、ＶＢＲのストリームであるかどうかストリームの判別を行う（Ｓ２４００）。ＶＢＲのストリームである場合には、エンコーダ１４の内部バッファ１５のデータ残量を測定する（Ｓ２４０１）。データ残量から下記（７式）を用いて処理時間の計算を行った後、ＶＢＲストリームに対応したサブストリーム処理をストリーム管理テーブルの対応ＩＤを参照して検索し、処理時間を更新する。また、空き時間をサブストリーム処理に割り当てるため、空き時間からサブストリーム処理の処理時間を引き、空き時間を更新する（Ｓ２４０２）。

処理時間 ＝ Ｍａｘ（データ残量 ／ ストリーム処理部のデータ処理速度） ・・・（７式）
なお、ステップＳ２４０２において、空き時間がサブストリーム処理の処理時間に満たない場合には、空き時間の最大値を割り当て、空き時間と処理時間の更新処理を行う。また、データ残量がない場合には、処理時間を０として登録し、登録したストリームはステップＳ７０３においてタイマ起動しないようにする。

図３１は、ステップＳ２４０２（図３０参照。）の処理により、ストリーム管理テーブル８８０（図２７参照。）において、ＩＤ２のサブストリームの処理時間および空き時間が更新されたことが示される図である。なお、ストリーム管理テーブル８８１には、サブストリーム処理Ａ’の処理時間として１０ｍｓが登録され、かつ空き時間から処理時間を引き、１０５ｍｓ−１０ｍｓ＝９５ｍｓが新たな空き時間として登録されている。

このように、本実施の形態におけるストリーム制御装置８００によれば、イベント管理部１０６からストリーム処理部１０９に通知される起動要求ごとに、エンコード１４の内部バッファ１５を計測し、処理できなかったデータ残量を次の起動要求で処理できるようにストリーム管理テーブル８８０のストリーム情報を更新する処理を追加したため、図３２に示されるように、空き時間としていた時間をサブストリーム処理に割り当てて処理を行うことができ、可変ビットレートのストリーム処理に対応できる。また、ストリームが登録されていたビットレート以上になった場合のみ、ストリーム処理部１０９が内部バッファ１５に残ったデータの転送処理を行い、必要時のみ空き時間を使用するため、空き時間を他の処理に使用することができる。

（実施の形態９）
次に、本発明に係る実施の形態９について、図面を参照しながら説明する。

本実施の形態におけるストリーム制御装置のハードウェア構成は、実施の形態８におけるストリーム制御装置のハードウェア構成と同様である。しかし、機能構成において、図３３に示されるように、イベント管理部１０６、およびアプリケーションプログラム実行部１１０の代わりに、イベント管理部９０６、およびアプリケーションプログラム実行部９１０を備える点が異なる。そして、イベント管理部１０６からアプリケーションプログラム実行部１１０に対するアラーム通知処理を追加することで、イベント管理部１０６の処理制御フローを変更したことを特徴とする。

なお、実施の形態８におけるストリーム制御装置８００によれば、可変ビットレート（ＶＢＲ）ストリームの処理により、空き時間をサブストリーム処理に割り当てるため、ストリーム管理テーブル８８０におけるサブストリームの処理時間を増加させた場合、空き時間が不足することがある。しかし、アプリケーションプログラム実行部１１０では空き時間が不足している状態を知ることができなかった。

例えば、アプリケーションプログラム実行部１１０がストリームの停止処理を行わず、空き時間不足の状態を継続した場合、エンコーダ１４の内部バッファ１５がオーバーフローする危険性があり、システムの動作を保証できない。

しかし、本実施の形態におけるストリーム制御装置によれば、この点が改善される。
図３４は、実施の形態９におけるイベント管理部９０６のフローチャートを示す図である。

なお、実施の形態８におけるイベント管理部８０６の制御フロー（図３０参照。）と比べて、下記の点が異なる。

図３４に示されるように、イベント管理部９０６は、エンコーダ１４からデータ転送通知を受理し、ストリーム管理テーブル８８０の更新処理（Ｓ２４０２）を行い、データ残量から計算した処理時間と空き時間の比較から空き時間不足か否かの判定処理（Ｓ２７００）を行い、空き時間が不足している場合には、アプリケーションプログラム実行部９１０へ通知する（Ｓ２７０１）。

このように、本実施の形態におけるストリーム制御装置９００によれば、イベント管理部９０６においてアプリケーションプログラム実行部９１０に対してアラーム情報を通知する処理を追加することで、アプリケーションプログラム実行部９１０は、ストリーム処理のための空き時間を正確に知ることができ、アプリケーションプログラム実行部９１０からストリーム処理の停止やビットレートの変更などの処理を行うことで、内部バッファ１５がオーバーフローすることを未然に防ぐことができる。

（実施の形態１０）
次に、本発明に係る実施の形態１０について、図面を参照しながら説明する。

本実施の形態におけるストリーム制御装置のハードウェア構成は、実施の形態１におけるストリーム制御装置のハードウェア構成と同様である。しかし、機能構成において、図３５に示されるように、イベント管理部１０６、ストリーム管理部１０７、ストリーム管理テーブル保持部１０８、およびアプリケーションプログラム実行部１１０の代わりに、イベント管理部１００６、ストリーム管理部１００７、ストリーム管理テーブル保持部１００８、およびアプリケーションプログラム実行部１０１０を備える点が異なる。そして、ストリーム管理テーブル１８０の構成要素に周期フラグを追加し、イベント管理部１０６とストリーム管理部１０７に非周期的に動作する処理の制御処理を追加することで、イベント管理部９０６とストリーム管理部１０７の処理制御フローを変更したことを特徴とする。

なお、実施の形態１におけるストリーム制御装置１００において、ストリーム管理テーブル１８０に登録されるストリーム情報は一定のビットレートでエンコーダ１４においてエンコードされ、ストリーム処理部１０９において周期的にストリーム処理されるストリームを登録の対象としていた。この場合、静止画記録処理など非周期的に起動要求が発生するストリームには対応しておらず、周期的に起動される前記ストリーム処理の空き時間中に処理されるため、非周期のストリーム処理の終了時間がアプリケーションプログラム実行部１１０にはわからない。

しかし、本実施の形態におけるストリーム制御装置によれば、この点が改善される。
以上の点を踏まえて、本実施の形態におけるストリーム制御装置について説明する。なお、実施の形態１におけるストリーム制御装置１００の構成と同一の構成については、同一の参照符号を付して説明を省略する。

図３６は、実施の形態１０におけるストリーム管理テーブル保持部１００８で保持されているストリーム管理テーブル１０８０の構造を示す図である。

図３６に示されるように、ストリーム管理テーブル１０８０には、実施の形態１におけるストリーム管理テーブル１８０（図４参照。）の情報に加え、周期フラグの管理を行っている。

周期フラグは、周期ストリーム（cyclic）および非周期ストリーム（non-cyclic）を判別するための情報が登録される。ストリーム管理テーブル１０８０では、ストリームＩＤ１〜３のストリームが周期ストリームとして登録され、ストリームＩＤ４のストリームが非周期ストリームとして登録されていることが示されている。

図３７は、実施の形態１０におけるストリーム管理部１００７のフローチャートを示す図である。

なお、実施の形態１におけるストリーム管理部１０７の制御フロー（図３参照。）と比べて、ステップＳ２８００〜Ｓ２８０７の処理を追加したものであり、周期ストリーム処理と非周期ストリーム処理の判別を行うステップを備えることにより、非周期ストリームの処理を可能としている。

なお、周期フラグは、ステップＳ４０６の処理においてストリーム情報として登録される情報である。

図３７に示されるように、ストリーム管理部１００７は、アプリケーションプログラム実行部１０１０からの記録開始要求を検出し、周期ストリームであるかどうか判別を行う（Ｓ２８００）。周期ストリームでない場合、非周期ストリームであると判断し、エンコーダ１４にエンコードの開始要求を行い（Ｓ２８０１）、エンコード処理が完了するまで待つ（Ｓ２８０２）処理を行い、エンコード処理完了後に内部バッファ１５の蓄積されたデータ量を計測（Ｓ２８０３）し、データ量とストリーム処理部１０９のストリーム処理時間から非周期ストリーム処理に必要な処理時間を計算する（Ｓ２８０４）。非周期ストリーム処理が実行可能な時間を確認するため、既に実行されているストリーム処理の有無を判別（Ｓ２８０５）し、既に実行されているストリームがない場合には、非周期ストリームのストリーム処理時間に制約が無いものと判断し、ストリーム管理テーブルへの登録（Ｓ４０６）を行う。既に実行されているストリームがある場合には、ストリーム管理テーブル１０８０のストリーム管理情報から空き時間を取得し、（８式）で計算したストリーム処理の分割数にストリーム処理を分割（Ｓ２８０６）する。

ストリーム処理分割数 ＝ （処理時間 ／ 空き時間）＋１ ・・・（８式）
次に、ストリーム処理の終了時間を計算するため、ストリーム管理テーブル１０８０から優先度１の処理の起動周期を取得し、（９式）による計算を行い、計算結果をアプリケーションプログラム実行部１０１０に通知する（Ｓ２８０７）。

ストリーム処理終了時間 ＝ 優先度１の処理の起動周期 ＊ ストリーム処理分割数 ・・・（９式）
図３８は、実施の形態１０におけるイベント管理部１００６のフローチャートを示す図である。

なお、実施の形態１におけるイベント管理部１０６の制御フロー（図６参照。）と比べて、ステップＳ３０００〜Ｓ３００３の処理を追加したものである。

図３８に示されるように、イベント管理部１００６は、ストリーム処理部１０９へのデータ転送通知（Ｓ７０１）を行った後、ストリーム管理テーブル１０８０のストリーム管理情報の周期フラグを参照し、全ての周期ストリーム処理のスケジューリングの完了を判別（Ｓ３０００）し、全ての周期ストリーム処理のスケジューリングが完了すれば、非周期ストリームの処理（Ｓ３００１〜Ｓ３００３）を開始する。ストリーム管理テーブル１０８０に登録されている非周期ストリームのストリーム処理部１０９へデータ転送通知を行い（Ｓ３００１）、ストリーム管理テーブル１０８０の非周期ストリームの空き時間を参照し、非周期ストリームの処理時間が空き時間より長い場合には、空き時間でタイマの起動を行い、非周期ストリームの処理時間が空き時間以下の場合には、非周期ストリームの処理時間でタイマの起動を行うことで、起動中のストリーム処理部１０９が終了することを待つ（Ｓ３００２）。ストリーム管理テーブル１０８０の非周期ストリームの処理時間について、非周期ストリームの処理時間が空き時間より長い場合には処理時間から空き時間を引いた値で更新し、非周期ストリームの処理時間が空き時間以下の場合には、処理時間を０とする（Ｓ３００３）。

このように、本実施の形態におけるストリーム制御装置１０００によれば、ストリーム管理部１００７により、周期ストリームと非周期ストリームを判別し、ストリーム管理テーブル１０８０への登録を行う時点で、非周期ストリーム処理の完了時間の予測を行うことができる。

なお、図１、図２では複数のエンコーダ１４で構成される例を示しているが、この例にとらわれることなくＤＳＰで複数のエンコード処理を並列実行するものでも良い。また、データ転送装置１２の代わりに共有メモリが利用されてもよい。

なお、ストリーム制御装置において実行されて本発明に係る１以上の機能が実現されるプログラム（以下、ストリーム制御プログラムと呼称する。）は、コンピュータシステム、組み込みシステムなどのようなハードウェアシステムに読み出され得るように、光学記録媒体（例えば、ＣＤ−ＲＯＭなど。）、磁気記録媒体（例えば、ハードディスクなど。）、光磁気記録媒体（例えば、ＭＯなど。）、半導体メモリ（例えば、メモリカードなど。）などのようなコンピュータ読み取り可能な記録媒体に記録しておくとしてもよい。そして、これ等の記録媒体を介して、他のハードウェアシステムにおいて実行されるとしてもよい。

また、ネットワーク上のハードウェアシステムにストリーム制御プログラムを保持しておき、ネットワークを介してストリーム制御プログラムをダウンロードした他のハードウェアシステムにおいて実行されるとしてもよい。

以上、本発明に係ることを実施の形態に基づいて説明をしたが、本発明はこれらの実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で変更可能である。

本発明にかかるストリーム制御装置およびストリーム制御方法は、複数のストリームに対する処理時間の効率を低下させることなく、複数のオーディオやビデオストリームを高効率でかつ精度よく記録するものであり、カメラやチューナーから入力された映像や音声のストリームを同時に記録するような携帯端末装置や、ＰＣ（Personal Computer）上のアプリケーションでリアルタイムに複数の映像や音声を記録する用途にも応用できる。

本発明の実施の形態１のストリーム制御装置を示すシステム構成図 本発明の実施の形態１のストリーム制御装置を示す処理ブロック図 本発明の実施の形態１のストリーム制御装置におけるストリーム管理部のフローチャート 本発明の実施の形態１におけるストリーム管理テーブルの構造を示す図 本発明の実施の形態１のストリーム制御装置におけるイベント管理部のフローチャート（開始、終了時） 本発明の実施の形態１のストリーム制御装置におけるイベント管理部のフローチャート（処理中） 本発明の実施の形態１のストリーム制御装置を実行した場合のスケジューリング結果を示す図 本発明の実施の形態２のストリーム制御装置を示す処理ブロック図 （ａ）本発明の実施の形態１のストリーム制御装置を実行した場合のスケジューリング結果を示す図、（ｂ）本発明の実施の形態２のストリーム制御装置を実行した場合のスケジューリング結果を示す図 本発明の実施の形態２におけるストリーム管理テーブルの構造を示す図 本発明の実施の形態２のストリーム制御装置におけるストリーム管理部のフローチャート 本発明の実施の形態２のストリーム制御装置におけるイベント管理部のフローチャート（開始、終了時） 本発明の実施の形態３のストリーム制御装置を示す処理ブロック図 本発明の実施の形態３におけるストリーム管理テーブルの構造を示す図 本発明の実施の形態３のストリーム制御装置におけるイベント管理部のフローチャート（処理中） 本発明の実施の形態３のストリーム制御装置を実行した場合のスケジューリング結果を示す図 本発明の実施の形態４のストリーム制御装置を示す処理ブロック図 本発明の実施の形態４におけるストリーム管理テーブルの構造を示す図 本発明の実施の形態４のストリーム制御装置を実行した場合のスケジューリング結果を示す図 本発明の実施の形態５のストリーム制御装置を示す処理ブロック図 本発明の実施の形態５のストリーム制御装置におけるストリーム管理部のフローチャート 本発明の実施の形態６のストリーム制御装置を示す処理ブロック図 本発明の実施の形態６のストリーム制御装置におけるストリーム管理部のフローチャート 本発明の実施の形態７のストリーム制御装置を示す処理ブロック図 本発明の実施の形態７のストリーム制御装置におけるストリーム管理部のフローチャート（ビットレート変更時） 本発明の実施の形態８のストリーム制御装置を示す処理ブロック図 本発明の実施の形態８におけるストリーム管理テーブルの構造を示す図 本発明の実施の形態８のストリーム制御装置におけるストリーム管理部のフローチャート 本発明の実施の形態８のストリーム制御装置におけるイベント管理部のフローチャート（開始、終了時） 本発明の実施の形態８のストリーム制御装置におけるイベント管理部のフローチャート（処理中） 本発明の実施の形態８におけるストリーム管理テーブルの変化を示す図 本発明の実施の形態８のストリーム制御装置を実行した場合のスケジューリング結果を示す図 本発明の実施の形態９のストリーム制御装置を示す処理ブロック図 本発明の実施の形態９のストリーム制御装置におけるイベント管理部のフローチャート（処理中） 本発明の実施の形態１０のストリーム制御装置を示す処理ブロック図 本発明の実施の形態１０におけるストリーム管理テーブルの構造を示す図 本発明の実施の形態１０のストリーム制御装置におけるストリーム管理部のフローチャート 本発明の実施の形態１０のストリーム制御装置におけるイベント管理部のフローチャート（処理中） 従来の方法による構成図およびスケジューリング結果を示す図

符号の説明

１０ 記憶装置
１１ ＣＰＵ
１２ データ転送装置
１３ 外部ＩＯ装置
１４ エンコーダ
１５ エンコーダの内部バッファ
１６ ＡＶ入力装置
１００ ストリーム制御装置
１０６ イベント管理部
１０７ ストリーム管理部
１０８ ストリーム管理テーブル保持部
１０９ ストリーム処理部
１１０ アプリケーションプログラム実行部

Claims (14)

1. ストリームをエンコードするエンコーダを複数有し、エンコード後のストリームデータを外部記憶装置に転送するストリーム処理をエンコーダ毎に起動するストリーム制御装置であって、
   ストリーム処理に付与される優先度、前記ストリーム処理に割り当てられる処理時間、および前記ストリーム処理に設定された起動周期がストリーム処理毎に登録されるストリーム管理テーブルを保持するストリーム管理テーブル保持手段と、
   前記ストリーム管理テーブルに登録されている中で最も優先度の高いストリーム処理を基準となるストリーム処理に設定し、前記ストリーム管理テーブルに登録されている全てのストリーム処理が前記基準となるストリーム処理の起動周期内に逐次処理される条件で、前記ストリーム管理テーブルに登録予定のストリーム処理に処理時間を割り当てるストリーム管理手段と、
   前記基準となるストリーム処理の起動周期内に前記基準となるストリーム処理から優先度順で逐次処理される条件で、各ストリーム処理に割り当てられた処理時間を割り当て直すイベント管理手段と
   を備えることを特徴とするストリーム制御装置。
2. 前記イベント管理手段は、
   前記ストリーム管理テーブルに登録されているストリーム処理のうち、優先度の高い方を第１のストリーム処理とし、優先度の低い方を第２のストリーム処理とした場合において、第１のストリーム処理の終了時刻に、前記第２のストリーム処理の開始時刻を同期させる
   ことを特徴とする請求項１に記載のストリーム制御装置。
3. 前記ストリーム管理手段は、
   最大ビットレートが割り当てられたストリーム処理を前記基準となるストリーム処理に設定し、前記基準となるストリーム処理の起動周期内に、前記ストリーム管理テーブルに登録されている他のストリーム処理に割り当てられた処理時間を割り当て直す
   ことを特徴とする請求項１に記載のストリーム制御装置。
4. 前記ストリーム管理テーブルには、前処理時間、および後処理時間がストリーム処理毎に登録されており、
   前記ストリーム管理手段は、
   前記前処理時間、前記後処理時間、および前記ストリーム処理の処理時間を加算したストリーム処理時間の単位で、前記ストリーム管理テーブルに登録されている全てのストリーム処理が基準となるストリーム処理に設定された起動周期内に逐次処理される条件で、前記登録予定のストリーム処理に処理時間を割り当てる
   ことを特徴とする請求項１に記載のストリーム制御装置。
5. 前記ストリーム管理テーブルには、予約処理時間がストリーム処理毎に登録されており、
   前記ストリーム管理手段は、
   前記予約処理時間を含めて、前記ストリーム管理テーブルに登録されている全てのストリーム処理が基準となるストリーム処理の起動周期内に逐次処理される条件で、前記登録予定のストリーム処理に処理時間を割り当てる
   ことを特徴とする請求項１に記載のストリーム制御装置。
6. 前記イベント管理手段は、
   前記ストリーム管理テーブルに登録されているストリーム処理のうち、優先度の高い方を第１のストリーム処理とし、優先度の低い方を第２のストリーム処理とした場合において、前記ストリーム処理時間に基づいて、第１のストリーム処理の終了時刻に、前記第２のストリーム処理の開始時刻を同期させる
   ことを特徴とする請求項４又は５に記載のストリーム制御装置。
7. 前記ストリーム制御装置は、
   アプリケーションプログラムを実行するアプリケーションプログラム実行手段を備え、
   前記ストリーム管理手段は、
   前記基準となるストリーム処理の起動周期内に全てのストリーム処理が逐次処理できない場合には、アラーム信号を前記アプリケーションプログラム実行手段に出力する
   ことを特徴とする請求項１に記載のストリーム制御装置。
8. 前記ストリーム管理手段は、
   前記基準となるストリーム処理の起動周期内に全てのストリーム処理が逐次処理できない場合には、各ストリーム処理のビットレートを変更する
   ことを特徴する請求項１に記載のストリーム制御装置。
9. 前記ストリーム管理手段は、
   ストリームデータを外部記憶装置に転送中のストリーム処理のビットレートを変更し、
   前記イベント管理手段は、
   ビットレート変更後、前記転送中のストリーム処理の起動時間を再設定する
   ことを特徴とする請求項１に記載のストリーム制御装置。
10. 前記ストリーム管理テーブルには、固定ビットレートのストリームおよび可変ビットレートのストリームのいずれかが特定される属性フラグ、およびストリーム処理同士の対応関係が特定される対応ＩＤがストリーム処理毎に登録されており、
    前記イベント管理手段は、
    前記属性フラグに基づいて、固定ビットレートのストリームおよび可変ビットレートのストリームのいずれかを判定し、可変ビットレートのストリームである場合には、前記ストリーム処理の起動周期ごとに前記エンコーダの内部バッファのデータの残量、および前記ストリーム処理のデータ処理速度に基づいて、前記可変ビットレートのストリームに対するストリーム処理の処理時間を割り当て直す
    ことを特徴とする請求項１に記載のストリーム制御装置。
11. 前記ストリーム制御装置は、
    アプリケーションプログラムを実行するアプリケーションプログラム実行手段を備え、
    前記ストリーム管理テーブルには、固定ビットレートのストリームおよび可変ビットレートのストリームのいずれかが特定される属性フラグ、およびストリーム処理同士の対応関係が特定される対応ＩＤがストリーム処理毎に登録されており、
    前記イベント管理手段は、
    前記属性フラグに基づいて、固定ビットレートのストリームおよび可変ビットレートのストリームのいずれかを判定し、可変ビットレートのストリームである場合には、前記ストリーム処理の起動周期ごとに前記エンコーダの内部バッファのデータの残量、および前記ストリーム処理のデータ処理速度から特定される処理時間に基づいて、前記可変ビットレートのストリームに対するストリーム処理の処理時間を割り当て直し、処理中に割り当て直された前記ストリーム処理の処理時間が、ストリーム処理が起動されるまでの空き時間を越える場合には、アラーム信号を前記アプリケーションプログラム実行手段に出力する
    ことを特徴とする請求項１に記載のストリーム制御装置。
12. 前記ストリーム制御装置は、
    アプリケーションプログラムを実行するアプリケーションプログラム実行手段を備え、
    前記ストリーム管理テーブルには、周期ストリームおよび非周期ストリームのいずれかが特定される周期フラグがストリーム処理毎に登録されており、
    前記ストリーム管理手段は、
    前記周期フラグに基づいて、周期ストリームおよび非周期ストリームのいずれかを判定し、非周期ストリームである場合には、ストリーム処理が起動されるまでの空き時間、および非周期ストリームの処理時間に基づいて、非周期ストリームのストリーム処理を分割し、分割したストリーム処理から特定される終了時間をアプリケーションプログラム実行手段に通知する
    ことを特徴とする請求項１に記載のストリーム制御装置。
13. ストリームをエンコードするエンコーダを複数有し、エンコード後のストリームデータを外部記憶装置に転送するストリーム処理をエンコーダ毎に起動するストリーム制御方法であって、
    ストリーム処理に付与される優先度、前記ストリーム処理に割り当てられる処理時間、および前記ストリーム処理に設定された起動周期がストリーム処理毎に登録されるストリーム管理テーブルを生成するストリーム管理テーブル生成ステップと、
    前記ストリーム管理テーブルに登録されている中で最も優先度の高いストリーム処理を基準となるストリーム処理に設定し、前記ストリーム管理テーブルに登録されている全てのストリーム処理が前記基準となるストリーム処理の起動周期内に逐次処理される条件で、前記ストリーム管理テーブルに登録予定のストリーム処理に処理時間を割り当てるストリーム管理ステップと、
    前記基準となるストリーム処理の起動周期内に前記基準となるストリーム処理から優先度順で逐次処理される条件で、各ストリーム処理に割り当てられた処理時間を割り当て直すイベント管理ステップと
    を含むことを特徴とするストリーム制御方法。
14. ストリームをエンコードするエンコーダを複数有し、エンコード後のストリームデータを外部記憶装置に転送するストリーム処理をエンコーダ毎に起動するストリーム制御プログラムであって、
    ストリーム処理に付与される優先度、前記ストリーム処理に割り当てられる処理時間、および前記ストリーム処理に設定された起動周期がストリーム処理毎に登録されるストリーム管理テーブルを生成するストリーム管理テーブル生成ステップと、
    前記ストリーム管理テーブルに登録されている中で最も優先度の高いストリーム処理を基準となるストリーム処理に設定し、前記ストリーム管理テーブルに登録されている全てのストリーム処理が前記基準となるストリーム処理の起動周期内に逐次処理される条件で、前記ストリーム管理テーブルに登録予定のストリーム処理に処理時間を割り当てるストリーム管理ステップと、
    前記基準となるストリーム処理の起動周期内に前記基準となるストリーム処理から優先度順で逐次処理される条件で、各ストリーム処理に割り当てられた処理時間を割り当て直すイベント管理ステップと
    をコンピュータシステムに実行させることを特徴とするストリーム制御プログラム。

Images