JP5054663B2 - マルチメディアデータのバイナリ記述のための拡張コードを含むデータをデコーダによりデコーディングする方法 - Google Patents

Description

本発明は、マルチメディアデータのバイナリ記述のための拡張コードを含むデータをデコーダによりデコーディングする方法に関する。

ＭＰＥＧ−７標準［１］のコンテキストにおいてマルチメディアデータの記述は記述子（Ｄ）と記述スキーム（ＤＳ）によって構成されており、この場合、記述要素（ＤまたはＤＳ）の個数は可変である。ＭＰＥＧ−７におけるすべてのＤおよびＤＳは、いわゆる記述定義言語（ＤＤＬ）を使用して定義される［３］。また、ＭＰＥＧ−７はテキストフォーマット（ＸＭＬ）でもバイナリフォーマット（ＢｉＭ）でも表現可能である［１］。ＭＰＥＧ−７を使用したアプリケーション間の共働を可能にするためには、ＭＰＥＧ−７において構成されるＤおよびＤＳのセットを適正な時点で所定のポイントにおいて決定する必要がある。ＤＤＬによってＭＰＥＧ−７のＤＳをまえもって定められたセット以上にさらに拡張し続けることができる一方、これら新たな（拡張された）ＤＳの意味はそれを設計した人以外の誰にもわからない。

したがって本発明の課題は、マルチメディアデータのバイナリ記述のための拡張コードを供給する方法において、上述の従来技術の問題点を解消することにある。

本発明によればこの課題は、マルチメディアデータは、記述要素として記述子と記述スキームから成り、拡張ツリーブランチコードがマルチメディアデータバイナリフォーマットに含められており、デコーダは該拡張ツリーブランチコードを検出し、拡張ツリーブランチコードに基づき前記デコーダは、拡張された記述スキームの２つに分割されたパートのうち一方のパートはまえもって定義されベースとなる記述スキームと同一であり、他方のパートは前記拡張ツリーブランチコード以降に続くことになる拡張を記述していることを検出することにより解決される。

請求項１記載の方法によれば、バイナリフォーマットにおけるマルチメディア記述スキームのユーザ固有またはアプリケーション固有の拡張が提供され、その際、まえもって定義されているたとえばＭＰＥＧ−７の記述スキームおよび拡張された記述スキームの双方に共通の記述スキームの部分におけるバイナリフォーマットが保存される。

従来技術によるマルチメディア記述スキームのためのバイナリフォーマットすなわちいわゆるＢｉＭにより、テキストによる記述をバイナリ形式で表すことができる。ＤおよびＤＳのセットがたとえばＭＰＥＧ−７のような標準で決定されたならば、定義されたそれらのＤおよびＤＳを原則的にはさらに拡張することができるけれども、拡張されたＤまたはＤＳのセマンティクスはその作成者にしかわからない。それにもかかわらず固有のＤやＤＳをたとえばＭＰＥＧ−７などのＤやＤＳといっしょに使用する多数のアプリケーションのために、両方の種類に対し同じバイナリフォーマットを使用するのが非常に重要となる。基本的にＢｉＭは、ＭＰＥＧ−７のＤＤＬをベースとしているかぎりいずれの種類のＤおよびＤＳにも使用することができる。しかし現行のＢｉＭをＭＰＥＧ−７のＤまたはＤＳに適用し、かつＭＰＥＧ−７のＤまたはＤＳをベースとする拡張されたＤＳに適用すると、両方のＤＳのバイナリフォーマットは両方の事例において同一のＤＳの部分であっても異なるものになってしまう。

本発明の利点は、まえもって定義されたたとえばＭＰＥＧ−７のＤＳと拡張されたＤＳの同一部分のバイナリフォーマットを同じままに保つことのできる手段が提供されることであり、その結果、拡張部分に対するバイナリフォーマットだけが異なるようになる。このことはマルチメディアデータバイナリフォーマットに拡張ツリーブランチコードを含めることによって達成される。

本発明のさらに別の観点として挙げられるのは、拡張ツリーブランチコード（tree branch code）ＴＢＣをポジションコードといっしょに使用できることである。

