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

Abstract

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

Description

本出願は、優先権を主張する米国特許仮出願６０/０４２，７９８に関連する。
本発明は、コード（符号）化マルチメディアおよびその記憶、ユーザへの配布に関し、特に、チャネルおよび復号資源のどちらかが制限され、時間により変動する場合、またはユーザ・アプリケーションが、符号化されたマルチメディアオブジェクトとの高度の相互作用を必要とする場合の符号化に関する。

デジタルマルチメディアは、操作面、複数のものを発生できるという面およびエラーに影響されないという利点およびその他の利点を持っているが、送信帯域幅の記憶容量により制限を受ける。それ故、実際に使用する場合には、多くの場合、圧縮または符号化する必要がある。さらに、インターネットおよび他のネットワーク上の、デジタルマルチメディアに対する需要が急速に増大しているため、効率的な記憶装置、ネットワークアクセスおよびサーチおよび検索、多くの符号化スキーム、記憶フォーマット、検索技術および送信プロトコルが開発されてきた。例えば、画像およびグラフィックス・ファイル用には、ＧＩＦ、ＴＩＦおよび他のフォーマットが使用されている。同様に、オーディオ・ファイルも、ＲｅａｌＡｕｄｉｏ、ＷＡＶ、ＭＩＤＩおよび他のフォーマットにより符号化され、記憶される。アニメーションおよびビデオ・ファイルは、多くの場合、ＧＩＦ８９ａ、Ｃｉｎｅｐａｋ、Ｉｎｄｅｏおよび他のフォーマットにより記憶される。

非常に多数の現存のフォーマットを再生するために、多くの場合、デコーダおよびインタープリタが必要になるが、その場合、前記デコーダおよびインタープリタが、ハードウェアで実行されるのか、ソフトウェアで実行されるのかにより、特にソフトウェアの場合には、ホストコンピュータの能力により、速度、品質および性能がまちまちになる。マルチメディアの内容が、コンピュータ（例えば、パソコンのような）を通してアクセスされた、ウェブページ内に含まれている場合には、ウェブブラウザを予想されるすべての内容に対して正しく設定する必要があり、また前記内容を処理するために、各タイプの内容を認識し、内容ハンドラ（ソフトウェア・プラグインまたはハードウェア）の機構をサポートしなければならない。

相互動作が可能でなければならないこと、品質および性能が保証されていなければならないこと、チップ設計の際のスケールが小さくなければならないこと、また種々様々のフォーマットのための内容を発生する際にコストがかかること等の理由で、マルチメディアコード化、パケット化、および確実な配布の分野で標準化が促進されてきた。特に、ＩＳＯ ＭＰＥＧ（国際規格組織動画専門家グループ）は、ＭＰＥＧ−１およびＭＰＥＧ−２と呼ばれる、二つの規格の形の符号化マルチメディアに対するビットストリーム・シンタックスおよび復号意味論の標準化を進めてきた。ＭＰＥＧ−１は、主として、コンパクトディスク（ＣＤ）のようなデジタル記憶媒体（ＤＳＭ）上で使用するためのものであり、一方、ＭＰＥＧ−２は、主として、放送環境（トランスポート・ストリーム）で使用するためものである。しかし、ＭＰＥＧ−２は、またＤＳＭ（プログラム・ストリーム）上で使用するための、ＭＰＥＧ−１類似の機構もサポートする。ＭＰＥＧ−２は、また独立のまたはネットワークに接続している、ＭＰＥＧ−２の標準化再生にために必要な場合がある、基本的なユーザの双方向通信のためのＤＳＭコマンドおよび制御のような追加機能を含む。

安価なボード／ＰＣＭＣＩＡカードが開発され、中央処理装置（ＣＰＵ）が入手することができるようになったために、ＭＰＥＧ−１規格が、パソコン上の映画およびゲームの再生に共通に使用することができるようになった。一方、ＭＰＥＧ−２規格は、比較的高画質のアプリケーション用のものであるため、デジタル衛星ＴＶ、デジタルケーブルおよびデジタル汎用ディスク（ＤＶＤ）からの、娯楽用アプリケーションに共通に使用されている。前記アプリケーション／プラットホームの他に、ＭＰＥＧ−１およびＭＰＥＧ−２は、ネットワークを通して送られるストリーム、ハードディスク／ＣＤ上に記憶されているストリーム、およびネットワークによるアクセスおよびローカル・アクセスの組み合わせの種々の他のコンフィギュレーションでの使用が期待されている。

ＭＰＥＧ−１およびＭＰＥＧ−２の成功、インターネットおよび移動チャネルの帯域幅制限、ブラウザを使用するウェブをベースとするデータアクセスの柔軟性、および双方向個人通信の必要が増大しているために、マルチメディア使用および制御のための新しいパラダイムが誕生した。それに応じて、ＩＳＯ ＭＰＥＧは、新しい規格、ＭＰＥＧ−４を制定に着手した。前記ＭＰＥＧ−４規格は、個々のオブジェクトの形のオーディオ・ビジュアル情報の符号化、および前記オブジェクトの合成および同期再生用のシステム向けのものである。前記固定パラメトリックシステムのＭＰＥＧ−４の開発が、引き続き行われる一方で、通信、ソフトウェアおよびＪａｖａ（登録商標）言語によるようなネットワーク運営用の新しいパラダイムにより、柔軟で、適応性を持ち、ユーザが双方向で通信できる新しい機会が生まれた。

例えば、Ｊａｖａ（登録商標）言語の開発により、ユーザがアクセスしたウェブページで、ホストとなるウェブサーバからの、クライアントパソコン上での、アプレット（ジャバ・クラス）のダウンローディングおよび実行に重要な、ネットワーク運営およびプラットホームの独立が可能になる。アプリットの設計により、サーバ側で記憶しているデータへの一回だけのアクセスが必要になる場合もあるし、すべての必要なデータを、クライアントのパソコン上に記憶することもできるし、または（スタートアップに必要な記憶スペースを少なくし、時間を短縮するために）数回の部分的アクセスが必要になる場合がある。後のシナリオは、ストリーム型再生と呼ばれる。

すでに説明したように、符号化マルチメディアを、例えば、パソコンのようなコンピュータ上で、インターネットおよびローカルのネットワーク接続アプリケーションのために使用し場合には、多くの状況が発生する。第一に、マルチメディアのネットワークによるアクセス用の帯域幅は、制限されるか、時間と共に変化するようになり、その場合には、最も重要な情報だけを送信し、その後で、もっと広い帯域幅を使用できるようになったとき、他の情報を送信しなければならない。

第二に、使用できる帯域幅がどのような幅のものであっても、復号を行わなければならないクライアント側のパソコンのＣＰＵおよび／またはメモリ資源は制限を受け、さらに、前記資源も時間により変化する。第三に、マルチメディア・ユーザ（消費者）は、高度に双方向の非直線ブラウジングおよび再生を必要とする場合がある。これは特別のことではない。何故なら、ウェブページ上の多くのテキスト内容は、ハイパーリンクされた機能を使用することにより、ブラウズすることができ、符号化オーディオ・ビジュアルオブジェクトを使用する表示用に、同じパラダイムの使用が期待されるからである。パラメトリックＭＰＥＧ−４システムは、非常に制限された方法でしか、前記の状況を処理できないだろう。すなわち、オブジェクトの欠落またはオブジェクトの一時的な発生が起こり、復号または表示ができなくなり、その結果、オーディオ・ビジュアルの表示が不安定になる。

