JPH10511801A - 種々の異なる資源レベルを持つハードウェアプラットフォーム上でマルチメディア・アプリケーションを実行可能とする方法、そのようなアプリケーションを含む物理的記録、及びそのようなアプリケーションを実行する装置 - Google Patents

Abstract

(57)【要約】 マルチメディア・アプリケーション情報が、対話型マルチメディア分配フォーマット(Interactive Multimedia Distribution Format‐IMDF)対応のプラットフォームのような、種々のプラットフォーム上で後に実行可能とするために記憶される。アプリケーションは複数の並列情報ストリームを含む。実行のスケーラビリティ(scalability)は、段階的に向上する品質レベルをそれに沿って示すところの品質レベル項目の単一ストリングを、ストリームに割り当てることにより可能化される。各項目は或る特定のストリームに対し関連する復号品質レベルを特定する。

Description

【発明の詳細な説明】 種々の異なる資源レベルを持つハードウェアプラットフォー ム上でマルチメディア・アプリケーションを実行可能とする 方法、そのようなアプリケーションを含む物理的記録、及び そのようなアプリケーションを実行する装置定義 十分な理解を得るために、次のような用語の定義が与えられる： 資源(Resource) 中央処理ユニット(CPU)のMIPSとか、メガバイト級のメモリサイズと か、メガビット／秒級のバスの帯域幅とかのような、プラットフォー ムの量的ないし質的属性； 資源への要求条件(Resource requirement) そのような資源の必要量； 性能(Performance) コンピュータ又はCPUの速度； 品質レベル(Quality level) プラットフォームとは独立に定義されている復号器の機能レベル。本発明の背景 本発明は、ユーザーに並列に提示する複数の情報ストリームを含むところの、 マルチメディア・アプリケーション情報を、種々のプラットフォーム上で実行す るために記憶する方法に関する。マルチメディア・アプリケーション・プログラ ム（複数）又はアプリケーション（複数）は種々のプラットフォーム上で実行す ることができなければならない。そのようなプラットフォームは、関係するアプ リケーションがその上を正しく走るのを保証することができるようにするために 、資源についての最小の要求条件を満足させなければならない。種々の場合にプ ラットフォームは最小より多くの資源を持っている。実際に利用可能なプラット フォームの資源が与えられた場合に、最適の品質レベルが達成されるために、ア プリケーションはスケーラブル(scalable)にしてあることが有益である。本発明の概要 その結果、本発明の目的はとりわけ、簡明なやり方でそのようなスケーラビリ ティが実現するところの、マルチメディア・アプリケーション情報を記憶する方 法を提供することである。茲で本発明の１つの態様によれば、本発明は、上記ア プリケーションの実行のスケーラビリティを可能なものとするために、上記方法 が、品質レベル項目の単一ストリングであってそのストリングに沿って段階的に 増加する品質レベルを指すところの、品質レベル項目の単一ストリングを上記ス トリームに集合的に割り当てること、及び各項目は、上記ストリームのうちの特 定の１つに対して、関連する復号品質レベルを明確にすることを特徴とする。ス トリング中のそれらの相対的な位置が種々のストリームの間に優先順位を与え、 また各単一ストリームに対する種々の品質レベル間にも優先順序を与える。先ず 初めに、すべてのストリームを一緒にしたものに対して、プラットフォームがア プリケーションを実行するため、又はしないために、指定された最小プラットフ ォーム資源が必要である。更に、もし余分の資源が存在するならば、それを相対 的な優先順序に基づいて種々のストリームに割り当てることは簡明である。この 組織は利用可能な資源に関してプラットフォームが最適の品質レベルをたやすく 選択することを許容する。 種々のプラットフォーム上でのマルチメディアの実行可能性だけについて云え ば、ヨーロッパ特許出願EP A 731 971号及びこれに対応する米国特許出願08/533 ,030号で本件出願人により既に考察されており、それを茲に参照文献として引用 する。該文献では、マルチメディア・アプリケーション自体がマルチプラットフ ォーム翻訳器を持ち、各実際のプラットフォームは抽象的なマシーンの一例であ る。本発明はそのような更に複雑な環境で使えるであろうが、もしプラットフォ ーム資源が量的性能においてのみ異なるならば既に有用である。 本発明による組織では、プラットフォーム又はプレーヤーは各復号器の各品質 レベルに対する資源への要求条件を知っている。それらはプラットフォームの資 源への要求条件テーブル内に記憶されている（図５参照）。データストリームと アプリケーション自体とのどちらもがそれを知る必要はないのであって、その理 由はデータストリームを形成しアプリケーションを書くに当たってターゲットプ ラットフォームは一般的に未だ分かっていないからである。データストリームは すべての関連する復号器の入力データを含んでいる。一般的には、本発明の組織 を実現するのには、これ以上の情報は必要としないのである。アプリケーション は、現実的又は記号的な項目のストリングとして実現されているモデルを含み、 それは関連の復号器レベルの観点でアプリケーションの段階的に上がるモデル又 は優先経路を記述する。 或る特定のプラットフォームの資源への要求条件は、プラットフォームを形成 するとき各復号器及び関連の品質レベルに対して固定されている。これらはプラ ットフォーム内に記憶されている。アプリケーションを生成することは、いわゆ るディスクビルダー(discbuilder)を使って実時間内ファイル内でデータストリ ームを結合することを意味する。更にまた、アプリケーションの段階的に上がる モデルが、それについての１つ又はそれ以上の数の呼(calls)を伴ってアプリケ ーション内に建てられる。一般的にはこのモデルは、データストリームから隔離 されている。 少なくとも１つのそのようなストリームが、上記ストリングの少なくとも２つ の非隣接項目に関連していることが有利である。このことは、ストリームＡが或 る特定の品質レベルを得たとき、ストリームＡの更に改善されることが許される ことのできる以前に、先ずストリームＢの品質が改善されるであろうことを意味 するのである。 品質レベル項目は記憶されるとき上記アプリケーションに沿ってダイナミック なやり方で上記ストリームに割り当てられるのが有利である。それによりアプリ ケーションの書き手は、アプリケーションの実行中に種々の復号器間の優先順序 が変動するかも知れない、ということを判断できる。或る特定のプラットフォー ム上で実行そのものの最中に、このことが実際に使われる品質レベルに影響する かも知れないし、しないかも知れない。 本発明はまた、そのようなアプリケーションの入っている単一の物理的記録担 体にも関し、更にまた、そのようなマルチメディア・アプリケーション情報を再 生するためのプラットフォームシステムにも関し、該プラットフォームは種々の ストリームにに対して適切な品質レベルを自動的に選択するであろう。本発明の その他の有益な態様は従属請求項に記載されている。図面の簡単な説明 これらの態様並びにその他の態様及び本発明の利点が、以下に開示される好適 実施例及び添付された図面を参照して、更に詳細に説明される。それらの添付さ れた図面は： 図１が、本発明によるアプリケーションを記憶するためのフローチャートを示 す図であり； 図２が、そのように形成された単一の記録担体を示す図であり； 図３が、記録を再生するためのプラットフォームシステムを示す図であり； 図４が、サービスの品質管理図表を示す図であり； 図５が、プラットフォームの資源への要求条件テーブルを示す図であり； 図６が、優先経路の図式を示す図である。一般的な考察 マルチメディア、及び特にIMDFアプリケーションは、その最も完全な形態にお いて、次の２つの処理形式を有するであろう： ●ストリーム処理(SP) ―これは、ビデオ(MPEG)，２次元又は３次元のグラフィ ック，オーディオ(MPEG，MIDI，PCM，ADPCM)のようなオーディオ・ビジュアル情 報ストリームのストリーム処理であって、これらのストリームはユーザーである 人間の期待する正規の再生速度における時間的に一致したやり方で処理されなけ ればならない。 ●非ストリーム処理(NSP) ―これは、上述のような時間的に一致したオーディ オ・ビジュアル情報ストリームには直接関連を持たない。しかし用語の簡単のた めに、物理的な記録担体上に在る上述のような時間的に一致したオーディオ・ビ ジュアル情報ストリームに関連する情報も同様にストリームと呼ばれる。この処 理形式は更に次のように再分割することができる： ●(a) 実時間の強制されたNSP ―これは例えば航空機運行シミュレータのよう なシミュレーション計算の類である。 ●(b) 非実時間の強制されたNSP ―これは定常情報(stationary information) を提供するためのデータベース又はエンサイクロペディアの探索の類である。 その低端でも各アプリケーションは最小の資源を持つプラットフォームを必要 とし、それらの資源は適用すべき標準中に定義されていよう。そのような最小の プラットフォーム上では、或る限定された数の情報ストリーム及び計算のみが並 列に処理されることができる。更に強力なプラットフォームでは原理的に、最小 のものに比べれば高品質レベルが許容されよう。そのような資源の例としては、 CPU処理サイクルの循環周波数、メモリサイズ、バス転送容量、I/O機能、等が ある。或る種の環境では原始命令(raw instruction)処理速度を示すMIPS数は、M OPSへの再計算の必要、すなわち演算速度を当該ストリームに相応しいものとす る必要があろう。同様に、全アプリケーション又は一部アプリケーションの搭載 用のような演算オーバヘッドも考慮する必要があろう。サーバー又はその他のマ ルチ処理環境の場合には、利用可能な資源は同時に走る種々のアプリケーション 間で共同使用しなければならないこともあろう。 ストリーム処理(SP)に対しては、資源管理は次の３ステップでなされる： ― すべての利用可能な復号器に対して目標品質レベルを定義する； ― 或る特定の復号器に対して実際の品質レベルを選定する； ― 選定された品質レベルで復号器を制御する。 但し、茲で復号器とは事実上は、種々の復号器間で共同使用されることもされな いこともあるハードウェア上を並列に走る復号器プログラムのことである。 最初のアプローチでは、非ストリーム処理(NSP)はアプリケーションによって 完全に定められ、スケーラブルではないと考えられる、それはプラットフォーム にとって NSPが何をしようとしているかを予見できないからである。このことは NSPに対しては資源への要求条件がプラットフォーム内で前以て分かっていなけ ればならないことを意味する。割り当てられた資源の量は、もし実時間が強制さ れるならば、常に最終期限に間に合っているために十分なものでなければならな い。もし実時間が強制されていないならば、すべての長期に亙る未完成業務の積 み上げを避けるために十分なものでなければならない。このことは一般的に NSP に対する資源が一括して割り当てられなければならないことを意味する。次いで 任意の残りの資源がSPに対して割り当てられることができる。好適な実施例の詳細な説明 図１は、本発明によるアプリケーションを記憶するためのフローチャートを示 す。このフローチャートに従う演算はアプリケーションの一般的書き込みの直ぐ 後に実行できる。ステップ20ではアプリケーションの未処理の情報が特定の時間 間隔又は情景(scene)に相応しいように受信される。一般的に情景のサイズはア プリケーションの開発者により定められている。そうするときには、情景は通常 は音楽又は動画の間隔、静画、グラフィックエレメント、等々のようなものから 積み上げられたものである。情報の中ではデータストリームは通常はつなぎ合わ せてインターリーブされ多重化されたデータファイルとなっている。十分な処理 能力が、該アプリケーションをその最高品質レベルで実行するために利用可能で ある。該アプリケーションの実行の過程では、処理はしばしば時間的に線形(lin ear)であり、種々のストリームが動画のやり方におけるように相互同期をとって ユーザーに提供される。しかしこの行動は時間的に同一(uniform)である必要は ないので、ある時点で画像は凍結し、付随する音楽は進行することもある。相互 に影響し合う状況では、相対的な行動は更に不均一(non-uniform)なこともあろ う。ステップ22ではアプリケーションの最初の未処理の項目が、その品質レベル 項目のストリングをそれに対して定める、という見地でアクセスされる。 ステップ28では該アプリケーション（の一部）を実行するための最小品質レベ ルが査定(assess)される。この判定はアプリケーションの書き手によってなされ る。次に、茲で情景の見出し(heading)が与えられて、品質レベル項目のストリ ングの最初の項目としてすべての復号器の最小限必要な品質レベルが示される。 この最初の項目は１個より多くの復号器に関連するから複合項目となるであろう 。自動的なスケーラビリティが達成できるようにするために、ストリングの以後 の項目は、進むに従って１段ずつ段階的に品質が向上するように配列されていな ければならない。ステップ28の演算は、孤立した１つの情景で実行することもで き、或いは前後の情景との関連で実行することもできる。次にステップ30では、 ストリームのうちの異なる複数の品質を許容するところの正確に唯１つの情景が その次に高い品質レベルで取り上げられて、情景が再度実行される。向上可能な 品質レベルを持つストリームの各々に対してこれが繰り返され、そのことがルー プ線31で示されている。単一品質向上のすべての可能性について情景が実行され 終わると、その中での最良の再生(performance)がステップ32で選定される。一 般的にこれは設計者個人による主観的行動である。品質を更に向上させることが 可能である限り（ステップ34）、システムは次にはステップ30に戻る。もしすべ てのストリームがそれぞれの最高品質レベルで実行され終わったら、該アプリケ ーション情景が搭載される（ステップ36）。本発明の最終的な結果は、この種類 の媒体(media)の標準的製造方法で造られた単一の担体(carrier)である。ステッ プ38で処理システムは終了する。簡単のために単一の情景の搭載のみが考察され た。しかしその次の情景に対して図１のフローチャートを実行すると決定しても よいのである。 図２は、そのように形成された単一の記録担体を表している。この担体は縦の 別々の列で示された８個のストリームを含んでいる。Compact-Disc Interactive のような物理的な記憶のために、一般的には直列化した演算が実行される；これ は実時間多重化ファイルを生成することができる。各ストリームにはブロック32 があり、それは識別子(identifier)，長さ，及びその他各種参考事項を含む。こ のストリームの並列特性は、それらストリームがインターリーブされたやり方で 再生のためにアクセスできる、という事実に在る。簡単のために物理的記憶の実 際の組織はアドレスされていない。模範的解答が本件と同一出願人によるヨーロ ッパ特許出願 EP Patent Application 95202623.5(PCT/IB96/00962に相当)に開 示されており、茲にそれを参照文献とする。そのようなインターリービングでは 、プレーヤーは、実際にアクセスされているところのストリームのトラックを維 持する。上述のように、段階的に品質が向上することを示す品質レベル項目のス トリングはこの図中のＸとして情景の見出しの中に記憶されている。 図３は記録担体を再生するためのプラットフォームシステムを示す。ディスク の形をした記録体40は、線44上に在る位置決め信号の制御の下に読み取り装置42 によりアクセスされる。プレーヤー本体60は、ユーザーの命令を入力するユーザ ーインターフェース50と、上述の品質レベル項目のストリングを検出する検出器 ブロック46とを持つ。この検出器ブロックはまた、当該プラットフォームに適応 する種々の復号器の種々の品質レベルに対して必要な資源についても知っている 。従ってそれは実際に達成可能な品質のレベルを、或る要求条件には適合するが 他の条件はプラットフォームに過重な負担となるように、選択できる。これにつ いては以後更に詳しく論ずる。中央処理デバイス48が上記選定に従って当該スト リームを処理する。そのような処理は更にインターフェース50上のユーザーの命 令の制御下にもあるであろう。原理的にはユーザーはプラットフォームにより選 定された品質レベルを覆すこともあろう。例えばユーザーがビデオよりオーディ オ上演を優先して選ぶことがあり、そのためにオーディオ処理に対しアプリケー ションの設計者が割り当てた相対的優先度よりも多くの資源を優先して割り当て ることがあろう。中央処理デバイス48は種々のユーザー情報信号を種々のユーザ ー出力装置52，54，56，58に出力する。それらのユーザー出力装置にはオーディ オチャネル、ビデオチャネル、及びデータチャネルが含まれる。これらのうちの 様々のものが並べて配列されることもある、例えば同じスクリーンにビデオとア ニメーションの表示が並列に置かれる、等。またこの処理は線44上で読み取り装 置42のために位置決めもさせる。 以後、資源管理について更に詳細に論ずる。中央処理デバイス48は種々の装置 、例えばメモリ，バス，及びI/O機能等を含む。それらの情報は検出器ブロック4 6に知らされ、該検出器ブロック46は更に種々の品質レベルに対して必要な資源 の量につても知っている。このことが、実際のアプリケーションに適合するよう に、現実に存在する資源を用いて実現できる最適の品質レベルを、選択すること を検出器ブロック46に許容する。もし適切な再生レベルが選択されたならば、必 要な資源が割り当てられて、アプリケーションが実行されるようになる。しかし もし、例えば帯域幅，遅延，誤り率，等について規定に対し資源が不十分である ならば、プレーヤーはユーザーに通知し、またアプリケーションの実行を一時停 止する。続いて起こる情景に遭遇すると資源割り当ては再始動しなければならな い。もし資源への要求条件がアプリケーションと共にダイナミックに変動するな らば、アプリケーションが必要な最小の全体的品質レベルをシグナルして、アプ リケーションの全体的実行可能性がプラットフォームによって決定できる。その 結果として瞬間的なサービスの品質は時間的に不均一であろう。 この関連において、図４はサービス品質の管理図表を示す図である。アプリケ ーション70が或る特定のサービス品質を管理装置72に要請し、該管理装置72は契 約提案を返送する。もしそれが受け入れられれば、管理装置72はパラメタを処理 装置に送る。処理装置は、走行時間資源割り当て(74)，計数処理及び規制(76)を 行い、ハードウェア・エレメント78−84を制御する。そのように割り当てられた 資源はそのサービスをアプリケーションに提供する。 図５は、プラットフォーム内に存在する典型的な資源への要求条件のテーブル を示し、様々なストリームがある故に、その結果として関連の資源への要求条件 は大幅に標準化されている。その上にアプリケーション自身はプラットフォーム 内に存在する種々の資源について知ろうとはしない。 MPEGビデオについては、次の客観的品質レベルが復号器に対し適用されるであ ろう： ●１．黒白／半フレームレート； ●２．黒白／全フレームレート； ●３．全カラー／半フレームレート；●４．全カラー／全フレームレート． MPEGオーディオについては、次の客観的品質レベルが復号器に対し適用される であろう： ●１．モノ； ●２．ステレオ； ●３．ドルビーサラウンド； ●４．５＋１サラウンド（５個の標準チャネル及び１個の特殊効果用）． ３次元グラフィックについては、次の客観的品質レベルが復号器に対し適用さ れるであろう： ●１．フレーム当たり5000個の三角形又は多角形； ●２−４．それぞれフレーム当たり 10k個,15k個,20k個の三角形． 図５では縦の列が、プラットフォーム内の既知の装置からのこれら種々の品質 レベルにより要求される資源を記載する。記載された要求条件は、平均値、平均 値プラス20％程度の安全マージン、又は最悪の場合に相当しているであろう。茲 で資源１ないし４は、それぞれ第１プロセッサ、第２プロセッサ、メモリ、及び I/O装置であろう。各資源は最高再生値により特徴付けられるところの抽象的実 在である。 利用可能な資源が或る特定のアプリケーションを実行するためにかろうじて最 小限の必要を超えている場合には、プラットフォームはどの復号器がどんな品質 レベルで再生しなければならないかについて決定しなければならない。この決定 のために、特定のストリームのアプリケーションに対する相対的重要性、及びそ の実行に対して必要な資源を知る必要があり；第１の知識は、アプリケーション 間で大幅に変動するが故にアプリケーションによってもたらされ；第２の知識は 、プラットフォーム自身の内に存在する。簡明なやり方は段階的に挙げて行くや り方で実行可能性レベルを記述することである。用語「復号器」は実際の復号用 ソフトウェアパッケージの意味で使われる。例えば： アプリケーション：品質レベル１でMPEG2 ビデオ復号器１を創造する； 品質レベル１でMPEG2 オーディオ復号器１を創造する； MPEG2 オーディオ復号器１を品質レベル２に上げる； MPEG2 ビデオ復号器１を品質レベル２に上げる； MPEG2 オーディオ復号器１を品質レベル３に上げる； プレーヤー１ MPEG2 ビデオ復号器１を品質レベル３に上げる； 品質レベル１でMIDI-16 復号器１を創造する； プレーヤー２ MIDI-16 復号器１を品質レベル２に上げる； MIDI-16 復号器１を品質レベル３に上げる． このテーブルに示すように、アプリケーションの完全機能性のために、３個の 復号器はすべて品質レベル３で動作しなければならない。２つの典型的な利用可 能プラットフォームの各々に対して、実際の再生は比較的低いものであり当該復 号器の各々に対し破線上で達成された最大レベルによって与えられる。例えば、 相対的に簡単なプレーヤーは、MIDI，レベル２におけるビデオ，及びレベル３に おけるオーディオを持たない。相対的に高い再生をするプレーヤーは、レベル１ におけるMIDI，及びレベル３におけるオーディオとビデオの双方を持つ。明らか に、MIDIのアプリケーションへの貢献は相対的に僅かな重要性しか持たないと判 定される。もう１つのアプリケーションでは、ストリームの相対的重要性は異な ることがあろう。例えば、MIDIは品質への妥当性は近似的にオーディオと同じレ ベルにあると評価することができよう。別のプレーヤーはいわゆる「サウンドブ ラスター(sound blasters)」カードをボード上に持つことがあり、これが中央プ ロセッサ機能の外でMIDI復号を行わせる。 この文脈で、図６は或る特定のアプリケーションに係わる２次元優先経路図表 (two-dimensional preference path diagram)を示し、この図表は当該アプリケ ーションの各別個の情報ストリームに対し１つの次元を持つ。簡単のためにこの 実例では２ストリームのアプリケーションが取り上げられている。優先経路は実 線で表され、それに沿った各×印は感知可能な資源のセットを表す。次々の×印 は該アプリケーションを再生する次々の品質レベルを示す。優先経路は０資源を 表す左上端の隅から開始する。実線に沿ったその次の×印は、以前に考察した３ 次元アプリケーションに対し与えられたのと同じやり方でその次の列に対応する 。茲で或る特定の（図中○で囲った）×印は、当該プラットフォーム上のアプリ ケーションを実行するための最小の資源への要求条件を示す。プラットフォーム は×印の線に沿って最も遠い×印によって表されるような最良の品質レベルを達 成しようと試みる。 更に、点線はプラットフォームの全資源を示す。この線を超えない最後の×印 がこの特定のプラットフォームの利用可能な最高品質を示す。もしこのアプリケ ーションが並列に多数のストリームを持つならば、該マトリクスは同じく多数の 次元を持ち、更に静的(static)であるに及ばない。或る状況ではプラットフォー ムはこの図表の線に厳密に沿い続けるには及ばない。例えば、もしMPEG-3オーデ ィオがプラットフォームに過重の負担を掛けようとするならば、該プラットフォ ームによりMPEG-3ビデオが（後に着実に改善される品質レベルのシーケンス中で ）巧く実行できるか否かを、該プラットフォームはなお試みることができよう。 もし巧く実行できるのであれば、該プラットフォームは実行に含まれよう。 アプリケーションにとっては相対的に重要なシーケンスを明記することは、も しストリームの数が多く相対的な重要性の割当てがダイナミックであるならば、 労の多い仕事である。言語の数が増加し、オーディオは標準又はカラオケであろ うし、ビデオも多くの変形が並列に提示されようから、ストリームの数は現実に 大きいものであることに留意しなければならない。これを簡単にするために、相 対的な重要性が各復号器に割り当てられ、これらは初等的モデル上にマップされ る。それは次のようになされる： ●復号器の重要性はその最小限許容される品質レベルであり；これは段階的に上 げる(incremental)記述中の最初の出現に対応するであろう。 ●各復号器の品質はそれがオープンになる順序で上がって行く。 ●各復号器の品質はそれが最高の品質に達するまで上がって行く。 例えば、各復号器に対し最高の品質が３であり、 復号器１＝オープン復号器（MPEG2,ビデオ,2） 復号器２＝オープン復号器（MPEG2,ビデオ,2） 復号器３＝オープン復号器（MIDI-16,1） として与えられている重要性の図式(importance scheme)は、次のような段階的 に上げる記述を与える： 品質レベル２でMPEG2 ビデオ復号器１を創造する； 品質レベル２でMPEG2 オーディオ復号器１を創造する； 品質レベル１でMIDI-16 復号器１を創造する； MPEG2 ビデオ復号器１を品質レベル３に上げる； MPEG2 オーディオ復号器１を品質レベル３に上げる； MIDI-16 復号器１を品質レベル２に上げる； MIDI-16 復号器１を品質レベル３に上げる． 各復号器の品質レベルを選定するのに、我々は段階的に上げるモデルの始まり で開始する。復号器は或る１つの品質レベルで創造され、各復号器品質レベルは 段階的に上げるモデル中に記述された優先経路に従って１つ上げられる。創造さ れる各復号器に対し、及び１つ上げられる各品質レベルに対して、資源への要求 条件は、資源への要求条件テーブル中でルックアップされ、足し算されて、アプ リケーションの全資源への要求条件に到達する。もし資源のうちのどれか１つに 対する要求条件がその最大値（すなわち 100％）を超えるならば、それ以上の復 号器品質はもはや果たされない。これが実際のアプリケーション又は情景に対す るこのプラットフォームの優先経路の終端である。

