JP2002312331A

JP2002312331A - メディアアクセラレータのサービス品質

Info

Publication number: JP2002312331A
Application number: JP2001364987A
Authority: JP
Inventors: Rajko Milovanovic; ミロヴァノヴィクライコ; Philip R Thrift; アール、スリフトフィリップ
Original assignee: Texas Instruments Inc
Current assignee: Texas Instruments Inc
Priority date: 2000-11-29
Filing date: 2001-11-29
Publication date: 2002-10-25
Also published as: US20020112097A1; EP1229444A1; US7140016B2

Abstract

(57)【要約】【課題】汎用プロセッサストリーミングメディアアプ
リケーションおよび／またはＤＳＰメディアアルゴリズ
ムを有するメディアプレイヤを統合するためのサービス
品質（ＱｏＳ）制御を実時間プラットフォームに提供す
ること。【解決手段】アルゴリズムプロセッサと連絡するアプ
リケーションプロセッサ上の実時間メディアアプリケー
ションのためのフレームワーク。アプリケーションプロ
セッサ上に実時間メディアアプリケーション用の複数の
プラグインを備え、アルゴリズムプロセッサ上に複数の
アルゴリズムコンポーネントとコンポーネントスケジュ
ーラとを備え、プラグインはそれぞれ１以上のアルゴリ
ズムコンポーネントに対応し、アルゴリズムプロセッサ
はアプリケーションプロセッサに連絡し、スケジューラ
は、コンポーネントの実行に関連するプラグインの制御
に応じたコンポーネントスケジューリングと、プラグイ
ンに送出するコンポーネントの実行に関するイベントの
通知とによって、コンポーネントに関してアプリケーシ
ョンにサービス品質を提供する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、電子デバイスに関
し、更に詳細に言えば、マルチプロセッサ及びデジタル
シグナルプロセッサのフレームワークと方法に関する。

【０００２】

【従来の技術】高速ネットワークアクセスと結びついた
インターネットの成長によって、実時間マルチメディア
処理はコンピュータ利用中心になった。実際、既に提案
されているマルチメディアフレームワークアーキテクチ
ャのＭＰＥＧ−２１規格化では、デジタルアイテムの定
義、マルチメディアコンテンツ表現、デジタルアイテム
の同定と説明、コンテンツの管理と使用、知的所有権の
管理と保護、端末とネットワーク、そして、イベント報
告という７つの構成要素が考えられている。こうしたア
ーキテクチャを持つアプリケーションは、インターネッ
ト上に接続し編集設備を有する、広範囲に分散した家族
メンバーのコンピュータに配布される写真アルバムの作
成に関するものであったり、あるいは、サービス品質
（ＱｏＳ）の解決と利用可能な端末及びネットワークリ
ソースを必要とし消費前に発行される、関連同時追加コ
ンテンツを利用可能なインターネットストリーミングビ
デオの消費であったりして良い。

【０００３】ＭＰＥＧ−２１提案の標準インターフェイ
スは、ネットワーク及び端末の設置、管理、および、実
行の諸問題から利用者を保護することが目的である。こ
うしたアーキテクチャは各端末にグローバルなＱｏＳマ
ネージャを含むことができる。ＱｏＳマネージャは、端
末リソースマネージャと予測マネージャーとを制御して
ネットワークリソースマネージャと予測マネージャとと
もにＡＰＩを通じて利用者と対話する。一般的なネット
ワークアーキテクチャを示す図２５及び図２４を参照さ
れたい。

【０００４】端末／ネットワークノード（クライアント
／サーバー）内におけるＱｏＳマネージャの必要性は、
特に、全てのストリーミングメディア系アプリケーショ
ンの実時間サービス要件から生じる。ストリーミングメ
ディアアプリケーションは、独自のレンダリング期限を
持つ異種のコーデック（エンコーダ／デコーダ）とフィ
ルタとを取り扱わなければならない。これらのアプリケ
ーションは、人間の知覚特性をサービス品質における段
階的異常停止に利用および翻訳もできるべきである。ア
プリケーションは、その処理及びレンダリングサイクル
において妥当な量のジッタを処理できるべきである。例
えば、ビデオアプリケーションでは、レンダリングのフ
レームレートは３０フレーム／秒（ｆｐｓ）、フレーム
周期に換算すると３３ｍｓに維持されなければならな
い。しかし、アプリケーションは、サーバーと取り決め
る際に瞬間的変動制限に耐えられるべきである。また、
３０ｆｐｓでは、人間の視覚は、約６フレーム／秒のフ
レーム落ちに耐えることができる。クライアントアプリ
ケーションは、さらに、性能における段階的異常停止
（瞬間的なフレーム落ち）をサポートでき、サーバーと
取り決めた特定の許容差内にレンダリングの定常状態を
維持しなければならない。ＱｏＳマネージャは、こうし
た実時間システムを実現するのに必要な機能と能力を提
供する機構である。

【０００５】マイクロソフト・ダイレクトショーは、ロ
ーカルファイルやインターネットサーバーからのマルチ
メディアストリームを再生するために、および、装置か
らマルチメディアストリームを取り込むために汎用プロ
セッサ上にアプリケーションフレームワークを提供す
る。ダイレクトショーは、フィルタの接続とフィルタ経
由のストリームのデータフローを制御するフィルタグラ
フマネージャと共にプラグ可能なフィルタコンポーネン
トからなるフィルタグラフを中心とする。アプリケーシ
ョンは、フィルタグラフマネージャと連絡してフィルタ
グラフを制御する。図２６を参照されたい。インターネ
ットからの再生には、単に、ソースフィルタがインター
ネットのＵＲＬから読み出し可能であるとが必要なだけ
である。ソースフィルタ後の構文解析プログラムフィル
タは、オーディオ、ビデオ、テキストなどにストリーム
を構文解析することができる。図２７を参照されたい。
フィルタグラフマネージャは、選択のためのメリット値
を持つレジストリにおいて必要なフィルタ（例えば、レ
ンダラ）を制御し検索する。フィルタは、フィルタ入出
力用のピンを持っている。フィルタグラフマネージャ
は、メディアストリーム開始、一時停止、再生期間など
を、フィルタの方法にアクセスするフィルタグラフマネ
ージャへのアプリケーション・アクティブＸ制御呼び出
しによってサポートする。フィルタグラフマネージャ
は、イベントをフィルタからアプリケーションに送る。

【０００６】フィルタは、タスクを実行するためのＣＯ
Ｍオブジェクトであり、ピンは、フィルタから／への一
方向データストリームのためにフィルタによって作成さ
れるＣＯＭオブジェクトである。図２８を参照された
い。フィルタはＩＢａｓｅＦｉｌｔｅｒインターフェイ
スを有し、ピン、プロパティなどを計数して、実行、一
時停止、停止などの状態処理の制御に加えて同期化を可
能にするＩＭｅｄｉａＦｉｌｔｅｒから継承する。フィ
ルタは、フィルタグラフマネージャによって呼び出され
る。ピンインターフェイスは、共有メモリや他のリソー
スを用いたタイムスタンプ付きデータの転送、ピン間接
続におけるネゴシエートデータフォーマット、データコ
ピーの最小化とデータ処理量の最大化のためのバッファ
管理・割当をサポートする。ＩＱｕａｌｉｔｙＣｏｎｔ
ｒｏｌインターフェイスは出力ピン上にある。

【０００７】品質制御データを含むフィルタグラフ（プ
ロトコル）におけるデータフローは、レンダラで生じ
て、メディアデータフロー変更が可能なフィルタが見つ
かるまでフィルタを通じて上流に（あるいはＱＣＭに）
流れる。例えば、メディアサンプルプロトコルは、メデ
ィアサンプルを如何にフィルタ間に割り当てて通過させ
るかである。品質管理プロトコルは、フィルタグラフを
ハードウェア及びネットワーク状態に対して動的に適応
させて性能を如何に段階的に低下／向上させるかであ
る。

【０００８】プッシュあるいはプルどちらかによるメデ
ィアサンプルデータフローは、下流フィルタからのＩＭ
ｅｍＩｎｐｕｔＰｉｎ：：Ｒｅｃｅｉｖｅコールによる
ソースフィルタのプッシュ、あるいは、ＩＡｓｙｎｃＲ
ｅａｄｅｒインターフェイス（ＩＡｓｙｎｃＲｅａｄｅ
ｒトランスポート）による下流プルである。メディアサ
ンプルは、ＩＭｅｄｉａＳａｍｐｌｅインターフェイス
をサポートするデータオブジェクトである。あるフィル
タから別のフィルタへ転送するデータは、「トランスポ
ート」と呼ばれ、ダイレクトショーの分類ではローカル
メモリトランスポートのためのサポートがあり、入力ピ
ンがＩＭｅｍＩｎｐｕｔＰｉｎインターフェイス及び出
力ピンをサポートする。ＩＡｓｙｎｃＲｅａｄｅｒイン
ターフェイスはプル用である。

【０００９】ノーテンブームのＵＳＰ５，７４８，４６
８及びイクエーター・テクノロジーズのＰＣＴ公表出願
ＷＯ９９／１２０９７は、それぞれ、多重タスクへのプ
ロセッサリソースの割り当て方法を記載している。ノー
テンブームでは、ホストプロセッサに加えて、タスクを
優先順位システムによってコプロセッサリソースに割り
当てるコプロセッサが考えられている。イクエーター・
テクノロジーズでは、少なくと１サービスレベル（プロ
セッサリソース消費率）を与えられた各タスクをサポー
トしながら、タスクの時間消費に応じてプロセッサリソ
ースのスケジュールを決め、サポートしたサービスレベ
ルのための十分なリソースが存在するならリソースマネ
ージャがタスクを許可する。

【００１０】２つ以上のプロセッサを備え、各プロセッ
サが独自のオペレーティングシステムあるいはＢＩＯＳ
を備えたシステムとしては、遠く離れたプロセッサをイ
ンターネット経由で接続したシステムと、１つのＲＩＳ
ＣＣＰＵに１つ以上のＤＳＰを加えたものなど、２つ
以上のプロセッサを同一半導体ダイ上に統合したシステ
ムがある。

【００１１】ＸＤＡＩＳ規格には、ＤＳＰ上で実行する
アルゴリズムのインターフェイスが規定される。これは
再使用可能オブジェクトを提供する。ＸＤＡＩＳは、標
準インターフェイスＩＡＬＧを実現するアルゴリズムに
加えて、このアルゴリズムを実行するための拡張を必要
とする。ＸＤＡＩＳは、また、再配置可能コードや命名
規則などの若干の柔軟性規則にも従わなければならな
い。クライアントアプリケーションは、ファンクション
ポインタのテーブルを訪問してアルゴリズムのインスタ
ンスを管理できる。ＸＤＡＩＳ規格・指針によれば、ア
ルゴリズム開発者はアルゴリズムを開発または変換でき
るので、ＤＳＰアプリケーション内にプラグインするの
がより簡単になる。

【００１２】図２０は、データが如何に現在の異種シス
テムの処理素子を通過して流れるかということを示す図
である。データトランザクションには、時間順を示すよ
うに１から６の番号を付けている。各トランザクション
に対して、データは、中央制御プロセッサ（ＣＣＰ）の
制御下にシステムバスを通過せねばならない。ＣＣＰ
は、メッセージまたはトリガーを制御経路経由でシステ
ム内の各種処理素子に送出することによってトランザク
ションを開始する。