さらに、ＭＰＥＧ−４を使用した場合、ユーザは、前記状況をうまく処理することができない。前記パラメトリックシステムの前記制限を回避するの、ＭＰＥＧ−４開発用の可能性のある一つの選択肢は、プログラムを使用するシステムの開発である。

ソフトウェア業界では、長い間、アプリケーション・プログラミング・インターフェイス（ＡＰＩ）が、多数の異なるタイプのコンピュータ・プラットホーム上での標準化動作および機能を達成するための手段として認識されてきた。通常、ＡＰＩを定義することにより、種々の動作を標準化することができるが、前記動作の性能は、特定のプラットホームに関心を持つ特定のベンダが、そのプラットホーム用に最適化された実行を供給する場合があるので、種々のプラットホーム上で異なる場合がある。グラフィックの分野では、バーチャルリアリティモデリング言語（ＶＲＭＬ）は、シーングラフ・アプローチを使用することにより、オブジェクトとシーンの説明との間の、空間的および時間的関係を指定する手段を使用することができる。ＭＰＥＧ−４は、リアルタイムのオーディオ／ビデオ・データ、および顔または体の動きを処理するために、多くの方法で、ＶＲＭＬおよび拡張ＶＲＭＬに対して、中心の構造物の二進表示（ＢＩＦＳ）を使用してきた。ＶＲＭＬの機能を強化し、プログラムによる制御を行うことができるように、ディメンションＸ社は、一組のＡＰＩを液体リアリティとして発売した。最近、サン・マイクロシステム社が、ジャバ３Ｄの初期バージョン、すなわち、他の機能も持っているが、とりわけ、合成オーディオ・ビジュアルオブジェクトの、シーングラフとしての表示をサポートするＡＰＩ仕様を発表した。サン・マイクロシステム社は、ジャバ・メディア・フレームワーク・プレーヤＡＰＩ、すなわち、マルチメディア再生用のフレームワークを発売した。しかし、現在市販されているＡＰＩパッケージは、どれもＭＰＥＧ−４符号化および他の高度のマルチメディアの内容の種々の要求に適した広範でしっかりした機能を持っていない。

本発明は、パラメトリックＭＰＥＧ−４のような非適応クライアントシステムが適応できるような方法で、符号化されたオーディオ・ビジュアルオブジェクトを再生およびブラウズすることができるようにする、符号化オーディオ・ビジュアルオブジェクトをインターフェイスにより接続するためのシステムおよび方法を提供する。本発明のシステムおよび方法は、アーキテクチャレベルでプログラムを使用するもので、特に、ＭＰＥＧ−４符号化データにアクセスし、それを処理するために構成された、指定の組のアプリケーション・プログラミング・インターフェイスにより、パラメトリックシステムの一番上に適応性のある一つの層を追加する。

当業者には周知のＭＰＥＧ−４は、デジタルメディア集積フレームワーク（ＤＭＩＦ）が監督するシステムズ・デマルチプレクス（Ｄｅｍｕｘ）、シーングラフ、およびメディアデコーダ、バッファ、コンポジタおよびレンダリング装置からなるパラメトリックシステムであると見なすことができる。標準ＭＰＥＧ−４に対して本発明のシステムおよび方法が行った強化または拡張としては、メディア復号の範囲に入る一組の指定ＡＰＩ、ユーザ機能およびクライアントアプリケーションが内蔵することができるオーサリング等がある。強力なオーディオ・ビジュアル・インターフェイス装置を提供することにより、ユーザの入力に応じて多数の強化リアルタイムおよび他の機能を実現することができ、ＭＰＥＧ−４クライアントが使用することができるシステム資源が少ない場合に、滑らかなデグラデーションを行うことができる。

本発明が行われた一つの理由は、ユーザの制御の下でＭＰＥＧ−４の再生およびブラウズを行うための標準化インターフェイスが、必要であったためである。本発明のインターフェイスは、符号化メディアデータを、直ちに使用することができるターミナル資源に容易に適応させるためのものである。本発明のインターフェイスは、また機能として直接、または近い将来に重要になると思われるオーディオ・ビジュアル・アプリケーションおよびサービスに埋設して、間接的に、ユーザが求めていると思われる相互作用を容易にする。

本発明は、いくつかの分野を含む、しっかりしたアプリケーション・プログラミング・インターフェイス（ＡＰＩ）の形の、インターフェイスによる接続方法を指定する。メディア復号の分野においては、ビジュアル復号インターフェイスが指定される。ユーザ機能の分野においては、順送り、ホットオブジェクト、方向性、トリックモードおよび透明なインターフェイスが指定される。ユーザ・オーサリングの分野においては、ストリーム編集インターフェイスが指定される。インターフェイスの前記全体の組は、すべての組を網羅しているわけではないが適応性のかなりの部分の実行を容易にする。

添付の図面を参照しながら、本発明を説明する。図面中、類似の素子には類似の番号が使用されている。

本発明のシステムおよび方法を、ＭＰＥＧ−４復号環境で説明する。前記環境において、本発明は、一つのＡＰＩではなく、種々のインターフェイスを拡張ＭＰＥＧ−４システムのためのＡＰＩの集合体を指定する。当業者には周知のＪａｖａ（登録商標）言語が、ＡＰＩを指定するために使用され、また当業者には周知の関連電子メモリ、記憶装置、バスおよび関連構成部分を持つ汎用プロセッサまたは特殊用途プロセッサ上で実行される。本発明においては、例示として、三つの分野のＡＰＩが識別され、各分野において、代表的な機能が提供される。

上記三つの例示としてのＡＰＩは下記の通りである。
・メディア復号
・ユーザ機能
・オーサリング
本発明の特定のＡＰＩおよび前記ＡＰＩの実行を組織する方法を、下記表に最初まとめ、以下に説明する。
表１ 本発明のＡＰＩ

パッケージは、ＡＰＩの実行を組織するための手段である。本発明が表示するＡＰＩのライブラリを考慮にいれた、パッケージの部分的なリストは下記の通りである。
・ｍｐｇｊ．ｄｅｃ
このパッケージは、相互作用を含むユーザ機能に対するクラスを含む。
・ｍｐｇｊ．ｆｕｎｃ
このパッケージは、優先を含むユーザ機能に対するクラスを含む。
・ｍｐｇｊ．ｕｔｉｌ
このパッケージは、種々の入力、出力、サウンドおよびビデオ装置へのインターフェイスを提供する。

ここで、本発明のシステムおよび方法および関連インターフェイス方法（ＡＰＩ）について説明する。
図１は、本発明のシステム実行のハイレベルのブロック図である。前記実行は、二つの主要な構成部分からなる。第一の構成部分は、デジタルメディア集積フレームワーク（ＤＭＩＦ）１６０からなる周知のパラメトリックシステムで、チャネル１５５に送付インターフェイスを供給し、システムズ・デマックス１６５に接続している。前記システムの出力は、図を簡単にするため、ＢＩＦＳおよびメディアデコーダ、バッファ、コンポジタおよびレンダリング装置１７０からなる一つの集合ブロックで示す、一連のブロックを通して送られる。レベル１７５上の前記集合ブロックの出力は、ディスプレイに送られる。第二の主要な構成部分は、ＭＰＥＧアプリケーション／アプレット（ＭＰＥＧ Ａｐｐ）１００であり、この構成部分は、それぞれ、１２０を通して、外部オーサリング・ユニット１３０およびユーザ入力に、本発明のオーサリングＡＰＩおよび機能ＡＰＩをインターフェイスする。さらに、ジャバ仮想機械、およびジャバ・メディア・フレームワーク（ＪＶＭおよびＪＭＦ）１１０は、ＢＩＦＳおよびメディアデコーダ、バッファ、コンポジタおよびレンダリング装置１７０に接続するための下支え基盤として使用され、また、シーングラフＡＰＩ１５０（ＭＰＥＧにより提供され、本発明で使用する）およびデコーダＡＰＩを通して、ＢＩＦＳおよびメディアデコーダ、バッファ、コンポジタおよびレンダリング装置１７０に直接インターフェイスする。