本発明のさらに別の観点によれば、ＭＰＥＧ−７固有の拡張ツリーブランチコード（ＴＢＣ）をツリーブランチコード（ＴＢＣ）テーブルに付加的にまたは択一的に含めることができる。このＭＰＥＧ−７固有の拡張ＴＢＣをＭＰＥＧ−７標準のＤおよびＤＳの拡張に使用することができ、それらは将来のバージョン２，３等で定義されそうである。この種のＭＰＥＧ−７固有の拡張ＴＢＣを含めることによって、所定の範囲まではＭＰＥＧ−７標準のフォワードコンパチビリティ（forward compatibility）が許容される。ここでいうフォワードコンパチビリティとは、ＭＰＥＧ−７バージョン１のデコーダは、ＭＰＥＧ−７バージョン２＋のＤＳのうち少なくともＭＰＥＧ−７バージョン１のＤＳと合致している部分をデコーディングできるということである。さらに既存のＭＰＥＧ−７バージョン１の内容を、バージョン１のＤＳから派生された将来のＭＰＥＧ−７のＤＳに非常にたやすく組み込むことができる。

図面には従来技術を引き合いに出しながら本発明の実施形態が描かれており、以下でそれらの実施形態について詳しく説明する。

本発明の詳細について論じる前に、いくつかの定義殊にＭＰＥＧ−７で使用される定義を示しておく。

現在開発中のＭＰＥＧ−７標準のコンテキストにおいて、マルチメディア環境におけるオーディオビジュアルデータを記述するための記述構造が定義されている。したがって記述子（Description, Ｄ）および記述スキーム（Description scheme, ＤＳ）が、いわゆる記述定義言語（Description Definition Language, DDL）を用いて定義されている。本明細書の以降のコンテキストにおいて、以下の定義が使用される：
・データ Data：データはオーディオビジュアル情報であって、これは記憶やコーディング、表示、伝送、媒体あるいは技術にかかわらず、ＭＰＥＧ−７を使用して記述される。
・フィーチャ Feature：フィーチャは何かを誰かに知らせるデータにおいて他との区別を示す特徴である。
・記述子 Descriptor（Ｄ）：記述子はフィーチャの表現である。記述子によってフィーチャ表現のシンタックスおよびセマンティクスが定義される。
・記述子値 Descriptor Value（ＤＶ）：記述子値は、目下のデータを表す所定のデータセット（またはそのサブセット）に対する記述子のインスタンシエーションである。
・記述スキーム Description Scheme（ＤＳ）：記述スキームは、記述子（Ｄ）および記述スキーム（ＤＳ）の両方とすることのできる各コンポーネント間の関係の構造およびセマンティクスを指定する。
・記述：１つの記述は、ＤＳ（構造）とデータを記述する記述子値（インスタンシエーション）のセットから成る。
・コーディングされた記述：コーディングされた記述は、圧縮効率、フォールトトラレンス、ランダムアクセス等のような関連する要求を満たすためにコーディングされた記述である。
・記述定義言語（ＤＤＬ）：記述定義言語は、新たな記述スキームおよび場合によっては記述子を生成することのできる言語である。さらにこれによって既存の記述スキームの拡張や変形も可能である。

記述の一番下のレベルは記述子である。これによって１つまたは複数のデータのフィーチャが定義される。これは個々のＤＶとともに、データの固有の部分を実際に記述するために使用される。次に上のレベルは記述スキームであり、これには少なくとも２つまたはそれよりも多くのコンポーネントおよびそれらの関係が含まれている。コンポーネントは記述子または記述スキームのどちらであってもよい。最も上のレベルは記述定義言語である。これはＭＰＥＧ−７のＤとＤＳを定義するために使用されるし、さらにたとえばＭＰＥＧ−７のコンテキストで定義された既存のＤＳを拡張するなどしてユーザ固有またはアプリケーション固有の新たなＤＳを定義するためにも使用できる。

ＭＰＥＧ−７の記述を表現するために２つのオプションがある。最初のオプションは、eXtended Markup Language (XML) を使用したテキスト表現である。この表現は人間が読むことができるけれども、かなり冗長になる可能性がある。２番目のオプションはバイナリ表現であり、これはＭＰＥＧ−７データのためのバイナリフォーマットである（Binary format for MPEG-7 Data, BiM）。ＢｉＭは人間には読めないが、帯域幅について効率的なＭＰＥＧ−７データの記憶や伝送、ＤＳの所定のコンポーネントへのランダムアクセスが可能となるし、さらにＤＳコンポーネントのフレキシブルな伝送順序が許容される。以下のセクションで、ＭＰＥＧ−７記述のテキストフォーマットとバイナリフォーマットについてさらに詳しく説明する。