【００１３】図２０の処理素子は、一組の定義されたタ
スクを実行可能な別個のプロセッサ（例えば、ＤＳＰ、
ＡＳＩＣ、ＧＰＰなど）として示されている。それはそ
れぞれのプロセッサが独自のメモリを有して示されてい
る理由である。処理素子は、同一プロセッサ上で実行さ
れる個々のタスクであっても良い。

【００１４】同一データが複数回（例えば、トランザク
ション１と２、３と４、および、５と６）システムバス
を通過せねばならない場合がある。そうしたシステムで
は、データは、合計２＋（２×ｎ）回、即ちこの場合は
６回、システムバスを通過せねばならない。システムバ
スを通過してＣＣＰによる介入を受ける度に、データフ
ローオーバーヘッドを生じるのでシステムス全体のスル
ープットは低下する。

【００１５】データフローオーバーヘッドは、所定の時
間のフレームにおいてシステムを移動可能なデータ量に
対してマイナスの影響を与えるので、システムが処理可
能なデータ量を制限する。こうしたシステムは、その素
子の能力の合計が示すものよりも少ない有効タスクしか
実行していないことになる。

【００１６】

【発明が解決しようとする課題】本発明は、汎用プロセ
ッサストリーミングメディアアプリケーションおよび／
またはＤＳＰメディアアルゴリズムを有するメディアプ
レイヤを統合するためのサービス品質（ＱｏＳ）制御を
持つ実時間プラットフォームを提供する。これには、Ｄ
ＳＰを含むシステム上においてＤＳＰアルゴリズムを使
用するアプリケーションのためのクライアントアプリケ
ーションプログラミングを簡単にする利点がある。

【００１７】

【発明の実施の形態】１．概要好適な実施例（ｉＤＳＰ）は、汎用プロセッサ（ＧＰ
Ｐ）ストリーミングメディアアプリケーションおよび／
またはコーデック、トランスフォーム、レンダラ、キャ
プチャラ、ソース、シンクなどのＤＳＰメディアアルゴ
リズムを有するメディアプレイヤを統合するためのサー
ビス品質（ＱｏＳ）制御を持つ実時間プラットフォーム
を提供する。

【００１８】ｉＤＳＰは、（１）ＸＤＡＩＳアルゴリズ
ム規格に準拠したメディアドメインフレームワークと、
（２）多重並行メディアストリームの処理および管理
と、（３）保証インボックスＱｏＳおよびＭＰＥＧ−２
１準拠の実時間メディア処理とを提供する。ＧＰＰアプ
リケーションには、各種フィルタがｉＤＳＰプラグイン
と統合型ＤＳＰ上の対応ｉＤＳＰコンポーネントとで置
換されたダイレクトショーアプリケーションが含まれ
る。

【００１９】図１ａ−１ｃは、ｉＤＳＰフレームワーク
を模式的に示し、それにはＤＳＰアルゴリズムａｌｇ
１、．．．ａｌｇ３（ｉＤＳＰコンポーネント）を、Ｄ
ＳＰにブリッジしたＲＩＳＣプロセッサ（ＧＰＰ）を含
むハードウェアプラットフォーム上の対応ＧＰＰプロキ
シオブジェクトｐ＿ａｌｇ１、．．．ｐ＿ａｌｇ３（ｉ
ＤＳＰプラグイン）を通して１つのＧＰＰメディアアプ
リケーションに統合する。このとき、ＧＰＰは実時間Ｏ
Ｓ（ＲＴＯＳ）を実行している。フレームワークは、ア
プリケーション開発者のためのＡＰＩとアルゴリズム開
発者のためのＡＰＩを有する。付録にあるｉＤＳＰプロ
グラマーズガイドでは、それらのＡＰＩに加えて、Ｇ．
７２３オーディオデコーディングをｉＤＳＰによって加
速したダイレクトショーアプリケーションの例に関する
詳細が提供される。

【００２０】２．サービス品質設計図２ａ−２ｂは、好適な実施例のｉＤＳＰフレームワー
クとスケジューラを模式的に示す。図２ａは、ＧＰＰア
プリケーションにおけるプラグインとＤＳＰ上のアルゴ
リズムの対応データグラフとの間のデータ及び制御フロ
ーを示す。実際には、プラグインＡのためのデータフロ
ーグラフは２つのトラックに５つのアルゴリズムを有
し、プラグインＢのためのデータフローグラフは２つの
アルゴリズムとデータリターンを有する。図２ｂは、ア
ルゴリズム優先順位解析を含むｉＤＳＰスケジューラの
実行を示す。ｉＤＳＰフレームワークにおけるＱｏＳサ
ポートは、スケジューラからプラグインへ送られるイベ
ント通知とプラグインからスケジューラへの制御を含
む。これによってプラグインを用いるアプリケーション
はＱｏＳを嵌め込むことが可能になる。特に、 −−ＩＤＳＰＰｌｕｇｉｎは、１つ以上のＩＤＳＰＣｏ
ｍｐｏｎｅｎｔのデータフロー（有向非環式）グラフへ
のアプリケーションインターフェイスである。 −−ＩＤＳＰＰｌｕｇｉｎは、一組の入出力ＩＤＳＰＦ
ｏｒｍａｔ形式を特定することによって作成される。 −−ＩＤＳＰＰｌｕｇｉｎへのデータＩ／Ｏインターフ
ェイスは、タイムスタンプ付き発行／再要求モデルであ
り、ＩＤＳＰＰｌｕｇｉｎを用いるアプリケーションか
らのメディアバッファがプレゼンテーション時間でスタ
ンプされる。 −−矢印は、ＩＤＳＰＰｌｕｇｉｎとＩＤＳＰＣｏｍｐ
ｏｎｅｎｔ間、および、ＩＤＳＰＣｏｍｐｏｎｅｎｔ間
のＩＤＳＰＢｕｆｆｅｒ（タイムスタンプ付きメディア
バッファ）のデータフローを示す。 −−ＩＤＳＰＢｕｆｆｅｒはタイムスタンプ（ＩＤＳＰ
時間）付きである。 −−ＩＤＳＰＳｃｈｅｄｕｌｅｒは、ＩＤＳＰＣｏｍｐ
ｏｎｅｎｔのオンタイム実行を最適化してメディアのオ
ンタイム（同期）プレゼンテーション（オーディオ及び
ビデオ）を維持する。 −−ＩＤＳＰＱｏＳＥｖｅｎｔは、ＩＤＳＰＰｌｕｇｉ
ｎによって非同期に受信される。この形式には次のもの
がある。ＩＤＳＰＱｏＳ＿ＡＬＧ＿ＣＯＭＰＬＥＴＥＤＩＤＳＰＱｏＳ＿ＰＲＥＳＥＮＴＡＴＩＯＮ＿ＴＩＭＥ
＿ＮＯＴ＿ＭＥＴＩＤＳＰＱｏＳ＿ＩＮＳＵＦＦＩＣＩＥＮＴ＿ＤＡＴＡＩＤＳＰＱｏＳ＿ＩＮＳＵＦＦＩＣＩＥＮＴ＿ＣＹＣＬ
ＥＳ＿ＡＶＡＩＬＡＢＬＥＩＤＳＰＱｏＳ＿ＩＮＳＵＦＦＩＣＩＥＮＴ＿ＭＥＭＯ
ＲＹ＿ＡＶＡＩＬＡＢＬＥ −−ＩＤＳＰＱｏＳＣｏｎｔｒｏｌは、ＩＤＳＰＰｌｕ
ｇｉｎによって送られる。この形式には次のものがあ
る。ＩＤＳＰＱｏＳ＿ＳＥＴ＿ＲＡＴＥＩＤＳＰＱｏＳ＿ＳＥＴ＿ＱＵＡＬＩＴＹ＿ＬＥＶＥＬＩＤＳＰＱｏＳ＿ＧＥＴ＿ＳＴＡＴＳ（使用メモリ、使
用サイクル、品質レベル、レート、期限に間に合ったバ
ッファの百分率、期限に間に合うために必要な品質レベ
ル） −−ＩＤＳＰＳｃｈｅｄｕｌｅｒは、ＱｏＳスケジュー
リングとイベント通知とを提供する。

【００２１】ＩＤＳＰＱｏｓ＿ｐｒｉｏｒｉｔｙ（）
は、プレゼンテーション期限に間に合うように時間臨界
に基づいて計算される。もし最高優先順位のコンポーネ
ントが実行不可能な場合、ＩＤＳＰＳｃｈｅｄｕｌｅｒ
は環境を解析してＩＤＳＰＱｏＳＥｖｅｎｔを送る。ア
プリケーションは品質レベルまたはレートを調整するこ
とができる。

【００２２】さらに一般的には、ＱｏＳは、付録にある
ｉＤＳＰプログラマーズガイドで説明されている次のイ
ンターフェイスでｉＤＳＰにおいてサポートされる。ＩＤＳＰＰｌｕｇｉｎ＿ｉｓｓｕｅ（）ＩＤＳＰＰｌｕｇｉｎ＿ｒｅｃｌａｉｍ（）ＩＤＳＰＰｌｕｇｉｎ＿ｇｅｔＰｅｒｆｏｒｍａｎｃｅ
（）ＩＤＳＰＰｌｕｇｉｎ＿ｏｐｔｉｍｉｚｅ（）ＩＤＳＰＰｌｕｇｉｎＭａｎａｇｅｒ＿ｇｅｔＭｅｍｏ
ｒｙＵｔｉｌ（）ＩＤＳＰＰｌｕｇｉｎＭａｎａｇｅｒ＿ｇｅｔＰｒｏｃ
ｅｓｓｏｒＵｔｉｌ（）ＩＤＳＰＣｏｍｍａｎｄ（）ＩＤＳＰＲａｔｅＣｈａｎｇｅＣｏｍｍａｎｄ（）

【００２３】実際には、ＱｏＳの鍵は「オンタイム」レ
ンダリングであり、ｉＤＳＰは次のことによってアプリ
ケーションプログラマーに対してＱｏＳ管理のためのサ
ポートを有する。 −−データフローチェーンに沿ってメディアバッファの
尚早・遅滞を計測しながら実行時間データへのアクセス
を提供すること。 −−特定のメディアプレイヤに必要な新たな能力に拡張
可能なＱｏＳ調整用コンポーネントへのインターフェイ
スを提供すること。 −−コンポーネントのメモリとプロセッサ利用へのアク
セスを提供すること。 −−時間をベースにしたメディアの「オンタイム」動作
を最適化する実行時間スケジューラを提供すること。

【００２４】メディアアプリケーション開発者は、これ
らのｉＤＳＰの特徴を利用してメディアプレイヤの特定
のＱｏＳ管理と連結しながらアプリケーション内にＱｏ
Ｓを構築することができる。