図２は、図１の種々のブロック、構成部分およびインターフェイスのさらに詳細な図面である。この図では、オーサリング・ユニット１３０が、ライン２００上で、ライン２０５を通してインターフェイスするユーザ入力１４０から独立して、ＭＰＥＧ Ａｐｐ１００にインターフェイスしている。この図は、また各インターフェイス、オーサリングＡＰＩ２９０および機能ＡＰＩ２９５も含む。さらに、この図では、ＭＰＥＧ Ａｐｐ１００およびその下のＪＶＭおよびＪＭＦ１１０が、ライン２１５を通してＢＩＦＳデコーダおよびシーングラフ２２５に働きかけ、２０７を通してシーングラフＡＰＩ２１０にインターフェイスしている。ＢＩＦＳデコーダおよびシーングラフ２２５は、ライン２６０、２６１、２６２を通して多数の例示としてのメディアデコーダ２７０、２７１、２７２を制御し、また（ライン２６８および２６９を通して）コンポジタ２８２およびレンダリング装置２８４を制御する。ＭＰＥＧ Ａｐｐ１００に関連するＪＶＭおよびＪＭＦ１１０は、同様に、各ライン２６３、２６４、２６５を通して、メディアデコーダ２７０、２７１および２７２を制御する。図２について、種々のプログラムを使用する制御装置およびインターフェイスを説明してきた。

図２の残りの部分は、ＭＰＥＧ−４のパラメトリックシステムを詳細に示す。この図の頂部の、本発明のプログラムを使用するシステムおよび方法の動作について説明する。復号されるＭＰＥＧ−４システムのビットストリームは、チャネル１５５を通して、ネットワーク／記憶装置配布インターフェイスＤＭＩＦ１６０に送られる。前記インターフェイスＤＭＩＦ１６０は、前記ビットストリームをライン２３０を通して、Ｄｅｍｕｘ１６５に送る。パッケージから取り出され、分離されたビットストリームは、シーン叙述情報を含む複数の部分からなり、ＢＩＦＳデコーダおよびシーングラフ２２５に送られる。前記ビットストリームは、また種々の各メディアデコーダ用の他の部分も含み、それぞれ、ライン２４０、２４５および２５０、復号バッファ２５１、２５２および２５３、ライン２５５、２５６および２５７を通して、メディアデコーダ２７０、２７１および２７２に送られ、前記メディアデコーダは、合成バッファ２７６、２７７および２７８への入力である復号したメディアを、ライン２７３、２７４および２７５に出力する。ライン２７９上のバッファ２７６の出力は、ライン２８０上のバッファ２７７の出力およびライン２８１上のバッファ２７８の出力と一緒に、コンポジタへ送られる。

図には、（復号バッファ２５１、２５２、２５３、デコーダ２７０、２７１、２７２および合成バッファ２７６、２７７、２７８を通しての）三組のメディア復号動作しか示していないが、実際には、メディアデコーダの数は、一つでもいいし、また幾つでも必要なだけ使用することができる。コンポジタ２８２は、ＢＩＦＳシーングラフ（およびおそらくはユニット入力）に基づいて、復号したメディアを相互に配列し、シーンを合成する。前記情報は、ライン２８３を通して、レンダリング装置２８４へ送られる。レンダリング装置２８４は、ピクセルおよびオーディオ・サンプルを与え、それらをライン１７５を通して、ディスプレイ（図示していないスピーカを持つ）２８５に送る。

図３は、特定の例として、ビジュアル復号を使用する本発明のメディア復号機能である。説明を簡単にするために、メディア復号を単に復号と呼ぶことにする。ベースＡＶオブジェクトまたはビデオ・デコーダ構造体の使用可能性に関していくつかの仮定が必要である。前記仮定は、デフォールトまたはプレースホールダ動作を含む前記抽出クラスが、その構造体を無視することによって、多くの場合、拡張される、オブジェクト指向プログラミングの状況としては普通のものである。

復号ＡＰＩ２２０は、インターフェイス、より詳しく説明すると、ビジュアル復号ＡＰＩ３０１である。前記ビジュアル復号ＡＰ１３０１を使用して、多数の異なるビジュアル・デコーダ３２０を接続することができる。前記接続は、ブロック選択復号ロジック（ＳＤＬ）３０６を通して行われる制御であると見なすことができる。図では、前記接続は、ロジックの他のいくつかの部分と一緒に、ＢＩＦＳデコーダ・ロジック３０５、ＢＩＦＳデコーダおよびシーングラフ２２５の一部または構成部分に属する。ＢＩＦＳ復号ロジック３０５は、制御ライン３０７を通してベース・ビデオ・デコーダ３１３のような種々のビジュアル・デコーダを制御し、制御ライン３０８を通して時間強化デコーダ３１４を制御し、制御ライン３０９を通して空間強化デコーダ３１５を制御し、制御ライン３１０を通して出力区分デコーダ３１６を制御し、制御ライン３１１を通して画像肌理デコーダ３１７を制御し、ライン３１２を通してメッシュ幾何学／運動デコーダ３１８を制御する。

復号されるビットストリームは、ライン３１９（図２のメディアデコーダ入力２５５または２５６または２５７に対応する）を通して、適当なデコーダに送られ、復号された出力は、ライン３２５（図２のメディアデコーダ出力２７３または２７４または２７５に対応する）上で入手することができる。ベース・ビデオ・デコーダ３１３は、スケール不可能なビデオを復号し、空間強化デコーダ３１５は、空間スケール可能性ビデオ層を復号し、時間強化デコーダ３１４は、時間スケール可能性ビデオ層を復号し、データ区分デコーダ３１６は、データ分割ビデオ層を復号し、画像肌理デコーダ３１７は、静止画像の肌理の空間／ＳＮＲスケール可能な層を復号し、メッシュ幾何学／運動デコーダ３１８は、オブジェクトの動きにより、波形メッシュ・ノード位置およびこれらノードの運動を復号する。

前記デコーダは、当業者には周知のＭＰＥＧ−４ビジュアル規格により指定される。柔軟で、一貫した方法でＭＰＥＧ−４ビジュアル・デコーダに、アクセスするのに使用する本発明の前記分類を、以下に詳細に説明する。

復号ＡＰＩ
Ｃｌａｓｓ ｍｐｇｊ．ｄｅｃ．ＢａｓｅＡＶＯｂｊｅｃｔ
ｐｕｂｌｉｃ ｃｌａｓｓ ＢａｓｅＡＶＯｂｊｅｃｔ
これは、ベース ＡＶオブジェクトストリームの復号を可能にする、基本的なクラスである。