───────────────────────────────────────────────────── フロントページの続き (54)【発明の名称】 種々の異なる資源レベルを持つハードウェアプラットフォーム上でマルチメディア・アプリケー ションを実行可能とする方法、そのようなアプリケーションを含む物理的記録、及びそのような アプリケーションを実行する装置

Claims (1)

1. 【特許請求の範囲】 １．ユーザーに並列に提示する複数の情報ストリームを含むところの、マルチメ ディア・アプリケーション情報を、種々のプラットフォーム上で実行するために 記憶する方法において、 上記アプリケーションの実行のスケーラビリティを可能なものとするために 、上記方法は、品質レベル項目の単一ストリングであってそのストリングに沿っ て段階的に増加する品質レベルを指すところの、品質レベル項目の単一ストリン グを上記ストリームに集合的に割り当てること、及び 各項目は、上記ストリームのうちの特定の１つに対して、関連する復号品質 レベルを明確にすること を特徴とするマルチメディア・アプリケーション情報を記憶する方法。 ２．請求項１に記載のマルチメディア・アプリケーション情報を記憶する方法に おいて、そのようなストリームのうちの少なくとも１つは、別のストリームに係 わる少なくとも１つの項目により隔離されているところの、上記ストリングの少 なくとも２つの非隣接の項目に関連することを特徴とする方法。 ３．請求項１又は２に記載のマルチメディア・アプリケーション情報を記憶する 方法において、品質レベル項目は、記憶されるとき上記アプリケーションに沿っ てダイナミックなやり方で、上記ストリームに割り当てられることを特徴とする 方法。 ４．請求項１，２又は３に記載のマルチメディア・アプリケーション情報を記憶 する方法において、該方法はストリームの数が少なくとも３であり、その各々に 少なくとも２つの上記品質レベルが割り当てられている場合に対するものである ことを特徴とする方法。 ５．請求項１ないし４のうちのいずれか１項に記載の方法に従って記憶される包 括的なマルチメディア・アプリケーションが入っている単一の物理的記録担体に おいて、 上記アプリケーションの実行のスケーラビリティを可能なものとするために 、上記アプリケーションは、品質レベル項目の単一ストリングであってそのス トリングに沿って段階的に増加する品質レベルを指すところの、品質レベル項 目の単一ストリングを上記ストリームに集合的に割り当てられていること、及び 各項目は、上記ストリームのうちの特定の１つに対して、関連する復号品質 レベルの関連する量を明確にすること を特徴とする記録担体。 ６．請求項５に記載の記録担体において、そのようなストリームのうちの少なく とも１つは、別のストリームに係わる少なくとも１つの項目により隔離されてい るところの、上記ストリングの少なくとも２つの非隣接の項目に関連することを 特徴とする記録担体。 ７．請求項５又は６に記載の記録担体であって、複数の上記ストリングを含み、 その各々が上記アプリケーションの或る特定の部分に係わるところの記録担体に おいて、品質レベル項目は、上記それぞれのストリング中でダイナミックなやり 方で、上記ストリームに割り当てられることを特徴とする記録担体。 ８．請求項５，６又は７に記載の記録担体において、該記録担体はストリームの 数が少なくとも３であり、その各々に少なくとも２つの上記品質レベルが割り当 てられている場合に対するものであることを特徴とする記録担体。 ９．種々のプラットフォームの連なりの上で実行可能であり且つ複数の並列な情 報ストリームを含むところのマルチメディア・アプリケーションの、記憶媒体か らのアプリケーション情報を再生するためのプラットフォームシステムにおいて 、 上記連なりに沿って実行のスケーラビリティを可能なものとするために、上 記アプリケーションは、品質レベル項目の単一ストリングであってそのストリン グに沿って段階的に増加する品質レベルを指すところの、品質レベル項目の単一 ストリングを上記ストリームに集合的に割り当てられており、 各項目は、上記ストリームのうちの特定の１つに対して、関連する復号品質 レベルの関連する量を明確にし、また、 上記プラットフォームは：上記項目を上記ストリングに沿って審問し、或る 特定の品質レベル項目に必要なすべてのプラットフォーム資源を累積するため の審問手段と；所要のプラットフォーム資源を現実のプラットフォーム資源と比 較するために、上記審問手段から供給を受ける比較手段と；当該アプリケーショ ン用にプラットフォームの提供できる最適品質レベルを選択するために、上記比 較手段から供給を受ける選択手段と；を有して成る ことを特徴とするプラットフォームシステム。 10．請求項９に記載のプラットフォームシステムにおいて、要求されるプラット フォーム資源が利用可能な最大プラットフォーム資源に調和していることを表す 項目を超えて追加のストリング項目を探索する手段であるが、２番目の情報スト リームには相応しいものであり且つ利用可能なプラットフォーム資源とよく釣り 合っている項目を支持して、プラットフォーム資源に過重な負担を掛ける項目で 且つ１番目の情報ストリームには相応しい項目を超えて通過するところの探索手 段を更に持ち、それによって上記再生品質を改善することを特徴とするプラット フォームシステム。