【００２５】ｉＤＳＰにおける全てのデータストリーム
は、時間ベースである。即ち、ＩＤＳＰＰｌｕｇｉｎ＿
ｉｓｓｕｅ（）とＩＤＳＰＰｌｕｇｉｎ＿ｒｅｃｌａｉ
ｍ（）は、データ転送に加えて、データフローグラフ中
の処理において尚早及び遅滞を計測するのに使用可能な
時間Ｉ／Ｏ情報を提供する。アプリケーションはこのデ
ータを使用して性能の測定値を得てメディア処理を調整
するのに必要な調整を決定することができる。ｉＤＳＰ
スケジューラはデータフローを最適化して遅滞を避け
る。ＩＤＳＰＰｌｕｇｉｎ＿ｏｐｔｉｍｉｚｅ（）は、
遅滞を最小化するようにプラグインのためのフレームレ
ートを下げるのに使用できる。ＩＤＳＰＰｌｕｇｉｎ＿
ｇｅｔＰｅｒｆｏｒｍａｎｃｅ（）は、プラグインがど
の程度「オンタイム」に動作しているかを示す測定値を
提供する。

【００２６】ＩＤＳＰＣｏｍｍａｎｄは、ＱｏＳ命令を
含む全てのＩＤＳＰＣｏｍｐｏｎｅｎｔ命令のための基
本形式である。ＩＤＳＰＲａｔｅＣｈａｎｇｅＣｏｍｍ
ａｎｄは、ｉＤＳＰ２．０によって与えられる形式であ
る。この命令を扱うＩＤＳＰＣｏｍｐｏｎｅｎｔは、そ
れに応じてそれぞれのフレームレートを調整することに
なる。アプリケーション開発者は、自分たちのプレイヤ
開発に必要なＱｏＳコマンドのためにＩＤＳＰＣｏｍｍ
ａｎｄを拡張する。

【００２７】ＩＤＳＰＰｌｕｇｉｎＭａｎａｇｅｒ＿ｇ
ｅｔＭｅｍｏｒｙＵｔｉｌ（）とＩＤＳＰＰｌｕｇｉｎ
Ｍａｎａｇｅｒ＿ｇｅｔＰｒｏｃｅｓｓｏｒＵｔｉ
ｌ（）は、プラグインのシステムへの負荷を決定するの
に使用される。これは、ともかく新たなプレイヤを構築
可能かどうかを知るためにアプリケーションによって使
用される。また、複数プロセッサへのコンポーネント割
り当てを管理するときにｉＤＳＰロードバランサによっ
ても使用される。

【００２８】３．ｉＤＳＰにおけるＭＰＥＧ−２１準
拠ＱｏＳ管理の主要特性次において「ＯＥＭソフトウェア」とは、ボックスビル
ダーがｉＤＳＰ（ＤＳＰ／ＢＩＯＳＩＩを含むとする）
ソフトウェアと統合（自分自身および第三者のソースか
ら）させた全てのソフトウェアを示す。 −−ＯＥＭソフトウェアへ利用可能なｉＤＳＰサービス
には、ｉＤＳＰに対して発行可能な次のメディアサービ
ス要求が含まれる。１．プラグ−−ＧＰＰ側のＯＥＭソフトウェア内部に
新たなｉＤＳＰメディアサービスを埋め込め。２．プレイ−−プラグされたｉＤＳＰサービスにメデ
ィアを供給せよ。３．コネクト−−２つの既存（集合体あるいは単体）
のｉＤＳＰメディアサービスを１つの集合体ｉＤＳＰメ
ディアサービスに接続せよ。４．ＱｏＳ−−プラグ、プレイ、および、コネクト中
にｉＤＳＰのＱｏＳ（の様相）に関して、（Ａ）問い合
わせ、（Ｂ）設定、および、（Ｃ）警告せよ。 −−ＱｏＳ特性１．ＯＥＭソフトウェアは、ｉＤＳＰのＱｏＳの如何
なる様相についても原則として問い合わせ可能である。２．ＯＥＭソフトウェアは、ｉＤＳＰのＱｏＳの如何
なる様相をも原則として設定可能である。３．ＯＥＭソフトウェアは、ｉＤＳＰのＱｏＳの如何
なる様相についても原則として警戒可能である。４．ＱｏＳは、全てのｉＤＳＰ関連のＭＰＥＧ−２１
端末ＱｏＳ要件に対して、および、そのネットワークＱ
ｏＳ要件のうち感知可能な部分集合（空集合でも良い）
に対して完全に準拠する。両者は、ＭＰＥＧ−２１によ
って現在明瞭に表現されているものと同じだけのもので
ある。５．ＤＳＰ／ＢＩＯＳのバージョンＩＩを用いると、
所与のＤＳＰ上のｉＤＳＰサービスの利用可能クラス
は、ＤＳＰコードイメージロード時間（＝全ＤＳＰサー
ビスのリセット時間）に固定される。ＤＳＰ／ＢＩＯＳ
がＤＬＬ能力を付加するときには、ｉＤＳＰサービスの
利用可能クラスは、ＤＳＰがそのサービスを実行中は可
変となる。６．ｉＤＳＰは「例外の場合」にはＯＥＭソフトウェ
アに対してＱｏＳを管理する。即ち、（ａ）特に逆のこ
とと分かったり（ｂ）全てが上手くいっているという周
期（ＯＥＭソフトウェアによって設定可能な周期）的な
通知に失敗したりしなければ、「全てをＯＥＭソフトウ
ェアの期待のままにして、ＯＥＭソフトウェアの邪魔を
しない。」７．全てのメディアストリーム化されたデジタルアイ
テムは、強力に型識別される。このことによって、間違
ったｉＤＳＰコンポーネントやサービスを、ＯＥＭソフ
トウェアと或いはそれら相互間で、接続することを防止
する。８．全てのメディアフレームは実時間でスタンプされ
る。ｉＤＳＰは、適時のメディア処理を保証する。９．現在のフレーム処理時間は、全ての使用中のスト
リーム化されたデジタルアイテムのための全ての現在フ
レームと数個の過去フレームに対してＯＥＭソフトウェ
アに利用可能である。１０．ｉＤＳＰは、ＯＥＭソフトウェアの指示通り
に、あるいは、段階的異常停止の一部として事前に、メ
ディアフレームレートを変更可能である。１１．リソースが枯渇寸前になったときに、今ＯＥＭ
ソフトウェアのＱｏＳ命令があるとすると、ｉＤＳＰ単
独でサービスの段階的異常停止を開始する。１２．ｉＤＳＰコンポーネントは、ストリームの一部
であって、そのストリームに対する意味負荷の所定レベ
ルの分散よりも長いｉＤＳＰサービスをストール・ブロ
ックすることはできない。この閾値を超えた瞬間に、ｉ
ＤＳＰはそのｉＤＳＰサービスを中断してＯＥＭソフト
ウェアに通知する。ｉＤＳＰ（しかもＯＥＭソフトウェ
アではなく）がレンダリング中ならば、ｉＤＳＰは、中
断したｉＤＳＰサービスを別の使用中の或いはデフォル
トのストリーム化されたデジタルアイテムに置換する。
即ち、特定のＯＥＭソフトウェアが初めてｉＤＳＰを呼
び出したときに最初は置換優先順位をそのＯＥＭソフト
ウェアに一致させておき、それ以後いつでも（例えば、
新たにストリーム化されたデジタルアイテムがスタート
・ストップする度に、あるいは、ストリーム化されたデ
ジタルアイテム（組）中に）ＯＥＭソフトウェアによっ
て修正可能になる。１３．プレイを開始する前にプラグすると、ＯＥＭは
そのメディアストリーム化されたデジタルアイテム
（組）の期待平均負荷と分散を設定する。１４．（最新の数個の）フレーム間負荷分散が設定さ
れたものを超えるとｉＤＳＰはＯＥＭソフトウェアに警
告し、増加した負荷の処理の選択を促す。（注：ピーク
よりも一定値大きいこと或いはピーク丁度であることを
ＯＥＭソフトウェアが識別しても良い。）

【００２９】１５．ＤＳＰ計算時間対ＤＳＰ−ＧＰＰ
通信時間の比を動的に管理するｉＤＳＰフレームワーク
によって、所与のＤＳＰ処理容量に対して最大のメディ
ア値加算スループットとなるようにｉＤＳＰを最適化し
て、ＤＳＰの内部対外部メモリアクセスパフォーマンス
における相違を最良適合する。１６．ＯＥＭソフトウェアへ／からの転送の最小意味
単位は、メディアフレームである。１７．ｉＤＳＰは、待ち時間の管理、フレーム間の変
化、ストリーム化されたデジタルアイテム間のクロスロ
ーディングを含む現在のメディアサービス全体のスケジ
ュールを立てる。１８．ＯＥＭソフトウェアの複数要素間の競合はあり
得ない。つまり、２つ以上のそうした構成要素による潜
在的に競合する要求は、予め定義された決定論的方法で
ｉＤＳＰによって解消される。１９．主要ｉＤＳＰメディアサービスのロードバラン
スはＧＰＰ上で取られ、分散されたｉＤＳＰが各ＤＳＰ
上でスケジュールを組む。２０．ｉＤＳＰは複数のＤＳＰを有する１つのＧＰＰ
をサポートする。２１．ＤＳＰ／ＢＩＯＳＩＩを用いれば、全ｉＤＳＰ
コンポーネントクラスをｉＤＳＰでラップおよびスケジ
ュールされたＤＳＰ／ＢＩＯＳＩＩタスクとして用い
て、所与のＤＳＰ用の全イメージを一回でロードする。
所与のクラスの多重インスタンスは、ＯＥＭソフトウェ
アのｉＤＳＰへの実行時間サービス要求によって作成さ
れる。２２．スケジューリングは、進行中のＤＳＰメディア
演算とＯＥＭソフトウェアからの実時間ベースのメディ
アフロー或いは新たなサービス要求との間のｉＤＳＰの
ＱｏＳ最適化された相互作用によって駆動される。２３．ｉＤＳＰコンポーネント（「ＤＳＰａｌ
ｇ」）は、１つの完全なオブジェクトコンポーネントシ
ェル内部に存在し、フレームワークの手引きによる使用
中のＱｏＳ最大化エージェントである。２４．ｉＤＳＰコンポーネント（「ＤＳＰａｌ
ｇ」）は、規格に規定したメディア処理だけを行う。ア
ルゴリズムのＩ／Ｏは、全てのアルゴリズムに対して一
様に、ｉＤＳＰフレームワークによって管理される。２５．統合性プラットフォームによって提供されるＱ
ｏＳを最大化する目標をもって、ｉＤＳＰフレームワー
クだけがｉＤＳＰコンポーネントを操作する。ＯＥＭソ
フトウェアはｉＤＳＰサービス要求だけを発行する。２６．ｉＤＳＰフレームワークは、メディアオブジェ
クトコンポーネントフォーマットの拡張（例えば、ＸＤ
ＡＩＳ準拠）によって保証された自動互換性ＱＡを用い
て、新たな形式のアルゴリズムを追加するための組込サ
ポートを有する。２７．コネクトサービス要求を使用して、ＯＥＭソフト
ウェアは、オブジェクトコンポーネントフォーマットを
使用したｉＤＳＰ内部の自動互換性ＱＡを用いて、ｉＤ
ＳＰコンポーネントを有向非周期的グラフ（最も単純な
例はチェーンである）内にリンクできる。２８．ｉＤＳＰフレームワークは、ＯＥＭソフトウェ
アにメディアプレイヤが存在しないという状況に対して
オーディオ・ビデオ同期サポートを持っている。２つ
（オーディオ＋ビデオ）のストリームの２番目を開始す
るときに、ｉＤＳＰを用いるＯＥＭソフトウェアは１番
目のものと同期進行する。両ストリームの開始は遅延す
ることができ、かつ／もしくは、両ストリームの開始は
特定の「同時に今開始せよ（両方とも予約済み）」に結
合させて、処理に遅延を確保することができて、相互の
サンプル間時相偏差が規定のものより小さいｉＤＳＰ送
出同期を２番目の開始が阻害しない。