構成装置
ｐｕｂｌｉｃ ＢａｓｅＡＶＯｂｊｅｃｔ（）
方法
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔａｒｔＤｅｃ（）
データ復号の開始
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔｏｐＤｅｃ（）
データ復号の停止
ｐｕｂｌｉｃ ｖｏｉｄ ａｔｔａｃｈＤｅｃｏｄｅｒ（Ｍｐ４Ｓｔｒｅａｍ ｂａｓｅｓｔｒｍ）
復号を行う有効なＭＰＥＧ−４ストリームを復号するための、準備中のベース・ストリームへのデコーダの取り付け。

ビジュアル復号ＡＰＩ
Ｃｌａｓｓ ｍｐｇｊ．ｄｅｃ．Ｍｐ４Ｄｅｃｏｄｅｒ
ｐｕｂｌｉｃ ｃｌａｓｓ Ｍｐ４ＶＤｅｃｏｄｅｒ
はビデオ・デコーダに拡張する。
このクラスは、ビデオ・デコーダ、抽出クラス（図示せず）を拡張する。このクラスは、種々のタイプのビジュアル・ビットストリームを復号するための方法を含む。

構成装置
ｐｕｂｌｉｃ Ｍｐ４ＶＤｅｃｏｄｅｒ（）
方法
ｐｕｂｌｉｃ ＶＯｂｊｅｃｔ ｂａｓｅＤｅｃｏｄｅ（Ｍｐ４ｓｔｒｅａｍ ｂａｓｅｓｔｒｍ）
ＭＰＥＧ−４ビデオストリーム、ｂａｓｅｓｔｒｍを復号し、復号したビジュアルオブジェクト、ＶＯｂｊｅｃｔを返す。
ｐｕｂｌｉｃ ＶＯｂｊｅｃｔ ｓｐｔＥｎｈＤｅｃｏｄｅ（Ｍｐ４ｓｔｒｅａｍ ｅｎｈｓｔｒｍ）
空間強化ＭＰＥＧ−４ビデオストリーム、ｅｎｈｓｔｒｅａｍを復号し、復号したビジュアルオブジェクト、ＶＯｂｊｅｃｔを返す。
ｐｕｂｌｉｃ ＶＯｂｊｅｃｔ ｔｍｐＥｎｈＤｅｃｏｄｅ（Ｍｐ４ｓｔｒｅａｍ ｅｎｈｓｔｒｍ）
時間強化ＭＰＥＧ−４ビデオストリーム、ｅｎｈｓｔｒｍを復号し、復号したビジュアルオブジェクト、ＶＯｂｊｅｃｔを返す。
ｐｕｂｌｉｃ ＶＯｂｊｅｃｔ ｓｎｒＥｎｈＤｅｃｏｄｅ（Ｍｐ４ｓｔｒｅａｍ ｅｎｈｓｔｒｍ、ｉｎｔ ｌｅｖｅｌ）は、レベルに従って、ｓｎｒ強化ＭＰＥＧ−４ビデオストリーム、ｅｎｈｓｔｒｍを復号し、復号したビジュアルオブジェクト、ＶＯｂｊｅｃｔを返す。
ｐｕｂｌｉｃ ＶＯｂｊｅｃｔ ｄａｔａｐａｒｔＤｅｃｏｄｅ（Ｍｐ４ｓｔｒｅａｍ ｅｎｈｓｔｒｍ、ｉｎｔ ｌｅｖｅｌ）
レベルに従って、データ分割ＭＰＥＧ−４ビデオストリーム、ｅｎｈｓｔｒｍを復号し、復号したビジュアルオブジェクト、ＶＯｂｊｅｃｔを返す。
ｐｕｂｌｉｃ ＶＯｂｊｅｃｔ ｔｒｉｃｋＤｅｃｏｄｅ（Ｍｐ４ｓｔｒｅａｍ ｔｒｋｓｔｒｍ、ｉｎｔ ｍｏｄｅ）は、モードに従って、トリックストリームをスキップおよび復号し、復号したビジュアルオブジェクト、ＶＯｂｊｅｃｔを返す。
ｐｕｂｌｉｃ ＭｅｓｈＯｂｊｅｃｔ ｍｅｓｈＡｕｘＤｅｃｏｄｅ（Ｍｐ４Ｓｔｒｅａｍ ａｕｘｓｔｒｍ）は、ＭＰＥＧ−４補助ビデオストリームを復号し、メッシュ幾何学および動作ベクトルを含む、メッシュオブジェクト、ＭｅｓｈＯｂｊｅｃｔを返す。

図４は、それに対して、インターフェイスが他の分類のＡＰＩにより定義される、多数の例示としての機能を使用する、本発明のいくつかの特徴の機能である。前記機能ＡＰＩ２９５は、いくつかのインターフェイスを示す。より詳しく説明すると、トリックモード機能（４０１）用のインターフェイス、方向性機能用のインターフェイス（４０２）、透明機能用のインターフェイス（４０３）、ホットオブジェクト機能用のインターフェイス（４０４）、および順送り機能用のインターフェイス（４０５）を示す。各ＡＰＩを使用して、多数の異なるデコーダを接続することができる。一例として、再びビジュアルデコーダを使用する。前記接続は、この図の場合、ＢＩＦＳデコーダおよびシーングラフ２２５および／またはＭＰＥＧ−４ Ａｐｐ１００の構成部分である、ＡＰＰ／ＢＩＦＳ Ｄｅｃ（ｏｄｅｒ）に属する、いくつかのブロック選択復号ロジック（ＳＤＬ）４１６、４１７、４１８、４１９、４２０を通しての制御と見なすことができる。ＡＰＰ／ＢＩＦＳ復号ロジック４１５は、制御ライン４２１、４２２、４２４、４２５を通して、ベース・ビデオ・デコーダ３１３のような種々のビジュアル・デコーダを制御し、制御ライン４２３および４２６を通して、時間強化デコーダ３１５を制御し、制御ライン４２７を通して、空間強化デコーダ３１５を制御し、制御ライン４２９を通して、データ分割デコーダ３１６を制御し、制御ライン４３０を通して、画像肌理デコーダ３１７を制御し、ライン４２８を通して、メッシュ幾何学／運動デコーダ３１８を制御する。

復号するビットストリームは、ライン４３１（図２のメディアデコーダ入力２５５または２５６または２５７に対応する）を通して、適当なデコーダへ送られ、復号した出力は、ライン４４５（図２のメディアデコーダ出力２７３または２７４または２７５に対応する）上で入手することができる。多くの場合、ビジュアルオブジェクトに関するユーザ機能は、一つまたはそれ以上のビジュアル・デコーダを使用することにより、実現することができることを理解することが重要である。前記ＳＬＤは、各ビジュアルオブジェクトを復号するために接続する特定のデコーダを選択するためばかりでなく、一つのビットストリームのために使用したデコーダ、および使用されるまたは使用されない特定の時間を選択するためにも使用される。図には多数のＳＤＬ４１６、４１７、４１８、４１９、４２０を示したが、各ＳＬＤは各機能に対応する。この図の各ＳＤＬは一つの制御入力を持つが、しかし、それはいくつかの可能性のある制御出力の中の一つである。もっと分かりやすく説明すると、図３の場合には、ベース・ビデオ・デコーダ３１３は、スケールすることができないビデオを復号し、空間強化デコーダ３１４は、空間スケール可能性ビデオ層を復号し、時間強化デコーダ３１５は、時間スケール可能性ビデオ層を復号し、データ分割デコーダ３１６は、データ分割ビデオ層を復号し、画像肌理デコーダ３１７は、静止画像肌理の空間／ＳＮＲスケール可能層を復号し、メッシュ幾何学／運動デコーダ３１８は、オブジェクトの運動により、ワイヤフレーム・メッシュ・ノードおよび前記ノードの運動を復号する。前記デコーダは、ここでもＭＰＥＧ−４ビジュアル規格により指定される。柔軟でしっかりした方法で前記機能を達成するために使用する、本発明のＡＰＩのこの分類についての詳細について以下に説明する。