ＭＰＥＧ−７データのためのテキストフォーマットはＸＭＬ言語をベースとしている。これはいわゆる「ＸＭＬタグ」から成り、タグ間でデータの構造と意味を定義する。記述は階層的に組み立てられており、ＤＳコンポーネントの開始を定義する各オープニングＸＭＬタグごとに、ＤＳコンポーネントの終了を定義するそれに対応するクロージングタグが設けられている。非常に簡単なＤＳの一例を以下に示す。ＤＳの定義はＤＤＬを使用することで行われ、これはＭＰＥＧ−７のＭＤＳパートに示されている［４］。

括弧（"<...>"）内のテキストは、オープニングＸＭＬタグおよびクロージングＸＭＬタグを表す。タグ間のテキストは記述のデータ値を表す。上述の例では、英国のグループ "The Beatles" の"Help" という名称のオーディオトラックのタイトル、プレゼンタならびにジャンルが記述されている。この記述も図１に示したように記述ツリーとして描くことができる。この場合、実際のデータはツリーのリーフ中に含まれる一方、個々のブランチノードによって構造が与えられる。このツリー表現は、ＭＰＥＧ−７のバイナリフォーマットを理解するうえで非常に有用であり、これについて以下のセクションで説明する。

本発明において引き合いに出すマルチメディア記述のためのバイナリフォーマットに関する従来技術はＭＰＥＧ−７ ＢｉＭとしており、これについては［２］に詳しく記載されている。ここではバイナリフォーマットについて、本発明を理解するうえで必要な範囲で説明する。

一般に、各ＭＰＥＧ−７記述はいわゆるＭＰＥＧ−７ルート要素からスタートし、これには１つまたは複数のＭＰＥＧ−７記述スキームを含めることができる。ルート要素の子であるＭＰＥＧ−７のＤＳを以下では「トップレベル要素」と称する。すべてのＭＰＥＧ−７記述は階層的に定義されているので、それらを図２に示されているように記述ツリーとして捉えることができる。

記述のツリー表現を使用しているので、以下の記述ではルート要素とトップレベル要素も「ルートノード」および「トップレベルノード」と称する。このツリー表現を、バイナリフォーマットのデコーディングの仕方を記述するためにも使用する。ルートノード情報はデコーダによって受け取られるので、ビットストリームの残りはいわゆるＢｉＭフラグメントから成る。各フラグメントは基本的に図３に示されているようになる。

図示されているように、ＢｉＭフラグメントは主として４つのパートから成り、以下でこれらについて手短に説明する。第１のパートはいわゆる「ナビゲーションコマンド」であって、これは記述スキームのどのインスタンス化パートを次に受け取るかをデコーダに通知する。３種類のアドレッシング記述要素が可能である：
・デコーダが目下存在するノードに対し相対的なアドレッシング
・デコーダが目下存在するＤＳの目下のトップレベルノードに対する絶対的なアドレッシング
・ルートノードに対し相対的な絶対アドレッシング
ＢｉＭフラグメントとの次のパートはナビゲーションパスであって、つまりこれはデコーダがＢｉＭフラグメント中に含められる情報を受け取りたいツリーノードに関する絶対アドレスまたは相対アドレスである。トップレベルＤＳのアドレス（識別子またはＩＤとも称する）は８ｂｉｔのコードから成り、これは以下のテーブルで指定されている。ルートノードを離れてＭＰＥＧ−７ビットストリームを終わらせることができるよう、トップレベルＤＳ ＩＤに加えて、「イクジットルート "exit root "」コマンドを通知する特定のビットコードが存在する。トップレベルＤＳの後続のサブ要素（子）のためのアドレスはローカルパスコードを使用して計算され、以下の説明ではこれをツリーブランチコードとも称する。

ＢｉＭフラグメントの第３のパートはいわゆる「コンテントマニピュレーションコマンド "content manipulation command" 」であって、これはデコーダに対し、どの種類のコンテントマニピュレーションをナビゲーションによりたったいま送られたノードに対してデコーダが受け取るのかを通知する。この場合、３つの可能なコマンドが設けられており、つまりそれらのコマンドとはサブツリーの追加 "add"、サブツリーの更新 "update"、ならびにサブツリーの削除 "delete" である。サブツリーには、デコーダが目下存在するノード要素が含まれている。そしてコマンドが実行される。追加 "add" または更新 "update" の場合、サブツリーのコンテントはＢｉＭフラグメントの第４のコンポーネント内に含まれる。削除 "delete" の場合、ＢｉＭフラグメントの第４のコンポーネントは空である。コマンドが実行された後（つまりサブツリー情報がデコーディングされるかまたは既存のサブツリーが削除された後）、デコーダは暗黙的にその親のノードに戻る。

