JP4726097B2 - 適応制御を行うことができるｍｐｅｇコード化オーディオ・ビジュアル対象物をインターフェースで連結するためのシステムおよび方法 - Google Patents

Description

関連出願への相互参照
本出願は、優先権を主張する米国特許仮出願６０/０４２，７９８に関連する。
発明の背景
発明の分野
本発明は、コード化マルチメディアおよびその記憶、ユーザへの配布に関し、特に、チャネルおよび解読資源のどちらかが制限され、時間により変動する場合、またはユーザ・アプリケーションが、コード化されたマルチメディア対象物との高度の相互作用を必要とする場合のコード化に関する。
関連技術の説明
デジタル・マルチメディアは、操作面、複数のものを発生できるという面およびエラーに影響されないという利点およびその他の利点を持っているが、送信帯域幅の記憶容量により制限を受ける。それ故、実際に使用する場合には、多くの場合、圧縮またはコード化する必要がある。さらに、インターネットおよび他のネットワーク上の、デジタル・マルチメディアに対する需要が急速に増大しているため、効率的な記憶装置、ネットワーク・アクセスおよびサーチおよび検索、多くのコード化スキーム、記憶フォーマット、検索技術および送信プロトコルが開発されてきた。例えば、画像およびグラフィックス・ファイル用には、ＧＩＦ、ＴＩＦおよび他のフォーマットが使用されている。同様に、オーディオ・ファイルも、ＲｅａｌＡｕｄｉｏ、ＷＡＶ、ＭＩＤＩおよび他のフォーマットによりコード化され、記憶される。アニメーションおよびビデオ・ファイルは、多くの場合、ＧＩＦ８９ａ、Ｃｉｎｅｐａｋ、Ｉｎｄｅｏおよび他のフォーマットにより記憶される。
非常に多数の現存のフォーマットを再生するために、多くの場合、デコーダおよびインタープリタが必要になるが、その場合、前記デコーダおよびインタープリタが、ハードウェアで実行されるのか、ソフトウェアで実行されるのかにより、特にソフトウェアの場合には、ホスト・コンピュータの能力により、速度、品質および性能がまちまちになる。マルチメディアの内容が、コンピュータ（例えば、パソコンのような）を通してアクセスされた、ウェブ・ページ内に含まれている場合には、ウェブ・ブラウザを予想されるすべての内容に対して正しく設定する必要があり、また前記内容を処理するために、各タイプの内容を認識し、内容ハンドラ（ソフトウェア・プラグインまたはハードウェア）の機構をサポートしなければならない。
相互動作が可能でなければならないこと、品質および性能が保証されていなければならないこと、チップ設計の際のスケールが小さくなければならないこと、また種々様々のフォーマットのための内容を発生する際にコストがかかること等の理由で、マルチメディア・コード化、パケット化および確実な配布の分野で標準化が促進されてきた。特に、ＩＳＯ ＭＰＥＧ（国際規格組織動画専門家グループ）は、ＭＰＥＧ−１およびＭＰＥＧ−２と呼ばれる、二つの規格の形のコード化マルチメディアに対するビット・ストリーム・シンタックスおよび解読意味論の標準化を進めてきた。ＭＰＥＧ−１は、主として、コンパクト・ディスク（ＣＤ）のようなデジタル記憶媒体（ＤＳＭ）上で使用するためのものであり、一方、ＭＰＥＧ−２は、主として、放送環境（トランスポート・ストリーム）で使用するためものである。しかし、ＭＰＥＧ−２は、またＤＳＭ（プログラム・ストリーム）上で使用するための、ＭＰＥＧ−１類似の機構もサポートする。ＭＰＥＧ−２は、また独立のまたはネットワークに接続している、ＭＰＥＧ−２の標準化再生にために必要な場合がある、基本的なユーザの双方向通信のためのＤＳＭコマンドおよび制御のような追加機能を含む。
安価なボード／ＰＣＭＣＩＡカードが開発され、中央処理装置（ＣＰＵ）が入手することができるようになったために、ＭＰＥＧ−１規格が、パソコン上の映画およびゲームの再生に共通に使用することができるようになった。一方、ＭＰＥＧ−２規格は、比較的高画質のアプリケーション用のものであるため、デジタル衛星ＴＶ、デジタル・ケーブルおよびデジタル汎用ディスク（ＤＶＤ）からの、娯楽用アプリケーションに共通に使用されている。前記アプリケーション／プラットホームの他に、ＭＰＥＧ−１およびＭＰＥＧ−２は、ネットワークを通して送られるストリーム、ハードディスク／ＣＤ上に記憶されているストリーム、およびネットワークによるアクセスおよびローカル・アクセスの組み合わせの種々の他のコンフィギュレーションでの使用が期待されている。
ＭＰＥＧ−１およびＭＰＥＧ−２の成功、インターネットおよび移動チャネルの帯域幅制限、ブラウザを使用するウェブをベースとするデータ・アクセスの柔軟性、および双方向個人通信の必要が増大しているために、マルチメディア使用および制御のための新しいパラダイムが誕生した。それに応じて、ＩＳＯ ＭＰＥＧは、新しい規格、ＭＰＥＧ−４を制定に着手した。前記ＭＰＥＧ−４規格は、個々の対象物の形のオーディオ・ビジュアル情報のコード化、および前記対象物の合成および同期再生用のシステム向けのものである。前記固定パラメトリック・システムのＭＰＥＧ−４の開発が、引き続き行われる一方で、通信、ソフトウェアおよびＪａｖａ言語によるようなネットワーク運営用の新しいパラダイムにより、柔軟で、適応性を持ち、ユーザが双方向で通信できる新しい機会が生まれた。
例えば、Ｊａｖａ言語の開発により、ユーザがアクセスしたウェブ・ページで、ホスト役をするウェブ・サーバからの、クライアント・パソコン上での、アプレット（ジャバ・クラス）のダウンローディングおよび実行に重要な、ネットワーク運営およびプラットホームの独立が可能になる。アプリットの設計により、サーバ側で記憶しているデータへの一回だけのアクセスが必要になる場合もあるし、すべての必要なデータを、クライアントのパソコン上に記憶することもできるし、または（スタートアップに必要な記憶スペースを少なくし、時間を短縮するために）数回の部分的アクセスが必要になる場合がある。後のシナリオは、ストリーム型再生と呼ばれる。
すでに説明したように、コード化マルチメディアを、例えば、パソコンのようなコンピュータ上で、インターネットおよびローカルのネットワーク接続アプリケーションのために使用し場合には、多くの状況が発生する。第一に、マルチメディアのネットワークによるアクセス用の帯域幅は、制限されるか、時間と共に変化するようになり、その場合には、最も重要な情報だけを送信し、その後で、もっと広い帯域幅を使用できるようになったとき、他の情報を送信しなければならない。
第二に、使用できる帯域幅がどのような幅のものであっても、解読を行わなければならないクライアント側の、パソコンのＣＰＵおよび／またはメモリ資源は制限を受け、さらに、前記資源も時間により変化する。第三に、マルチメディア・ユーザ（消費者）は、高度に双方向の非直線ブラウジングおよび再生を必要とする場合がある。これは特別のことではない。何故なら、ウェブ・ページ上の多くのテキスト内容は、ハイパー・リンクされた機能を使用することにより、ブラウズすることができ、コード化オーディオ・ビジュアル対象物を使用する表示用に、同じパラダイムの使用が期待されるからである。パラメトリックＭＰＥＧ−４システムは、非常に制限された方法でしか、前記の状況を処理できないだろう。すなわち、対象物の欠落または対象物の一時的な発生が起こり、解読または表示ができなくなり、その結果、オーディオ・ビジュアルの表示が不安定になる。さらに、ＭＰＥＧ−４を使用した場合、ユーザは、前記状況をうまく処理することができない。前記パラメトリック・システムの前記制限を回避するの、ＭＰＥＧ−４開発用の可能性のある一つの選択肢は、プログラムを使用するシステムの開発である。
ソフトウェア業界では、長い間、アプリケーション・プログラミング・インターフェース（ＡＰＩ）が、多数の異なるタイプのコンピュータ・プラットホーム上での標準化動作および機能を達成するための手段として認識されてきた。通常、ＡＰＩを定義することにより、種々の動作を標準化することができるが、前記動作の性能は、特定のプラットホームに関心を持つ特定のベンダが、そのプラットホーム用に最適化された実行を供給する場合があるので、種々のプラットホーム上で異なる場合がある。グラフィックの分野では、バーチャル・リアリティ・モデリング言語（ＶＲＭＬ）は、シーン・グラフ・アプローチを使用することにより、対象物とシーンの説明との間の、空間的および時間的関係を指定する手段を使用することができる。ＭＰＥＧ−４は、リアルタイムのオーディオ／ビデオ・データ、および顔または体の動きを処理するために、多くの方法で、ＶＲＭＬおよび拡張ＶＲＭＬに対して、中心の構造物の二進表示（ＢＩＦＳ）を使用してきた。ＶＲＭＬの機能を強化し、プログラムによる制御を行うことができるように、ディメンションＸ社は、一組のＡＰＩを液体リアリティとして発売した。最近、サン・マイクロシステム社が、ジャバ３Ｄの初期バージョン、すなわち、他の機能も持っているが、とりわけ、合成オーディオ・ビジュアル対象物の、シーン・グラフとしての表示をサポートするＡＰＩ仕様を発表した。サン・マイクロシステム社は、ジャバ・メディア・フレームワーク・プレーヤＡＰＩ、すなわち、マルチメディア再生用のフレームワークを発売した。しかし、現在市販されているＡＰＩパッケージは、どれもＭＰＥＧ−４コード化および他の高度のマルチメディアの内容の種々の要求に適した広範でしっかりした機能を持っていない。
発明の概要
本発明は、パラメトリックＭＰＥＧ−４のような非適応クライアント・システムが適応できるような方法で、コード化されたオーディオ・ビジュアル対象物を再生およびブラウズすることができるようにする、コード化オーディオ・ビジュアル対象物をインターフェースにより接続するためのシステムおよび方法を提供する。本発明のシステムおよび方法は、アーキテクチャ・レベルでプログラムを使用するもので、特に、ＭＰＥＧ−４コード化データにアクセスし、それを処理するために構成された、指定の組のアプリケーション・プログラミング・インターフェースにより、パラメトリック・システムの一番上に適応性のある一つの層を追加する。
当業者には周知のＭＰＥＧ−４は、デジタル・メディア内蔵フレームワーク（ＤＭＩＦ）が監督するシステムズ・デマルチプレクス（Ｄｅｍｕｘ）、シーン・グラフ、およびメディア・デコーダ、バッファ、コンポジタおよび再現装置からなるパラメトリック・システムであると見なすことができる。標準ＭＰＥＧ−４に対して本発明のシステムおよび方法が行った強化または拡張としては、メディア解読の範囲に入る一組のと指定ＡＰＩ、ユーザ機能およびクライアント・アプリケーションが内蔵することができるオーサリング等がある。強力なオーディオ・ビジュアル・インターフェース装置を提供することにより、ユーザの入力に応じて多数の強化リアルタイムおよび他の機能を実現することができ、ＭＰＥＧ−４クライアントが使用することができるシステム資源が少ない場合に、滑らかなデグラデーションを行うことができる。
本発明が行われた一つの理由は、ユーザの制御の下でＭＰＥＧ−４の再生およびブラウズを行うための標準化インターフェースが、必要であったためである。本発明のインターフェースは、コード化メディア・データを、直ちに使用することができるターミナル資源に容易に適応させるためのものである。本発明のインターフェースは、また機能として直接、または近い将来に重要になると思われるオーディオ・ビジュアル・アプリケーションおよびサービスに埋設して、間接的に、ユーザが求めていると思われる相互作用を容易にする。
本発明は、いくつかの分野を含む、しっかりしたアプリケーション・プログラミング・インターフェース（ＡＰＩ）の形の、インターフェースによる接続方法を指定する。メディア解読の分野においては、ビジュアル解読インターフェースが指定される。ユーザ機能の分野においては、順送り、ホット・オブジェクト、方向性、トリック・モードおよび透明なインターフェースが指定される。ユーザ・オーサリングの分野においては、ストリーム編集インターフェースが指定される。インターフェースの前記全体の組は、すべての組を網羅しているわけではないが適応性のかなりの部分を実行を容易にする。
【図面の簡単な説明】
添付の図面を参照しながら、本発明を説明する。図面中、類似の素子には類似の番号が使用されている。
図１は、本発明の一実施形態を示すシステムのハイ・レベルのブロック図である。
図２は、本発明の前記実施形態を詳細に示す前記システムのブロック図である。
図３、本発明のビジュアル解読のためのインターフェース方法である。
図４は、本発明の機能用のインターフェース方法である。
図５は、本発明のオーサリングのためのインターフェース方法である。
好適な実施形態の詳細な説明
本発明のシステムおよび方法を、ＭＰＥＧ−４解読環境で説明する。前記環境において、本発明は、一つのＡＰＩではなく、種々のインターフェースを拡張ＭＰＥＧ−４システムのためのＡＰＩの集合体を指定する。当業者には周知のＪａｖａ言語が、ＡＰＩを指定するために使用され、また当業者には周知の関連電子メモリ、記憶装置、バスおよび関連構成部分を持つ汎用プロセッサまたは特殊用途プロセッサ上で実行される。本発明においては、例示として、三つの分野のＡＰＩが識別され、各分野において、代表的な機能が提供される。
上記三つのの例示としてのＡＰＩは下記の通りである。
・メディア解読
・ユーザ機能
・オーサリング
本発明の特定のＡＰＩおよび前記ＡＰＩの実行を組織する方法を、下記表に最初まとめ、以下に説明する。

