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

Abstract

(57)【要約】 本発明は、ＭＰＥＧ−４のパラメトリック・システムのようなコード化されたオーディオ・ビジュアル対象物を再生／ブラウズするために、非適応システムを適応させることができるシステムおよび方法を提供する。本発明の前記システムは、パラメトリック・システムと呼ばれ、前記パラメトリック・システムの頂部に適応性を内蔵する。ＭＰＥＧ−４の前記パラメトリック・システムは、デジタル・メディア内蔵フレームワーク（ＤＭＩＦ）により制御されるシステムズ・デマルチプレクス（Ｄｅｍｕｘ）、シーン・グラフおよびメディア・デコーダ、バッファ、コンポジタおよび再現装置からなる。本発明により実現できる適応としては、メディア解読、ユーザ機能およびオーサリングの分類に入るインターフェース等があり、それにより、入力の使用に応じて多数の強化機能を実現でき、限定されたシステム資源に応じて滑らかなデグラデーションを行うことができる。本発明は、アプリケーション・プログラミング・インターフェース（ＡＰＩ）の形のインターフェース接続法の仕様を含む。ホット・オブジェクト、方向性、トリック・モード、透明および他のインターフェースが指定される。

Description

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

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ファング，イーハン アメリカ合衆国 10025 ニューヨーク, ニューヨーク，アパートメント ２イー, ウエスト ワンハンドレッド ツェルヴス ストリート 539 (72)発明者 カルヴァ，ハリ アメリカ合衆国 10027 ニューヨーク, ニューヨーク，アパートメント ８イー, ウエスト ワンハンドレッド ナインテイ ーンス ストリート 419 (72)発明者 プリ，アチュル アメリカ合衆国 10463 ニューヨーク, リヴァーデール，ナンバー １エー，ワル ド アヴェニュー 3660 (72)発明者 シュミット，ロバート エル. アメリカ合衆国 07731 ニュージャーシ ィ，ホーウェル，オーク グレン ロード 333 【要約の続き】 ード、透明および他のインターフェースが指定される。

Claims (1)

1. 【特許請求の範囲】 １．ＭＰＥＧ−４規格によりコード化されたオーディオ・ビジュアル対象物を 解読するためのシステムであって、 それぞれが、予め定義した機能呼出を持つ標準化プログラミング・インターフ ェースである、オーディオ・ビジュアル対象物を処理するための、予め定めた組 の標準化アプリケーション・プログラミング・インターフェースを含むインター フェース・ライブラリと、 前記インターフェース・ライブラリにアクセスし、少なくとも一つの前記アプ リケーション・プログラミング・インターフェースに関連する機能呼出に従って 、オーディオ・ビジュアル対象物を解読し、提示するように構成されたプロセッ サとを備えるシステム。 ２．請求項１に記載のシステムにおいて、前記プロセッサ・ユニットが、前記 機能呼出を呼び出すクライアント・アプリケーションを実行するシステム。 ３．請求項１に記載のシステムにおいて、さらに、ユーザ入力ユニットを含み 、前記システムが、システム資源の解読、再生またはブラウズの状態、および前 記ユーザ入力ユニットを通して供給されるユーザ相互作用に応答するシステム。 ４．請求項１に記載のシステムにおいて、前記インターフェース・ライブラリ が、ビジュアル対象物ビットストリームを解読するための、ビジュアル解読イン ターフェースを備える。システム。 ５．請求項１に記載のシステムにおいて、前記インターフェース・ライブラリ が、強化ユーザ相互作用を提供するための、機能インターフェースを備えるシス テム。 ６．請求項１に記載のシステムにおいて、前記インターフェース・ライブラリ が、ビットストリーム編集および操作能力を提供する、オーサリング・インター フェースを備えるシステム。 ７．前記インターフェース・ライブラリを使用して、ビジュアル機能およびオ ーサリング・・インターフェースを提供する、請求項１に記載のシステムを使用 するオペレーティング・システム。 ８．請求項１に記載のシステムにおいて、さらに、前記インターフェース・ラ イブラリをサポートする、ビデオ解読および再生ユニットを備えるシステム。 ９．請求項１に記載のシステムにおいて、さらに、ユーザ閲覧用に、前記イン ターフェース・ライブラリを使用する、マルチメディア・ブラウザ・モジュール を備えるシステム。 １０．請求項１に記載のシステムにおいて、さらに、前記インターフェース・ ライブラリを使用するウェブ・ブラウザから呼び出されたマルチメディア・プラ グイン・モジュールを備えるシステム。 １１．予め定めた組の標準化アプリケーション・プログラミング・インターフ ェースを備える前記インターフェース・ライブラリを発生するステップと、 前記インターフェース・ライブラリの一組のインターフェース定義の少なくと も一つに関連する変数を使用して、オーディオ・ビジュアル対象物にアクセスす るステップと、 前記変数により表される前記オーディオ・ビジュアル・対象物を解読するステ ップとを含む、ＭＰＥＧ−４規格によりコード化されたオーディオ・ビジュアル 対象物を解読する方法。 １２．請求項１１に記載の方法において、さらに、下に位置する ＭＰＥＧ−４解読システムを制御する適応システムを形成するクライアント・ア プリケーションを実行するステップを含む方法。 １３．請求項１１に記載の方法において、さらに、ユーザ入力を供給するステ ップを含み、前記インターフェースが、システム資源の解読、再生またはブラウ ズ状態、および前記ユーザ入力ユニットを通して供給されるユニット相互作用に 応答する方法。 １４．請求項１１に記載の方法において、前記インターフェース・ライブラリ が、ビジュアル対象物ビットストリームを解読するための、ビジュアル解読イン ターフェースを備える。方法。 １５．請求項１１に記載の方法において、前記インターフェース・ライブラリ が、強化ユーザ相互作用を提供するための機能インターフェースを備える方法。 １６．請求項１１に記載の方法において、前記インターフェース・ライブラリ が、ビットストリーム編集および操作能力を提供するオーサリング・インターフ ェースを備える方法。 １７．請求項１１に記載の方法において、さらに、前記インターフェース・ラ イブラリを使用するユーザに、ビジュアル、機能およびオーサリング・インター フェースを使用するオペレーティング・システムを提供するステップを含む方法 。 １８．請求項１１に記載の方法において、さらに、前記インターフェース・ラ イブラリを使用して、ビデオ情報を解読および再生するステップを含む方法。 １９．請求項１１に記載の方法において、さらに、前記インターフェース・ラ イブラリを使用するマルチメディア・ブラウザを提供するステップを含む方法。 ２０．請求項１１に記載の方法において、さらに、前記インターフェース・ラ イブラリを使用する、ウェブ・ブラウザから呼び出されたマルチメディア・プラ グイン・モジュールを供給するステップを含む方法。