ＢｉＭフラグメントのコンテントマニピュレーションセクションは２つのパートから成り、すなわちそれらはコンテントマニピュレーションコマンドとサブツリーバイナリ表現である。ナビゲーションパスを含むナビゲーションコマンドの終了後、コンテントマニピュレーションコマンドを待つ。同様に、サブツリーのバイナリ表現を含むコンテントマニピュレーションコマンドの終了後、ナビゲーションコマンドを待ち、これは新たなＢｉＭフラグメントの開始である。デコーダの初期化時はカレントノードがルートノードにデフォルトとして設定され、ナビゲーションコマンドを待つ。ＢｉＭ中に定義されるコンテントマニピュレーションコマンドに関するコードテーブルを表１として以下に示す。

コマンドがカレントノードに適用される。ナビゲーション後のカレントノード（記述ツリー中の個々のポジション）は、ターミネーションＴＢＣ（図４参照）を除いて完全なナビゲーションパスにより参照されるノードである。この場合、コンテントマニピュレーションコマンド（追加 add、更新 update、削除 delete）は、カレントノード自身を含むサブツリーに適用される。コンテントマニピュレーションコマンドが発行された後、カレントノードがナビゲーション後のノードの父 father にセットされる。

コマンドコードテーブルには以下のコードが含まれている：
・AddSubtree：ツリー中のカレントポジションを含むサブツリーを追加。このコマンドに続いてサブツリー全体のバイナリ表現がくる。AddSubtree コマンドが発行された後、カレントノードがナビゲーション後のカレントノードの父 father にセットされる。
・UpdateSubtree：ツリー中のカレントポジションを含むサブツリーを更新。このコマンドに続いてサブツリー全体のバイナリ表現がくる。UpdateSubtree コマンドが発行された後、カレントノードがナビゲーション後のカレントノードの父 father にセットされる。
・DleteSubtree：ツリー中のカレントポジションを含むサブツリーを削除。DeleteSubtree コマンド発行後、カレントノードがナビゲーション後のカレントノードの父にセットされる。

カレントノードが単純型の要素または属性であるならば、コマンド直後にバイナリコンテント表現が続く。コマンド実行後、デコーダはナビゲーションモードに戻る。

ＢｉＭフラグメントのナビゲーションセクションは２つのパートに分割され、それらはすなわちナビゲーションコマンドとナビゲーションパスである。ナビゲーションコマンドは２ｂｉｔの固定ビット長であり、それに続いて可変長のナビゲーションパスが設けられる。ナビゲーションパスは連続的なツリーブランチコード（ＴＢＣ）から成り、そこにおいて各ＴＢＣは記述ツリー内部のあるノードにおけるパスのフラクションを記述する。したがってナビゲーションパスはローカルナビゲーションパスのシーケンスであり、これはツリーを通るパス中に含まれる各ノードにおけるツリーブランチを指定する（図６参照）。ナビゲーションコマンドによって、表２中で指定されているようにナビゲーションパスをどのように解釈すべきかを指定する。

ナビゲーションコマンドのパラメータでありビットストリーム中のナビゲーションコマンドコードに続く＜ＴＢＣ＞は、インスタンス化された記述のベースとなるＭＰＥＧ−７スキーマから生成される。スキーマ定義によって、種々のＴＢＣによりアドレッシングされるべき記述中の１つのノードの可能な子 children が指定される。スキーマ定義中、子の可能な型およびそれらの最大オカレンス数が指定される。個々の記述ノードに関してインスタンス化された要素内のツリーブランチに従い、ＴＢＣは子要素の仕様（SchemaBranch）および１回以上インスタンス化可能ならばポジションが含まれる。１つのナビゲーションパス全体は、連続的なツリーブランチコード（Tree Branch Code, TBC）の順序づけられたリストとして構成される。