【００３０】４．ＱｏＳタイミング管理ｉＤＳＰシステムにおけるサービス品質（ＱｏＳ）マネ
ージャは、以下ｉＤＳＰ−ＱｏＳＭと称するが、クライ
アントアプリケーションに対してサービスの約定レベル
を提供する機構である。ｉＤＳＰ−ＱｏＳＭは、保証サ
ービス品質に対して、クライアントに伝達される予定異
常停止ポリシーを提供する。ｉＤＳＰ−ＱｏＳＭは、次
の特徴を持つ。即ち、（１）ｉＤＳＰ−ＱｏＳＭは、ス
トリーミングメディア処理の限定的な文脈内で定義され
る。（２）図１ａ−１ｃで図示された好適な実施例は１
つの単一ＤＳＰ（サーバー）のみを有するが、ｉＤＳＰ
−ＱｏＳＭは、負荷共有能力を有する複数プロセッサ環
境に対して定義される。

【００３１】ｉＤＳＰ−ＱｏＳＭによって実施される機
能には、一般的に、次のものが含まれる。即ち、（１）
システム内のサーバー（ＤＳＰ）に掛かる定常状態の処
理負荷を監視すること。（２）過負荷サーバーからその
同位サーバーへ負荷を分配すること。（３）サーバーへ
の如何なる付加的な負荷の登録のために、クライアント
アプリケーションとサービス要件を交渉すること。
（４）サーバーによってサービスされている個々のオブ
ジェクトの特定の特性に基づいてサーバーに掛かる将来
の負荷を予測すること。（５）アルゴリズム実行時間予
測は処理時間ではなくてプロセッサ時間のサイクルに基
づくこと。したがって、この方法では、アルゴリズム実
行時間予測は、プロセッサの動作周波数に制限されな
い。

【００３２】テキサス・インスツルメンツ社のＴＭＳ３
２０Ｃ６２ＸＸ系ＤＳＰでは、内部（オンチップ）デー
タメモリ量に制限がある。ＴＭＳ３２０Ｃ６２１１（及
びその派生物）を除いて、ＴＭＳ３２０Ｃ６２ＸＸ系Ｄ
ＳＰは、外部メモリ（オフチップ）アクセスを効率的に
するためのデータキャッシュを持たない。内部メモリ
は、ＴＭＳ３２０Ｃ６２ＸＸ系ＤＳＰのデータメモリ階
層において最高レベルにある。それゆえ、ＴＭＳ３２０
Ｃ６２ＸＸ系ＤＳＰ上で実行される全てのアルゴリズム
は、内部メモリをそれぞれのデータ作業空間として使用
しようとする。何故なら、それがデータメモリへのアク
セスに最高レベルの効率であるからである。

【００３３】典型的には、ＤＳＰ用のアルゴリズムは、
ＤＳＰプロセッサ全体、したがって、ＤＳＰの内部メモ
リの全てを所有すると仮定して開発される。このため、
幾つかの異なるアルゴリズムを統合することは、それら
が同一（同種）のものであろうと異なる（異種の）もの
であろうと、極端に難しくなる。内部メモリなどのシス
テムリソースへアクセスしてそれを使用する１つの共通
な方法に関してアルゴリズム開発者には一組の規則が必
要となる。

【００３４】好適な実施例では、ＤＳＰ内部メモリにデ
ータページングアーキテクチャを用いることによってデ
ータキャッシュレスＤＳＰ上で複数のアルゴリズムを実
行するときのプロセッサ利用を増加させる方法が提供さ
れる。ＤＳＰアルゴリズムをデータページングアーキテ
クチャに準拠するように開発または変換することは、テ
キサス・インスツルメンツ社のＸＤＡＩＳ規格で達成可
能である。この規格は、アルゴリズム開発者がアルゴリ
ズムのために全てのデータメモリをサポートすることに
なる少なくとも１つ以上のメモリ領域を定義することを
必要とする。これらのユーザー定義領域は、１つまたは
全部がアルゴリズム開発者によってＴＭＳ３２０Ｃ６２
Ｘ系ＤＳＰの内部メモリでの実行のために選択される。
アプリケーションのＤＳＰシステムソフトウェア部分内
で、内部メモリはシステムサポートとデータ作業空間
（ページ）に分割される。ＤＳＰアプリケーション内の
全てのアルゴリズムは、作業空間を共有し、実行時間に
は全ての作業空間を所有する。２つのアルゴリズム間の
文脈切り換え上で、ＤＳＰシステムソフトウェアは作業
空間と各アルゴリズムの外部シャドーメモリとの間の転
送をそれぞれ担当する。好適な実施例は、次のことを提
供する。（１）２つ以上のＤＳＰアルゴリズム間でのデータキ
ャッシュレスＤＳＰにおける内部データメモリの共有は
プロセッサ利用を増加させる。（２）同一共有内部メモリからの複数アルゴリズムの
実行によって、各アルゴリズムは、スタック要件とアル
ゴリズム内部変数とをサポートするためにデータメモリ
にアクセスするときにＴＭＳ３２０Ｃ６２Ｘ系ＤＳＰに
おいて最大効率を享受できる。（３）このアーキテクチャは、内部メモリとプロセッ
サの内部メモリへのアクセスを持つＤＭＡ利用とを持つ
如何なる単一プロセッサでも機能する。（４）データ入力フレーム境界でのみ文脈切り換えを
実行すると、最良効率のデータページングアーキテクチ
ャが得られる。

【００３５】リードオンリーであるアルゴリズムデータ
の非対称ページ転送のサポートアプリケーションにおけ
るデータフローは、アルゴリズムからアルゴリズムへで
も良く、また、好適な実施例は、各アルゴリズム実行の
ためにＧＰＰとバス経由でやりとりされるのではなく、
１つ以上のＤＳＰに滞在するデータに備えるものであ
る。

【００３６】５．複数サーバーのためのＱｏＳｉＤＳＰサービス品質マネージャ（ｉＤＳＰ−ＱｏＳ
Ｍ）の定義されている好適な実施例構成は、一群のデジ
タル信号プロセッサ（ＤＳＰ）を同位サーバーとして有
するホストプロセッサからなる。特定のサービス品質を
維持するのに必要な全ての機能を実施する包括的ＱｏＳ
マネージャがこのＤＳＰサーバー群を管理する。ホスト
プロセッサは、汎用プロセッサ（ＧＰＰ）であり、共有
メモリやバス型インターフェイスなどのハードウェアイ
ンターフェイスを通じてＤＳＰと接続される。ＱｏＳマ
ネージャは、ｉＤＳＰの一部、あるいは、より一般的に
は、ＤＳＰ上の別個のマネージャである。システムは、
ハードウェア割り込みとソフトウェア割り込みの両方に
よって駆動される。好適な実現方法は、主要ユーザー
（クライアント）アプリケーションをＧＰＰ上で実行さ
せ、特定サービスを負荷分散に基づいてＤＳＰ上で実行
させることである。全てのプロセッサ上でＱｏＳマネー
ジャと同時実行するのが、ｉＤＳＰメディアフレームワ
ークなどのフレームワークであっても良い。ｉＤＳＰＱ
ｏＳマネージャは３つの主要機能を実施する。即ち、
（１）オブジェクトの分類、（２）オブジェクトのスケ
ジューリング、そして、（３）オブジェクトの実行時間
の予測、である。

【００３７】これらの機能は、ＧＰＰ／マルチＤＳＰ環
境で、メディアの具体的な例を用いて以下に説明する。

【００３８】ａ．オブジェクトの分類ある特定のメディア環境では、オブジェクトは、メディ
アコーデック／フィルタ（アルゴリズム）に変換する。
メディアオブジェクトは、それらのストリーム形式、ア
プリケーション形式、あるいは、アルゴリズム形式に基
づいて分類可能である。アルゴリズムの形式に応じて、
ＱｏＳマネージャはコーデックサイクル、フィルタサイ
クルなどとして公知の測定基準を定義する。

【００３９】ｂ．オブジェクトのスケジューリング
（ハード期限）ｉＤＳＰ−ＱｏＳＭは、２相スケジューラに基づいてア
ルゴリズムオブジェクトのスケジュールを立てる。第１
相は、新たなメディアストリームがＤＳＰ上でスケジュ
ールを組むことが可能かどうかを決定し、コーデックサ
イクルのハード実時間期限を設定する高度スケジューラ
である。第２相は、個々のメディアフレームのスケジュ
ールを立てて、第１相からのハード実時間期限を利用す
る。第１相は、オブジェクトネゴシエーション時に、し
かも典型的にはホスト（ＧＰＰ）上で作動する。第２相
は、ＤＳＰ（サーバー）上で作動してフレーム単位に基
づいて作動する。

【００４０】スケジューリングの第１相は、オブジェク
トが既に同時実行中のオブジェクトでサポートされるこ
とが可能かどうかをＱｏＳマネージャが概して決定する
場合である。また、第１相のスケジューリングの一部と
して必要なものは、メモリの点でオブジェクトに対して
十分なサポートを考慮することである。内部の利用およ
び入出力のためのオブジェクトメモリバッファは、メモ
リを動的に割り当てるという不確実性を取り除くために
そのインスタンスの生成時には静的に固定されなければ
ならない。ｉＤＳＰメディアプラットフォームは、ＸＤ
ＡＩＳ準拠アルゴリズムを実行するだけである。開発者
は、自分のアルゴリズムに対して異なる条件下で処理時
間を定義することが求められる。ＱｏＳマネージャが各
オブジェクトに期限を設定するときにＱｏＳマネージャ
によって要素として入れられる初期化の時にサーバーか
ら／へのデータ伝送に必要な凡その時間は、決定され
る。

【００４１】各ＤＳＰオブジェクトはＱｏＳマネージャ
に以下の情報を供給する必要がある。ｎコーデックサイクル及びフレーム数（デフォル
ト：フレーム／秒）Ｔ_acc 目的サーバー（ＤＳＰ）サイクル数でコーデッ
クサイクルを計算する平均時間Ｔ_acd 目的サーバー（ＤＳＰ）サイクル数でのコーデ
ックサイクルの表示時間

【００４２】１つのビデオコーデックに対して、ｎは通
常、連続したＩ−フレーム間のフレーム数（例えば、１
５フレーム）である。Ｔ_accは通常、１つのＩ−フレー
ムに必要な最大時間量とＰ及びＢフレームに必要な平均
時間との合計になる。ＱｏＳマネージャは、全てのメデ
ィアオブジェクトに対してＴ_ccdを記録しておく。この
時間（ＤＳＰサイクルに関して）は、現在のフレームレ
ートに基づく。例えば、３０ｆｐｓビデオストリームで
ｎ＝１５の場合、Ｔ_ccd＝１２５Ｍサイクルとする。