パッケージは、ＡＰＩの実行を組織するための手段である。本発明が表示するＡＰＩのライブラリを考慮にいれた、パッケージの部分的なリストは下記の通りである。
・ｍｐｇｊ．ｄｅｃ
このパッケージは、相互作用を含むユーザ機能に対するクラスを含む。
・ｍｐｇｊ．ｆｕｎｃ
このパッケージは、優先を含むユーザ機能に対するクラスを含む。
・ｍｐｇｊ．ｕｔｉｌ
このパッケージは、種々の入力、出力、サウンドおよびビデオ装置へのインターフェースを提供する。
ここで、本発明のシステムおよび方法および関連インターフェース方法（ＡＰＩ）について説明する。
図１は、本発明のシステム実行のハイ・レベルのブロック図である。前記実行は、二つの主要な構成部分からなる。第一の構成部分は、デジタル・メディア内蔵フレームワーク（ＤＭＩＦ）１６０からなる周知のパラメトリック・システムで、チャネル１５５に送付インターフェースを供給し、システムズ・デマックス１６５に接続している。前記システムの出力は、図を簡単にするため、ＢＩＦＳおよびメディア・デコーダ、バッファ、コンポジタおよび再現装置１７０からなる一つの集合ブロックで示す、一連のブロックを通して送られる。レベル１７５上の前記集合ブロックの出力は、ディスプレイに送られる。第二の主要な構成部分は、ＭＰＥＧアプリケーション／アプレット（ＭＰＥＧ Ａｐｐ）１００であり、この構成部分は、それぞれ、１２０を通して、外部オーサリング・ユニット１３０およびユーザ入力に、本発明のオーサリングＡＰＩおよび機能ＡＰＩをインターフェースする。さらに、ジャバ仮想機械、およびジャバ・メディア・フレームワーク（ＪＶＭおよびＪＭＦ）１１０は、ＢＩＦＳおよびメディア・デコーダ、バッファ、コンポジタおよび再現装置１７０に接続するための下支え基盤として使用され、また、シーン・グラフＡＰＩ１５０（ＭＰＥＧにより提供され、本発明で使用する）およびデコーダＡＰＩを通して、ＢＩＦＳおよびメディア・デコーダ、バッファ、コンポジタおよび再現装置１７０に直接インターフェースする。
図２は、図１の種々のブロック、構成部分およびインターフェースのさらに詳細な図面である。この図では、オーサリング・ユニット１３０が、ライン２００上で、ライン２０５を通してインターフェースするユーザ入力１４０から独立して、ＭＰＥＧ Ａｐｐ１００にインターフェースしている。この図は、また各インターフェース、オーサリングＡＰＩ２９０および機能ＡＰＩ２９５も含む。さらに、この図では、ＭＰＥＧ Ａｐｐ１００およびその下のＪＶＭおよびＪＭＦ１１０が、ライン２１５を通してＢＩＦＳデコーダおよびシーン・グラフ２２５に働きかけ、２０７を通してシーン・グラフＡＰＩ２１０にインターフェースしている。ＢＩＦＳデコーダおよびシーン・グラフ２２５は、ライン２６０、２６１、２６２を通して多数の例示としてのメディア・デコーダ２７０、２７１、２７２を制御し、また（ライン２６８および２６９を通して）コンポジタ２８２および再現装置２８４を制御する。ＭＰＥＧ Ａｐｐ１００に関連するＪＶＭおよびＪＭＦ１１０は、同様に、各ライン２６３、２６４、２６５を通して、メディア・デコーダ２７０、２７１および２７２を制御する。図２について、種々のプログラムを使用する制御装置およびインターフェースを説明してきた。
図２の残りの部分は、ＭＰＥＧ−４のパラメトリック・システムを詳細に示す。この図の頂部の、本発明のプログラムを使用するシステムおよび方法の動作について説明する。解読されるＭＰＥＧ−４システムのビットストリームは、チャネル１５５を通して、ネットワーク／記憶装置配布インターフェースＤＭＩＦ１６０に送られる。前記インターフェースＤＭＩＦ１６０は、前記ビットストリームをライン２３０を通して、Ｄｅｍｕｘ１６５に送る。パッケージから取り出され、分離されたビットストリームは、シーン叙述情報を含む複数の部分からなり、ＢＩＦＳデコーダおよびシーン・グラフ２２５に送られる。前記ビットストリームは、また種々の各メディア・デコーダ用の他の部分も含み、それぞれ、ライン２４０、２４５および２５０、解読バッファ２５１、２５２および２５３、ライン２５５、２５６および２５７を通して、メディア・デコーダ２７０、２７１および２７２に送られ、前記メディア・デコーダは、合成バッファ２７６、２７７および２７８への入力である解読したメディアを、ライン２７３、２７４および２７５に出力する。ライン２７９上のバッファ２７６の出力は、ライン２８０上のバッファ２７７の出力およびライン２８１上のバッファ２７８の出力と一緒に、コンポジタへ送られる。
図には、（解読バッファ２５１、２５２、２５３、デコーダ２７０、２７１、２７２および合成バッファ２７６、２７７、２７８を通しての）三組のメディア解読動作しか示していないが、実際には、メディア・デコーダの数は、一つでもいいし、また幾つでも必要なだけ使用することができる。コンポジタ２８２は、ＢＩＦＳシーン・グラフ（およびおそらくはユニット入力）に基づいて、解読したメディアを相互に配列し、シーンを合成する。前記情報は、ライン２８３を通して、再現装置２８４へ送られる。再現装置２８４は、ピクセルおよびオーディオ・サンプルを与え、それらをライン１７５を通して、ディスプレイ（図示していないスピーカを持つ）２８５に送る。
図３は、特定の例として、ビジュアル解読を使用する本発明のメディア解読機能である。説明を簡単にするために、メディア解読を単に解読と呼ぶことにする。ベースＡＶ対象物またはビデオ・デコーダ構造体の使用可能性に関していくつかの仮定が必要である。前記仮定は、デフォールトまたはプレースホールダ動作を含む前記抽出クラスが、その構造体を無視することによって、多くの場合、拡張される、対象物指向プログラミングの状況としては普通のものである。
解読ＡＰＩ２２０は、インターフェース、より詳しく説明すると、ビジュアル解読ＡＰＩ３０１である。前記ビジュアル解読ＡＰＩ３０１を使用して、多数の異なるビジュアル・デコーダ３２０を接続することができる。前記接続は、ブロック選択解読ロジック（ＳＤＬ）３０６を通して行われる制御であると見なすことができる。図では、前記接続は、ロジックの他のいくつかの部分と一緒に、ＢＩＦＳデコーダ・ロジック３０５、ＢＩＦＳデコーダおよびシーン・グラフ２２５の一部または構成部分に属する。ＢＩＦＳ解読ロジック３０５は、制御ライン３０７を通してベース・ビデオ・デコーダ３１３のような種々のビジュアル・デコーダを制御し、制御ライン３０８を通して時間強化デコーダ３１４を制御し、制御ライン３０９を通して空間強化デコーダ３１５を制御し、制御ライン３１０を通して出力区分デコーダ３１６を制御し、制御ライン３１１を通して画像肌理デコーダ３１７を制御し、ライン３１２を通してメッシュ幾何学／運動デコーダ３１８を制御する。解読されるビットストリームは、ライン３１９（図２のメディア・デコーダ入力２５５または２５６または２５７に対応する）を通して、適当なデコーダに送られ、解読された出力は、ライン３２５（図２のメディア・デコーダ出力２７３または２７４または２７５に対応する）上で入手することができる。ベース・ビデオ・デコーダ３１３は、スケール不可能なビデオを解読し、空間強化デコーダ３１５は、空間スケール可能性ビデオ層を解読し、時間強化デコーダ３１４は、時間スケール可能性ビデオ層を解読し、データ区分デコーダ３１６は、データ分割ビデオ層を解読し、画像肌理デコーダ３１７は、静止画像の肌理の空間／ＳＮＲスケール可能な層を解読し、メッシュ幾何学／運動デコーダ３１８は、対象物の動きにより、波形メッシュ・ノード位置およびこれらノードの運動を解読する。前記デコーダは、当業者には周知のＭＰＥＧ−４ビジュアル規格により指定される。柔軟で、一貫した方法でＭＰＥＧ−４ビジュアル・デコーダに、アクセスするのに使用する本発明の前記分類を、以下に詳細に説明する。
解読ＡＰＩ
Ｃｌａｓｓ ｍｐｇｊ．ｄｅｃ．ＢａｓｅＡＶＯｂｊｅｃｔ
ｐｕｂｌｉｃ ｃｌａｓｓ ＢａｓｅＡＶＯｂｊｅｃｔ
これは、ベース ＡＶ対象物ストリームの解読を可能にする、基本的なクラスである。
構成装置
ｐｕｂｌｉｃ ＢａｓｅＡＶＯｂｊｅｃｔ（）
方法
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔａｒｔＤｅｃ（）
データ解読の開始
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔｏｐＤｅｃ（）
データ解読の停止
ｐｕｂｌｉｃ ｖｏｉｄ ａｔｔａｃｈＤｅｃｏｄｅｒ（Ｍｐ４Ｓｔｒｅａｍ ｂａｓｅｓｔｒｍ）
解読を行う有効なＭＰＥＧ−４ストリームを解読するための、準備中のベース・ストリームへのデコーダの取り付け。
ビジュアル解読ＡＰＩ
Ｃｌａｓｓ ｍｐｇｊ．ｄｅｃ．Ｍｐ４Ｄｅｃｏｄｅｒ
ｐｕｂｌｉｃ ｃｌａｓｓ Ｍｐ４ＶＤｅｃｏｄｅｒは、
ビデオ・デコーダの拡張。
このクラスは、ビデオ・デコーダ、抽出クラス（図示せず）を拡張する。このクラスは、種々のタイプのビジュアル・ビットストリームを解読するための方法を含む。
構成装置
ｐｕｂｌｉｃ Ｍｐ４ＶＤｅｃｏｄｅｒ（）
方法
ｐｕｂｌｉｃ ＶＯｂｊｅｃｔ ｂａｓｅＤｅｃｏｄｅ（Ｍｐ４ｓｔｒｅａｍ ｂａｓｅｓｔｒｍ）
ＭＰＥＧ−４ビデオ・ストリーム、ｂａｓｅｓｔｒｍを解読し、解読したビジュアル対象物、ＶＯｂｊｅｃｔを返す。
ｐｕｂｌｉｃ ＶＯｂｊｅｃｔ ｓｐｔＥｎｈＤｅｃｏｄｅ（Ｍｐ４ｓｔｒｅａｍ ｅｎｈｓｔｒｍ）
空間強化ＭＰＥＧ−４ビデオ・ストリーム、ｅｎｈｓｔｒｅａｍを解読し、解読したビジュアル対象物、ＶＯｂｊｅｃｔを返す。
ｐｕｂｌｉｃ ＶＯｂｊｅｃｔ ｔｍｐＥｎｈＤｅｃｏｄｅ（Ｍｐ４ｓｔｒｅａｍ ｅｎｈｓｔｒｍ）
時間強化ＭＰＥＧ−４ビデオ・ストリーム、ｅｎｈｓｔｒｍを解読し、解読したビジュアル対象物、ＶＯｂｊｅｃｔを返す。
ｐｕｂｌｉｃ ＶＯｂｊｅｃｔ ｓｎｒＥｎｈＤｅｃｏｄｅ（Ｍｐ４ｓｔｒｅａｍ ｅｎｈｓｔｒｍ、ｉｎｔ ｌｅｖｅｌ）は、
レベルに従って、ｓｎｒ強化ＭＰＥＧ−４ビデオ・ストリーム、ｅｎｈｓｔｒｍを解読し、解読したビジュアル対象物、ＶＯｂｊｅｃｔを返す。
ｐｕｂｌｉｃ ＶＯｂｊｅｃｔ ｄａｔａｐａｒｔＤｅｃｏｄｅ（Ｍｐ４ｓｔｒｅａｍ ｅｎｈｓｔｒｍ、ｉｎｔ ｌｅｖｅｌ）
レベルに従って、データ分割ＭＰＥＧ−４ビデオ・ストリーム、ｅｎｈｓｔｒｍを解読し、解読したビジュアル対象物、ＶＯｂｊｅｃｔを返す。
ｐｕｂｌｉｃ ＶＯｂｊｅｃｔ ｔｒｉｃｋＤｅｃｏｄｅ（Ｍｐ４ｓｔｒｅａｍ ｔｒｋｓｔｒｍ、ｉｎｔ ｍｏｄｅ）は、
モードに従って、トリック・ストリームをスキップおよび解読し、解読したビジュアル対象物、ＶＯｂｊｅｃｔを返す。
ｐｕｂｌｉｃ ＭｅｓｈＯｂｊｅｃｔ ｍｅｓｈＡｕｘＤｅｃｏｄｅ（Ｍｐ４Ｓｔｒｅａｍ ａｕｘｓｔｒｍ）は、ＭＰＥＧ−４補助ビデオ・ストリームを解読し、メッシュ幾何学および動作ベクトルを含む、メッシュ対象物、ＭｅｓｈＯｂｊｅｃｔを返す。
図４は、それに対して、インターフェースが他の分類のＡＰＩにより定義される、多数の例示としての機能を使用する、本発明のいくつかの特徴の機能である。前記機能ＡＰＩ２９５は、いくつかのインターフェースを示す。より詳しく説明すると、トリック・モード機能（４０１）用のインターフェース、方向性機能用のインターフェース（４０２）、透明機能用のインターフェース（４０３）、ホット・オブジェクト機能用のインターフェース（４０４）、および順送り機能用のインターフェース（４０５）を示す。各ＡＰＩを使用して、多数の異なるデコーダを接続することができる。一例として、再びビジュアル・デコーダを使用する。前記接続は、この図の場合、ＢＩＦＳデコーダおよびシーン・グラフ２２５および／またはＭＰＥＧ−４ Ａｐｐ１００の構成部分である、ＡＰＰ／ＢＩＦＳ Ｄｅｃ（ｏｄｅｒ）に属する、いくつかのブロック選択解読ロジック（ＳＤＬ）４１６、４１７、４１８、４１９、４２０を通しての制御と見なすことができる。ＡＰＰ／ＢＩＦＳ解読ロジック４１５は、制御ライン４２１、４２２、４２４、４２５を通して、ベース・ビデオ・デコーダ３１３のような種々のビジュアル・デコーダを制御し、制御ライン４２３および４２６を通して、時間強化デコーダ３１５を制御し、制御ライン４２７を通して、空間強化デコーダ３１５を制御し、制御ライン４２９を通して、データ分割デコーダ３１６を制御し、制御ライン４３０を通して、画像肌理デコーダ３１７を制御し、ライン４２８を通して、メッシュ幾何学／運動デコーダ３１８を制御する。
解読するビットストリームは、ライン４３１（図２のメディア・デコーダ入力２５５または２５６または２５７に対応する）を通して、適当なデコーダへ送られ、解読した出力は、ライン４４５（図２のメディア・デコーダ出力２７３または２７４または２７５に対応する）上で入手することができる。多くの場合、ビジュアル対象物に関するユーザ機能は、一つまたはそれ以上のビジュアル・デコーダを使用することにより、実現することができることを理解することが重要である。前記ＳＬＤは、各ビジュアル対象物を解読するために接続する特定のデコーダを選択するためばかりでなく、一つのビットストリームのために使用したデコーダ、および使用されるまたは使用されない特定の時間を選択するためにも使用される。図には多数のＳＤＬ４１６、４１７、４１８、４１９、４２０を示したが、各ＳＬＤは各機能に対応する。この図の各ＳＤＬは一つの制御入力を持つが、しかし、それはいくつかの可能性のある制御出力の中の一つである。もっと分かりやすく説明すると、図３の場合には、ベース・ビデオ・デコーダ３１３は、スケールすることができないビデオを解読し、空間強化デコーダ３１４は、空間スケール可能性ビデオ層を解読し、時間強化デコーダ３１５は、時間スケール可能性ビデオ層を解読し、データ分割デコーダ３１６は、データ分割ビデオ層を解読し、画像肌理デコーダ３１７は、静止画像肌理の空間／ＳＮＲスケール可能層を解読し、メッシュ幾何学／運動デコーダ３１８は、対象物の運動により、ワイヤフレーム・メッシュ・ノードおよび前記ノードの運動を解読する。前記デコーダは、ここでもＭＰＥＧ−４ビジュアル規格により指定される。柔軟でしっかりした方法で前記機能を達成するために使用する、本発明のＡＰＩのこの分類についての詳細について以下に説明する。
機能ＡＰＩ
下記のＡＰＩは、種々のユーザ相互作用機能のためのものである。
順送りＡＰＩ
Ｃｌａｓｓ ｍｐｇｊ．ｆｕｎｃ．ＰｒｏｇＡＶＯｊｅｃｔ
ｐｕｂｌｉｃ ｃｌａｓｓ ＰｒｏｇＡＶＯｊｅｃｔ
ＢａｓｅＡＶＯｂｊｅｔの拡張。
ＰｒｏｇＡＶＯｂｊｅｃｔにより、ユーザ制御下のＡＶ対象物の品質を順送りに洗練することができる。現在、ビジュアル対象物は、靜的なもの（任意に形成した対象物の時間どおりの一例である、静止画像「ｖｏｐｓ」、ビデオ対象物面と見なされる。前記形が長方形である場合には、ｖｏｐは一つのフレームと同じものである。）
構成装置
ｐｕｂｌｉｃ ＰｒｏｇＡＶＯｂｊｅｃｔ（）
方法
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔａｒｔＤｅｃ（）
データ解読の開始
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔｏｐＤｅｃ（）
データ解読の停止
ｐｕｂｌｉｃ ｖｏｉｄ ｐａｕｓｅＤｅｃ（）
データ解読の一時的な中止
ｐｕｂｌｉｃ ｖｏｉｄ ｒｅｓｕｍｅＤｅｃ（）
現在の一時中止の状態からの、データ解読の再開
ｐｕｂｌｉｃ ｉｎｔ ｓｅｌｅｃｔＰｒｏｇＬｅｖｅｌ（）
変換（ＤＣＴまたはウェブレット）係数の解読が行われるまでのレベルの選択。一つのレベルは、走査順序中のある位置までの係数である。
ｐｕｂｌｉｃ ｖｏｉｄ ａｔｔａｃｈＤｅｃｏｄｅｒ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ ｉｎｔ ｐｒｏｇｌｖｌ）
有効なＭＰＥＧ−４ストリームを解読するための、準備中のｓｒｃｓｔｒｍへのデコーダの取り付け、および解読が行われるまでのプログラム・レベルの指定。
ｐｕｂｌｉｃ ｖｏｉｄ ｏｆｆｓｅｔＳｔｒｅａｍ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇｏｆｆｓｅｔ）
ｓｒｃｔｒｍへの、解読開始目標としてのオフセットの挿入可能。実際には、現実の目標位置は、必要な目標より遠い場合があり、ストリーム内の有効なエントリの位置により異なる。
Ｈｏｔ Ｏｂｊｅｃｔ／Ｒｅｇｉｏｎ ＡＰＩ
このＡＰＩにより、ホット（能動）ＡＶ対象物と相互作用を行うことができる。前記ＡＰＩは、一つの対象物の能動領域と、相互作用を行うことができるように拡張することができる。このＡＰＩは、ＡＶ対象物の空間解像度強化、品質強化、時間的品質強化のような、一つまたはそれ以上の高度な機能を可能にするためのものである。実現する実際の強化は、（マウス．クリック／メニューを通しての）ローカルおよび遠隔地からのユーザ相互作用および強化ストリーム、および使用することができる強化デコーダにより異なる。
Ｃｌａｓｓ ｍｐｇｊ．ｆｕｎｃ．ＨｏｔＡＶＯｂｊｅｃｔ
ｐｕｂｌｉｃ ｃｌａｓｓ ＨｏｔＡＶＯｂｊｅｃｔ
ＢａｓｅＡＶＯｂｊｅｃｔの拡張
ＨｏｔＡＶＯｂｊｅｃｔは、その対象物がホット・オブジェクトである場合に、ＡＶＯｂｊｅｃｔの強化動作をトリガするクラスである。それ故、ホット対象物は、必要な場合にトリガされる、それ自身に関連するいくつかの強化ストリームを持つ。このクラスは、ベース（層）ストリームを解読するために主として使用される、ＢａｓｅＡＶＯｂｊｅｃｔを拡張する。さらに、ホット対象物の定義を、問題の領域（ＫｅｙＲｅｇｉｏｎ）を含むように拡張することができる。
構成装置
ｐｕｂｌｉｃ ＨｏｔＡＶＯｂｊｅｃｔ（）
方法
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔａｒｔＤｅｃ（）
データ解読の開始
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔｏｐＤｅｃ（）
データ解読の停止
ｐｕｂｌｉｃ ｖｏｉｄ ｐａｕｓｅＤｅｃ（）
データ解読の一時的な中止
ｐｕｂｌｉｃ ｖｏｉｄ ｒｅｓｕｍｅＤｅｃ（）
現在の一時中止の状態からの、データ解読の再開
ｐｕｂｌｉｃ ｉｎｔ ｓｅｌｅｃｔＨｏｔＴｙｐｅ（）
（空間、品質、時間等の）強化のタイプの選択。
ｐｕｂｌｉｃＭｐ４Ｓｔｒｅａｍ ｅｎｈａｎｃｅＯｂｊｅｃｔ（ｉｎｔ ｔｙｐｅ）
必要な強化ストリームを入手するための、選択した強化タイプの使用。
ｐｕｂｌｉｃ ｖｏｉｄ ａｔｔａｃｈＤｅｃｏｄｅｒ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ ｉｎｔ ｔｙｐｅ）
有効なＭＰＥＧ−４ストリームを解読するための、準備中のｓｒｃｓｔｒｍへのデコーダの取り付け、および解読が行われるタイプの指定。
ｐｕｂｌｉｃ ｖｏｉｄ ｏｆｆｓｅｔＳｔｒｅａｍ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇｏｆｆｓｅｔ）
ｓｒｃｔｒｍへの、解読開始目標としてのオフセットの挿入可能。実際には、現実の目標位置は、必要な目標より遠い場合があり、ストリーム内の有効なエントリの位置により異なる。
方向性ＡＰＩ
このＡＰＩにより、方向を感知するＡＶ対象物との相互作用を行うことができる。前記ＡＰＩは、静的ビジュアル対象物（静止ｖｏｐ）、動的ビジュアル対象物（運動するｖｏｐ）および方向性を持つ音声およびオーディオをサポートする。ビジュアル対象物の場合には、このＡＰＩは、視点の選択を可能にし、対応するビットストリームだけが解読され、解読されたデータは、コンポジタへ送られる。音声対象物の場合には、必要な音声点により、アナログ動作が行われる。現在のところ、予め定めた方向性を持つ選択が行われる。
Ｃｌａｓｓ ｍｐｇｊ．ｆｕｎｃ．ＤｉｒｅｃＡＶＯｂｊｅｃｔ
ｐｕｂｌｉｃ ｃｌａｓｓ ＤｉｒｅｃＡＶＯｂｊｅｃｔ
ＢａｓｅＡＶＯｂｊｅｃｔの拡張。
ＤｉｒｅｃＡＶＯｂｊｅｃｔは、（予め定めた量子化した方向の形での）空間の、ｘ−ｙ−ｚ位置に応答する対象物の生成を可能にする。ユーザ相互作用により、一つまたはそれ以上の視点に対応するｖｏｐが、必要に応じて解読されるように、ビットストリームが、ＡＶ対象物としてコード化された多数の靜的ビジュアルｖｏｐからできていると仮定すると、もっと容易に説明することができる。前記クラスは、動的ＡＶＯｂｊｅｃｔをコード化するのにも適している。
構成装置
ｐｕｂｌｉｃ ＤｉｒｅｃＡＶＯｂｊｅｃｔ（）
方法
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔａｒｔＤｅｃ（）
データ解読の開始
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔｏｐＤｅｃ（）
データ解読の停止
ｐｕｂｌｉｃ ｖｏｉｄ ｐａｕｓｅＤｅｃ（）
データ解読の一時的な中止
ｐｕｂｌｉｃ ｖｏｉｄ ｒｅｓｕｍｅＤｅｃ（）
現在の一時中止の状態からの、データ解読の再開
ｐｕｂｌｉｃ ｖｏｉｄ ｌｏｏｐＤｅｃ（）
この方法により、閉ループを形成する予め定めた順序の靜的ｖｏｐとしての、動的ビジュアル対象物のユーザ相互作用解読が可能になる。この方法はオーディオの場合にも、適用することができる。ユーザの選択は、マウスのクリックまたはメニューにより行われる。
ｐｕｂｌｉｃ ｉｎｔ ｓｅｌｅｃｔＤｉｒｅｃｔ（）
方向（シーンの向き）の選択。対象物上のホット点上またはメニュー上で、マウスをクリックすることにより、多数の予め定めた方向を使用することができ、選択を行うことができる。
ｐｕｂｌｉｃ Ｍｐ４Ｓｔｒｅａｍ ｅｎｈｎｃｅＯｂｊｅｔ（ｉｎｔ ｏｒｉｅｎｔ）
必要な時間補助（強化）ストリームを入手するするための、選択したシーンの向きの使用。
ｐｕｂｌｉｃ ｖｏｉｄ ａｔｔａｃｈＤｅｃｏｄｅｒ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ ｉｎｔ ｏｒｉｅｎｔ）
有効なＭＰＥＧ−４ストリームを解読するための、準備中のｓｒｃｓｔｒｍへの時間補助（強化）デコーダの取り付け、およびＡＶ対象物の選択したシーン方向の指定。
ｓｒｃｔｒｍへの、解読開始目標としてのオフセットの挿入可能。実際には、現実の目標位置は、必要な目標より遠い場合があり、ストリーム内の有効なエントリの位置により異なる。
トリック・モードＡＰＩ
トリック・モードＡＰＩは、強化されたトリック・プレイ能力を使用することができるように、ユーザの制御の下での条件付き解読をサポートする。強化トリック・プレイは、ＦＦまたはＦＲ、フリーズ・フレーム、ランダム・アクセスおよび逆方向再生のような、他の動作に対する異なる速度のような、ＶＣＲ／ＣＤプレーヤのような機能を使用できるようにするようなものであると見なすことができる。しかし、合成された全シーンに基づく他に、個々のＡＶ対象物に基づいて、ＭＰＥＧ−４がこれら能力を使用することができるという違いを持つ。
Ｃｌａｓｓ ｍｐｇｊ．ｆｕｎｃ．ＴｒｉｃｋＡＶＯｂｊｅｃｔ
ｐｕｂｌｉｃ ｃｌａｓｓ ＴｒｉｃｋＡＶＯｂｊｅｃｔ
ＢａｓｅＡＶＯｂｊｅｃｔの拡張。
ＴｒｉｃｋＡＶＯｂｊｅｃｔは、トリック・プレイに適する解読を行うことができる、対象物を形成するのに使用することができるクラスである。
構成装置
ｐｕｂｌｉｃ ＴｒｉｃｋＡＶＯｂｊｅｃｔ（）
方法
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔａｒｔＤｅｃ（）
データ解読の開始
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔｏｐＤｅｃ（）
データ解読の停止
ｐｕｂｌｉｃ ｖｏｉｄ ｐａｕｓｅＤｅｃ（）
データ解読の一時的な中止
ｐｕｂｌｉｃ ｖｏｉｄ ｒｅｓｕｍｅＤｅｃ（）
現在の一時中止の状態からの、データ解読の再開
ｐｕｂｌｉｃ ｖｏｉｄ ｌｏｏｐＤｅｃ（）
このクラスにより、種々の速度での順方向および逆方向への、ｓｒｃｓｔｒｅａｍの選択した部分のユーザ相互作用解読が可能になる。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ｓｅｌｅｃｔＤｉｒｅｃ（）
解読方向の選択。トリック解読が（正規の）順方向に行われる場合には、真に戻る。逆方向のトリック解読が選択された場合には、偽に戻る。
ｐｕｂｌｉ ｃＭｐ４Ｓｔｒｅａｍ ｅｎｈａｎｃｅＯｂｊｅｃｔ（ｂｏｏｌｅａｎ ｄｅｃｄｉｒｅｃ）
ｄｅｃｄｉｒｅｃにより指定した方向へ解読するＭＰＥＧ−４ストリームの入手。
ｐｕｂｌｉｃ ｖｏｉｄ ａｔｔａｃｈＤｅｃｏｄｅｒ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ ｉｎｔ ｄｅｃｄｉｒｅｃ）
有効なトリック・モードのＭＰＥＧ−４ストリームを解読するための、準備中のｓｒｃｓｔｒｍにトリック・デコーダの取り付け、解読方向の指定。
ｐｕｂｌｉｃ ｖｏｉｄ ｏｆｆｓｅｔＳｔｒｅａｍ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇｏｆｆｓｅｔ）
ｓｒｃｔｒｍへの、解読開始目標としてのオフセットの挿入可能。実際には、現実の目標位置は、必要な目標より遠い場合があり、ストリーム内の有効なエントリの位置により異なる。
透明ＡＰＩ
透明ＡＰＩは、ユーザ制御下の一つの対象物の、複数の領域の選択的な解読をサポートする。ビジュアル対象物の場合には、その対象物内の他のピクセルの透明度を変化させることによって、大きな対象物をいくつかのより小さな領域に分割するという方法で、コード化が行われると仮定する。問題の領域に属さないピクセルは、コード化されている領域内に存在しない選択したキー・カラーを、前記ピクセルに割り当てることによりコード化される。このＡＰＩにより、いくつかのまたは全部の領域をコード化することができるように、ユーザの制御下でコード化を行うことができる。さらに、問題の領域の場合には、空間および時間的品質を改善するために、強化ビットストリームが必要になる場合がある。各領域に対する前記キー・カラーは、コンポジタに対して識別される。ユーザは、帯域幅／計算資源が限定されていたり、対象物のいくつかの部分が隠れていて必要がないため、または他の領域ないに画像を削除するかその品質を犠牲にして、特定の領域に必要な遙かに高い品質のため、ユーザが、全部の領域の解読を必要としない場合がある。キー・カラーを使用する前記プロセスは、放送分野の「クロマキー」技術に類似している。
Ｃｌａｓｓ ｍｐｇｊ．ｓｖｓ．ＴｒａｎｓｐＡＶＯｂｊｅｃｔ
ｐｕｂｌｉｃ ｃｌａｓ ＴｒａｓｎｓｐＡＶＯｂｊｅｃｔ
ＢａｓｅＡＶＯｂｊｅｃｔの拡張
ＴｒａｓｎｓｐＡＶＯｂｊｅｃｔは、透明情報により対象物を形成するために使用することができるクラスである。音声およびビジュアル対象物タイプの両方が処理される。
構成装置
ｐｕｂｌｉｃ ＴｒａｎｓｐＡＶＯｂｊｅｃｔ（）
方法
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔａｒｔＤｅｃ（）
データ解読の開始
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔｏｐＤｅｃ（）
データ解読の停止
ｐｕｂｌｉｃ ｖｏｉｄ ｐａｕｓｅＤｅｃ（）
データ解読の一時的な中止
ｐｕｂｌｉｃ ｖｏｉｄ ｒｅｓｕｍｅＤｅｃ（）
現在の一時中止の状態からの、データ解読の再開
ｐｕｂｌｉｃ ｉｎｔ ｇｅｔＲｅｇｉｏｎ（）
リストの形のメニュー内の番号、または（同様に番号に翻訳される）ホット・ポイントを、クリックすることによる領域の選択。
ｐｕｂｌｉｃ Ｍｐ４Ｓｔｒｅａｍ ｅｎｈａｎｃｅＯｂｊｅｃｔ
（ｉｎｔ ｔｙｐｅ，ｉｎｔ ｒｅｇｎｕｍ）
ｒｅｇｉｏｎ ｒｅｇｎｕｍに対する必要な強化ストリームを入手するための、選択した強化タイプの使用。
ｐｕｂｌｉｃ ｖｏｉｄ ａｔｔａｃｈＤｅｃｏｄｅｒ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｉｎｔ ｔｙｐｅ、ｉｎｔ ｒｅｇｎｕｍ）
一つの領域およびそのキー・ｃカラーを解読するための準備中のｓｒｃｓｔｒｍにデコーダの取り付け。
ｐｕｂｌｉｃ ｖｏｉｄ ｏｆｆｓｅｔＳｔｒｅａｍ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇｏｆｆｓｅｔ）
ｓｒｃｔｒｍへの、解読開始目標としてのオフセットの挿入可能。実際には、現実の目標位置は、必要な目標より遠い場合があり、ストリーム内の有効なエントリの位置により異なる。
図５は、それに対して、インターフェースが他の分類のＡＰＩで定義される、ストリーム編集の一例を使用する本発明のオーサリング機能である。オーサリングＡＰＩ２９０は、オーサリング関連のインターフェース、より詳しく説明すると、ストリーム編集ＡＰＩ（５０１）を表す。前記ＡＰＩを使用することにより、ＭＰＥＧ Ａｐｐ（１００）またはＢＩＦＳデコーダおよびシーン・グラフ（２２５）が使用するための、ビットストリームを編集／修正することができる。ＡＰＩ５０１は、制御ライン５０５を通して、ＭＰＥＧ ＡＰＰ１００を制御し、制御ライン５０６を通してＢＩＦＳデコーダおよびシーン・グラフ２２５を制御する。それ故、ストリーム編集ＡＰＩは、種々のオーディオ・ビジュアル対象物およびＢＩＦＳシーン叙述を含む、ＭＰＥＧ−４の編集／修正を助けることができる。ストリーム編集ＡＰＩの他に、他のＡＰＩを使用することができるオーサリングも行うことができるが、本発明は指定しない。ストリーム編集ＡＰＩの詳細を下記に説明する。
オーサリング
下記のＡＰＩは、ＭＰＥＧ−４ビットストリームを部分的にオーサリングするためのものである。
ストリーム編集ＡＰＩ
Ｃｌａｓｓ ｍｐｇｊ．ｕｔｉｌ．ＳｔｒｅａｍＥｄｉｔ
ｐｕｂｌｉｃ ｃｌａｓｓ ＳｔｒｅａｍＥｄｉｔ
このクラスは、ＭＰＥＧ−４ストリームの内容および修正を決定することができる。アクセス、コピー、追加、置き換え、削除のような動作および他の動作がサポートされる。
構成装置
ｐｕｂｌｉｃ ＳｔｒｅａｍＥｄｉｔ（）
方法
ｐｕｂｌｉｃ ｉｎｔ［］ ｇｅｔＯｂｊｅｃｔＬｉｓｔ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ）
ストリーム内の対象物のリストの返還。返還された対象物は、ビットストリーム内の対象物の累積表となる。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ｒｅｐｌａｃｅＯｂｊｅｃｔ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇｓｒｃｏｂｊｉｄ、Ｍｐ４Ｓｔｒｅａｍ ｄｅｓｔｓｔｒｍ，、ｕｌｏｎｇ ｄｅｓｔｏｂｊｉｄ）
ストリーム内の対象物ｉｄ、ｄｅｓｔｏｂｊｉｄを持つ対象物の発生の、ｓｒｃｓｔｒｍ内の対象物ｉｄ、ｓｒｃｏｂｊｉｄを持つ対象物の対応する発生による置き換え。対象物表はそれに従って更新される。更新が成功した場合には、動作は真に戻り、更新が失敗した場合には偽に戻る。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ｒｅｐｌａｃｅＯｂｊｅｃｔＡｔ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇｓｒｃｏｊｉｄ、ｕｌｏｎｇ ｍ、Ｍｐ４Ｓｔｒｅａｍ ｄｅｓｔｓｔｒｍ、ｕｌｏｎｇ ｄｅｓｔｏｂｊｉｄ、ｕｌｏｎｇ ｎ）
置き換えを開始する位置を除いて、ｒｅｐｌａｃｅＯｂｊｅｃｔ（）と同じ意味論が指定される。ｄｅｓｔｏｂｊｉｄのｎ番目の発生からの宛先対象物の、ｓｒｃｏｂｊｉｄのｍ番目の発生からのソース対象物による置き換え。ｍ＝ｎ＝０の場合には、ｒｅｐｌａｃｅＯｂｊｅｃｔ（）と同じことが行われる。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ｃｏｎｔａｉｎＯｂｊｅｃｔＴｙｐｅ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇ ｏｂｊｔｙｐｅ）
ｓｒｃｓｔｒｍがｏｂｊｔｙｐｅの対象物を含んでいる場合には、真に戻り、そうでない場合には偽に戻る。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ａｄｄＯｂｊｅｃｔｓ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇ ｓｒｃｏｂｊｉｄ、Ｍｐ４Ｓｔｒｅａｍ ｄｅｓｔｓｒｍ）
ｄｅｓｔｓｔｒｍへのｓｒｃｓｔｒｍからのｓｒｃｏｂｊｉｄの追加。成功の場合は真に戻り、そうでない場合には偽に戻る。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ａｄｄＯｂｊｅｃｔＡｔ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇ ｓｒｃｏｂｊｉｄ、Ｍｐ４Ｓｔｒｅａｍ ｄｅｓｔｓｒｍ、ｕｌｏｎｇ ｄｅｓｔｏｂｊｉｄ、ｕｌｏｎｇ ｎ）
ｄｅｓｔｏｂｊｉｄのｎ番目の発生の後から始まるｄｅｓｔｓｔｒｍへの、ｓｒｃｓｔｒｍからのｓｒｃｏｂｊｉｄの追加。成功の場合は真に戻り、そうでない場合には偽に戻る。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ｃｏｐｙＯｂｊｅｃｔｓ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｃｓｔｒｍ、ｕｌｏｎｇ ｓｒｃｏｂｊｉｄ、Ｍｐ４Ｓｔｒｅａｍ ｄｅｓｔｓｔｅａｍ、ｄｅｓｔｏｂｊｉｄ）
ｓｒｓｔｒｍ内のｓｒｃｏｂｊｉｄを持つ対象物を、新しい対象物ｉｄ、ｄｅｓｔｏｂｊｉｄを持つｄｅｓｔｓｔｒｅａｍへコピー。ｄｅｓｔｓｔｒｍが存在しない場合には、生成される。存在する場合には重ね書きされる。この動作は、以降の動作に対する多重化されていないストリームから、基本的ストリームを生成するために使用される。成功の場合は真に戻り、そうでない場合には偽に戻る。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ｄｅｌｅｔｅＯｂｊｅｃｔｓ（Ｍｐ４Ｓｔｒｅａｍ ｓｄｅｓｔｓｔｒｍ、ｕｌｏｎｇ ｄｅｓｔｏｂｊｉｄ）
ｄｅｓｔｓｔｒｍ内のｄｅｓｔｏｂｊｉｄを持つストリーム対象物の削除。また、すべての合成情報の除去。成功の場合は真に戻り、そうでない場合には偽に戻る。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ｓｐｌｉｃｅＡｔ（Ｍｐ４Ｓｔｒｅａｍ ｄｅｓｔｓｔｒｍ、ｕｌｏｎｇ ｄｅｓｔｏｂｊｉｄ、ｕｌｏｎｇ ｎ、Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ）
ｄｅｓｔｏｂｊｉｄのｎ番目の発生の後のｄｅｓｔｓｔｒｍのスプライス、およびｓｒｃｓｔｒｍのペースト。成功の場合は真に戻り、そうでない場合には偽に戻る。
まとめると、図１−図５のＡＰＩに反映された、一組のライブラリ機能を含む柔軟なシステムおよび方法は、コード化されたメディア・ストリームをリモート・ラップトップ・パソコンまたは他の装置にような解読ターミナル資源とマッチさせることができる、新しいレベルの適応性を提供する。さらに、本発明は、また適当なデコーダおよびコード化されたメディア対象物ビットストリームの選択的な解読と一緒に、高度の新しい機能を可能にする、ユーザ相互作用に対するサポートも含む。
本発明を実行する場合には、定義のＡＶ関連機能を含む分類が導入され、すべての汎用で一貫している方法で、埋設されたオーディオ・ビジュアル対象物の解読と合成との間の、簡単でありながら、より複雑な相互作用を行うことができるように、一組のＡＰＩが設定される。
本発明のシステムおよび方法の前記説明は、単に例示としてのものに過ぎず、当業者ならその構造および実行を種々に変更することができるだろう。例えば、三つの分類の入力、出力およびマッピング機能のコンパクトで汎用装置を説明してきたが、ネットワーク、アプリケーションまたは他のニーズの変更により、ＡＰＩにいくつかの機能を追加したり、取り除いたりすることができる。本発明の範囲は、下記の請求の範囲だけにより制限される。

