(57)【要約】【課題】  グラフィックデータ圧縮に関するメタ表現を用いた入力ファイルの生成方法およびシステムを提供する。【解決手段】  少なくとも圧縮する客体データに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子を定義しているXMLスキーマ240とを備える段階と、XML入力ファイル200をXMLスキーマ240を参照して所定のデータ圧縮符号化器（エンコーダ）250，260に入力されるファイルへの変換を支援するスタイルシート220，230を備える段階と、XML入力ファイル200をXMLスキーマ240及びスタイルシート220，230を参照してパーシングして所定のデータ圧縮符号化器（エンコーダ）250，260に入力されるファイルを生成する段階と、を含むことを特徴とする。【選択図】      図２
2007080274.tif 000002
【特許請求の範囲】
【請求項１】
圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子、及び少なくとも圧縮されたオブジェクトデータファイルの位置情報を含むBitWrapperEncodingHintsを定義しているＸＭＴスキーマを格納する段階と、
ＸＭＴ入力ファイルを取得する段階と、
前記ＸＭＴ入力ファイルを、前記ＸＭＴスキーマを含む情報を参照してパーシングして所定のデータ圧縮符号化器に入力されるファイルを生成する段階を含み、
前記圧縮ノードは、
圧縮するオブジェクトデータを含むノードフィールドと、
urlフィールドと相互排他的に使われ、ノードの圧縮されたビットストリームをイン−バンドとして伝送するバッファフィールドと、
前記バッファフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをアウト−バンドとして伝送するurlフィールドと、
ノード圧縮スキームの種類を示すタイプフィールドとを含み、
前記圧縮媒介因子は、
圧縮対象となるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、３次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子及び位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含み、
前記BitWrapperEncodingHintsは、
圧縮ノードのURL IDのようなオブジェクト記述ID情報及びmuxファイルが提供する圧縮されたビットストリームを伝送するファイル名とビットストリームのフォーマットの種類に関する情報とを含むこと、
を特徴とするグラフィックデータ圧縮に関するメタ表現を用いた入力ファイル生成方法。
【請求項２】
圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子、及び少なくとも圧縮された客体データファイルの位置情報を含むBitWrapperEncodingHintsを定義しているＸＭＴスキーマを格納する段階と、
ＸＭＴ入力ファイルを取得する段階と、
前記ＸＭＴ入力ファイルを、前記ＸＭＴスキーマを含む情報を参照してパーシングして所定のデータ圧縮符号化器に入力されるファイルを生成する段階を含み、
前記圧縮ノードは、
圧縮するオブジェクトデータを含むノードフィールドと、 
urlフィールドと相互排他的に使われ、ノードの圧縮されたビットストリームをイン−バンドとして伝送するバッファフィールドと、
前記バッファフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをアウト−バンドとして伝送するurlフィールドと、
ノード圧縮スキームの種類を示すタイプフィールドとを含み、
前記圧縮媒介因子は、
圧縮対象になるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、３次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子及び位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含み、
前記BitWrapperEncodingHintsは、
圧縮ノードのURL IDのようなオブジェクト記述ID情報及びmuxファイルが提供する圧縮されたビットストリームを伝送するファイル名とビットストリームのフォーマットの種類に関する情報を含み、
前記ＸＭＴ入力ファイルの圧縮ノードに、既に圧縮されたデータに対する情報及び前記既に圧縮されたデータが一時貯蔵されるバッファ情報が含まれる場合、前記既に圧縮されたデータのビットストリームを、前記バッファ情報を使って伝送すること、
を特徴とするグラフィックデータ圧縮に関するメタ表現により生成された入力ファイル伝送方法。
【請求項３】
圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子、及び少なくとも圧縮されたオブジェクトデータファイルの位置情報を含むBitWrapperEncodingHintsを定義しているＸＭＴスキーマを格納する段階と、
ＸＭＴ入力ファイルを取得する段階と、
前記ＸＭＴ入力ファイルを、前記ＸＭＴスキーマを含む情報を参照してパーシングして所定のデータ圧縮符号化器に入力されるファイルを生成する段階を含み、
前記圧縮ノードは、
圧縮するオブジェクトデータを含むノードフィールドと、
urlフィールドと相互排他的に使われ、ノードの圧縮されたビットストリームをイン−バンドとして伝送するバッファフィールドと、
前記バッファフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをアウト−バンドとして伝送するurlフィールドと、
ノード圧縮スキームの種類を示すタイプフィールドを含み、
前記圧縮媒介因子は、
圧縮対象となるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、３次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子及び位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含み、
前記BitWrapperEncodingHintsは、
圧縮ノードのURL IDのようなオブジェクト記述ID情報及びmuxファイルが提供する圧縮されたビットストリームを伝送するファイル名とビットストリームのフォーマットの種類に関する情報を含み、
前記ＸＭＴ入力ファイルの圧縮ノードに、既に圧縮されたデータに対する情報及びリンクされたＵＲＬ情報が含まれる場合、前記既に圧縮されたデータのビットストリームを、前記ＵＲＬ情報を使って伝送すること、
を特徴とするグラフィックデータ圧縮に関するメタン表現により生成された入力ファイル伝送方法。
【請求項４】
圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子、及び少なくとも圧縮されたオブジェクトデータファイルの位置情報を含むBitWrapperEncodingHintsを定義しているＸＭＴスキーマを格納する段階と、
ＸＭＴ入力ファイルを取得する段階と、
前記ＸＭＴ入力ファイルを、前記ＸＭＴスキーマを含む情報を参照してパーシングして所定のデータ圧縮符号化器に入力されるファイルを生成する段階を含み、
前記圧縮ノードは、
圧縮するオブジェクトデータを含むノードフィールドと、
urlフィールドと相互排他的に使われ、ノードの圧縮されたビットストリームをイン−バンドとして伝送するバッファフィールドと、
前記バッファフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをアウト−バンドとして伝送するurlフィールドと、
ノード圧縮スキームの種類を示すタイプフィールドを含み、
前記圧縮媒介因子は、
圧縮対象となるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、３次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子及び位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含み、
前記BitWrapperEncodingHintsは、
圧縮ノードのURL IDのようなオブジェクト記述ID情報及びmuxファイルが提供する圧縮されたビットストリームを伝送するファイル名とビットストリームのフォーマットの種類に関する情報を含み、
前記ＸＭＴ入力ファイルの圧縮ノードに、圧縮されていないオリジナルデータ、圧縮媒介因子、及びバッファ情報が含まれる場合、前記圧縮されていないオリジナルデータを、前記圧縮媒介因子を使って圧縮することにより得られるビットストリームを、前記バッファ情報を使って伝送すること、
を特徴とするグラフィックデータ圧縮に関するメタ表現により生成された入力ファイル伝送方法。
【請求項５】
圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子、及び少なくとも圧縮されたオブジェクトデータファイルの位置情報を含むBitWrapperEncodingHintsを定義しているＸＭＴスキーマを格納する段階と、
ＸＭＴ入力ファイルを受け入れる段階と、
前記ＸＭＴ入力ファイルを、前記ＸＭＴスキーマを含む情報を参照してパーシングして所定のデータ圧縮符号化器に入力されるファイルを生成する段階を含み、
前記圧縮ノードは、
圧縮するオブジェクトデータを含んでいるノードフィールドと、 
urlフィールドと相互排他的に使われ、ノードの圧縮されたビットストリームをイン−バンドとして伝送するバッファフィールドと、
前記バッファフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをアウト−バンドとして伝送するurlフィールドと、
ノード圧縮スキームの種類を示すタイプフィールドを含み、
前記圧縮媒介因子は、
圧縮対象になるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、３次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子及び位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含み、
前記BitWrapperEncodingHintsは、
圧縮ノードのURL IDのようなオブジェクト記述ID情報及びmuxファイルが提供する圧縮されたビットストリームを伝送するファイル名とビットストリームのフォーマットの種類に関する情報を含み、
前記ＸＭＴ入力ファイルの圧縮ノードに圧縮されていないオリジナルデータ、圧縮媒介因子、及びURL情報が含まれる場合、前記圧縮されていないオリジナルデータを、前記圧縮媒介因子を使って圧縮することにより得られるビットストリームを、前記ＵＲＬ情報を使って伝送すること、
を特徴とするグラフィックデータ圧縮に関するメタ表現により生成された入力ファイル伝送方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はグラフィックデータの制作に係り、特に、グラフィックデータの圧縮に関するメタ言語を用いた入力ファイルの生成方法およびシステムに関する。
【背景技術】
【０００２】
従来のXMT(eXtensible MPEG-4 Textual Format)技術は、例えば、2D・3Dグラフィック、オーディオ、ビデオ等に対するMPEG-4プリミティブ技術に対して、制作者の立場で容易にかつ 便利に取り扱えるように改良が加えられた技術である。また、従来のXMT技術は、MPEG-4プリミティブ技術に対し、作成したデータが複数のアプリケー ションにおいて再使用できるように、データの互換性および移植性に優れた設計が、コンテンツを制作するフレームワークに施されている。このような、従来の XMT技術における特性は、MPEG-4プリミティブに対して、XML(eXtensible markup Language)構文を定義することにより実現化したものである。
【０００３】
しかし、従来のXMT技術においては、3Dデータの圧縮表現を取り扱っておらず、3Dで作成されたアニメーションやコンテンツを圧縮させることができなかった。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明が解決しようとする技術的課題は、制作段階でグラフィックデータの圧縮を容易に取り扱うために、MPEG-4 AFXで提案された圧縮表現をXMTで定義することによって、グラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法およびシステムを提 供することである。
【課題を解決するための手段】
【０００５】
本発明は、前記した目的を達成するために創案されたものであり、
前記技術的課題を達成するための本発明によるグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法は、圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子、及び少なくとも圧縮されたオブジェクトデータファイルの位置情報を含むBitWrapperEncodingHintsを定義しているＸＭＴスキーマを格納する段階と、ＸＭＴ入力ファイルを取得する段階と、前記ＸＭＴ入力ファイルを、前記ＸＭＴスキーマを含む情報を参照してパーシングして所定のデータ圧縮符号化器に入力されるファイルを生成する段階を含み、前記圧縮ノードは、圧縮するオブジェクトデータを含むノードフィールドと、urlフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをイン−バンドとして伝送するバッファフィールドと、前記バッファフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをアウト−バンドとして伝送するurlフィールドと、ノード圧縮スキームの種類を示すタイプフィールドとを含み、前記圧縮媒介因子は、圧縮対象となるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、３次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子及び位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含み、前記BitWrapperEncodingHintsは、圧縮ノードのURL IDのようなオブジェクト記述ID情報及びmuxファイルが提供する圧縮されたビットストリームを伝送するファイル名とビットストリームのフォーマットの種類に関する情報とを含むことを特徴とする。
【０００６】
本発明のその他の態様は後記する実施の形態において説明する。
【発明の効果】
【０００７】
本発明によるグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法およびシステムによれば、制作者がメタ言語を使用して3Dコンテンツ 制作段階での3Dデータの表現および圧縮が可能である。さらに、制作者による圧縮の選択および調節が可能である。その方法はメタ言語の選択如何によって圧 縮の可否を決定しうる。また、メタ言語の表現方法を調節するので圧縮方式を調節することができる(encoding paramters，in-band/out-band scenario)。
【０００８】
そして、本発明を用い、XML基盤のMPEG-4プリミディブをツールとして制作した2D・3Dコンテンツは如何なるプラットホームのアプリケーションで も再使用が可能となる。また、制作段階で制作者が3Dデータを圧縮できるために、低いネットワーク帯域幅でも3Dグラフィックデータのリアルタイム視覚化 またはリアルタイムアニメーションを可能にする。そして、多様な3Dグラフィックデータを製作可能にする。
【発明を実施するための最良の形態】
【０００９】
以下、添付された図面を参照して本発明に係るグラフィックデータ圧縮に関するメタ言語を用いた入力ファイル生成システムについて詳細に説明する。
制作者が3次元データの圧縮を容易に実施可能にするためには、3次元データが表示、処理および圧縮される際に、関連するさまざまな因子を容易に調節する機能が必要である。そして、これら因子の調節はXMTを通じて可能である。このXMTは、オーディオ、ビデオ、2次元グラフィックおよび3次元グラフィック等のコンテンツ制作に用いられるMPEG-4をフレームワークとしている。
【００１０】
また、前記XMTは、テキスト構文を使用してシーンが記述されるMPEG-4をフレームワークとする。図3は、フレームワークを示す図である。このように、XMTはコンテンツ制作者に対し、制作者が作ったコンテンツをX3D(eXtensible3D)やSMIL(Synchronized Multimedia Integration Language)上で相互運用できるようにするツールおよびサービスを提供する。
【００１１】
図3に示すように、XMTフォーマットでは、SMILプレーヤー、VRMLプレーヤー、MPEG-4プレーヤーで相互に互換してプレーすることが可能となっている。図3について、さらに詳細に説明すれば、XMTフォーマットはパーシングされてSMILプレーヤーでプレーされる。そして、XMTフォーマットは、X3Dに対して、前処理を行った後にVRMLプレーヤーでプレーさせる。また、MPEG-4表現(mp4)にコンパイルした後に、MPEG-4プレーヤーでプレーさせる場合もある。
【００１２】
前記XMTはXMT-AフォーマットとXMT-Wフォーマットとの2段階構造から構成されている。前記XMT-Aとは、XML（eXtensible markup Language）を基盤としたMPEG-4コンテンツのバージョンであり、オーディオ、ビデオ、2D・3Dグラフィックデータ表現およびこれらの圧縮データならびに拡張された3Dグラフィック(X3D)を含むものである。また、XMT-Aフォーマットは、MPEG-4の特徴を明確にするために、さらに、MPEG-4を拡張したX3Dフォーマットも含んでいる。そして、XMT-Aでは、テキストフォーマットとバイナリフォーマットとが1:1の比率でマッピングされる。
【００１３】
前記XMT-Wフォーマットとは、SMILに基づくMPEG-4の上位ランクに位置付けされるものである。そして、コンテンツ制作者がXMTのメカニズムについて詳しくなくとも、XMT-WからXMT-Aにデフォルトマッピングすることを可能にするものである。このように、XMT-Wはコンテンツ製作者に、便利なインターフェース機能を提供する役目を果たす。一般に、MPEG-4データに関する表示、処理および圧縮に関することはXMT-Aフォーマットでなされる。
【００１４】
このように、制作者が3Dデータを圧縮する場合、制作者が3Dコンテンツを制作する段階から3Dデータを表現、操作および圧縮するのに必要な多様な因子を容易に調節できるように、圧縮に関連した技術をXMT-Aで定義し、これを使用してデータを圧縮可能にする。
【００１５】
すなわち、アニメーションデータおよび表現データにより制作された3Dコンテンツの圧縮は、MPEG-4 AFXで提案されている圧縮表現をXMTに対して定義することによって実現される。このような定義に基づいて制作者は、3Dデータを圧縮して、圧縮したデータを伝送する。そして、XMTフォーマットのパラメータで定義された、3Dデータ（アニメーションデータおよび表現データ）の圧縮データを得るのに必要な因子を得ることが可能となる。そして、本発明では、制作者が圧縮を表現するノードを用いて3Dデータの圧縮に必要な多様な因子をXMT-Aスキーマで定義する。
【００１６】
本発明では3Dデータの圧縮に用いられる多様な因子に対するメタ言語の表現方法を提供し、これを使用して圧縮を実行する。
図1は、本発明によるグラフィックデータ圧縮に関するメタ言語を用いた入力ファイル生成システムの構成を示すブロック図であって、XMLスキーマ120、スタイルシート130およびXMLパーサ110を含んでなる。前記XMLスキーマ120では、少なくとも圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子とを定義している。
【００１７】
前記スタイルシート130は、XML入力ファイル100の参照の下、XMLスキーマ120がデータ圧縮符号化器140に入力される所定のファイルへの変換される処理を支援する。前記XMLパーサ110は、XMLスキーマ120およびスタイルシート130の参照の下、XML入力ファイル100をパーシングしてデータ圧縮符号化器140に入力される所定のファイルを生成する。
【００１８】
図2は、図1に示されたグラフィックデータ圧縮に関するメタ言語を用いた入力ファイル生成システムの一例を示すブロック図である。図２は、MPEG-4 AFXで提案された圧縮表現をXMTに対して定義することで、メタ言語による入力ファイルを生成し、グラフィックデータを圧縮することを可能にしたシステムの構成が示されている。
【００１９】
前記グラフィックデータ圧縮に関するメタ言語を用いた入力ファイル生成システムは、XMTスキーマ240、XMT2BIFSスタイルシート230、XMT2MUXスタイルシート220、XMTパーサ210を含んでなる。XMTスキーマ240は、圧縮するオブジェクトデータに関する情報を含んでいる圧縮ノードと、圧縮に必要な圧縮媒介因子、および少なくとも圧縮されたオブジェクトデータファイルの位置情報を含むBitWrapperEncodingHintsを定義している。
【００２０】
XMT2BIFSスタイルシート230は、XMTスキーマ210の参照の下、XMT入力ファイル200をシーン（.scene）ファイルに変換する動作を支援する。そして、XMT2MUXスタイルシート220は、XMTスキーマ210の参照の下、XMT入力ファイル200をmuxファイルに変換する動作を支援する。次に、XMTパーサ210は、XMTスキーマ240、XMT2BIFSスタイルシート230およびXMT2MUXスタイルシート220に基づきXMT入力ファイル200をパーシングしてシーンファイルおよびmuxファイルを生成するものである。
【００２１】
前記圧縮ノードは、圧縮するオブジェクトデータを含むノードフィールドと、urlフィールドに対して相互に排他的に使用され前記ノードの圧縮されたビットストリームがイン-バンドとして伝送されるバッファフィールドと、このバッファフィールドに対して相互排他的に使用され前記ノードの圧縮されたビットストリームがアウト-バンドとして伝送されるurlフィールドと、を備える。
【００２２】
そして、前記圧縮媒介因子は、圧縮対象となるオブジェクトのあらゆる頂点座標に対するキーフレームアニメーションデータに関する媒介因子と、3次元メッシュ情報に関する媒介因子と、回転移動キーフレームアニメーションデータに関する媒介因子と、位置移動キーフレームアニメーションデータに関する媒介因子と、のうち少なくとも１つが選択されてなる。
前記BitWrapperEncodingHintsは圧縮ノードのURL IDのようなオブジェクト記述ID情報およびmuxファイルが提供する圧縮されたビットストリームを伝送するファイル名と、ビットストリームのフォーマットの種類に関する情報と、を備える。
【００２３】
図2に示す、グラフィックデータ圧縮に関するメタ言語を用いた入力ファイル生成システムをさらに詳細に説明する。まず、3Dデータを圧縮するノードとその媒介因子のXMT-Aスキーマを使用して圧縮を実行する方法および構造について説明する。
【００２４】
既存のXMT技術においては、3Dデータを圧縮する表現に関するXMT-Aスキーマが定義されていないために3Dデータ圧縮に関するXMTファイルが入力されてもパーシングすることができなかった。これに対し、本発明のXMT-Aスキーマ240（図2）は、3Dデータを圧縮する圧縮ノードの定義およびその媒介因子を含んでいる。
【００２５】
このため、XMTパーサ210は、入力したXMT入力ファイル200を、XMT-Aスキーマ240、XMT2MUXスタイルシート220およびXMT2BIFSスタイルシート230に基づいて3Dデータ圧縮が定義された圧縮ノードにより、パーシングする。そして、生成した入力ファイルをMPEG-4標準符号化器に出力する。
なお、このMPEG-4標準符号化器はBIFSエンコーダ250とMP4エンコーダ260とで構成されている。そして、生成した前記入力ファイルが、各々BIFSエンコーダ250およびMP4エンコーダ260に入力すると、ビットストリーム(.mp4)を生成し、MPEG-4プレーヤーで視覚化され視聴される。
【００２６】
3Dデータを圧縮するノードと、その媒介因子であるメタ言語すなわちXMT-Aスキーマとを使用するか否かにより、圧縮を行うかあるいは行わないかの判断が、制作段階における制作者のメタ言語の選択如何にゆだねられることになる。そして、3Dデータに対して圧縮を実行する場合は、圧縮媒介因子としてメタ言語を適用することになる。
【００２７】
制作者が３Dデータを圧縮する場合、この3Dデータは、その媒介因子の調節方法によって大きく2種に分類され、何れかの方法を選択して伝送されることになる。第1の方法は、オリジナルデータを圧縮してビットストリームに伝送する方法で、第2の方法は、既に圧縮されたビットストリームを含めて伝送する方法である。
【００２８】
前記2種の方法はさらに細分化されて、以下に示す4種の伝送方法となり、制作者はこれらのうち何れかの伝送方法を選択することができる。第1の方法は、オリジナルデータを、媒介因子を使用してビットストリームに圧縮し、バッファを使用して伝送する方法である。第2の方法は、オリジナルデータが、既に圧縮されたビットストリームにより、バッファを使用して伝送する方法である。第３の方法は、媒介因子を用いてオリジナルデータをビットストリームに圧縮しURLにより伝送する方法である。第４の方法は、既に圧縮されたビットストリームがURLにより伝送される方法である。
【００２９】
次に、3Dデータ圧縮に使われる多様な因子に対するメタ言語の表現方法(XMT)について説明する。このメタ言語の表現方法は、3Dデータの圧縮に必要なノードおよびその媒介因子をメタ言語にする方法である。ここで、3Dデータの圧縮に必要なノードのBitWrapperノードとその媒介変数について実例を挙げて説明する。
【００３０】
1. BitWrapperノードに対するXMT-Aスキーマ
1.1 BitWrapperノードのBIFS構文(Syntax)
BitWrapper { #%NDT=SF2DNode,SF3DNode,SFGeometryNode 
Field  SFWorldNode   node    NULL 
Field  SFInt32         type      0 
Field  MFUrl           url       [] 
Field  SFString        buffer     "" 
}
【００３１】
まず、BitWrapperについて簡単に説明する。BitWrapperノードの機能は"node"フィールドのデータを圧縮し、このビットストリームをイン-バンドまたはアウト-バンドを使用して伝送することである。"url"フィールドはアウト-バンドビットストリームを伝送し、"バッファ"フィールドはBIFSビットストリームのようにイン-バンドビットストリームを伝送する。
【００３２】
もし、制作者がデータを圧縮してBitWrapperノードを通じて伝送しようとすれば、制作者はビットストリームを生成するための媒介因子を調節することになる。この媒介因子の調節は、XMT-Aスキーマ構文（Syntax）により可能となる。しかし、特定のエンコード構文（Syntax）を除き、デコード構文（Syntax）は、データ圧縮の最中に調節可能な媒介因子として関連付けされている。現在のBitWrapperノードでは、7個の圧縮ツールを使用して圧縮されたビットストリームの伝送がサポートされている。
【００３３】
次に、BitWrapperノードと、3つの3次元キーフレームアニメーションデータ(CoordinateInterpolator、OrientationInterpolator、PositionInterpolator)ノードの媒介因子と、3次元メッシュ情報(IndexedFaceSet)ノードの媒介因子と、に関するXMT-Aスキーマ構文を説明する。
【００３４】
1.2 BitWrapperノードに関するXMT-Aスキーマ
1.2.1 Syntax（構文）
<?xml version="1.0" encoding="UTF-8"?> 
<schema xmlns="http://www.w3.org/2001/XMLSchema" 
xmlns:xmta="urn:mpeg:mpeg4:xmta:schema:2002" 
targetNamespace="urn:mpeg:mpeg4:xmta:schema:2002" 
elementFormDefault="qualified"> 
<element name="BitWrapper"> 
<complexType> 
<element name="node"    minOccurs="0"      form="qualified"> 
<complexType> 
<group ref="xmta:SFWorldNodesType"     minOccurs="0"/> 
</complexType> 
</element> 
<choice> 
<element name="CoordinateInterpolatorEncodingParameter"   minOccurs="0" maxOccurs="1"> 
<complexType> 
<attribute name="keyQbits"   "type="xmta:numOfKeyQBits"   use="optional" default="8"/> 
<attribute   name="keyValueQBits"    type="xmta:numOfKeyValueQBits     use="optional" default="16"/> 
<attribute   name="transpose"   type="xmta:transposeType"    use="optional" default="&quot;ON&quot;"/> 
<attribute   name="linearKeycoder"   type="xmta:linearKeycoderType"    use="optional" default="&quot;LINEAR&quot;"/> 
</complexType> 
</element> 
<element name="IndexedFaceSetEncodingParameter"  minOccurs="0" maxOccurs="1"> 
<complexType> 
<attribute   name="coordQBits"  type="xmta:numOfCoordQBits"  use="optional" default="10"/> 
<attribute   name="normalQBits" type="xmta:numOfNormalQBits" use="optional" default="9"/> 
<attribute   name="colorQBits"  type="xmta:numOfColorQBits"  use="optional" default="6"/> 
<attribute   name="texCoordQBits"    type="xmta:numOftexCoordQBits"    use="optional" default="10"/> 
<attribute  name="coordPredMode"   type="xmta:coordPredType"   use="optional" default="2"/> 
<attribute   name="normalPredMode"   type="xmta:normalPredType"   use="optional" default="0"/> 
<attribute   name="colorPredMode"   type="xmta:colorPredType"    use="optional" default="0"/> 
<attribute   name="texCoordPredMode" type="xmta:texCoordPredType" use="optional" default="0"/> 
<attribute   name="errorResilience"  type="xmta:errorResilienceType"   use="optional" default="&quot;OFF&quot;"/> 
<attribute  name="bitsPerPacket"   type="xmta:SFInt32" use="optional" 
default="360"/> 
<attribute name="boundaryPrediction"  type="xmta:boundaryPredictionType"     use="optional" default="0"/> 
</complexType> 
</element> 
<element name="OrientationInterpolatorEncodingParameter"  minOccurs="0" maxOccurs="1"> 
<complexType> 
<attribute   name="keyQBits"     type="xmta:numOfKeyQBits"    use=
"optional" default="8"/> 
<attribute  name="keyValueQBits"   type="xmta:numOfKeyValueQBits"    use="optional" default="16"/> 
<attribute   name="preservingMode"   type="xmta:preservingType"  use="optional" default="&quot;KEY&quot;"/> 
<attribute   name="dpcmMode"     type="xmta:orientationDpcmType"   use="optional" default="0"/> 
<attribute   name="aacMode_X"   type="xmta:aacType" use="optional" default="&quot;BINARY&quot;"/> 
<attribute   name="aacMode_Y"   type="xmta:aacType" use="optional" default="&quot;BINARY&quot;"/> 
<attribute   name="aacMode_Z"   type="xmta:aacType" use="optional" default="&quot;BINARY&quot;"/> 
<attribute   name="linearKeycoder"   type="xmta:linearKeycoderType"    use="optional" default="&quot;LINEAR&quot;"/> 
</complexType> 
</element> 
<element name="PositionInterpolatorEncodingParameter" minOccurs="0" 
maxOccurs="1"> 
<complexType> 
<attribute   name="keyQBits"     type="xmta:numOfKeyQBits"    use=
"optional" default="8"/> 
<attribute   name="keyValueQBits"   type="xmta:numOfKeyValueQBits”use="optional" default="16"/> 
<attribute  name="preservingMode"   type="xmta:preservingType"   use="optional" default="&quot;KEY&quot;"/> 
<attribute  name="dpcmMode_X"  type="xmta:positionDpcmType" use="optional" default="0"/> 
<attribute  name="dpcmMode_Y"  type="xmta:positionDpcmType" use="optional" default="0"/> 
<attribute  name="dpcmMode_Z"  type="xmta:positionDpcmType" use="optional" default="0"/> 
<attribute  name="aacMode_X"   type="xmta:aacType" use="optional" default="&quot;BINARY&quot;"/> 
<attribute  name="aacMode_Y"   type="xmta:aacType" use="optional" default="&quot;BINARY&quot;"/> 
<attribute  name="aacMode_Z"   type="xmta:aacType" use="optional" default="&quot;BINARY&quot;"/> 
<attribute  name="linearKeycoder"   type="xmta:linearKeycoderType"    use="optional" default="&quot;LINEAR&quot;"/> 
<attribute  name="intra_X"   type="xmta:intraType"    use="optional" 
default="0"/> 
<attribute  name="intra_Y" type="xmta:intraType"   use="optional" 
default="0"/> 
<attribute  name="intra_Z" type="xmta:intraType"   use="optional" 
default="0"/> 
</complexType> 
</element> 
<element name="WaveletSubdivisionSurfaceEncodingParameter" > 
</element> 
<element name="MeshGridEncodingParameter" > 
</element> 
</choice> 
<attribute     name="type"    type="xmta:SFInt32" use="optional" default="0"/> 
<attribute     name="buffer" type="xmta:SFString"    use="optional" /> 
<attribute     name="url"     type="xmta:MFUrl"  use="optional" /> 
<attributeGroup ref="xmta:DefUseGroup"/> 
<complexType> 
</element>                          
</schema> 
【００３５】
1.2.2. Semantics（意味）
BitWrapperノードはノード圧縮スキーム専用である。圧縮されたデータはBIFSストリーム内で伝送されるか、外部の分離されたストリームに伝送される。ストリームがBIFSアップデート内で伝送される時、"バッファ"フィールドは圧縮データを含む。ストリームがBIFSアップデート外部の分離されたストリームに伝送される時、"url"フィールドはストリームのURLを含む。
【００３６】
"バッファ"フィールドと"url"フィールドとは相互排他的に使われる。すなわち、"バッファ"フィールドが使われれば"url"フィールドは使われず、"url"フィールドが使われれば"バッファ"フィールドは使われない。"node"フィールドは圧縮データとして表現されたノードを含む。BitWrapperノードは"node"の位置で使われうる。"type"フィールド（タイプフィールド）はノード圧縮スキームが使われねばならないことを示している。"type"フィールド値のデフォルト値は0である。"type"フィールド値は、将来的なノード圧縮スキーム開発の可能性を鑑みながら決定される値である。このようにしてデフォルトスキームが定義される。
【００３７】
"CoordinateInterpolatorEncodingParameter”フィールドはオブジェクトのあらゆる頂点座標に対するキーフレームアニメーションデータ(CoordinateInterpolatorノードデータ)を圧縮するために使われる媒介因子を定義する。この場合、"node"フィールドはCoordinateInterpolatorノードである。
【００３８】
"IndexedFaceSetEncodingParameter”フィールドは3次元メッシュ情報(IndexedFaceSetノードデータ)の圧縮に使われる媒介因子を定義する。この場合に"node"フィールドはIndexedFaceSetノードである。
【００３９】
"OrientationInterpolatorEncodingParameter”フィールドは回転移動キーフレームアニメーションデータ(OrientationInterpolatorノードデータ)を圧縮するために使われる媒介因子を定義する。この場合に"node"フィールドはOrientationInterpolatorノードである。
【００４０】
"PositionInterpolatorEncodingParameter”フィールドは位置移動キーフレームアニメーションデータ(PositionInterpolatorノードデータ)を圧縮するために使われる媒介因子を定義する。この場合に"node"フィールドはPositionInterpolatorノードである。
【００４１】
データ圧縮の際に媒介因子を使用しない場合は、必ずしも媒介因子がファイル中に明示される必要はない。媒介因子を使用して圧縮が実行される場合は、媒介因子フィールドは排他的に使われるべきである。その理由は、"node"フィールドが一回に圧縮されるノードデータのうち、１つ類型だけを含むことによる。また、媒介因子フィールドが"<choice>"エレメントでグルーピングされていることにもよる。各パラメータフィールドの"attribute"は次の節で説明する。
【００４２】
圧縮して表現されたデータが、分離されたストリームに含まれて伝送される時、ノードデコーダは所定の枠に合わせて定義されるべきである。オブジェクト記述子ストリームにおいてノードデコーダはstreamType 0x03とobjectTypeIndication 0x05を参照しつつ、DecoderConfig descriptorの中で定義されなければならない。デコーダはAFXConfigdescriptorで形成される。
【００４３】
1.3. numOfKeyQBits
1.3.1 Syntax（構文）
<simpleType name="numOfKeyQBits"> 
<restriction base="int"> 
<minInclusive value="0"/> 
<maxInclusive value="31"/> 
</restriction> 
</simpleType> 
【００４４】
1.3.2 Semantics（意味）
numOfKeyQBitsはkeyデータの量子化ビットサイズを示す。これは整数タイプである。numOfKeyQBitsの最小値は0であり最大値は31である。
【００４５】
1.4 numOfKeyValueQBits
1.4.1 Syntax（構文）
<simpleType name="numOfKeyValueQBits"> 
<restriction base="int"> 
<minInclusive value="0"/> 
<maxInclusive value="31"/> 
</restriction> 
</simpleType> 
【００４６】
1.4.2 Semantics（意味）
numOfKeyValueQBitsはkeyValueデータの量子化ビットサイズを示す。これは整数タイプである。numOfKeyQBitsの最小値は0であり、最大値は31である。
【００４７】
1.5 linearKeycoderType
1.5.1 Syntax（構文）
<simpleType name="linearKeycoderType"> 
<restriction base="string"> 
<enumeration value="&quot;LINEAR&quot;"/> 
<enumeration value="&quot;NOLINEAR&quot;"/> 
</restriction> 
</simpleType> 
【００４８】
1.5.2 Semantics（意味）
linearKeycoderTypeはストリングタイプである。linearKeycoderTypeはlinear key coderの使用有無を示す。
【００４９】
1.6 preservingType
1.6.1 Syntax（構文）
<simpleType name="preservingType"> 
<restriction base="string"> 
<enumeration value="&quot;KEY&quot;"/> 
<enumeration value="&quot;PATH&quot;"/> 
</restriction> 
</simpleType> 
【００５０】
1.6.2 Semantics（意味）
preservingTypeはストリングタイプである。preservingTypeは現在モードがkeypreservingモードか、pathpreservingモードかを示す。
【００５１】
1.7 aacType
1.7.1 Syntax（構文）
<simpleType name="aacType"> 
<restriction base="string"> 
<enumeration value="&quot;BINARY&quot;"/> 
<enumeration value="&quot;UNARY&quot;"/> 
</restriction> 
</simpleType> 
【００５２】
1.7.2 Semantics（意味）
aacTypeはストリングタイプである。aacTypeは各keyValueコンポーネントX，Y，Zに対して現在のモードがBinaryAACモードか、UnaryAACモードかを示す。
【００５３】
1.8 orientationDpcmType
1.8.1 Syntax（構文）
<simpleType name="orientationDpcmType"> 
<restriction base="int"> 
<enumeration value="1"/> 
<enumeration value="2"/> 
</restriction> 
</simpleType> 
【００５４】
1.8.2 Semantics（意味）
orientationDpcmTypeが各keyValueコンポーネントX，Y，Zに対して使われたDPCM次数を示す。これは整数タイプである。もし、DPCM次数が"1"であればフラグが0にセットされる。DPCM次数が"2"であれば1にセットされる。
【００５５】
1.9 positionDpcmType
1.9.1 Syntax（構文）
<simpleType name="positionDpcmType”> 
<restriction base="int"> 
<enumeration value="0"/> 
<enumeration value="1"/> 
<enumeration value="2"/> 
</restriction> 
</simpleType> 
【００５６】
1.9.2 Semantics（意味）
positionDpcmTypeは各keyValueコンポーネントX，Y，Zに対して使われたDPCM次数を示す。これは整数タイプである。DPCM次数が"1"であればフラグは0にセットされる。DPCM次数が"2"であれば1にセットされる。SADが使われれば2にセットされる。SADは[2]に詳細に説明されている。
【００５７】
1.10 intraType
1.10.1 Syntax（構文）
<simpleType name="intraType"> 
<restriction base="int"> 
<enumeration value="0"/> 
<enumeration value="1"/> 
</restriction> 
</simpleType> 
【００５８】
1.10.2 Semantics（意味）
intraTypeはPositionInterpolatorCompressionに使われる。intraTypeは各keyValueコンポーネントX，Y，Zに対してintra codingモードの使用有無を示す。
【００５９】
1.11 transposeType
1.11.1 Syntax（構文）
<simpleType name="transposeType"> 
<restriction base="string"> 
<enumeration value="&quot;ON&quot;"/> 
<enumeration value="&quot;OFF&quot;"/> 
</restriction> 
</simpleType> 
【００６０】
1.11.2 Semantics（意味）
transposeTypeはtransposeモードまたはvertexモードに対するフラグである。もし、valueが"ON"にセットされたならば、transposeモードが使われ、そうでなければvertexモードが使われる。
【００６１】
1.12 numOfCoordQBits
1.12.1 Syntax（構文）
<simpleType name="numOfCoordQBits"> 
<restriction base="int"> 
<minInclusive value="1"/> 
<maxInclusive value="24"/> 
</restriction> 
</simpleType> 
【００６２】
1.12.2 Semantics（意味）
numOfCoordQBitsはgeometryに対する量子化ステップを示す。numOfCoordQBitsの最小値が1であり、最大値は24である。
【００６３】
1.13 numOfNormalQBits
1.13.1 Syntax（構文）
<simpleType name="numOfNormalQBits"> 
<restriction base="int"> 
<minInclusive value="3"/> 
<maxInclusive value="31"/> 
</restriction> 
</simpleType> 
【００６４】
1.13.2 Semantics（意味）
numOfNormalQBitsはnormalに対する量子化ステップを示す。numOfNormalQBitsの最小値が3であり、最大値は31である。
【００６５】
1.14numOfColorQBits
1.14.1 Syntax（構文）
<simpleType name="numOfColorQBits"> 
<restriction base="int"> 
<minInclusive value="1"/> 
<maxInclusive value="16"/> 
</restriction> 
</simpleType> 
【００６６】
1.14.2 Semantics（意味）
numOfColorQBitsはcolorに対する量子化ステップを示す。numOfColorQBitsの最小値が1であり、最大値は16である。
【００６７】
1.15 numOfTexCoordQBits
1.15.1 Syntax（構文）
<simpleType name="numOftexCoordQBits"> 
<restriction base="int"> 
<minInclusive value="1"/> 
<maxInclusive value="16"/> 
</restriction> 
</simpleType> 
【００６８】
1.15.2 Semantics（意味）
NumOftexCoordQBitsはtexturecoordinatesに対する量子化ステップを示す。NumOftexCoordQBitsの最小値が1であり、最大値は16である。
【００６９】
1.16 coordPredType
1.16.1 Syntax（構文）
<simpleType name="coordPredType"> 
<restriction base="int"> 
<enumeration value="0"/> 
<enumeration value="2"/> 
</restriction> 
</simpleType> 
【００７０】
1.16.2 Semantics（意味）
CoordPredTypeはメッシュのvertex coordinatesを再構成するために使われるprediction typeである。no_predictionが使われれば、CoordPredType値は0にセットされる。parallelogram_predictionが使われれば、2にセットされる。
【００７１】
1.17 normalPredType
1.17.1 Syntax（構文）
<simpleType name="normalPredType"> 
<restriction base="int"> 
<enumeration value="0"/> 
<enumeration value="1"/> 
<enumeration value="2"/> 
</restriction> 
</simpleType> 
【００７２】
1.17.2 Semantics（意味）
NormalPredTypeはいかにnormalvaluesが予測(predict)されるかを示す。no_predictionが使われれば、値が0にセットされ、tree_predictionが使われれば1にセットされ、parallelogram_predictionが使われれば2にセットされる。
【００７３】
1.18 colorPredType
1.18.1 Syntax（構文）
<simpleType name="colorPredType"> 
<restriction base="int"> 
<enumeration value="0"/> 
<enumeration value="1"/> 
<enumeration value="2"/> 
</restriction> 
</simpleType> 
【００７４】
1.18.2 Semantics（意味）
colorPredTypeはいかにcolorsが予測されるかを示す。no_predictionが使われれば、値が0にセットされ、tree_predictionが使われれば1にセットされ、parallelogram_predictionが使われれば2にセットされる。
【００７５】
1.19 texCoordPredType
1.19.1 Syntax（構文）
<simpleType name="texCoordPredType"> 
<restriction base="int"> 
<enumeration value="0"/> 
<enumeration value="2"/> 
</restriction> 
</simpleType> 
【００７６】
1.19.2 Semantics（意味）
texCoordPredTypeはいかにcolorsが予測されるかを示す。no_predictionが使われれば、値は0にセットされ、parallelogram_predictionが使われれば2にセットされる。
【００７７】
1.20 errorResilienceType
1.20.1 Syntax（構文）
<simpleType name="errorResilienceType"> 
<restriction base="string"> 
<enumeration value="&quot;ON&quot;"/> 
<enumeration value="&quot;OFF&quot;"/> 
</restriction> 
</simpleType>
【００７８】
1.20.2 Semantics（意味）
ErrorResilienceTypeはエラー強靭性(Error Resilience)モードが使われたかを示す。エラー強靭性が使われないと"OFF"にセットされ、エラー強靭性が使われれば"ON"にセットされる。もし、""ON"になった場合にのみboundaryPredictionTypeとbitsPerPacketとが使われうる。
【００７９】
1.21 boundaryPredictionType
1.21.1Syntax（構文）
<simpleType name="boundaryPredictionType"> 
<restriction base="int"> 
<enumeration value="0"/> 
<enumeration value="1"/> 
</restriction> 
</simpleType> 
【００８０】
1.21.2 Semantics（意味）
BoundaryPredictionTypeはboundarypredictionのタイプを示す。値が0であれば制限された予測が使われ、値1が使われるならば拡張予測が使われる。
【００８１】
1.22 bitsPerPacket
1.22.1 Syntax（構文）
bitsPerPacketの構文はSFInt32タイプと同一である。
<simpleType name="SFInt32"> 
<restriction base="int"/> 
</simpleType>
【００８２】
1.22.2 Semantics（意味）
BitsPerPacketはエラー強靭ビットストリームに対するパケットサイズを示す。この値はエラー強靭モードで各部分の大きさを決定する。bitsPerPacketのタイプはSFInt32である。デフォルト値は360である。
【００８３】
2. BitWrapperEncodingHintsに対するXMT-Aスキーマ
2.1. BitWrapperEncodingHints
2.1.1. Syntax（構文）
次はBitWrapperEncodingHintsの構文である。
【００８４】
<!-- Declaration of BitWrapperEncodingHints --> 
<element name="StreamSource"> 
<complexType> 
<choice minOccurs="0" maxOccurs="unbounded"> 
<element ref="xmta:BitWrapperEncodingHints"/> 
</choice> 
... 
</complexType> 
</element> 
・.. 
<!-- Definition of BitWrapperEncodingHints --> 
<element name="BitWrapperEncodingHints"> 
<complexType>      
<element name="BitWrapper3DMCEncodingHints"> 
<complexType> 
<sequence> 
<element name="sourceFormat"> 
<complexType> 
<sequence> 
<element ref="xmta:param" minOccurs="0" maxOccurs=
"unbounded"/> 
</sequence> 
</complexType> 
</element> 
<element name="targetFormat"> 
<complexType> 
<sequence> 
<element ref="xmta:param" minOccurs="0" maxOccurs=
"unbounded"/> 
</sequence> 
</complexType> 
</element> 
</sequence> 
</complexType> 
</element> 
<element name="BitWrapperICEncodingHints"> 
<complexType> 
<sequence> 
<element name="sourceFormat"> 
<complexType> 
<sequence> 
<element ref="xmta:param" minOccurs="0" maxOccurs=
"unbounded"/> 
</sequence> 
</complexType> 
</element> 
<element name="targetFormat"> 
<complexType> 
<sequence> 
<element ref="xmta:param" minOccurs="0" maxOccurs=
"unbounded"/> 
</sequence> 
</complexType> 
</element> 
</sequence> 
</complexType> 
</element>                
<element name="OthersEncodingHints"> 
... 
</element> 
</complexType> 
</element> 
【００８５】
2.1.2. Semantics（意味）
BitWrapperEncodingHintsはスクリプト(.mux)ファイルで"MuxInfo"descriptionを明確にするために使われる。その結果、BitWrapperEncodingHintsのフォーマットは、バイナリテキストのフォーマットに一致する。BitWrapperノードがその中にある"url"フィールドを用いて、アウト-バンドシナリオに対して使われる。BitWrapperEncodingHintsはストリームのフォーマットのタイプに係る"MuxInfo"descriptionに使われる適切な情報を説明している。
【００８６】
3.XMT2MUXスタイルシートにBitWrapperEncodingHintsに対する修正
次はXMT2MUXスタイルシートにMuxInfoとBitWrapperEncodingHints構文を次のように修正した。
【００８７】
3.1 Syntax（構文）
元の構文は次のようである。
<xsl:template match="xmt:StreamSource"> muxInfo { 
fileName <xsl:value-of select="@url"/><xsl:text> 
<!-- what to do for urls? --> 
</xsl:text> 
<!-- if no encoding hints are given, it is assumed the stream is of type BIFS. otherwise 
the streamFormat should be declared in the parameter element of sourceFormat or targetFormat 
(name 'streamFormat' and value corresponding to a streamFormat recognised by BIFSEnc) --> 
<xsl:if test="not(xmt:EncodingHints)">streamFormat BIFS<xsl:text> 
</xsl:text></xsl:if> 
<xsl:apply-templates select="xmt:EncodingHints|xmt:BIFSEncodingHints|xmt:FBAEncodingHints"/> 
} 
</xsl:template> 
【００８８】
修正された構文は次の通りである。
<xsl:template match="xmt:StreamSource"> muxInfo MuxInfo{ 
fileName <xsl:value-of select="@url"/> 
<xsl:apply-templates select="xmt:EncodingHints|xmt:BIFSEncodingHints|xmt:FBAEncodingHints|xmt:
BitWrapperEncodingHints"/> 
<xsl:if
test="not(xmt:EncodingHints|xmt:BitWrapperEncodingHints)">streamFormat BIFS<xsl:text> 
</xsl:text></xsl:if> 
<xsl:if test="xmt:BitWrapperEncodingHints"><xsl:text> 
</xsl:text></xsl:if> 
<xsl:apply-templates select="xmt:BitWrapper3DMCEncodingHints|xmt:BitWrapperICEncodingHints|xmt:OthersEncodingHints"/> 
} 
<xsl:template match="xmt:BitWrapperEncodingHints"> 
<xsl:apply-templates select="xmt:BitWrapper3DMCEncodingHints|xmt:BitWrapperICEncodingHints|xmt:
OthersEncodingHints"/> 
<xsl:apply-templates select="xmt:sourceFormat|xmt:targetFormat"/> 
</xsl:template> 
<xsl:template match="xmt:BitWrapper3DMCEncodingHints"> 
<xsl:apply-templates select="xmt:sourceFormat|xmt:targetFormat"/> 
streamFormat 3DMC<xsl:text> 
</xsl:text> 
</xsl:template> 
<xsl:template match="xmt:BitWrapperICEncodingHints"> 
<xsl:apply-templates select="xmt:sourceFormat|xmt:targetFormat"/> 
streamFormat InterpolatorCompression<xsl:text> 
</xsl:text> 
</xsl:template> 
<xsl:template match="xmt:OthersEncodingHints"> 
<xsl:apply-templates select="xmt:sourceFormat|xmt:targetFormat"/> 
streamFormat BIFS<xsl:text> 
</xsl:text> 
</xsl:template> 
<xsl:template match="xmt:sourceFormat"> 
<xsl:apply-templates select="xmt:param"/> 
</xsl:template> 
<xsl:template match="xmt:targetFormat"> 
<xsl:apply-templates select="xmt:param"/> 
</xsl:template> 
</xsl:template> 
【００８９】
3.2 semantics（意味）
オリジナルの構文では、MP4エンコーダに伝送されるビットストリームに対するmux情報(ビットストリームの名称および種類、例えば、A.bifs，A.od)がXMT2MUXスタイルシートにおいて正しく記述されていない。また、BitWrapperでURLを使用する場合、URLを通じて伝送されるビットストリームに関する情報(ファイル名（実施例3に示すような"bunny-15000-tcp.m3d"）、ビットストリームの種類)が、XMT2MUXスタイルシートにおいて明確にされていない。そのかわり、XMT2MUXスタイルシートには、BitWrapperで定義されたビットストリームを運搬するファイル名とビットストリームの種類とが記述されている。具体的に3次元アニメーションデータ圧縮についてはInterpolatorCompressionstreamformat、3Dメッシュデータ圧縮については3DMC streamformatが記述されている。
【００９０】
4. ObjectDescriptorUpdateに対する修正
4.1 構文
次はXMT2BIFSスタイルシートでObjectDescriptorUpdate構文を次の通り修正した。
元の構文は次の通りである。
<xsl:template match="xmt:ObjectDescriptorUpdate"> 
UPDATE OD [ 
<xsl:apply-templates select="xmt:OD"/> 
] 
</xsl:template>
【００９１】
修正された構文は次の通りである。
<xsl:template match="xmt:ObjectDescriptorUpdate"> 
UPDATE OD [ 
<xsl:apply-templates select="xmt:OD"/> 
] 
</xsl:template> 
<xsl:template match="xmt:OD"> 
<xsl:apply-templates select="xmt:ObjectDescriptorBase" /> 
</xsl:template> 
<xsl:template match="xmt:ObjectDescriptorBase"> 
<xsl:apply-templates select="xmt:ObjectDescriptor|xmt:InitialObjectDescriptor"/> 
</xsl:template> 
<xsl:template match="xmt:ObjectDescriptor"> 
ObjectDescriptor { 
<xsl:if test="@objectDescriptorID"> objectDescriptorID <xsl:value-of select=
"@objectDescriptorID"/></xsl:if> 
<xsl:text></xsl:text> 
<xsl:apply-templates select="xmt:URL" /> 
} 
</xsl:template> 
<xsl:template match="xmt:URL"> 
<xsl:if test="@URLstring"> muxScript 
<xsl:value-of select="@URLstring"/></xsl:if> 
<xsl:text></xsl:text> 
</xsl:template> 
【００９２】
4.2 Semantics（意味）
オリジナルの構文において、"Update OD"の内部には、何も記述されていない。"Update OD"は、制作者が"url"フィールドを通じて他のエレメントストリームに連結しようとする場合、すなわち、場面説明ストリーム(scene description stream(BIFS stream))をリンクする時に使われる。また、Update ODの内部には、オブジェクト記述IDおよびスクリプトファイル名を説明する部分も追加されている。これはbinary textual formatと一致する。
【実施例１】
【００９３】
図2および図4を参照して、オリジナルデータを媒介因子(encoding parameter)によりビットストリームとし、バッファに伝送する場合について実施例を説明する。
図4は、オブジェクトA(例えば、カップ)の3次元データ(幾何情報、連結情報、色相情報等)が媒介因子により圧縮されてなるビットストリームが、バッファを介して"ＢufferWithEP.m3d"に伝送される場合について示す図である。
【００９４】
図2に示されるように、XMT入力ファイル200がXMTパーサ210に入力すると、XMT-Aスキーマ240に基づいて、XMT2BIFSスタイルシート230およびXMT2MUXスタイルシート220を使用したビットストリームが.sceneファイルと共にBIFSエンコーダ250に伝送される。この際、.mux内の情報にはMPEG-4エンコーダであるBIFSエンコーダ250が実行された結果である.bifs/.odが含まれる。そして.mux内の情報と.bifs/.odファイルとがMP4エンコーダ260に入力して.mp4が生成され、MPEG-4プレーヤーで再生される。
【００９５】
以下に、例示するXMTファイルは、BitWrapperを使用して圧縮されたオリジナルデータの3次元メッシュ情報を、媒介因子を使用してビットストリームとし、バッファを使用して伝送する処理を示したものである。
<Header> 
<InitialObjectDescriptor objectDescriptorID="1" binaryID="1" > 
<Descr> 
<esDescr> 
<ES_Descriptor ES_ID="xyz" binaryID="201" OCR_ES_ID="xyz">          
... 
<StreamSource>                              
<BIFSEncodingHints> 
<sourceFormat> 
<param value=" BufferWithEP.bif"> </param> 
</sourceFormat> 
</BIFSEncodingHints> 
</StreamSource> 
</ES_Descriptor> 
</esDescr> 
</Descr> 
</InitialObjectDescriptor> 
</Header> 
... 
<BitWrapper type="0" buffer="MyIndexFaceSet.m3d"> 
<node> 
<IndexedFaceSet  ccw="TRUE"         solid="TRUE" 
coordIndex="0, 1, 2, -1, 3, 4, 5, -1,..." normalPerVertex="TRUE"> 
<coord DEF="Box-COORD"></coord> 
<Coordinate point= “0 1 2, 0 2 3, 4 0 1, 1 5 4, 5 1 2, 2 6 5, ..."></Coordinate> 
<normal> 
<Normal vector="0.7859 -0.341 -0.5157, 0.3812 -0.801 0.4615, ..."> 
</Normal></normal> 
</IndexedFaceSet>                        
</node>                                               
<IndexedFaceSetEncodingParameter  coordQBits="10 
normalQBits="9"                                   coordPredMode="2 
normalPredMode="0"                              errorResilience="OFF">
</IndexedFaceSetEncodingParameter> 
</BitWrapper> 
... 
【００９６】
実施例1においては、XMTパーサ210は、XMT入力ファイル200を受信すると、BitWrapperノード媒介因子とを使用して、3次元メッシュ情報を圧縮し、ビットストリームを生成する。これはBitWrapperノードおよび媒介因子に対するXMT-Aスキーマ定義に基づくものである。また、XMT-Aスキーマ240とスタイルシート(MT2BIFSとXMT2MUX)ファイル220，230とにより、MPEG-4符号化器に入力するファイル(".scene"ファイルと".mux"ファイル)が生成する。その結果は次の通りである。
【００９７】
-"BufferWithEP.scene"File
... 
BitWrapper { 
node IndexedFaceSet { 
ccw="TRUE" 
solid="TRUE" 
coodIndex="0, 1, 2, -1, 3, 4, 5, -1, ..." 
normalPerVertex="TRUE" 
coord DEF Box-COORD Coordinate {    
point [0 1 2, 0 2 3, 4 0 1, 1 5 4, 5 1 2, 2 6 5, ... } 
} 
normal Normal { 
Vector[0.7859, -0.341, -0.5157, 0.3812, -0.801, 0.4615, ...] 
} 
} 
IndexedFaceSetEncodingParameter{ 
coordQBits 10 
NormalQBits 9 
coordPredMode 2 
normalPredMode 0 
errorResilience OFF 
} 
type 0 
buffer "MyIndexFaceSet.m3d" 
} 
・.. 
- "BufferWithEP.mux"File 
InitialObjectDescriptor { 
… 
muxInfo MuxInfo{ 
fileName  "BufferWithEP.bif" 
streamFormat BIFS 
} 
} 
【００９８】
前記のような.sceneファイルと.muxファイルとはMPEG-4プレーヤーに入力され、BIFSエンコーダ250を経てbifs/odファイルが生成される。このbifs/odファイルとmuxファイルとがMP4エンコーダ260に入力されて１つのビットストリーム(".mp4")ファイルを生成する。前記".mp4"ファイルは最終的にMPEG-4プレーヤーで視覚化される。
【実施例２】
【００９９】
次に、図2および図5を参照して、既に圧縮されたビットストリームを使用して、バッファに伝送する実施例について説明する。図5の内容は次の通りである。オブジェクトA(例えば、カップ)の3次元データ(幾何情報、連結情報、色相情報等)が既に圧縮されたビットストリームの形として使われる。そして、このビットストリームはバッファを通じて"BufferWithoutEP.m3d"に伝送される。
【０１００】
前記した、オリジナルデータを媒介因子によりビットストリームとしてバッファに伝送する場合（実施例１）と実施例２との差異点は次の通りである。すなわち、XMT入力ファイル200でBitWrapperノードにオブジェクトAの3次元データおよび媒介因子を使用して直接圧縮するのでなく、既に圧縮されたオブジェクトAに対するビットストリームをバッファに伝送する点である。
【０１０１】
図2に示すように、XMT入力ファイル200がXMTパーサ210に入力すると、XMT-Aスキーマ240を参照し、XMT2BIFSスタイルシート230およびXMT2MUXスタイルシート220を使用して圧縮したビットストリームと共に場面データが.sceneビットストリームとなって伝送する。この時、.mux内の情報には、MPEG-4符号化器であるBIFSエンコーダ250で生成したbifs/.odが含まれる。そして、.Mux内の情報と.bifs/.odファイルとがMP4エンコーダ260に入力し最終結果ファイル(.mp4)が生成され、MPEG-4プレーヤーでその結果が視聴される。以下、実施例を挙げてさらに詳細に説明する。
【０１０２】
以下に、例示するXMTファイルは、BitWrapperを使用して既に圧縮された3次元メッシュ情報のビットストリームをバッファにより伝送する処理を示すものである。
... 
<Header> 
<InitialObjectDescriptor objectDescriptorID="1" binaryID="1" > 
<Descr> 
<esDescr> 
<ES_Descriptor ES_ID="xyz" binaryID="201" OCR_ES_ID="xyz"> 
... 
<StreamSource>                                    
<BIFSEncodingHints> 
<sourceFormat> 
<param value="BufferWithoutEP.bif"> </param> 
</sourceFormat> 
</BIFSEncodingHints> 
</StreamSource> 
</ES_Descriptor> 
</esDescr> 
</Descr> 
</InitialObjectDescriptor> 
</Header> 
<Body> 
<Replace> 
<Scene> 
<Group> 
<children> 
<Shape> 
<geometry DEF="MY_BOX"> 
<BitWrapper type="0" buffer="MyIndexFaceSet.m3d"> 
<node> 
<IndexedFaceSet> 
<coord DEF="Box-COORD"></coord> 
<Coordinate></Coordinate> 
</node> 
</BitWrapper>           
</geometry>                                                           
</Shape> 
</children> 
</Group> 
</Scene> 
</Replace>  
</Body> 
... 
【０１０３】
実施例2では、BitWrapperノードにより圧縮された3次元メッシュ情報のビットストリームをバッファで伝送させるXMT入力ファイル200がXMTRefパーサ210（図２参照）に入力されると、BitWrapperノード内のバッファに伝送される圧縮された3次元メッシュ情報のビットストリームが生成される。このビットストリームの生成は、BitWrapperノードと媒介因子により定義されたXMT-Aスキーマに基づくものである。また、XMT-Aスキーマとスタイルシート(XMT2BIFS,XMT2MUX)230,220とを使用してMPEG-4符号化器に入力する.sceneファイルおよび.muxファイルが生成される。その結果は次の通りである。
【０１０４】
-BufferWithoutEP.scene File
... 
BitWrapper {   
node       IndexedFaceSet {
coord DEF Box-COORD Coordinate {   
} 
} 
type 0 
buffer "MyIndexFaceSet.m3d" 
} 
... 
-BufferWithoutEP.mux File
InitialObjectDescriptor { 
… 
muxInfo MuxInfo{ 
fileName  "BufferWithoutEP.bif" 
streamFormat BIFS 
} 
} 
【０１０５】
前記のような.sceneファイルおよび.muxファイルはMPEG-4符号化器に入力され、BIFSエンコーダ250を経てbifs/odファイルを生成する。このbifs/odファイル（またはビットストリーム）とmuxファイルとは、MP4エンコーダ260に入力され、１つのビットストリーム(".mp4")ファイルを生成する。この"mp4"ファイルは最終的にMPEG-4プレーヤーで視覚化される。
【実施例３】
【０１０６】
次に、図2および図6を参照して、媒介因子を使用してオリジナルデータからビットストリームを生成しURLに伝送する実施例について説明する。
図6は、BitWrapperノード内でオブジェクトA(例えば、カップ)のような3次元データ(幾何情報、連結情報、色相情報等)を媒介因子で圧縮して形成したビットストリームをURLで伝送する方法について示す。ここでは前述したバッファを通じて伝送する方法とは異なる２つの方法を示す。
【０１０７】
第1の方法では、BitWrapperでURL ID(例えば、12)を使用し、前記URL IDのようなObjectDescriptorID（オブジェクト記述ID）を有するBitWrapperEncodingHintsにオブジェクトAの圧縮されたビットストリームの位置情報(ファイル"bunny-15000-tcp.m3d")が明示され、これを使用して圧縮されたビットストリームが伝送される。
【０１０８】
第2の方法では、オブジェクトAの圧縮されたビットストリームの位置情報は.muxの位置情報に含まれる。そして、.muxファイルに含まれる位置情報はBitWrapperノードのURL IDのようにObjectDescriptorUpdateで明示される。前記.muxファイルにおける位置情報はオブジェクトAの圧縮されたビットストリームの位置情報(ファイル"bunny-15000-tcp.m3d")にリンクしている。したがって、URLを使用して"bunny-15000-tcp.m3d"ファイルのビットストリームが伝送される。
【０１０９】
このような方法で図６に示すように、図２に明示されたXMT入力ファイル200がXMTパーサ210に入力されると、XMT-Aスキーマ240を参照し、XMT2BIFSスタイルシート230およびXMT2MUXスタイルシート220を使用して.muxの位置情報が、場面データと共に.sceneのビットストリームに載せて伝送される。そして.muxファイルには、MPEG-4符号化器に含まれるBIFSエンコーダ250が実行された結果として生成される.bifs/.odファイルが含まれる。さらに、.muxファイルは、オブジェクトAの圧縮されたビットストリームの位置情報"bunny-15000-tcp.m3d"も含まれる。
【０１１０】
これにより、オブジェクトAの圧縮されたビットストリームの位置情報(.mux内の内容)と.bifs/.odファイルとがMP4エンコーダ260に入力され１つのビットストリームファイル(.mp4)が生成され、MPEG-4プレーヤーでその結果が視聴される。
以下、実施例を挙げてさらに詳細に説明する。
【０１１１】
以下に、例示するXMTファイルは、BitWrapperを使用してオリジナルデータの3次元メッシュ情報を、媒介因子を使用してビットストリームに作ってURLを使用して伝送する処理を示すものである。
<Header> 
... 
<ObjectDescriptor objectDescriptorID="12" binaryID="12"> 
<Descr> 
<esDescr> 
<ES_Descriptor ES_ID="PI" binaryID="211" OCR_ES_ID="PIC"> 
... 
<StreamSource>                                   
<BitWrapperEncodingHints> 
<BitWrapper3DMCEncodingHints> 
<sourceFormat> 
<paramvalue="bunny-15000-tcp.m3d"> </param> 
</sourceFormat> 
</BitWrapper3DMCEncodingHints> 
</BitWrapperEncodingHints>                                 
</StreamSource>                                            
</ES_Descriptor> 
</esDescr> 
</Descr> 
</ObjectDescriptor> 
</Header> 
<Body> 
<Replace> 
<Scene> 
<Group> 
<children> 
<Shape> 
<geometry DEF="MY_BOX"> 
<Box size="69"></Box> 
<BitWrapper type="0" url="12">                      <node> 
<IndexedFaceSet    ccw="TRUE" 
solid="TRUE" 
coordIndex="0,1,2,-1,3,4,5,-1, ..." 
normalPerVertex="TRUE"> 
<coord DEF="Box-COORD"></coord> 
<Coordinate point="012,023,401,154,512,265, ..."></Coordinate> 
<normal> 
<Normal vector="0.7859 -0.341 -0.5159, 0.3821 
-0.801 0.4615, ...">  </Normal> 
</normal> 
</IndexedFaceSet> 
<node> 
</IndexedFaceSetEncodingParameter coordQits="10" 
normalQBits="9" 
coordPreMode="2" 
normalPredMode="0" 
errorResilience="OFF">          </IndexedFaceSe
EncodingParameter> 
</BitWrapper> 
</geometry>                                                
</Shape> 
</children> 
</Group> 
</Scene> 
</Replace>     
<ObjectDescriptorUpdate> 
<OD> 
<ObjectDescriptorBase> 
<ObjectDescriptor objectDescriptorID="12" binaryID="12">                        
<URL URLstring="UrlWithEP.scr"></URL>                                               
</ObjectDescriptor> 
</ObjectDescriptorBase> 
</OD> 
</ObjectDescriptorUpdate> 
</Body> 
【０１１２】
実施例3に示すように、BitWrapperノードで定義された媒介因子により圧縮された3次元メッシュ情報で表現されたXMT入力ファイルが、XMTパーサ210に入力すると、BitWrapperノードで定義された媒介因子により3次元メッシュ情報が圧縮されてビットストリームを生成する。このようにして生成したビットストリームは、BitWrapperノードおよび媒介因子で定義されたXMT-Aスキーマに基づく。また、XMT-AスキーマとスタイルシートXMT2BIFS、XMT2MUXファイルを使用して生成し、MPEG-4符号化器に入力する.sceneファイルおよび.mux"ファイルは次のようにして作られる。
【０１１３】
-UrlWithEP.sceneFile-
... 
BitWrapper {      
node IndexedFaceSet {    
ccw TRUE 
coordIndex [ 0, 1, 2, -1, 3, 4, 5, -1, ... ] 
normalPerVertex TRUE 
solid TRUE 
coord DEF Box-COORD Coordinate {    
point [012, 023, 401, 154, 512, 265, ...・] 
}               
normal  Normal {    
vector [0.7859, -0.341, -0.5159,  0.3821, -0.801, 0.4651, ... ] 
} 
} 
IndexedFaceSetEncodingParameter {   
coordQBits 10 
normalQBits 9 
coordPredMode 2 
normalPredMode 0 
errorResilience OFF                    
} 
type 0 
url 12 
} 
・.. 
UPDATE OD [ 
ObjectDescriptor { 
objectDescriptorID 12 
muxScript UrlWithEP.scr 
} 
] 
-"UrlWithEP.mux"File-
... 
ObjectDescriptor { 
objectDescriptorID 12 
esDescr [ 
ES_Descriptor { 
ES_ID  211 
... 
muxInfo MuxInfo{ 
fileName  "bunny-15000-tcp.m3d" 
streamFormat 3DMC 
} 
] 
} 
【０１１４】
前記したように.sceneファイルおよび.muxファイルがMPEG-4符号化器に入力すると、BIFSエンコーダ250を経て.bifs/.odファイルを生成し、この.bifs/.odビットストリームとmuxファイルがMP4エンコーダ260に入力してビットストリーム(".mp4")ファイルを生成する。この"mp4"ファイルは最終的にMPEG-4プレーヤーで視覚化される。
【実施例４】
【０１１５】
次に、図2および図6を参照して、既に圧縮されたビットストリームを使用してURLに伝送する実施例について説明する。
【０１１６】
図7は、BitWrapperノード内で、オブジェクトA(例えば、カップ)の既に圧縮された3次元データ(幾何情報、連結情報、色相等)のビットストリームが、URLを用いて伝送される方法について示す図である。この場合と、実施例３で述べた場合とを比較すると、オリジナルデータが媒介因子によりビットストリームとしてURLに伝送する点において同じであるが、オブジェクトAの3次元データが媒介因子により直接圧縮されるのでなく、既に圧縮されたオブジェクトAに対するビットストリームがURLを使用して伝送される点において相違する。従って、図2に示す、XMT入力ファイル200におけるBitWrapperノードには、オリジナルデータと媒介因子とがなく、URL IDだけがある。
【０１１７】
以下に例示するXMTファイルは、BitWrapperを使用して既に圧縮された3次元メッシュ情報ビットストリームをURLを使用して伝送する処理を示すものである。
<Header> 
... 
<ObjectDescriptor objectDescriptorID="12" binaryID="12"> 
<Descr> 
<esDescr> 
<ES_Descriptor ES_ID="PI" binaryID="211" OCR_ES_ID="PIC"> 
<StreamSource>                                
<BitWrapperEncodingHints> 
<BitWrapper3DMCEncodingHints> 
<sourceFormat> 
<param value="bunny-15000-tcp.m3d"> </param> 
</sourceFormat> 
</BitWrapper3DMCEncodingHints> 
</BitWrapperEncodingHints>                           
</StreamSource>       
</ES_Descriptor> 
</esDescr> 
</Descr> 
</ObjectDescriptor> 
</Header> 
<Body> 
<Replace> 
<Scene> 
<Group> 
<children> 
<Shape> 
<geometry DEF="MY_BOX">
<BitWrapper type="0" url="12">
<node> 
<IndexedFaceSet> 
<coord DEF="Box-COORD"></coord> 
<Coordinate> </Coordinate> 
</IndexedFaceSet>                                                     </node> 
</BitWrapper> 
</geometry>                                                                     </Shape> 
</children> 
</Group> 
</Scene> 
</Replace>     
<ObjectDescriptorUpdate> 
<OD> 
<ObjectDescriptorBase> 
<ObjectDescriptor objectDescriptorID="12" binaryID="12"> 
<URL URLstring=" UrlWithoutEP.scr"> 
</URL>              
</ObjectDescriptor> 
</ObjectDescriptorBase> 
</OD> 
</ObjectDescriptorUpdate> 
</Body> 
【０１１８】
実施例4では、BitWrapperノードにより既に圧縮され、3次元メッシュ情報ビットストリームとしてURLに伝送されるXMT入力ファイルがXMTRefパーサ210に入力すると、BitWrapperノード内のURLに伝送される圧縮された3次元メッシュ情報のビットストリームが生成される。このような、ビットストリームの生成は、BitWrapperノードと媒介因子とにより定義されたXMT-Aスキーマ240に基づく。また、XMT-Aスキーマとスタイルシート(XMT2BIFS、XMT2MUX)ファイルを使用して、MPEG-4符号化器の入力ファイル(".scene"ファイル、".mux"ファイル)が生成される。その結果は次の通りである。
【０１１９】
-URLWithoutEP.sceneFile-
... 
BitWrapper {   
node IndexedFaceSet { 
coord DEF Box-COORD Coordinate {    
} 
}   
type 0 
url 12 
} 
... 
UPDATE OD [ 
ObjectDescriptor { 
objectDescriptorID 12 
muxScript UrlWithoutEP.scr 
} 
] 
-URLWithoutEP.muxFile-
... 
ObjectDescriptor { 
objectDescriptorID 12 
esDescr [ 
ES_Descriptor { 
ES_ID  211 
... 
muxInfo MuxInfo{ 
fileName  "bunny-15000-tcp.m3d" 
streamFormat 3DMC 
} 
... 
【０１２０】
前記したように、.sceneファイルおよび.muxファイルはMPEG-4符号化器に入力する。.sceneファイルは、BIFSエンコーダ250を経て.bifs/.odファイルを生成し、この.bifs/.odファイルとmuxファイルとがMP4エンコーダ260に入力されて１つのビットストリーム(".mp4")ファイルを生成する。前記"mp4"ファイルは最終的にMPEG-4プレーヤーで視覚化される。
【０１２１】
本発明はコンピュータにて読取れる記録媒体にコンピュータ(情報処理機能を有する装置を全て含む)が読込めるコードとして具現しうる。コンピュータにて読取れる記録媒体はコンピュータシステムによって読取られるデータが貯蔵されるあらゆる種類の記録装置を含む。コンピュータにて読取れる記録装置の例としては、ROM、RAM、CD-ROM、磁気テープ、フレキシブルディスク、光データ貯蔵装置などがある。
本発明は図面に示された実施例に基づいて説明されたが、これは例示的なものに過ぎず、当業者ならばこれより多様な変形および均等な他実施例が可能であるという点を理解できるであろう。従って、本発明の真の技術的保護範囲は特許請求の範囲の技術的思想により決まるべきである。
【産業上の利用可能性】
【０１２２】
本発明はコンピュータグラフィック分野に適用でき、特にコンピュータグラフィックの制作ツールおよびグラフィックデータの圧縮を効率よく行う。
【図面の簡単な説明】
【０１２３】
【図１】本発明によるグラフィックデータ圧縮に関するメタ言語を用いた入力ファイル生成システムの構成を示すブロック図である。
【図２】本発明によるグラフィック圧縮に関するメタ言語を用いた入力ファイル生成システムの他の構成を示すブロック図である。
【図３】テキスト構文を用いてMPEG-4場面記述を示すためのXMTフレームワークである。
【図４】オブジェクトAに対する3次元データを媒介因子を使用して圧縮し、オブジェクトAの圧縮されたビットストリームをバッファ("バッファWithEP.m3d")を使用して伝送する方法を示す図面である。
【図５】既に圧縮されたビットストリームをバッファで伝送する場合を説明する図面である。
【図６】BitWrapperノード内でオブジェクトAに対する3次元データを媒介因子を用いて圧縮し、オブジェクトAの圧縮されたビットストリームをURLを用いて伝送する方法を示す。
【図７】BitWrapperノード内で既に圧縮されたオブジェクトAに対する3次元データのビットストリームをURLを用いて伝送する方法を示す図面である。
【符号の説明】
【０１２４】
２００  XMT入力ファイル
２１０  XMTパーサ
２２０  XMT2MUXスタイルシート
２３０  XMT2BIFSスタイルシート
２４０  XMTスキーマ
２５０  BIFSエンコーダ
２６０  MP4エンコーダ
２７０  .mp４出力ファイル
【図１】
2007080274.tif 000003
【図２】
2007080274.tif 000004
【図３】
2007080274.tif 000005
【図４】
2007080274.tif 000006
【図５】
2007080274.tif 000007
【図６】
2007080274.tif 000008
【図７】
2007080274.tif 000009