【００４３】このとき、ＱｏＳマネージャは、新たなス
トリームが以下のようにスケジュールを組むことが可能
かどうか決定可能である。Ｓを現在スケジュールされて
いる全ストリームのコーデックサイクル（Ｔ_acc）の合
計とする。新たなストリームに対する（Ｓ＋Ｔ_acc）が
新たなストリームに対するＴ_ccdより小さいなら、スト
リームはスケジュールを組むことが可能であるし、そう
でないなら、スケジュールを組むことが不可能である。
例えば、ｎ＝１５、Ｔ_axc＝３９．５Ｍサイクル（１５
８ｍｓ）、Ｔ_ccd＝１２５Ｍサイクル（５００ｍｓ）の
オブジェクトＡが存在し、ＤＳＰ上でスケジュールされ
たタスクが存在しない（したがって、Ｓ＝０）とする。
ＱｏＳマネージャは、オブジェクトＡを必要とする新た
なストリームに対するリソースのスケジュールを立てる
ように通知される。Ｓ＋３９．５＝３９．５Ｍサイクル
＜１２５Ｍサイクル（５００ｍｓ）なので、このストリ
ームはスケジュール可能である。２番目のストリームが
オブジェクトＡを求めてやってくると、Ｓ＋３９．５＝
７９Ｍサイクル（３１６ｍｓ）＜１２５Ｍサイクル（５
００ｍｓ）なので、これもスケジュールされる。３番目
のストリームもスケジュール可能である。しかし、４番
目のストリームは、１５８Ｍサイクル（６３２ｍｓ）を
必要とするのでスケジュールできず、５００ｍｓのハー
ド期限に応じることができない。この点で、ＱｏＳマネ
ージャは１つのストリームのフレームレートを下げるよ
うに交渉し、それに失敗すると、そのストリームを完全
に拒絶することになる。

【００４４】一変型例では、スケジューラは異なるコー
デックサイクル時間を持つ異種メディアオブジェクトを
扱うことができる。より長いＴ_ccdを持つオブジェクト
は、最小Ｔ_ccdに割り振られる。例えば、ｎ＝３０、Ｔ
_axc＝４０Ｍサイクル（１６０ｍｓ）、Ｔ_ccd＝１６９Ｍ
サイクル（６７５ｍｓ）のオブジェクトＢが存在し、Ｄ
ＳＰ上でスケジュールされた２つのオブジェクトＡオブ
ジェクト（上述のように定義）が存在する（したがっ
て、Ｓ＝７９Ｍサイクル／３１６ｍｓ）とする。Ｓ＋４
０^*（１２５／１５８）＝１１０．４５Ｍサイクル（Ｓ
＋１６０^*５００／６７５＝４３５ｍｓ）なので、新た
なオブジェクトＢのストリームはスケジュール可能であ
る。（７９＋４０＜１２５）Ｍサイクル／（３１６＋１
６０＜５００）ｍｓなのでこのことは立証可能に正し
い。したがって、５００ｍｓのより短いコーデックサイ
クル期限内の全てのストリームを実際に保証可能であ
る。オブジェクトＢを必要とする２番目のストリームが
スケジューリングを必要とするとどうなるか。１１０．
４５＋４０^*１２５／１５８＝１３９＞１２５Ｍサイク
ル／４３５＋１６０^*（５００／６７５）＝５５４ｍｓ
＞５００ｍｓである。したがって、スケジューラはこの
ストリームを拒絶して、上述のように交渉を開始する。

【００４５】ｉＤＳＰ−ＱｏＳＭは、コーデックサイク
ルに基づいてメディアオブジェクトに対して十分な処理
帯域幅を確保するためにアプリケーション或いはそのプ
ロキシと交渉する。この交渉では、他の同時実行中のＤ
ＳＰアプリケーションと共に、オブジェクトに必要なメ
モリ、要求ＱｏＳレベル、および、ＤＳＰの利用可能な
ＭＩＰＳが考慮される。オブジェクト選択が変わると、
ＱｏＳマネージャは、ＤＳＰプロセッサ帯域幅の再交渉
を実施する。ＱｏＳマネージャの交渉プロセスへの入力
パラメータには、アプリケーションが１つのオブジェク
トに対して以下のことを定義する必要がある。（１）ＤＳＰメモリ要件（入出力バッファの数とサイ
ズ）（２）所望のＱｏＳレベル（典型的には１秒当たりの
フレーム数で表現）（３）オブジェクト開始のための最悪実行時間（４）コーデックサイクル（フレーム数及び平均実行
時間）と称される、メディアフレームのシーケンスのた
めのハード実時間期限を持つこと

【００４６】ｉＤＳＰ−ＱｏＳＭマネージャにおけるオ
ブジェクトの第２相のスケジューリングは、期限が最初
にくるのもの、および、最高優先順位を持つものという
２つの様相に基づく。次の例を考える。もしオブジェク
トＡが１０ｍｓで期限を有し、オブジェクトＤが３ｍｓ
で期限を有するなら、ｉＤＳＰ−ＱｏＳマネージャは、
オブジェクトＡがより高い優先順位を持っているとして
もオブジェクトＤを最初に実行するようにスケジュール
を組む。オブジェクトの近似的な実行時間は分かるの
で、あるオブジェクトがその期限に間に合うように開始
しなければならないという「遅延の無い」時間を決定で
きる。図３では、オブジェクトＤがオブジェクトＡの
「遅延の無い」開始点以前に完了することが予測されて
いる。このシナリオでは、より高い優先順位のオブジェ
クトＡとオブジェクトＤの間には期限競合が存在しな
い。それゆえ、より低い優先順位のオブジェクトＤの後
でオブジェクトＡが実行される。

【００４７】優先順位が最初の期限よりも重視される別
のスケジューリングの例では、より高い優先順位のオブ
ジェクトＡの「遅延の無い」時間がオブジェクトＤの予
測終了時間よりも前の場合である。この場合、オブジェ
クトＤがオブジェクトインスタンス化時に特定されるフ
レーム落ちパラメータを満足しさえするならば、オブジ
ェクトＡはより高い優先順位なであり、かつ、オブジェ
クトＤは後で実行しても良いるので、オブジェクトＡが
最初に実行されることになる。図４を参照されたい。

【００４８】ｉＤＳＰ−ＱｏＳが最良可能な効率に期限
を管理するためには、ＧＰＰは、出来るだけ速やかにデ
ータ入力フレームをＤＳＰサブシステムに送り、１つの
オブジェクトに対する到着時と期限の間に最大量の時間
を許さなければならない。データフレームの到着と期限
の間の時間が長くなればなるほど、ｉＤＳＰ−ＱｏＳＭ
には、他の並行オブジェクトとの各オブジェクトのスケ
ジューリングにより大きな柔軟性を持たせることができ
る。

【００４９】ｃ．オブジェクトの実行時間予測（ソフ
ト期限）ｉＤＳＰ−ＱｏＳＭの中心機能は、全てのスケジュール
されたオブジェクトの次の入力フレームに対して必要な
処理時間を予測することである。予測は非トリビアルで
オブジェクト独特のものである。ＱｏＳマネージャは、
次の入力フレームに対する期待実行時間を計算するため
に先行実行時間の統計値を用いることによってオブジェ
クトの実行時間を予測する。オブジェクトに対する期待
実行時間は、最大可能正方向変化（各オブジェクト独自
に決まる）をもつ先行実行時間の関数（オブジェクト独
自）である。例えば、ビデオオブジェクトの場合、Ｉ、
Ｐ及びＢフレームの周期が決定論的である。したがっ
て、将来の処理時間は、ビデオフレームの周期内の現在
フレームの形式とその位置に基づいて予測可能である。
全ての並行アルゴリズムにこうした予測を直接実施する
ことは、予測処理時間と近似ハード期限に基づいた動的
な優先順位の再配置に役立つ。

【００５０】これらの予測は、処理時間におけるソフト
期限とジッタの管理にとって鍵となる成功因子である。
ｉＤＳＰ−ＱｏＳＭは、これらの予測に基づいて、処理
のためのオブジェクトを瞬時に再スケジュールすること
になる。この瞬時の再スケジューリングは、個々のオブ
ジェクトのコーデックサイクル期限時間（平均して定義
されるハード期限）内で発生する。この方法は、個々の
フレームがハード期限とソフト期限の両方に応じて重み
付けされるという点で独特なものである。上述の例で
は、オブジェクトＢにおける全てのフレームが平均して
オブジェクトＡと５００ｍｓ重複する作業負荷となる同
一時間量を必要とすると仮定した。これは、オブジェク
トＢのフレームは現実の重複中にもっと多くの時間を必
要とする場合もあったり、オブジェクトＢが平均時間量
を与えられない場合もあったりするので、真実ではな
い。それゆえ、コーデックサイクル期限に最も近いフレ
ームがより高い優先順位を受ける。

【００５１】予測される実行時間がユーザー定義期限要
件に違反するなら、ＱｏＳマネージャは幾つかの可能な
行動のうちの１つを採ることになる。単一ＤＳＰ構成に
おいては、（レベル１）単純にバイナリ切り捨て。この結果、自
動的なフレーム落ちが発生する。該当するオブジェクト
はフレーム落ちが破局的な結果を生じるかどうかを表示
可能であるべきである。（レベル２）オブジェクトが割り当て時間の最後に割
り込むことでより低い優先順位のオブジェクトの割り当
て実行時間を一般的に短縮すること。これによってフレ
ーム落ちが生じることもあるし、生じないこともある。（レベル３）オブジェクトは、出力データの品質縮小
などのＱｏＳコマンドを受け入れる能力を持つことが求
められる。複数ＤＳＰ構成では、（１）各ＱｏＳタイムスライスの終わりに、負荷デー
タを持つメッセージが各ＤＳＰからＧＰＰに送出され
る。（２）ＧＰＰは、期限に間に合わないと推測される場
合にのみ、オブジェクトの再分配という手段を採用す
る。このタスクの再割り当ては、動作中のＤＳＰからの
「負荷データ」を受信後にＧＰＰ（ＯＲＢ層）によって
実施されるものである。しかし、タスク切り換え時間を
減少させるためには、全てのＤＳＰが外部メモリ空間の
共通クラスタから動作することが極めて望ましい。

【００５２】ｉＤＳＰシステムで実行する全てのオブジ
ェクトは、実行時間が決定論的でなければならない。Ｄ
ＳＰオブジェクトは、３つの形式、即ち、データ圧縮
（符号化）、データ解凍（復号化）、および、データ変
換（オブジェクトのデータの事前または事後処理）に分
類できる。オブジェクトには、ブロックに分類された処
理用データが与えられる。これらのブロックは入力デー
タフレームと称される。オブジェクトは、入力データフ
レームを処理して出力データフレームを生成する。計量
データと同様に、入力及び出力データフレームは共に、
処理のサイズと量に関して限界がある。与えられた入力
フレームのサイズに基づいて、ＤＳＰまたは当該問題処
理用の他のコンピュータがその入力フレームに処理を実
施しなければならない最大処理量を正確に決定すること
ができる。