機能ＡＰＩ
下記のＡＰＩは、種々のユーザ相互作用機能のためのものである。
順送りＡＰＩ
Ｃｌａｓｓ ｍｐｇｊ．ｆｕｎｃ．ＰｒｏｇＡＶＯｊｅｃｔ
ｐｕｂｌｉｃ ｃｌａｓｓ ＰｒｏｇＡＶＯｊｅｃｔ
ＢａｓｅＡＶＯｂｊｅｔの拡張。
ＰｒｏｇＡＶＯｂｊｅｃｔにより、ユーザ制御下のＡＶオブジェクトの品質を順送りに洗練することができる。現在、ビジュアルオブジェクトは、靜的なもの（任意に形成したオブジェクトの時間どおりの一例である、静止画像「ｖｏｐｓ」、ビデオオブジェクト面と見なされる。前記形が長方形である場合には、ｖｏｐは一つのフレームと同じものである。）

構成装置
ｐｕｂｌｉｃ ＰｒｏｇＡＶＯｂｊｅｃｔ（）
方法
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔａｒｔＤｅｃ（）
データ復号の開始
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔｏｐＤｅｃ（）
データ復号の停止
ｐｕｂｌｉｃ ｖｏｉｄ ｐａｕｓｅＤｅｃ（）
データ復号の一時的な中止
ｐｕｂｌｉｃ ｖｏｉｄ ｒｅｓｕｍｅＤｅｃ（）
現在の一時中止の状態からの、データ復号の再開
ｐｕｂｌｉｃ ｉｎｔ ｓｅｌｅｃｔＰｒｏｇＬｅｖｅｌ （）
変換（ＤＣＴまたはウェブレット）係数の復号が行われるまでのレベルの選択。一つのレベルは、走査順序中のある位置までの係数である。
ｐｕｂｌｉｃ ｖｏｉｄ ａｔｔａｃｈＤｅｃｏｄｅｒ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ ｉｎｔ ｐｒｏｇｌｖｌ）
有効なＭＰＥＧ−４ストリームを復号するための、準備中のｓｒｃｓｔｒｍへのデコーダの取り付け、および復号が行われるまでのプログラム・レベルの指定。
ｐｕｂｌｉｃ ｖｏｉｄ ｏｆｆｓｅｔＳｔｒｅａｍ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇｏｆｆｓｅｔ）
ｓｒｃｔｒｍへの、復号開始目標としてのオフセットの挿入可能。実際には、現実の目標位置は、必要な目標より遠い場合があり、ストリーム内の有効なエントリの位置により異なる。

Ｈｏｔ Ｏｂｊｅｃｔ／Ｒｅｇｉｏｎ ＡＰＩ
このＡＰＩにより、ホット（能動）ＡＶオブジェクトと相互作用を行うことができる。前記ＡＰＩは、一つのオブジェクトの能動領域と、相互作用を行うことができるように拡張することができる。このＡＰＩは、ＡＶオブジェクトの空間解像度強化、品質強化、時間的品質強化のような、一つまたはそれ以上の高度な機能を可能にするためのものである。実現する実際の強化は、（マウス．クリック／メニューを通しての）ローカルおよび遠隔地からのユーザ相互作用および強化ストリーム、および使用することができる強化デコーダにより異なる。

Ｃｌａｓｓ ｍｐｇｊ．ｆｕｎｃ．ＨｏｔＡＶＯｂｊｅｃｔ
ｐｕｂｌｉｃ ｃｌａｓｓ ＨｏｔＡＶＯｂｊｅｃｔ
ＢａｓｅＡＶＯｂｊｅｃｔの拡張
ＨｏｔＡＶＯｂｊｅｃｔは、そのオブジェクトがホットオブジェクトである場合に、ＡＶＯｂｊｅｃｔの強化動作をトリガするクラスである。それ故、ホットオブジェクトは、必要な場合にトリガされる、それ自身に関連するいくつかの強化ストリームを持つ。このクラスは、ベース（層）ストリームを復号するために主として使用される、ＢａｓｅＡＶＯｂｊｅｃｔを拡張する。さらに、ホットオブジェクトの定義を、問題の領域（ＫｅｙＲｅｇｉｏｎ）を含むように拡張することができる。

構成装置
ｐｕｂｌｉｃ ＨｏｔＡＶＯｂｊｅｃｔ（）
方法
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔａｒｔＤｅｃ（）
データ復号の開始
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔｏｐＤｅｃ （）
データ復号の停止
ｐｕｂｌｉｃ ｖｏｉｄ ｐａｕｓｅＤｅｃ（）
データ復号の一時的な中止
ｐｕｂｌｉｃ ｖｏｉｄ ｒｅｓｕｍｅＤｅｃ（）
現在の一時中止の状態からの、データ復号の再開
ｐｕｂｌｉｃ ｉｎｔ ｓｅｌｅｃｔＨｏｔＴｙｐｅ（）
（空間、品質、時間等の）強化のタイプの選択
ｐｕｂｌｉｃＭｐ４Ｓｔｒｅａｍ ｅｎｈａｎｃｅＯｂｊｅｃｔ（ｉｎｔ ｔｙｐｅ）
必要な強化ストリームを入手するための、選択した強化タイプの使用
ｐｕｂｌｉｃ ｖｏｉｄ ａｔｔａｃｈＤｅｃｏｄｅｒ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ ｉｎｔ ｔｙｐｅ）
有効なＭＰＥＧ−４ストリームを復号するための、準備中のｓｒｃｓｔｒｍへのデコーダの取り付け、および復号が行われるタイプの指定
ｐｕｂｌｉｃ ｖｏｉｄ ｏｆｆｓｅｔＳｔｒｅａｍ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇｏｆｆｓｅｔ）
ｓｒｃｔｒｍへの、復号開始目標としてのオフセットの挿入可能。実際には、現実の目標位置は、必要な目標より遠い場合があり、ストリーム内の有効なエントリの位置により異なる。

方向性ＡＰＩ
このＡＰＩにより、方向を感知するＡＶオブジェクトとの相互作用を行うことができる。前記ＡＰＩは、静的ビジュアルオブジェクト（静止ｖｏｐ）、動的ビジュアルオブジェクト（運動するｖｏｐ）および方向性を持つ音声およびオーディオをサポートする。ビジュアルオブジェクトの場合には、このＡＰＩは、視点の選択を可能にし、対応するビットストリームだけが復号され、復号されたデータは、コンポジタへ送られる。音声オブジェクトの場合には、必要な音声点により、アナログ動作が行われる。現在のところ、予め定めた方向性を持つ選択が行われる。