Claims (15)

1. ＭＰＥＧ−４規格によりコード化されたオーディオ・ビジュアル・オブジェクトを復号するためのシステムであって、
   それぞれが、予め定義した機能呼出を持つ標準化プログラミング・インターフェースである、処理資源又はユーザの入力に適応できるインターフェースを提供するための、予め定めた組の標準化アプリケーション・プログラミング・インターフェースを含むインターフェース・ライブラリ、及び
   前記インターフェース・ライブラリにアクセスし、少なくとも一つの前記アプリケーション・プログラミング・インターフェースに関連する機能呼出に従って、オーディオ・ビジュアル・オブジェクトを復号し、提示するように構成されたプロセッサ
   を備え、
   前記インターフェース・ライブラリが、ビットストリーム編集および操作能力を提供するオーサリング・インターフェースを備える、システム。
2. 請求項１に記載のシステムにおいて、前記プロセッサが、前記機能呼出を呼び出すクライアント・アプリケーションを実行するシステム。
3. 請求項１に記載のシステムにおいて、前記インターフェース・ライブラリが、ビジュアルオブジェクトビットストリームを復号するためのビジュアル復号インターフェースを備えるシステム。
4. 請求項１に記載のシステムにおいて、前記インターフェース・ライブラリが、ユーザとの拡張された相互作用を提供するための機能インターフェースを備えるシステム。
5. 請求項１に記載のシステムにおいて、さらに、前記インターフェース・ライブラリをサポートするビデオ復号および再生ユニットを備えるシステム。
6. 請求項１に記載のシステムにおいて、さらに、ユーザ閲覧用に、前記インターフェース・ライブラリを使用するマルチメディア・ブラウザ・モジュールを備えるシステム。
7. 請求項１に記載のシステムにおいて、さらに、前記インターフェース・ライブラリを使用するウェブ・ブラウザから呼び出されたマルチメディア・プラグイン・モジュールを備えるシステム。
8. 処理資源又はユーザの入力に適応できるインターフェースを提供するための予め定めた組の標準化アプリケーション・プログラミング・インターフェースを備える前記インターフェース・ライブラリを生成するステップ、
   前記インターフェース・ライブラリの一組のインターフェース定義の少なくとも一つに関連する変数を使用して、オーディオ・ビジュアル・オブジェクトにアクセスするステップ、及び
   前記変数により表される前記オーディオ・ビジュアル・オブジェクトを復号するステップ
   を含み、
   前記インターフェース・ライブラリが、ビットストリーム編集および操作能力を提供するオーサリング・インターフェースを備える、ＭＰＥＧ−４規格により符号化されたオーディオ・ビジュアル・オブジェクトを復号する方法。
9. 請求項８に記載の方法において、さらに、下層にあるＭＰＥＧ−４復号システムを制御する適応システムを形成するクライアント・アプリケーションを実行するステップを含む方法。
10. 請求項８に記載の方法において、前記インターフェース・ライブラリが、ビジュアルオブジェクトビットストリームを復号するためのビジュアル復号インターフェースを備える方法。
11. 請求項８に記載の方法において、前記インターフェース・ライブラリが、ユーザとの拡張された相互作用を提供するための機能インターフェースを備える方法。
12. 請求項８に記載の方法において、さらに、前記インターフェース・ライブラリを使用するユーザに、ビジュアル復号、機能およびオーサリング・インターフェースを使用するオペレーティング・システムを提供するステップを含む方法。
13. 請求項８に記載の方法において、さらに、前記インターフェース・ライブラリを使用して、ビデオ情報を復号および再生するステップを含む方法。
14. 請求項８に記載の方法において、さらに、前記インターフェース・ライブラリを使用するマルチメディア・ブラウザを起動するステップを含む方法。
15. 請求項８に記載の方法において、さらに、前記インターフェース・ライブラリを使用する、ウェブ・ブラウザから呼び出されたマルチメディア・プラグイン・モジュールを提供するステップを含む方法。

Images