【００５３】各オブジェクトは、ｉＤＳＰシステムに統
合される前に、単一フレームの場合にそのオブジェクト
に対する最悪実行時間を宣言しておく必要がある。この
最悪実行時間は、オブジェクトを開始可能なように、最
初の入力データフレームの実行時間を計算するのに用い
られる。ＱｏＳマネージャは、オブジェクト実行前に入
力データフレームを特徴付けることはできない。エンコ
ーダやデコーダオブジェクトは最悪シナリオではほぼ動
作しないので、最初の入力データフレームは高価なもの
となる（最悪と予測しなければならないので）。この最
悪スケジュールは、最初のフレームの実際の実行時間よ
りも長い時間がかかると考えられる。このことは、現実
の実行時間が最悪スケジュールよりも長い場合に問題と
なるだけである。

【００５４】上述したように、アルゴリズムオブジェク
トの処理時間は入力フレーム間で変化する。最初は、ｉ
ＤＳＰ−ＱｏＳＭは、最初のデータ入力フレームに対し
て最悪値で開始する。最初のフレームの後、ＱｏＳマネ
ージャは、アルゴリズムの特徴と最初のフレームに対し
て測定した処理時間とを基にして次の入力フレームの処
理時間を予測する。後続のフレームそれぞれに対して、
アルゴリズムオブジェクトの意味論と履歴を基に、近似
的な処理時間要件を予測する。例えば、復号化オブジェ
クトは、将来の符号化時間を予測するために、同様な先
行入力フレームの平均符号化時間とともにオブジェクト
意味論（例えば、Ｉ、Ｐ及びＢフレーム形式）を用い
る。エンコーダオブジェクトは、実行のためにスケジュ
ールされる度に同一サイズの入力フレームに対して働き
かける。処理時間の変動は、フレームにおける使用中レ
ベル、フレーム間のモーションの程度などの要因から生
じる。これらの変動には、しかし、限界がある。したが
って、２つのフレーム間の処理時間には有限な最大差が
あり、この有限な最大差は次のフレームに対する最悪処
理時間を決定するために予測処理時間に追加され得る。
図５−６を参照されたい。

【００５５】復号化オブジェクトには、典型的には、可
変サイズの入力フレームが与えられる。入力データフレ
ームの処理時間は、そのサイズに正比例する。次のフレ
ームの処理時間に増分があるかどうかを決定するため
に、ＱｏＳマネージャは、現在のデータ入力フレームサ
イズと次のデータ入力フレームサイズとの差の大きさを
照合する。エンコーダと同様の議論はデコーダにも適用
できる。即ち、２つの意味論的に類似したフレーム間の
処理の差には限界がある。デコーダに対する最大または
最悪処理時間は、オブジェクトに対して定義される最大
可能なバッファである。図７を参照されたい。

【００５６】変換オブジェクトは、常に同一サイズの入
力フレームに対して働きかけるという点で復号化オブジ
ェクトと同様な動作をする。各フレームは常に同一の処
理時間量を要し、入力フレームからの単一パスである。
それゆえ、入力フレーム当たりの処理時間は常に一定の
ままとなる。

【００５７】各オブジェクトは、通過フレームがそのオ
ブジェクトによって完了しなければならないという相対
時間をユーザーアプリケーションから受け取る。例え
ば、アプリケーションは、このフレームは次の７ｍＳ内
に処理されなければならないと指定する。ホストＧＰＰ
とＤＳＰの間には共通のソフトウェアクロックは存在し
ないので、期限は相対期間でのみ指定可能である。ホス
トとＤＳＰの間のデータフレームの伝送時間は決定論的
であるとする。ｉＤＳＰシステムは内部クロックを保有
していて、データフレームが到着時にタイムスタンプを
受けその後期待処理時間を計算する。期待処理時間を計
算した後で、今度はＱｏＳマネージャがデータフレーム
実行をスケジュールする。

【００５８】オブジェクトがスケジュールできる前に、
ＱｏＳマネージャは、他の並行オブジェクトと比較し
て、適当なオブジェクト実行順序を決定する。もし入力
フレームを処理中の他のオブジェクトが存在しないな
ら、オブジェクトフレームは即座に実行をスケジュール
される。他の実行中のオブジェクトが存在するなら、Ｑ
ｏＳマネージャは、各要求オブジェクトの優先順位と期
待期限とハードまたはソフト実時間要件とを考慮して実
行順序を決定する。図８を参照されたい。

【００５９】異なる実行時間優先順位を持つ複数のオブ
ジェクトが同一のＤＳＰ上に組み合わされるとき、Ｑｏ
Ｓマネージャは、オブジェクトの特定の実行時間の計算
に基づいて各オブジェクトの実行時間予測を計算する。
その後、スケジューリングオブジェクト（ＴＢＤ）に基
づいて異なるタスクをスケジュールする。次の３つのス
ケジューリングシナリオがあり得る。

【００６０】（１）全てのオブジェクトは、与えられ
た入力データフレームについて完了するまで動作し、ア
プリケーション指定の期限内に完了する。このシナリオ
は、図９で示される。ただし、図中のオブジェクトは全
て、各オブジェクト期限前に完了する。全てのオブジェ
クトがそれぞれの期限前に完了するなら、ＱｏＳマネー
ジャに要求する作業は最小である。

【００６１】（２）１つ以上のオブジェクト（例え
ば、オブジェクトＢ）の処理負荷は増加するが、このこ
とは次のオブジェクトが予測期限に間に合わないという
事態を引き起こさない。オブジェクトＢにおいてなど１
つ以上のオブジェクトの負荷は増加することがあり得
る。オブジェクトによっては、同一のオブジェクトの後
続のデータフレームがその期限制約内に処理されるなら
ば、期限に間に合わないことが受け入れ可能な場合もあ
る。一例は、「Ｉ」フレームが計算に最も長時間を要す
Ｈ２６３エンコーダにおいてである。「Ｉ」フレームに
続くフレームは、常に、「Ｐ」フレームであり、典型的
には、数多くの小さな処理要件を持つ。このため、
「Ｉ」フレーム処理は後続のＰフレーム処理からのサイ
クルスティールが可能となる。こうして、１つのフレー
ムが期限に間に合わないことも、次のフレームに十分な
処理余地が存在するならば、破局的にならない場合があ
る。

【００６２】オブジェクトＢの期限は過ぎてしまうの
で、システム全体の効果が決定されなければならない。
もしオブジェクトＢの期限に間に合わないことが後続の
オブジェクトの予測期限に間に合わない結果を引き起こ
さないのであれば、システム全体の障害は最小である。
図１０−１１を参照されたい。

【００６３】（３）１つ以上のオブジェクト（例え
ば、オブジェクトＢ）の処理負荷が増加するが、このこ
とは、後続のオブジェクトの予測期限に間に合わない結
果を引き起こしてしまう。図１２を参照されたい。

【００６４】この場合、オブジェクトＢの期限に間に合
わないことが、後続オブジェクトの予測期限に間に合わ
ない結果を引き起こしてしまう。この場合でも、システ
ム全体の障害が最小になる場合もあるし、ならない場合
もある。並行に実行中のオブジェクトは、それぞれ、後
続フレームからサイクルスティールをすることが可能
で、期限失敗のドミノ効果を回避できる場合がある。

【００６５】ｉＤＳＰ−ＱｏＳＭは、ソフト期限管理の
ために一組の規則を提案する。この一組の規則は、単一
の致命的期限失敗から生じる期限失敗の雪だるま効果を
制限しようとするものである。（１）どのアルゴリズム
オブジェクトも許容される秒当たりのフレーム落ちの最
大数をＱｏＳマネージャに提供する。（２）各オブジェ
クトは、各処理サイクル後に移動平均として「失敗した
期限」の実行計数を更新する。（３）オブジェクトが期
限失敗の限界を超えてしまうと、そのオブジェクトの優
先順位を最高値に変える。計数が一旦限界値を下回ると
元来の優先順位が回復される。（４）制限後に期限を失
敗した後続フレームは全て落とす。この結果、ＱｏＳは
次の即値レベルに一時的に低下する。この瞬間的なＱｏ
Ｓ低下（非常に稀であるはずであるが）は、その後クラ
イアントに報告される。（５）ＤＳＰが期限が過ぎた後
も当該オブジェクトを開始していない場合にのみ、原則
としてフレームを落とす。

【００６６】ｄ．周期メディアレンダリングのための
絞り制御与えられたアルゴリズムオブジェクトに対して、ｉＤＳ
Ｐ−ＱｏＳＭは、どの瞬間の実行可能待ち行列にも１つ
の要求のみが存在すると仮定する。一般的に、メディア
ストリームは、ＱｏＳマネージャに対するサービス品質
制約として特定される周期期限（例えば、ビデオストリ
ームの場合３０フレーム／秒）を持っている。メディア
システムにおけるオーディオ及びビデオレンダリングコ
ンポーネントは、到着時の分散を処理するためにフレー
ムをバッファへ移すことが可能であり、フレームが僅か
にスケジュールに先行して到着することも許容する。し
かし、これらのバッファは有限なので、メディアシステ
ムの上流コンポーネントは、フレームを処理する相対速
度を慎重に絞らなければならない。

【００６７】アルゴリズムオブジェクトの処理速度を絞
るためにｉＤＳＰ−ＱｏＳＭは２つの機構を提供する。

【００６８】（１）ＤＳＰアルゴリズムオブジェクト
のクライアントは、そのアルゴリズムオブジェクトの処
理機能（サーバー）を呼び出す速度を制御する。この結
果、要求を満たさなければならない期間内に要求がなさ
れるならば、ＱｏＳマネージャのスケジューリングアル
ゴリズムの部分最適動作を生じることができる。例え
ば、バッファＡ１が期間Ｔ１内に、バッファＡ２が期間
Ｔ２内に処理されねばならない上述のアルゴリズムオブ
ジェクトＡが考えられる。なお、Ｔ１とＴ２は、２つの
連続期間であり、［ｘ］はバッファｘの到着を示し、
｛ｘ｝はバッファｘの処理完了を示す。図１３ａを参照
されたい。

【００６９】（２）ＱｏＳマネージャは、メディアス
トリームの絞りを制御する。この機構によって、クライ
アントは、入力バッファを用いて出来るだけ速やかにア
ルゴリズムオブジェクトの処理機能を呼び出すことが可
能になる。ＱｏＳマネージャは、その後、入力バッファ
に「始動期限」を付加する。スケジューラは、「始動期
限」後までこのバッファをスケジュールしない。クライ
アントは、その現在バッファの処理が完了するまで遮断
する。図１３ｂを参照されたい。

【００７０】このように、両方の場合において、どの瞬
間のＱｏＳマネージャの実行可能待ち行列にも１つのア
ルゴリズムオブジェクトに付きせいぜい１つの要求が存
在する。