Ｃｌａｓｓ ｍｐｇｊ．ｆｕｎｃ．ＤｉｒｅｃＡＶＯｂｊｅｃｔ
ｐｕｂｌｉｃ ｃｌａｓｓ ＤｉｒｅｃＡＶＯｂｊｅｃｔ
ＢａｓｅＡＶＯｂｊｅｃｔの拡張。
ＤｉｒｅｃＡＶＯｂｊｅｃｔは、（予め定めた量子化した方向の形での）空間の、ｘ−ｙ−ｚ位置に応答するオブジェクトの生成を可能にする。ユーザ相互作用により、一つまたはそれ以上の視点に対応するｖｏｐが、必要に応じて復号されるように、ビットストリームが、ＡＶオブジェクトとして符号化された多数の靜的ビジュアルｖｏｐからできていると仮定すると、もっと容易に説明することができる。前記クラスは、動的ＡＶＯｂｊｅｃｔを符号化するのにも適している。

構成装置
ｐｕｂｌｉｃ ＤｉｒｅｃＡＶＯｂｊｅｃｔ（）
方法
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔａｒｔＤｅｃ（）
データ復号の開始
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔｏｐＤｅｃ（）
データ復号の停止
ｐｕｂｌｉｃ ｖｏｉｄ ｐａｕｓｅＤｅｃ（）
データ復号の一時的な中止
ｐｕｂｌｉｃ ｖｏｉｄ ｒｅｓｕｍｅＤｅｃ（）
現在の一時中止の状態からの、データ復号の再開
ｐｕｂｌｉｃ ｖｏｉｄ ｌｏｏｐＤｅｃ（）
この方法により、閉ループを形成する予め定めた順序の靜的ｖｏｐとしての、動的ビジュアルオブジェクトのユーザ相互作用復号が可能になる。この方法はオーディオの場合にも、適用することができる。ユーザの選択は、マウスのクリックまたはメニューにより行われる。
ｐｕｂｌｉｃ ｉｎｔ ｓｅｌｅｃｔＤｉｒｅｃｔ（）
方向（シーンの向き）の選択。オブジェクト上のホット点上またはメニュー上で、マウスをクリックすることにより、多数の予め定めた方向を使用することができ、選択を行うことができる。
ｐｕｂｌｉｃ Ｍｐ４Ｓｔｒｅａｍ ｅｎｈｎｃｅＯｂｊｅｔ（ｉｎｔ ｏｒｉｅｎｔ）
必要な時間補助（強化）ストリームを入手するための、選択したシーンの向きの使用。
ｐｕｂｌｉｃ ｖｏｉｄ ａｔｔａｃｈＤｅｃｏｄｅｒ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ ｉｎｔ ｏｒｉｅｎｔ）
有効なＭＰＥＧ−４ストリームを復号するための、準備中のｓｒｃｓｔｒｍへの時間補助（強化）デコーダの取り付け、およびＡＶオブジェクトの選択したシーン方向の指定。
ｓｒｃｔｒｍへの、復号開始目標としてのオフセットの挿入可能。実際には、現実の目標位置は、必要な目標より遠い場合があり、ストリーム内の有効なエントリの位置により異なる。

トリックモードＡＰＩ
トリックモードＡＰＩは、強化されたトリックプレイ能力を使用することができるように、ユーザの制御の下での条件付き復号をサポートする。強化トリックプレイは、ＦＦまたはＦＲ、フリーズ・フレーム、ランダム・アクセスおよび逆方向再生のような、他の動作に対する異なる速度のような、ＶＣＲ／ＣＤプレーヤのような機能を使用できるようにするようなものであると見なすことができる。しかし、合成された全シーンに基づく他に、個々のＡＶオブジェクトに基づいて、ＭＰＥＧ−４がこれら能力を使用することができるという違いを持つ。

Ｃｌａｓｓ ｍｐｇｊ．ｆｕｎｃ．ＴｒｉｃｋＡＶＯｂｊｅｃｔ
ｐｕｂｌｉｃ ｃｌａｓｓ ＴｒｉｃｋＡＶＯｂｊｅｃｔ
ＢａｓｅＡＶＯｂｊｅｃｔの拡張。
ＴｒｉｃｋＡＶＯｂｊｅｃｔは、トリックプレイに適する復号を行うことができる、オブジェクトを形成するのに使用することができるクラスである。

構成装置
ｐｕｂｌｉｃ ＴｒｉｃｋＡＶＯｂｊｅｃｔ（）
方法
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔａｒｔＤｅｃ（）
データ復号の開始
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔｏｐＤｅｃ（）
データ復号の停止
ｐｕｂｌｉｃ ｖｏｉｄ ｐａｕｓｅＤｅｃ（）
データ復号の一時的な中止
ｐｕｂｌｉｃ ｖｏｉｄ ｒｅｓｕｍｅＤｅｃ（）
現在の一時中止の状態からの、データ復号の再開
ｐｕｂｌｉｃ ｖｏｉｄ ｌｏｏｐＤｅｃ（）
このクラスにより、種々の速度での順方向および逆方向への、ｓｒｃｓｔｒｅａｍの選択した部分のユーザ相互作用復号が可能になる。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ｓｅｌｅｃｔＤｉｒｅｃ（）
復号方向の選択。トリック復号が（正規の）順方向に行われる場合には、真に戻る。逆方向のトリック復号が選択された場合には、偽に戻る。
ｐｕｂｌｉ ｃＭｐ４Ｓｔｒｅａｍ ｅｎｈａｎｃｅＯｂｊｅｃｔ（ｂｏｏｌｅａｎ ｄｅｃｄｉｒｅｃ）
ｄｅｃｄｉｒｅｃにより指定した方向へ復号するＭＰＥＧ−４ストリームの入手。
ｐｕｂｌｉｃ ｖｏｉｄ ａｔｔａｃｈＤｅｃｏｄｅｒ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ ｉｎｔ ｄｅｃｄｉｒｅｃ）
有効なトリックモードのＭＰＥＧ−４ストリームを復号するための、準備中のｓｒｃｓｔｒｍにトリックデコーダの取り付け、復号方向の指定。
ｐｕｂｌｉｃ ｖｏｉｄ ｏｆｆｓｅｔＳｔｒｅａｍ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇｏｆｆｓｅｔ）
ｓｒｃｔｒｍへの、復号開始目標としてのオフセットの挿入可能。実際には、現実の目標位置は、必要な目標より遠い場合があり、ストリーム内の有効なエントリの位置により異なる。

透明ＡＰＩ
透明ＡＰＩは、ユーザ制御下の一つのオブジェクトの、複数の領域の選択的な復号をサポートする。ビジュアルオブジェクトの場合には、そのオブジェクト内の他のピクセルの透明度を変化させることによって、大きなオブジェクトをいくつかのより小さな領域に分割するという方法で、符号化が行われると仮定する。問題の領域に属さないピクセルは、符号化されている領域内に存在しない選択したキー・カラーを、前記ピクセルに割り当てることにより符号化される。このＡＰＩにより、いくつかのまたは全部の領域を符号化することができるように、ユーザの制御下で符号化を行うことができる。さらに、問題の領域の場合には、空間および時間的品質を改善するために、強化ビットストリームが必要になる場合がある。各領域に対する前記キー・カラーは、コンポジタに対して識別される。ユーザは、帯域幅／計算資源が限定されていたり、オブジェクトのいくつかの部分が隠れていたりして必要がないため、または他の領域ないに画像を削除するかその品質を犠牲にして、特定の領域に必要な遙かに高い品質のため、ユーザが、全部の領域の復号を必要としない場合がある。キー・カラーを使用する前記プロセスは、放送分野の「クロマキー」技術に類似している。