コードテーブルおよびそのＴＢＣは、複合型 complexType の指定されたすべての要素または記述スキーム中の指定された複合型 complexType について固有のものである。したがってナビゲーションのために、インスタンス化された要素の型により使用されるコードテーブルも決定される。したがって同じ複合型のノードに関するすべての要素は同じコードテーブルを有する。１つのノードにおける各々の子要素および属性はそれを参照する符号語に割り当てられる。これらの符号語はツリーブランチコード(Tree-Branch-Code, TBC）と呼ばれ、以下で説明する規範的アルゴリズムにより記述スキームから生成される。

上述のようにＴＢＣは２つのパートによって構成されている。すなわち１つはスキーマブランチ SchemaBranch であって、これはスキーマ中で指定された種々の子要素の定義に対応し、もうひとつはポジションであって、これはスキーマ定義に従いこの子の多数のオカレンスが可能であるときにのみ存在する。記述ツリー内のナビゲーションのため、父のノードを参照するためのコードも設けられている。さらに、パスをターミネートしコマンドモードへ暗黙的にスイッチするためにコードが用いられる。表３にはこの種のコードテーブルのプロトタイプが示されている。

ＴＢＣの割り当ては下記のルールに従い実行される：
・種々の子の数は記述スキームから既知であり、これにより以下のルールに従いＴＢＣのスキーマブランチ SchemaBranch ビットフィールドの長さが定義される

・オール０のスキーマブランチ SchemaBranch コードは、父のノードへの参照に常に割り当てられる。
・子を参照するスキーマブランチコードは、ISO/IEC 15938 の個々のパートにおいて指定された指定されたその要素または型のスキーマ定義中に定義された順序でシーケンシャルに割り当てられる。
・オール１のスキーマブランチコードは、パスをターミネートしコマンドモードにスイッチするために常に使用される。
・１つの子が多数のオカレンスを持つことができるならば、フィールド＜#position＞により以下のルールに従いインスタンス化された記述中の子の個数が指定される：フィールド #position のビット表現は、スキーマ定義におけるmaxOccur の個数を表すために必要とされる最小ビット数である。このビット数が３を超えるならば、最初のビット（Ｅｘｔ）は４つのビットの拡張が存在するのかを指定する（図５参照）。この４つのビットは、以降で拡張が８ｂｉｔである点を除いて先行する４つのビットと同じセマンティクスをもち、その８ｂｉｔのうち最初のビットは拡張を通知するために予約されている。代替グループにグループ分けされた要素は付加的に、ＴＢＣの後の属性としてこの代替グループ内のアドレスをコーディングしなければならない（これは上述の例の図面には示されていない）。この付加的なコードは SubstGrpSelect と呼ばれる。代替グループ内の各要素は SubstGrpSelect に割り当てられる。要素を参照する SubstGrpSelect コードは、ゼロから始まってスキーマ定義中に定義された順序でシーケンシャルに割り当てられる。

単純型 simpleType の属性、要素および指定された単純型 simpleType は、１つのリーフテーブルによって表される。この種のリーフテーブルのプロトタイプを表４として示す。

１つのパスはＴＢＣを連結することによって作成される。リーフノードを除いてすべてのノードはその父への参照をもっているので、相対パスを使用するならば記述ツリー階層において上へ向かって動かすこともできる。

絶対ナビゲーションおよび相対ナビゲーションは、後続のコンテントマニピュレーションコマンドを適用するツリー構造内のインスタンスノードの位置決定を目的としている。絶対パスは、インスタンス構造のＭＰＥＧ−７記述ルートまたはカレントノードのトップレベルからターゲット要素までの経路を表すのに対し、相対パスは個々のノードのカレントポジションから始まるパスを指定しようというものである（図６参照）。

本発明はナビゲーションモードの拡張に係わるものであって、殊にいわゆるツリーブランチコードの方法論を拡張することに係わる。以下のセクションでこのことについて詳しく説明する。

マルチメディア記述スキームのための従来技術のバイナリフォーマットすなわちいわゆるＢｉＭによって、テキスト形式の記述をバイナリ形態で存在させることができる。たとえばＭＰＥＧ−７のような標準においてＤおよびＤＳのセットが確定されると、定義されたＤおよびＤＳは基本的にさらに拡張可能であるが、拡張されたＤまたはＤＳのセマンティクスはその作者しかわからない。それにもかかわらず、固有のＤとＤＳをたとえばＭＰＥＧ−７のＤおよびＤＳといっしょに使用する多くのアプリケーションにとって、両方の種類のために同じバイナリフォーマットを使用するのが非常に重要になる。原則的にＢｉＭは、ＭＰＥＧ−７のＤＤＬをベースとするかぎり、ＤとＤＳのどちらの種類にも使用することができる。しかし現行のＢｉＭをＭＰＥＧ−７のＤまたはＤＳに適用し、かつＭＰＥＧ−７のＤまたはＤＳをベースとする拡張されたＤＳにも適用すると、両方の事例において同一であるＤＳのパートであっても両方のＤＳのバイナリフォーマットが異なってしまう。図７にはその事例が示されている。この図には単純なＭＰＥＧ−７のＤＳと拡張されたＤＳが示されている。拡張されたＤＳは、１つのノード "DiCo" をノード "Lang" に加えることでＭＰＥＧ−７のＤＳから派生している。しかしながら各ノードに関するＴＢＣテーブルはその子の目下の個数に左右されるので、ノード "LaCo" のアドレスは両方の事例で異なる。つまりＭＰＥＧ−７の事例では（ノード "Clas" に対し相対的に）"010 001 111" となる。拡張されたＤＳについてアドレスは（ノード "Clas" に対し相対的に） "010 010 111" となる。ここでわかるように、拡張がなされているノードの子のアドレスは変わっており、したがってＭＰＥＧ−７のバイナリフォーマットのその部分も変化することになる。

本発明の利点は、まえもって定義されているＤＳたとえばＭＰＥＧ−７のＤＳと拡張されたＤＳの同一のパートにおけるバイナリフォーマットを同じままにしておく手段が得られるので、拡張パートに対するバイナリフォーマットのみしか異ならないようになる。このことはＢｉＭ中に「拡張ツリーブランチコード "extension tree branch code」を含ませることにより達成され、これによりこのコード以降はまえもって定義されたＤＳについてのいくつかの拡張が続くことになることが通知される。これにより拡張されたＤＳを２つのパートに分けることができる。この場合、一方のパートはベースのＤＳと同一であり、すなわちまえもって定義された（たとえばＭＰＥＧ−７の）ＤＳであり、拡張されたＤＳはこれをベースとしており、他方のパートはベースのＤＳについてＤＳの拡張を記述している。この場合、第１のパートは、１つまたは複数のＢｉＭフラグメントおよび第２のパートによって表すことができる。このようにすることで、拡張されたコードにおいてＭＰＥＧ−７と合致したパートを符号変換する必要なく抽出するのが非常に簡単になる。さらに、拡張されたＤＳのユーザにとって拡張ＤＳの一部分であるＭＰＥＧ−７のＤＳへのアクセスおよび利用も格段に簡単になり、この場合も内容全体を符号変換する必要がない。それぞれまったく異なるニーズをもつ多数のアプリケーションが存在するが、それらは部分的にＭＰＥＧ−７のＤＳを使用するけれども、それらのニーズを満たす目的でおそらくは拡張を望むであろうから、ＭＰＥＧ−７と非ＭＰＥＧ−７のＤＳの簡単なコンビネーションは将来、非常に重要になる。

本発明の全般的な着想は、「拡張ツリーブランチコード "extension tree branch code"」をＢｉＭに含めることであり、これによってこのコード後には拡張された事前に定義された（たとえばＭＰＥＧ−７などの）ＤＳの拡張パートが続くことが通知される。したがって以下で示すように、項目「拡張ツリーブランチコード "extension tree branch code"」が複合型のツリーブランチコードに関する表３に含められる。

指定された複合型または要素に対しこのようなＴＢＣテーブルを形成する目的で、ＴＢＣを割り当てるための本来のルールを以下のとおり変更する：
・種々の子の個数は記述スキームから知られており、以下のルールに従いＴＢＣにおける SchemaBranch ビットフィールドの長さが定義される。

・オール０の SchemaBranch コードは常に父のノードへの参照に割り当てられる。
・子を参照する SchemaBranch コードは、ISO/IEC 15938 の個々のパートにおいてこの指定された要素または型のスキーマ定義中で定義されている順序でシーケンシャルに割り当てられる。
・オール１のSchemaBranch コードは、パスのターミネーションおよびコマンドモードへのスイッチのために常に使用される。
・１つの子が複数のオカレンスをもつことができるならば、あるいは複数のオカレンスをもつことのできる拡張ＴＢＣであるならば、フィールド＜#position＞によって以下のルールに従いインスタンス化された記述中の子の数が指定される：フィールド #position のビット表現はスキーマ定義中の maxOccur の個数を表すのに必要とされる最小ビット数である。このビット数が３を超えたならば、最初のビット（Ｅｘｔ）は４ビットの拡張が存在するかを指定する（図５参照）。これら４つのビットは、それ以降は拡張が８ビットであり最初のビットは拡張を通知するために予約されている点を除いて、先行の４つのビットと同じである。

このように変更することで、まえもって定義された（たとえばＭＰＥＧ−７などの）ＤおよびＤＳのためにも、ＭＰＥＧ−７をベースとする拡張されたＤおよびＤＳのためにも、ＢｉＭを使用することができるようになり、さらに両方のＤＳにおいてＭＰＥＧ−７と合致したパートについてバイナリフォーマットを同じままに保つことができる。しかも、まえもって定義された（たとえばＭＰＥＧ−７などの）ＤおよびＤＳと拡張されたＤおよびＤＳのために、同じＢｉＭエンコーダおよびデコーダを使用することができる。図８には、ＭＰＥＧ−７ベースのＤＳと拡張されたパートの拡張されたＤＳインスタンスのツリー表現を描くことで、拡張ＴＢＣの利用に関する一例が描かれている。ここに示されているように、２つのサブツリーの各々を１つまたは複数のＢｉＭフラグメントによって表すことができる。しかしＭＰＥＧ−７と合致したＤＳのパートのＢｉＭフラグメントのフォーマットはＭＰＥＧ−７のＤＳ事態のものと同じである。

本発明の別の観点によれば、拡張ツリーブランチコードＴＢＣをポジションコードといっしょに使用することができる（たとえば表５を参照）。このポジションコードは何度も現れてよいＤＳノードの子の場合に使用される。表５に定義されているようにポジションコードがディスエーブル（表のエントリが "--"）である拡張ＴＢＣであれば、１つのＤＳノードにおいてただ１つの拡張ＴＢＣだけしか現れてはならない。オプションとしてポジションコードをイネーブルにすることもでき、そうすることで１つのＤＳノードにおいて２つ以上の拡張ＴＢＣが許可されるようになる。これはごく小さい変更しか生じないＤＳの拡張の事例に対して殊に有利である。図９にはやはり、個々の拡張ＤＳパートのツリー表現を描くことで多数の拡張ＴＢＣの一例が示されている。やはりすべてのサブツリーは１つまたは複数のＢｉＭフラグメントによって表現されており、ＭＰＥＧ−７のＤＳのＢｉＭフラグメントのフォーマットが保たれることになる。

本発明の別の観点によれば付加的または択一的に、ＭＰＥＧ−７固有の拡張ツリーブランチコード（ＴＢＣ）をツリーブランチコード（ＴＢＣ）テーブルに含めることができる。このＭＰＥＧ−７固有の拡張ＴＢＣを、将来のバージョン２，３等で定義される可能性の高いＭＰＥＧ−７標準のＤおよびＤＳの拡張に使用することができる。このようなＭＰＥＧ−７固有の拡張ＴＢＣを含めることによって、所定の範囲までＭＰＥＧ−７標準のフォワードコンパチビリティが許容される。ここでいうフォワードコンパチビリティとは、ＭＰＥＧ−７バージョン１のデコーダは、ＭＰＥＧ−７バージョン２＋のＤＳのうち少なくともＭＰＥＧ−７バージョン１のＤＳと合致した部分をデコーディングできるということである。さらに、既存のＭＰＥＧ−７バージョン１の内容をバージョン１のＤＳから派生した将来のＭＰＥＧ−７のＤＳに組み入れるのが非常に容易になる。

参考文献
［１］ ISO/IEC, "Introduction to MPEG-7", Doc. ISO/IEC JTC1/SC29/WG11 N3751, La Baule, France, October 2000.
［２］ ISO/IEC, "Text of ISO/IEC CD 15938-1 Information technology - Multimedia content description interface: Systems", Doc. ISO/IEC JTC1/SC29/WG11 N3701, La Baule, France, October 2000.
［３］ ISO/IEC, "Text of ISO/IEC CD 15938-2 Information technology - Multimedia content description interface: Description Definition Language", Doc. ISO/IEC JTC1/SC29/WG11 N3702, La Baule, France, October 2000.
［４］ ISO/IEC, "Text of ISO/IEC CD 15938-5 Information technology - Multimedia content description interface: Description Definition Language", Doc. ISO/IEC JTC1/SC29/WG11 N3705, La Baule, France, October 2000.

ある特定の例に関するＭＰＥＧ−７記述のツリー表現を示す図 ＭＰＥＧ−７記述のツリー表現の一例を示す図 ＢｉＭフラグメントの構造を示す図 ＢｉＭフラグメント内部の種々の状態に関するカレントモードのポジションを示す図 各要素に関するポジションのビット表現をオカレンスとともに示す図。 ６．ａはルートノードに関して絶対パスを示す図であり、６．ｂはトップレベルノードに関して絶対パスを示す図であり、６．ｃはカレントノードに関して相対パスを示す図 ＭＰＥＧ−７のＤＳと拡張ＭＰＥＧ−７のＤＳのツリー表現を示す図 あるＤＳノードにおいて単一の拡張ＴＢＣを使用する例を示す図 あるＤＳノードにおいて複数の拡張ＴＢＣを使用する例を示す図

Claims (6)

1. マルチメディアデータのバイナリ記述のための拡張コードを含むデータをデコーダによりデコーディングする方法において、
   前記マルチメディアデータは、記述要素として記述子（Ｄ）と記述スキーム（ＤＳ）から成り、拡張ツリーブランチコード（ＴＢＣ）がマルチメディアデータバイナリフォーマット（ＢｉＭ）に含められており、
   前記デコーダは該拡張ツリーブランチコード（ＴＢＣ）を検出し、該拡張ツリーブランチコード（ＴＢＣ）に基づき前記デコーダは、拡張された記述スキーム（ＤＳ）の２つに分割されたパートのうち一方のパートはまえもって定義されベースとなる記述スキーム（ＤＳ）と同一であり、他方のパートは前記拡張ツリーブランチコード（ＴＢＣ）以降に続くことになる拡張を記述していることを検出することを特徴とする、
   マルチメディアデータのバイナリ記述のための拡張コードをデコーダによりデコーディングする方法。
2. 前記まえもって定義されベースとなる記述スキーム（ＤＳ）はＭＰＥＧ−７の記述スキーム（ＤＳ）である、請求項１記載の方法。
3. 少なくとも前記一方のパートが前記マルチメディアバイナリフォーマット（ＢｉＭ）における１つまたは複数のＢｉＭフラグメントにより表され、該フラグメントにより拡張記述スキーム（ＤＳ）のうちＭＰＥＧ−７と合致したパートは、前記デコーダにより符号変換されることなく抽出される、請求項１または２記載の方法。
4. １つの記述スキーム（ＤＳ）のノードにおいて２つ以上の拡張を可能にするため、前記拡張ツリーブランチコード（ＴＢＣ）がポジションコードといっしょに使用される、請求項１から３のいずれか１項記載の方法。
5. ＭＰＥＧ−７標準の記述子（Ｄ）および記述スキーム（ＤＳ）の拡張を定義してフォワードコンパチビリティを可能にするために、ＭＰＥＧ−７固有の拡張ツリーブランチコード（ＴＢＣ）が含まれている、請求項１から４のいずれか１項記載の方法。
6. 拡張を伴うＭＰＥＧ−７のデータのためのバイナリフォーマットは、ナビゲーションコマンドとナビゲーションパスとコンテンツマニピュレーションコマンドとサブツリーバイナリ表現であって、
   前記デコーダは、前記ナビゲーションパスを含む前記ナビゲーションコマンドを実行し、記述スキーム（ＤＳ）のどのパートを次に受け取ることになるのかの情報を検出し、
   前記ナビゲーションパスは、前記デコーダがＭＰＥＧ−７データフォーマット中に含まれる情報を受け取るツリーノードのアドレスを表し、
   前記デコーダは、前記ナビゲーションコマンドの終了後、コンテンツマニピュレーションコマンドを待ち、
   前記デコーダは、前記サブツリーバイナリ表現を含む前記コンテンツマニピュレーションコマンドを実行し、前記サブツリーに対しどのようなコンテンツマニピュレーションを受け取るのかの情報を検出し、
   前記デコーダは、前記コンテンツマニピュレーションコマンドの終了後、ナビゲーションコマンドを待つ、
   請求項１から５のいずれか１項記載の方法。

Images