【００７１】メモリページング１つのＤＳＰまたは当該問題処理用のプロセッサ上で複
数アルゴリズムを最良に実行するためには、システムリ
ソースがアルゴリズム間で公平に共用されるように一組
の規則が確立されなければならない。これらの規則は、
それらのアルゴリズムのためのＤＭＡ、内部メモリ、お
よび、スケジューリング方法などのプロセッサの周辺装
置へのアクセスを特定する。一旦一組の規則が受け入れ
られてしまうと、システムインターフェイスは、アルゴ
リズムがプラグインされるように展開できるので、アル
ゴリズムはシステムリソースにアクセス可能となる。１
つの共通なシステムインターフェイスはアルゴリズム開
発者に十分定義された限界を提供し、その限界によっ
て、アルゴリズム開発者がシステムサポート問題ではな
くアルゴリズム開発にのみ集中することが可能なので、
アルゴリズムをより速やかに開発できる。このようなイ
ンターフェイスがテキサス・インスツルメンツ社のｉＤ
ＳＰメディアプラットフォームＤＳＰフレームワークで
ある。アルゴリズムとＴＭＳ３２０Ｃ６２ＸＸ系ＤＳＰ
とのアクセスは全てこのフレームワークを通して発生す
る。

【００７２】テキサス・インスツルメンツ社のＸＤＡＩ
Ｓ規格要件は、１つ以上のアルゴリズムをｉＤＳＰメデ
ィアプラットフォーム内にプラグ能力を許容して「シス
テム統合者が１つ以上のアルゴリズムから製造品質シス
テムを速やかに組み立てることができる」規則を確立す
る。ＸＤＡＩＳ規格は、全てのアルゴリズムがＡｌｇイ
ンターフェイスと称される共通インターフェイス要件を
満たすことを求める。ＸＤＡＩＳ規格の課す規則には幾
つかあるが、最も重要なものは、アルゴリズムがメモリ
を直接定義したりハードウェア周辺装置に直接アクセス
したりできないことである。システムサービスは、アル
ゴリズムに対して単一の共通なインターフェイスを通じ
て提供される。それゆえ、システム統合者は、全てのア
ルゴリズムに対してＡｌｇインターフェイスをサポート
する１つのＤＳＰフレームワークだけを提供する。Ａｌ
ｇインターフェイスは、アルゴリズム開発者に対して、
システムサービスへのアクセス及びそのアルゴリズムの
呼び出しの手段も提供する。

【００７３】アルゴリズムはその内部メモリ要件を厳密
に定義しなければならない。これは、ページングアーキ
テクチャが複数アルゴリズムの内部メモリ内の同一空間
へのアクセスをサポートするのに必要不可欠である。Ｘ
ＤＡＩＳ準拠アルゴリズムは、その内部及び外部メモリ
要件を特定することが求められる。

【００７４】内部（オンチップ）メモリは２つの領域に
分割されなければならない。１番目のものはシステムオ
ーバーヘッド領域であり、これは、特定のＤＳＰシステ
ム構成用のＯＳデータ構造に対するサポートである。２
番目の領域は、アルゴリズムが実行のためにスケジュー
ルされている場合にのみ使用するものである。両メモリ
領域はサイズが固定されなければならない。この２番目
のメモリ領域は、アルゴリズムオンチップ作業空間と称
される。言い換えれば、この作業空間領域は、データオ
ーバレイまたはデータメモリページとしても説明でき
る。図１４を参照されたい。

【００７５】どれぐらいのメモリがアルゴリズムオンチ
ップ作業空間に利用可能かを決定するため、システム開
発者は利用可能な内部データメモリ空間の総量を取得
し、ページングアーキテクチャのためのＯＳサポートと
データサポートなどのシステムソフトウェアをサポート
するのに必要な量をその内部データメモリ空間の総量か
ら引く。タスクやセマフォなどのＯＳ構成は、システム
ＤＳＰ設計者によって、設計者が一度に同時実行させた
いアルゴリズムの総数をサポートする最大サイズに設定
されるべきである。これによって、ＯＳサポートオーバ
ーヘッドは最小に保ち、アルゴリズム作業空間を増加さ
せる。

【００７６】アルゴリズムがこの環境で動作するには、
その内部メモリ要件が作業空間のサイズよりも少なけれ
ばならない。そうでなければシステム統合者はアルゴリ
ズムを統合できない。限界は、アルゴリズム当たり１ペ
ージだけ存在することである。このアーキテクチャは、
１つのアルゴリズムに対して複数ページをサポートしな
い。

【００７７】アルゴリズム作業空間は３つのコンポーネ
ント、即ち、スタック（必須）、持続性メモリ、及び、
非持続性メモリに分割される。持続性メモリのリードオ
ンリー部分を扱う後述の４番目のコンポーネントが存在
することもある。図１５を参照されたい。

【００７８】１つのアルゴリズムは、実行している間、
オンチップ作業空間だけを使用する。アルゴリズムが実
行をスケジュールされている場合、ＤＳＰシステムソフ
トウェアは、その外部記憶位置（シャドー記憶装置）か
らオンチップの内部作業空間内にアルゴリズムの作業空
間を転送することになる。アルゴリズムが制御を生じる
と、ＤＳＰシステムソフトウェアは次にどのアルゴリズ
ムを実行すべきかを決定する。もし次のアルゴリズムが
同一のアルゴリズムならば、アルゴリズムの作業空間の
転送は必要ない。次のアルゴリズムが異なるアルゴリズ
ムならば、現在の作業空間を外部メモリ内のそのシャド
ー位置に格納して、次のアルゴリズムの作業空間を転入
する。図１６を参照されたい。

【００７９】１つのアルゴリズムに対する作業空間が文
脈切り換える際に全て転送されるのではない。スタック
と持続性データメモリの使用部分のみが転送される。ア
ルゴリズムのスタックは、アルゴリズムがそのコールス
タックにおいて最高レベルにあるときに、最高レベル
（最小使用）にある。言い換えれば、アルゴリズムはそ
の入り口点にある。

【００８０】アルゴリズムにとっての理想の文脈切り換
えは、そのスタックがその最高レベルにある時に起こ
る。何故なら、それは、シャドー記憶装置内へのオフチ
ップ転送すべきデータが少ないことを意味するからであ
る。図１７を参照されたい。

【００８１】好適な実施例のデータページアーキテクチ
ャは、文脈切り換えが最も効率的であることを要求す
る。オーバーヘッドを処理する文脈切り換えは、ＤＳＰ
がアルゴリズムを実行可能な時間を減らす。アルゴリズ
ムを文脈切り換える最良時間はそのコール境界にあるの
で、アルゴリズムの中断は、絶対的に最小化されるはず
である。アルゴリズムのスタックがその最小値よりも大
きいときにアルゴリズムを中断するとシステム全体を低
下させてしまう。このことは必要条件でないといけない
が、極めて限られる範囲の中断しか受け入れることがで
きない。図１８−１９を参照されたい。

【００８２】アルゴリズムがリードオンリーの持続性メ
モリを必要とする場合が、アルゴリズム作業空間の特別
な場合である。この種のメモリは、アルゴリズムの使用
する参照表のために使用される。このメモリは決して修
正されないので、読み込みだけが必要で書き込みは必要
ない。この非対称ページ転送は、アルゴリズムの文脈切
り換えを用いてオーバーヘッドを減少させる。

【００８３】このデータページングアーキテクチャを用
いて、単一アルゴリズムのインスタンスを１度以上生成
することができる。アルゴリズムが内部メモリ要件とし
て必要なものを定義しているので、ＤＳＰシステム統合
者は同一アルゴリズムのインスタンスを１つ以上作成可
能である。ＤＳＰシステムソフトウェアは、複数インス
タンスと、アルゴリズムの各インスタンスを何時スケジ
ュールすればいいかを記録しておく。インスタンスの数
は、アルゴリズムインスタンスのシャドーバージョンを
維持するためにＤＳＰシステム内に存在するメモリの数
によって制限される。

【００８４】ＤＳＰシステムソフトウェアは、アルゴリ
ズムをスケジュールするに際してアルゴリズムデータと
正確に調和するように各インスタンスを管理しなければ
ならない。殆どのＤＳＰアルゴリズムのインスタンスは
タスクとして生成されるので、ＤＳＰシステムソフトウ
ェアはアルゴリズムインスタンスを管理する手段として
タスク環境ポインタを使用することができる。

【００８５】連鎖を持つデータフローデータフローの好適な実施例では、処理素子を統合し、
それらの素子に１つの共有メモリ空間を提供して、ＧＰ
Ｐによる介入無しで処理素子間で直接データを回送す
る。こうしたシステムは図２１に示されている。

【００８６】処理素子ＰＥ_aがかなりのデータ量の処理
を完了すると、生じたデータを共有メモリ内の事前定義
出力バッファに書き込む。処理素子ＰＥ_aは、その後、
適当な制御経路経由でチェーンの次の処理素子ＰＥ_bに
通知する。この通知はどちらの共有メモリバッファを処
理素子ＰＥ_bが入力として使用すべきかを示す。処理素
子ＰＥ_bは、その後、更なる処理のために入力バッファ
からデータを読み込む。この方法では、データは、全て
のデータが消費されるまでの間に必要な処理素子全ての
間を通過させられる。

【００８７】上述のように、一組のバッファが２つの処
理素子間のデータ通信に使用され、それらの素子間に１
つのＩ／Ｏチャンネルを形成する。多重Ｉ／Ｏチャンネ
ルがどの２つの処理素子間にも存在してもよく、その場
合、システムによって同時に（即ち、並行に）複数デー
タストリームを処理することができる。図２２は複数デ
ータストリームｓ１とｓ２の並行処理の例を示す。

【００８８】Ｉ／Ｏチャンネルに接続した一連の処理素
子は１つのチャンネルチェーンを構成する。１つの特定
のシステム内には幾つかのチャンネルチェーンを定義で
きる。チェーン中央位置にある処理素子の場合、各入力
チャンネルは関連の出力チャンネルを持つ。端末位置に
ある処理素子は入力または出力チャンネルのみを持つ。

【００８９】処理素子の入力チャンネルは、データを読
み出すべきバッファを定義する。処理素子の出力チャン
ネルは、データを書き込むべきバッファとどの処理素子
に後に通知すべきかとを定義する。データ処理素子と中
央制御プロセッサ（ＣＣＰ）の間の制御メッセージの形
式には、次のものがある。（１）状態メッセージ：データストリーム処理開始、
停止、強制終了、一時停止、再開、など。（２）サービス品質メッセージ：タイムスタンプ、シ
ステム負荷、リソース・フリー／ビジー、など。（３）データストリーム制御メッセージ：開始、停
止、一時停止、再開、巻き戻し、など。（４）システム負荷メッセージ：タスク実行、使用中
チャンネル数、処理素子当たりのチャンネル、など。

【００９０】好適な一実施例では、処理素子とのＩ／Ｏ
チャンネルの作成と関連付けは、システム初期化時に読
み出し可能な構成ファイルから静的に定義される。処理
されるビットストリーム形式ごとに、構成ファイルは適
当な処理素子と接続する１つのチャンネルチェーン（即
ち、データ経路）を定義する。１つのチャンネルチェー
ン内の全ての処理素子の集合的処理の結果、データは完
全に消費される。

【００９１】１つの所与のビットストリームに対して複
数のデータ経路が存在する場合、代替またはバックアッ
プチャンネルチェーンが定義可能である。主チャンネル
チェーンの処理素子が全て利用不可の場合、ビットスト
リームは、これら代替またはバックアップチャンネルチ
ェーンに回送できる。実行時におけるビットストリーム
形式の決定と動的ＱｏＳ解析とによって、データを回送
するチャンネルチェーンを選択する。実行時には、シス
テム内の全ての正当なチャンネルチェーンが固定され、
修正不可になる。