Ｃｌａｓｓ ｍｐｇｊ．ｓｖｓ．ＴｒａｎｓｐＡＶＯｂｊｅｃｔ
ｐｕｂｌｉｃ ｃｌａｓ ＴｒａｓｎｓｐＡＶＯｂｊｅｃｔ
ＢａｓｅＡＶＯｂｊｅｃｔの拡張
ＴｒａｓｎｓｐＡＶＯｂｊｅｃｔは、透明情報によりオブジェクトを形成するために使用することができるクラスである。音声およびビジュアルオブジェクトタイプの両方が処理される。

構成装置
ｐｕｂｌｉｃ ＴｒａｎｓｐＡＶＯｂｊｅｃｔ（）
方法
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔａｒｔＤｅｃ（）
データ復号の開始
ｐｕｂｌｉｃ ｖｏｉｄ ｓｔｏｐＤｅｃ （）
データ復号の停止
ｐｕｂｌｉｃ ｖｏｉｄ ｐａｕｓｅＤｅｃ（）
データ復号の一時的な中止
ｐｕｂｌｉｃ ｖｏｉｄ ｒｅｓｕｍｅＤｅｃ（）
現在の一時中止の状態からの、データ復号の再開
ｐｕｂｌｉｃ ｉｎｔ ｇｅｔＲｅｇｉｏｎ（）
リストの形のメニュー内の番号、または（同様に番号に翻訳される）ホット・ポイントを、クリックすることによる領域の選択。
ｐｕｂｌｉｃ Ｍｐ４Ｓｔｒｅａｍ ｅｎｈａｎｃｅＯｂｊｅｃｔ（ｉｎｔ ｔｙｐｅ，ｉｎｔ ｒｅｇｎｕｍ）
ｒｅｇｉｏｎ ｒｅｇｎｕｍに対する必要な強化ストリームを入手するための、選択した強化タイプの使用。
ｐｕｂｌｉｃ ｖｏｉｄ ａｔｔａｃｈＤｅｃｏｄｅｒ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｉｎｔ ｔｙｐｅ、ｉｎｔ ｒｅｇｎｕｍ）
一つの領域およびそのキー・ｃカラーを復号するための準備中のｓｒｃｓｔｒｍにデコーダの取り付け。
ｐｕｂｌｉｃ ｖｏｉｄ ｏｆｆｓｅｔＳｔｒｅａｍ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇｏｆｆｓｅｔ）
ｓｒｃｔｒｍへの、復号開始目標としてのオフセットの挿入可能。実際には、現実の目標位置は、必要な目標より遠い場合があり、ストリーム内の有効なエントリの位置により異なる。

図５は、それに対して、インターフェイスが他の分類のＡＰＩで定義される、ストリーム編集の一例を使用する本発明のオーサリング機能である。オーサリングＡＰＩ２９０は、オーサリング関連のインターフェイス、より詳しく説明すると、ストリーム編集ＡＰＩ（５０１）を表す。前記ＡＰＩを使用することにより、ＭＰＥＧＡｐｐ（１００）またはＢＩＦＳデコーダおよびシーングラフ（２２５）が使用するための、ビットストリームを編集／修正することができる。ＡＰＩ５０１は、制御ライン５０５を通して、ＭＰＥＧ ＡＰＰ１００を制御し、制御ライン５０６を通してＢＩＦＳデコーダおよびシーングラフ２２５を制御する。それ故、ストリーム編集ＡＰＩは、種々のオーディオ・ビジュアルオブジェクトおよびＢＩＦＳシーン叙述を含む、ＭＰＥＧ−４の編集／修正を助けることができる。ストリーム編集ＡＰＩの他に、他のＡＰＩを使用することができるオーサリングも行うことができるが、本発明は指定しない。ストリーム編集ＡＰＩの詳細を下記に説明する。

オーサリング
下記のＡＰＩは、ＭＰＥＧ−４ビットストリームを部分的にオーサリングするためのものである。

ストリーム編集ＡＰＩ
Ｃｌａｓｓ ｍｐｇｊ．ｕｔｉｌ．ＳｔｒｅａｍＥｄｉｔ ｐｕｂｌｉｃ ｃｌａｓｓ ＳｔｒｅａｍＥｄｉｔ
このクラスは、ＭＰＥＧ−４ストリームの内容および修正を決定することができる。アクセス、コピー、迫加、置き換え、削除のような動作および他の動作がサポートされる。

構成装置
ｐｕｂｌｉｃ ＳｔｒｅａｍＥｄｉｔ（）
方法
ｐｕｂｌｉｃ ｉｎｔ［］ｇｅｔＯｂｊｅｃｔＬｉｓｔ（Ｍｐ４Ｓｔｒｅａｍ ｒｃｓｔｒｍ）
ストリーム内のオブジェクトのリストの返還。返還されたオブジェクトは、ビットストリーム内のオブジェクトの累積表となる。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ｒｅｐｌａｃｅＯｂｊｅｃｔ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇｓｒｃｏｂｊｉｄ、Ｍｐ４Ｓｔｒｅａｍ ｄｅｓｔｓｔｒｍ、ｕｌｏｎｇ ｄｅｓｔｏｂｊｉｄ）
ストリーム内のオブジェクトｉｄ、ｄｅｓｔｏｂｊｉｄを持つオブジェクトの発生の、ｓｒｃｓｔｒｍ内のオブジェクトｉｄ、ｓｒｃｏｂｊｉｄを持つオブジェクトの対応する発生による置き換え。オブジェクト表はそれに従って更新される。更新が成功した場合には、動作は真に戻り、更新が失敗した場合には偽に戻る。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ｒｅｐｌａｃｅＯｂｊｅｃｔＡｔ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇｓｒｃｏｊｉｄ、ｕｌｏｎｇ ｍ、Ｍｐ４Ｓｔｒｅａｍ ｄｅｓｔｓｔ ｒｍ、ｕｌｏｎｇ ｄｅｓｔｏｂｊｉｄ、ｕｌｏｎｇ ｎ）
置き換えを開始する位置を除いて、ｒｅｐｌａｃｅＯｂｊｅｃｔ（）と同じ意味論が指定される。ｄｅｓｔｏｂｊｉｄのｎ番目の発生からの宛先オブジェクトの、ｓｒｃｏｂｊｉｄのｍ番目の発生からのソースオブジェクトによる置き換え。ｍ＝ｎ＝０の場合には、ｒｅｐｌａｃｅＯｂｊｅｃｔ（）と同じことが行われる。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ｃｏｎｔａｉｎＯｂｊｅｃｔＴｙｐｅ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇ ｏｂｊｔｙｐｅ）
ｓｒｃｓｔｒｍがｏｂｊｔｙｐｅのオブジェクトを含んでいる場合には、真に戻り、そうでない場合には偽に戻る。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ａｄｄＯｂｊｅｃｔｓ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇ ｓｒｃｏｂｊｉｄ、Ｍｐ４Ｓｔｒｅａｍ ｄｅｓｔｓｒｍ）
ｄｅｓｔｓｔｒｍへのｓｒｃｓｔｒｍからのｓｒｃｏｂｊｉｄの追加。成功の場合は真に戻り、そうでない場合には偽に戻る。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ａｄｄＯｂｊｅｃｔＡｔ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ、ｕｌｏｎｇ ｓｒｃｏｂｊｉｄ、Ｍｐ４Ｓｔｒｅａｍ ｄｅｓｔｓｒｍ、ｕｌｏｎｇ ｄｅｓｔｏｂｊｉｄ、ｕｌｏｎｇ ｎ）
ｄｅｓｔｏｂｊｉｄのｎ番目の発生の後から始まるｄｅｓｔｓｔｒｍへの、ｓｒｃｓｔｒｍからのｓｒｃｏｂｊｉｄの追加。成功の場合は真に戻り、そうでない場合には偽に戻る。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ｃｏｐｙＯｂｊｅｃｔｓ（Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｃｓｔｒｍ、ｕｌｏｎｇ ｓｒｃｏｂｊｉｄ、Ｍｐ４Ｓｔｒｅａｍ ｄｅｓｔｓｔｅａｍ、ｄｅｓｔｏｂｊｉｄ）
ｓｒｓｔｒｍ内のｓｒｃｏｂｊｉｄを持つオブジェクトを、新しいオブジェクトｉｄ、ｄｅｓｔｏｂｊｉｄを持つｄｅｓｔｓｔｒｅａｍへコピー。ｄｅｓｔｓｔｒｍが存在しない場合には、生成される。存在する場合には重ね書きされる。この動作は、以降の動作に対する多重化されていないストリームから、基本的ストリームを生成するために使用される。成功の場合は真に戻り、そうでない場合には偽に戻る。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ｄｅｌｅｔｅＯｂｊｅｃｔｓ（Ｍｐ４Ｓｔｒｅａｍ ｓｄｅｓｔｓｔｒｍ、ｕｌｏｎｇ ｄｅｓｔｏｂｊｉｄ）
ｄｅｓｔｓｔｒｍ内のｄｅｓｔｏｂｊｉｄを持つストリームオブジェクトの削除。また、すべての合成情報の除去。成功の場合は真に戻り、そうでない場合には偽に戻る。
ｐｕｂｌｉｃ ｂｏｏｌｅａｎ ｓｐｌｉｃｅＡｔ（Ｍｐ４Ｓｔｒｅａｍ ｄｅｓｔｓｔｒｍ、ｕｌｏｎｇ ｄｅｓｔｏｂｊｉｄ、ｕｌｏｎｇ ｎ、Ｍｐ４Ｓｔｒｅａｍ ｓｒｃｓｔｒｍ）
ｄｅｓｔｏｂｊｉｄのｎ番目の発生の後のｄｅｓｔｓｔｒｍのスプライス、およびｓｒｃｓｔｒｍのペースト。成功の場合は真に戻り、そうでない場合には偽に戻る。