【００９２】別の好適な実施例では、新たなビットスト
リームが通信プロセッサに到着すると、異なるビットス
トリームに対するチャンネルチェーンを動的に構築可能
になる。実行時に由来するビットストリーム情報が制御
メッセージ経由でＣＣＰに送られる。ＣＣＰは必要な処
理素子を決定し、決定した処理素子間にＩ／Ｏチャンネ
ルを動的に割り当てる。この方法は、実行時にリソース
をサービスから奪ったりオンラインで与えたりすること
ができ、システムの自動適応を可能にする。

【００９３】共有メモリ異種システムでは、データはＣ
ＣＰによる介入無しで外部共有メモリ経由で処理素子間
を流れる。データがバス上に現れることがないので、デ
ータトランザクションの速度はバス伝送時間ではなく共
有メモリアクセス時間によって決定される。ＣＣＰ介入
も最小化されるので、ＣＣＰ応答及び処理の遅延が全体
のデータフロー時間から除去される。これによって、処
理素子間のデータ転送時間を最小化してシステムのスル
ープットを向上させる。

【００９４】ａ．実施例ここで述べられたデータフロー技術の典型的な用途は、
メディア処理システム用である。こうしたシステムは、
復号化、符号化、翻訳、変換、拡大縮小などの処理のた
めにブロードバンドのメディアのストリームを開始およ
び制御する。システムは、ローカルディスクから、ある
いは、ケーブルモデム、ＤＳＬ、無線などの通信媒体経
由でリモート機械／サーバーから生じるメディアストリ
ームを処理可能である。図２３は、こうしたシステムの
一例を示す。

【００９５】図２３のメディア処理システムは次の５つ
の処理素子を含む。（１）ＤＳＬまたはケーブルモデムＩ／Ｏフロントエ
ンドＤＳＰ（２）メディア処理ＤＳＰ（３）ビデオ／グラフィックオーバレイプロセッサ（４）Ｈ．２６３デコーダタスク（５）カラースペースコンバータタスク

【００９６】Ｉ／ＯフロントエンドＤＳＰに入ったＨ．
２６３ストリームは、アーク番号１〜３によって定義さ
れるチャンネルチェーンを進む。各チャンネルは、２つ
の処理素子を接続し、素子間にデータを通すために使用
される一組のＩ／Ｏバッファからなる。制御フローは影
付きのアーク経由で示されている。

【００９７】Ｈ．２６３ストリームは、Ｉ／Ｏフロント
エンドＤＳＰからグローバル共有メモリ内に定義された
チャンネル１Ｉ／Ｏバッファ内に流れる。Ｉ／Ｏフロン
トエンドＤＳＰは、チャンネル１に関連付けられた目的
地の処理素子、即ち、メディア処理ＤＳＰ上のＨ．２６
３デコーダタスクに対して、その入力バッファが満杯で
あり、読み出し準備ができていることを通知する。Ｈ．
２６３デコーダタスクは、チャンネル１Ｉ／Ｏバッファ
から読み出し、データを復号し、生じたＹＵＶデータを
ローカル共有メモリ内のチャンネル２Ｉ／Ｏバッファに
書き込む。

【００９８】ただし、チャンネルはインタープロセッサ
またはイントラプロセッサであり得る。データはグロー
バル共有メモリ（インタープロセッサ）経由、または、
所定のプロセッサ（イントラプロセッサ）に対して「ロ
ーカル」である共有メモリ経由でプロセッサ間を通過で
きる。図２３では、チャンネル１と３がインタープロセ
ッサであり、チャンネル２がイントラプロセッサであ
る。

【００９９】図２５は、提案のリソース管理フレームワ
ークを単純化したものを示す。矢印は、必ずしもフロー
ではなく、ＡＰＩを経由した制御フロー通信を表示す
る。これらの制御フローはプロトコルによって支配され
る。

【０１００】変型好適な実施例は、サービス品質制御とイベント通知を行
うアルゴリズムプロセッサのアルゴリズムプロセッサス
ケジューラを有する汎用プロセッサ用フレームワークの
特徴を保ちながら、多様な方法で変更可能である。

【０１０１】以上の説明に関して更に以下の項を開示す
る。（１）ａ）アプリケーションプロセッサ上の実時間
メディアアプリケーション用の複数のプラグインと、
（ｂ）アルゴリズムプロセッサ上の複数のアルゴリズ
ムコンポーネントと、ただし、前記プラグインがそれぞ
れ１つ以上のアルゴリズムコンポーネントに対応し、前
記アルゴリズムプロセッサがアプリケーションプロセッ
サに連絡しており、（ｃ）前記アルゴリズムプロセッ
サ上のコンポーネントスケジューラとを備え、（ｄ）
前記スケジューラは、（ｉ）前記コンポーネントの実行
に関連する前記プラグインからの制御に応じたコンポー
ネントのスケジューリングと、（ｉｉ）前記プラグイン
に送出される前記コンポーネントの実行に関連するイベ
ントの通知とによって、前記コンポーネントに関して前
記アプリケーションに対してサービス品質を提供する、
アルゴリズムプロセッサと連絡するアプリケーションプ
ロセッサ上の実時間メディアアプリケーションのための
フレームワーク。（２）（ａ）前記制御が前記コンポーネントの１つに
対する一組のデータレートを含む第１項記載のフレーム
ワーク。（３）（ａ）前記イベントが前記コンポーネントの１
つに対するプレゼンテーション時間に間に合わないとの
通知を含む第１項記載のフレームワーク。（４）（ａ）前記アルゴリズムプロセッサ上でスケジ
ュール可能なメディアストリームの期限を決定するアプ
リケーションプロセッサスケジューラを更に有し、前記
アルゴリズムプロセッサ上の前記スケジューラが前記メ
ディアストリームの１回のフレームをスケジュールする
第１項記載のフレームワーク。（５）（ａ）第２アルゴリズムプロセッサ上に複数の
第２アルゴリズムコンポーネントを更に有し、前記第２
アルゴリズムプロセッサが前記アプリケーションプロセ
ッサと前記アルゴリズムプロセッサとに連絡し、前記プ
ラグインも前記第２アルゴリズムコンポーネントに関連
する第１項記載のフレームワーク。

【０１０２】（６）アプリケーションを実行する汎用
プロセッサがＤＳＰアルゴリズムに対するプロクシとし
てプラグインオブジェクトを含み、サービス品質がアル
ゴリズムスケジューリングのアプリケーション制御とア
プリケーションへ報告されるアルゴリズムイベントとを
含む、ＤＳＰ実行アルゴリズムの統合。

【０１０３】本出願は、２０００年１１月２９日提出の
仮出願番号第６０／２５３，８４８号に由来する優先権
を要求する。次の特許出願は関連主題を開示する。即
ち、２００１年４月２５日提出の出願番号第０９／８４
１，８４７である。これらの出願は、本出願と共通の譲
受人を有する。

【０１０４】

【０１０５】

【０１０６】

【０１０７】

【０１０８】

【０１０９】

【０１１０】

【０１１１】

【０１１２】

【０１１３】

【０１１４】

【０１１５】

【０１１６】

【０１１７】

【０１１８】

【０１１９】

【０１２０】

【０１２１】

【０１２２】

【０１２３】

【０１２４】

【０１２５】

【０１２６】

【０１２７】

【０１２８】

【０１２９】

【０１３０】

【０１３１】

【０１３２】

【０１３３】

【０１３４】

【０１３５】

【０１３６】

【０１３７】

【０１３８】

【０１３９】

【０１４０】

【０１４１】

【０１４２】

【０１４３】

【０１４４】

【０１４５】

【０１４６】

【０１４７】

【０１４８】

【０１４９】

【０１５０】

【０１５１】

【０１５２】

【０１５３】

【０１５４】

【０１５５】

【０１５６】

【０１５７】

【０１５８】

【０１５９】

【０１６０】

【０１６１】

【０１６２】

【図面の簡単な説明】

【図１ａ】好適な実施例のＤＳＰ構造を示す。

【図１ｂ】好適な実施例のＤＳＰ構造を示す。

【図１ｃ】好適な実施例のＤＳＰ構造を示す。

【図２ａ】好適な実施例のサービス品質を示す。

【図２ｂ】好適な実施例のサービス品質を示す。

【図３】ＱｏＳのためのタイミング図である。

【図４】ＱｏＳのためのタイミング図である。

【図５】ＱｏＳのためのタイミング図である。

【図６】ＱｏＳのためのタイミング図である。

【図７】ＱｏＳのためのタイミング図である。

【図８】ＱｏＳのためのタイミング図である。

【図９】ＱｏＳのためのタイミング図である。

【図１０】ＱｏＳのためのタイミング図である。

【図１１】ＱｏＳのためのタイミング図である。

【図１２】ＱｏＳのためのタイミング図である。

【図１３】ＱｏＳのためのタイミング図である。

【図１４】好適な実施例のメモリ解析を示す。

【図１５】好適な実施例のメモリ解析を示す。

【図１６】好適な実施例のメモリ解析を示す。

【図１７】好適な実施例のメモリ解析を示す。

【図１８】好適な実施例のメモリ解析を示す。

【図１９】好適な実施例のメモリ解析を示す。

【図２０】異種からなるシステムにおける既知のデータ
フローを示す。

【図２１】好適な実施例のデータフローを示す。

【図２２】好適な実施例のデータフローを示す。

【図２３】好適な実施例のデータフローを示す。

【図２４】クライアントサーバーとＭＰＥＧ−２１シス
テムを示す。

【図２５】クライアントサーバーとＭＰＥＧ−２１シス
テムを示す。

【図２６】ダイレクトショーフィルタとアプリケーショ
ン制御を示す。

【図２７】ダイレクトショーフィルタとアプリケーショ
ン制御を示す。

【図２８】ダイレクトショーフィルタとアプリケーショ
ン制御を示す。

フロントページの続き (72)発明者フィリップアール、スリフトアメリカ合衆国テキサス、ダラス、チャーチルウェイ 7900、ナンバー2304 Ｆターム(参考） 5B045 AA01 BB34 BB36 BB38

Claims

【特許請求の範囲】

【請求項１】（ａ）アプリケーションプロセッサ上の
実時間メディアアプリケーション用の複数のプラグイン
と、（ｂ）アルゴリズムプロセッサ上の複数のアルゴ
リズムコンポーネントと、ただし、前記プラグインがそ
れぞれ１つ以上のアルゴリズムコンポーネントに対応
し、前記アルゴリズムプロセッサがアプリケーションプ
ロセッサに連絡しており、（ｃ）前記アルゴリズムプ
ロセッサ上のコンポーネントスケジューラとを備え、
（ｄ）前記スケジューラは、（ｉ）前記コンポーネン
トの実行に関連する前記プラグインからの制御に応じた
コンポーネントのスケジューリングと、（ｉｉ）前記プ
ラグインに送出される前記コンポーネントの実行に関連
するイベントの通知とによって、前記コンポーネントに
関して前記アプリケーションに対してサービス品質を提
供する、アルゴリズムプロセッサと連絡するアプリケーションプ
ロセッサ上の実時間メディアアプリケーションのための
フレームワーク。