まとめると、図１−図５のＡＰＩに反映された、一組のライブラリ機能を含む柔軟なシステムおよび方法は、符号化されたメディア・ストリームをリモート・ラップトップ・パソコンまたは他の装置のような復号ターミナル資源とマッチさせることができる、新しいレベルの適応性を提供する。さらに、本発明は、また適当なデコーダおよび符号化されたメディアオブジェクトビットストリームの選択的な復号と一緒に、高度の新しい機能を可能にする、ユーザ相互作用に対するサポートも含む。

本発明を実行する場合には、定義のＡＶ関連機能を含む分類が導入され、すべての汎用で一貫している方法で、埋設されたオーディオ・ビジュアルオブジェクトの復号と合成との間の、簡単でありながら、より複雑な相互作用を行うことができるように、一組のＡＰＩが設定される。

本発明のシステムおよび方法の前記説明は、単に例示としてのものに過ぎず、当業者ならその構造および実行を種々に変更することができるだろう。例えば、三つの分類の入力、出力およびマッピング機能のコンパクトで汎用装置を説明してきたが、ネットワーク、アプリケーションまたは他のニーズの変更により、ＡＰＩにいくつかの機能を追加したり、取り除いたりすることができる。本発明の範囲は、下記の請求の範囲だけにより制限される。

本発明の一実施形態を示すシステムのハイレベルのブロック図である。 本発明の前記実施形態を詳細に示す前記システムのブロック図である。 本発明のビジュアル復号のためのインターフェイス方法である。 本発明の機能用のインターフェイス方法である。 本発明のオーサリングのためのインターフェイス方法である。

Claims (9)

1. ＭＰＥＧプレーヤ及びＪａｖａ（登録商標）コードの間で相互に作用可能な通信を可能とするシステムであって、
   少なくとも複数のＡＰＩ（２９０、２９５）及びＪａｖａ（登録商標）仮想機械（１１０）を有するアプリケーションエンジン、及び
   該アプリケーションエンジンと通信し、ユーザ入力／出力装置（１３０、１４０）と双方向通信するＭＰＥＧアプリケーション（１００）であって、少なくとも１つのメディアデコーダと通信するＭＰＥＧアプリケーションエンジン
   からなるシステム。
2. 請求項１のシステムにおいて、該複数のＡＰＩが、オーディオ・ビジュアルオブジェクトを復号するメディアデコーダにアクセスして制御する少なくともメディアデコーダＡＰＩからなるシステム。
3. 請求項２のシステムにおいて、該少なくとも１つのメディアデコーダＡＰＩがデコーダを開始、停止及び再開させるシステム。
4. 請求項２のシステムにおいて、該少なくとも１つのメディアデコーダＡＰＩがさらにデコーダへのビットストリームの送信及び分離を促進するシステム。
5. ＭＰＥＧ・Ｊａｖａ（登録商標）アプリケーションとプレゼンテーションエンジンとの間で通信する少なくとも１つのＭＰＥＧアプリケーション・プログラミング・インターフェイス（ＡＰＩ）を用いてＭＰＥＧビットストリームを復号及びレンダリングする方法であって、
   ＭＰＥＧアプリケーションにおいてＪａｖａ（登録商標）コードを持つＭＰＥＧプレーヤの相互作用性を制御することに関連する基本ビットストリームを受信するステップ、及び
   該ＭＰＥＧアプリケーション（１００）と、少なくともデマルチプレクス（Ｄｅｍｕｘ・１６５）、シーングラフ、複数のメディアデコーダ（２７０、２７１、２７２）、デジタルメディア集積フレームワーク（ＤＭＩＦ）、複数のバッファ（２４１、２５２、２５３、２７７、２７８）、コンポジタ（２８２）及びレンダリング装置（２８４）からなるプレゼンテーションエンジンとの間のインターフェイスを提供するために、シーングラフＡＰＩ及びメディアデコーダＡＰＩの少なくとも１つを使用するステップ
   からなる方法。
6. 請求項５の方法であって、さらに、
   オーディオ・ビジュアルオブジェクトに関連するユーザ入力を受信するステップ、及び
   該シーングラフＡＰＩ（２１０）及び該メディアデコーダＡＰＩ（２２０）の少なくとも一方の使用を介して、該プレゼンテーションエンジンによってレンダリングされるシーンを修正するステップ
   からなる方法。
7. 請求項５の方法において、該メディアデコーダＡＰＩ（２２０）デコーダを開始、停止及び再開させる方法。
8. 請求項７の方法において、該メディアデコーダＡＰＩ（２２０）がさらにデコーダからのビットストリームの送付及び分離を促進する方法。
9. 請求項５の方法において、該シーングラフＡＰＩ（２１０）がシーングラフ（２２５）とＭＰＥＧ・Ｊａｖａ（登録商標）アプリケーション（１００）の間のインターフェイスを提供する方法。

Images