JP2004187308A - グラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法およびシステム - Google Patents

グラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法およびシステム Download PDF

Info

Publication number
JP2004187308A
JP2004187308A JP2003407786A JP2003407786A JP2004187308A JP 2004187308 A JP2004187308 A JP 2004187308A JP 2003407786 A JP2003407786 A JP 2003407786A JP 2003407786 A JP2003407786 A JP 2003407786A JP 2004187308 A JP2004187308 A JP 2004187308A
Authority
JP
Japan
Prior art keywords
file
xmt
compression
information
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2003407786A
Other languages
English (en)
Other versions
JP3930851B2 (ja
Inventor
Gyeong-Ja Jang
敬 子 張
Do-Kyoon Kim
道 均 金
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR10-2003-0084216A external-priority patent/KR100513736B1/ko
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of JP2004187308A publication Critical patent/JP2004187308A/ja
Application granted granted Critical
Publication of JP3930851B2 publication Critical patent/JP3930851B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234318—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into objects, e.g. MPEG-4 objects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23412—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs for generating or manipulating the scene composition of objects, e.g. MPEG-4 objects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44012—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving rendering scenes according to scene graphs, e.g. MPEG-4 scene graphs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8543—Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)
  • Processing Or Creating Images (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

【課題】 グラフィックデータ圧縮に関するメタ表現を用いた入力ファイルの生成方法およびシステムを提供する。
【解決手段】 少なくとも圧縮する客体データに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子を定義しているXMLスキーマ240とを備える段階と、XML入力ファイル200をXMLスキーマ240を参照して所定のデータ圧縮符号化器（エンコーダ）250，260に入力されるファイルへの変換を支援するスタイルシート220，230を備える段階と、XML入力ファイル200をXMLスキーマ240及びスタイルシート220，230を参照してパーシングして所定のデータ圧縮符号化器（エンコーダ）250，260に入力されるファイルを生成する段階と、を含むことを特徴とする。
【選択図】 図２

Description

本発明はグラフィックデータの制作に係り、特に、グラフィックデータの圧縮に関するメタ言語を用いた入力ファイルの生成方法およびシステムに関する。
従来の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で定義することによって、グラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法およびシステムを提供することである。
本発明は、前記した目的を達成するために創案されたものであり、
前記技術的課題を達成するための本発明によるグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法は、少なくとも圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子を定義しているXMLスキーマとを備える段階と、XML入力ファイルを前記XMLスキーマを参照して所定のデータ圧縮符号化器に入力されるファイルへの変換を支援するスタイルシートを備える段階と、XML入力ファイルを前記XMLスキーマおよび前記スタイルシートを参照してパーシングして所定のデータ圧縮符号化器に入力されるファイルを生成する段階と、を含むことを特徴とする。
前記XMLスキーマは少なくとも前記圧縮されたオブジェクトデータを貯蔵しているファイルの位置情報を含んでいるEncodingHintsをさらに備えることが望ましい。
前記圧縮媒介因子は、圧縮対象となるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、３次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子および位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含むことが望ましい。
前記技術的課題を達成するための本発明によるMPEG-4 AFXで提案した圧縮表現をXMTで定義してグラフィックデータを圧縮可能にするグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法は、圧縮するオブジェクトデータに関する情報を含んでいる圧縮ノードと、圧縮に必要な媒介因子、および少なくとも圧縮されたオブジェクトデータファイルの位置情報を含むBitWrapperEncodingHintsを定義しているXMTスキーマとを備えるスキーマ段階と、XMT入力ファイルを前記XMTスキーマを参照してシーン（.scene）ファイルへの変換を支援するXMT2BIFSスタイルシートと、XMT入力ファイルを前記XMTスキーマを参照してmuxファイルへの変換を支援するXMT2MUXスタイルシートを備えるスタイルシート段階と、XMT入力ファイルを前記XMTスキーマと前記XMT2BIFSスタイルシートおよびXMT2MUXスタイルシートを用いてパーシングしてシーン（.scene）ファイルおよびmuxファイルを生成するパーシング段階と、を含むことを特徴とする。
前記圧縮ノードは、圧縮するオブジェクトデータを含んでいるノードフィールドと、urlフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをイン-バンドとして伝送するバッファフィールドと、前記バッファフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをアウト-バンドとして伝送するurlフィールドとを含んでなることが望ましい。
前記圧縮ノードはノード圧縮スキームの種類を示すタイプフィールドをさらに備えることが望ましい。
前記圧縮媒介因子は圧縮対象となるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、3次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子および位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含むことが望ましい。
前記BitWrapperEncodingHintsは圧縮ノードのURL IDのようなオブジェクト記述ID情報およびmuxファイルが提供する圧縮されたビットストリームを伝送するファイル名とビットストリームのフォーマットの種類とに関する情報とをさらに備えることが望ましい。
前記パーシング段階は、オリジナルデータと圧縮媒介因子およびバッファ情報を備える圧縮ノードを含むXMT入力ファイルを受け取る段階と、前記XMTスキーマと前記XMT2BIFSスタイルシートおよびXMT2MUXスタイルシートを用いて前記XMT入力ファイルをパーシングしてシーン（.scene）ファイルおよびmuxファイルを生成する段階とを含んでなることが望ましく、前記シーンファイルは前記オリジナルデータと、圧縮媒介因子と、前記オリジナルデータを圧縮したビットストリームを伝送するバッファ情報と、を備え、前記muxファイルは前記シーンファイルをBIFSエンコーダを通じて符号化されたファイル名と、ビットストリームのフォーマットの情報と、を備える。
前記パーシング段階は既に圧縮されたオブジェクトデータが貯蔵されているバッファ情報を備える圧縮ノードを含むXMT入力ファイルを受け取る段階と、前記XMTスキーマと前記XMT2BIFSスタイルシートおよびXMT2MUXスタイルシートを用いて前記XMT入力ファイルをパーシングしてシーンファイルおよびmuxファイルを生成する段階と、を含んでなることが望ましい。
前記シーンファイルはオブジェクトデータを圧縮したビットストリームを伝送するバッファ情報を備え、前記muxファイルは前記シーンファイルをBIFSエンコーダを通じて符号化されたファイル名と、ビットストリームのフォーマット情報と、を備える。
前記パーシング段階は、オリジナルデータと圧縮媒介因子およびurl情報を備える圧縮ノードと、圧縮ノードのURL IDのようなObjectDescriptorID（オブジェクト記述ID）情報およびオブジェクトの圧縮されたビットストリームの位置情報を備えるBitWrapperEncodingHintsを含むXMT入力ファイルを受け取る段階と、前記XMTスキーマと前記XMT2BIFSスタイルシートおよびXMT2MUXスタイルシートを用いて前記XMT入力ファイルをパーシングしてシーンファイルおよびmuxファイルを生成する段階と、を含んでなることが望ましく、前記シーンファイルは前記オリジナルデータと、圧縮媒介因子と、前記オリジナルデータを圧縮したビットストリームを伝送するurl情報と、を備え、前記muxファイルは前記BitWrapperEncodingHintsに明示されたオブジェクトの圧縮されたビットストリームの位置情報およびビットストリームのフォーマット情報を備える。
前記XMT入力ファイルは前記BitWrapperEncodingHintsに現れたオブジェクトIDと同じオブジェクト記述ID情報とのパーシングの結果生成されるmuxファイル名情報を含んでいるObjectDescriptorUpdateとをさらに備え、前記シーンファイルは前記BitWrapperEncodingHintsに現れたオブジェクトIDと同じオブジェクト記述ID情報とmuxファイル名情報とをさらに備えることが望ましい。
前記パーシング段階は既に圧縮されたオブジェクトデータがリンクされたURL情報を備える圧縮ノードとURL IDのようなオブジェクト記述ID情報およびオブジェクトの圧縮されたビットストリームの位置情報を備えるBitWrapperEncodingHintsを含むXMT入力ファイルを受け取る段階と、前記XMTスキーマと前記XMT2BIFSスタイルシートおよびXMT2MUXスタイルシートを用いて前記XMT入力ファイルをパーシングしてシーンファイルおよびmuxファイルを生成する段階と、を含んでなることが望ましく、前記シーンファイルは前記圧縮ノードに明示されたオブジェクト記述IDと同一で前記オリジナルデータを圧縮したビットストリームを伝送するurl情報を備え、前記muxファイルは前記BitWrapperEncodingHintsに明示されたオブジェクトの圧縮されたビットストリームの位置情報およびビットストリームのフォーマット情報を備える。
前記XMT入力ファイルは前記BitWrapperEncodingHintsに現れたオブジェクトIDと同じオブジェクト記述ID情報とのパーシングの結果生成されるmuxファイル名情報を含んでいるObjectDescriptorUpdateをさらに備え、前記シーンファイルは前記BitWrapperEncodingHintsに現れたオブジェクトIDと同じオブジェクト記述ID情報とmuxファイル名情報とをさらに備えることが望ましい。
前記技術的課題を達成するための本発明によるグラフィックデータ圧縮に関するメタ言語を用いた入力ファイル生成システムは、少なくとも圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子を定義しているXMLスキーマと、XML入力ファイルを前記XMLスキーマを参照して所定のデータ圧縮符号化器に入力されるファイルへの変換を支援するスタイルシートと、XML入力ファイルを前記XMTスキーマおよび前記スタイルシートを参照してパーシングして所定のデータ圧縮符号化器に入力されるファイルを生成するXLMパーサと、を含むことを特徴とする。
前記圧縮媒介因子は圧縮対象となるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、3次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子および位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含むことが望ましい。
前記技術的課題を達成するための本発明による、MPEG-4 AFXで提案した圧縮表現をXMTで定義してグラフィックデータを圧縮可能にするグラフィックデータ圧縮に関するメタ言語を用いた入力ファイル生成システムは、圧縮するオブジェクトデータに関する情報を含んでいる圧縮ノードと、圧縮に必要な媒介因子、および少なくとも圧縮されたオブジェクトデータファイルの位置情報を含むBitWrapperEncodingHintsを定義しているXMTスキーマと、XMT入力ファイルを前記XMTスキーマを参照してシーンファイルへの変換を支援するXMT2BIFSスタイルシートと、XMT入力ファイルを前記XMTスキーマを参照してmuxファイルへの変換を支援するXMT2MUXスタイルシートと、XMT入力ファイルを前記XMTスキーマと前記XMT2BIFSスタイルシートおよびXMT2MUXスタイルシートを用いてパーシングしてシーンファイルおよびmuxファイルを生成するXMTパーサと、を含むことを特徴とする。
前記圧縮ノードは圧縮するオブジェクトデータを含んでいるノードフィールドと、urlフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをイン−バンドとして伝送するバッファフィールドと、前記バッファフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをアウト−バンドとして伝送するurlフィールドと、を含んでなることが望ましい。前記圧縮媒介因子は圧縮対象となるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、3次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子および位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含むことが望ましい。
前記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-Ωフォーマットとの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-Ωフォーマットとは、SMILに基づくMPEG-4の上位ランクに位置付けされるものである。そして、コンテンツ制作者がXMTのメカニズムについて詳しくなくとも、XMT-ΩからXMT-Aにデフォルトマッピングすることを可能にするものである。このように、XMT-Ωはコンテンツ製作者に、便利なインターフェース機能を提供する役目を果たす。一般に、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４出力ファイル

Claims (21)

  1. 少なくとも圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な圧縮媒介因子を定義しているXMLスキーマとを備える段階と、
    XML入力ファイルを前記XMLスキーマを参照して所定のデータ圧縮符号化器に入力されるファイルへの変換を支援するスタイルシートを備える段階と、
    XML入力ファイルを前記XMLスキーマおよび前記スタイルシートを参照してパーシングして所定のデータ圧縮符号化器に入力されるファイルを生成する段階と、を含むことを特徴とするグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法。
  2. 前記XMLスキーマは、
    少なくとも前記圧縮されたオブジェクトデータを貯蔵しているファイルの位置情報を含んでいるEncodingHintsをさらに備えることを特徴とする請求項１に記載のグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法。
  3. 前記圧縮媒介因子は、
    圧縮対象となるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、3次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子および位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含むことを特徴とする請求項１または２に記載のグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法。
  4. 圧縮するオブジェクトデータに関する情報を含んでいる圧縮ノードと、圧縮に必要な圧縮媒介因子、および少なくとも圧縮されたオブジェクトデータを貯蔵しているファイルの位置情報を含むBitWrapperEncodingHintsを定義しているXMTスキーマとを備えるスキーマ段階と、
    XMT入力ファイルを前記XMTスキーマを参照してシーンファイルへの変換を支援するXMT2BIFSスタイルシートと、XMT入力ファイルを前記XMTスキーマを参照してmuxファイルへの変換を支援するXMT2MUXスタイルシートを備えるスタイルシート段階と、
    XMT入力ファイルを前記XMTスキーマと前記XMT2BIFSスタイルシートおよびXMT2MUXスタイルシートを用いてパーシングし、シーンファイルおよびmuxファイルを生成するパーシング段階と、を含むことを特徴とするグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法。
  5. 前記圧縮ノードは、
    圧縮するオブジェクトデータを含んでいるノードフィールドと、
    urlフィールドと相互排他的に使われ、ノードの圧縮されたビットストリームをイン-バンドとして伝送するバッファフィールドと、
    前記バッファフィールドと相互排他的に使われ、ノードの圧縮されたビットストリームをアウト-バンドとして伝送するurlフィールドとを含んでなることを特徴とする請求項４に記載のグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法。
  6. 前記圧縮ノードは、
    ノード圧縮スキームの種類を示すタイプフィールドをさらに備えることを特徴とする請求項５に記載のグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法。
  7. 前記圧縮媒介因子は、
    圧縮対象となるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、3次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子および位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含むことを特徴とする請求項４に記載のグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法。
  8. 前記BitWrapperEncodingHintsは、
    圧縮ノードのURL IDのようなオブジェクト記述ID情報およびmuxファイルが提供する圧縮されたビットストリームを伝送するファイル名とビットストリームのフォーマットの種類に関する情報とをさらに備えることを特徴とする請求項４に記載のグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法。
  9. 前記パーシング段階は、
    オリジナルデータ、圧縮媒介因子およびバッファを備える圧縮ノードを含むXMT入力ファイルを受け取る段階と、
    前記XMTスキーマと前記XMT2BIFSスタイルシートおよびXMT2MUXスタイルシートを用いて前記XMT入力ファイルをパーシングしてシーンファイルおよびmuxファイルを生成する段階と、を含んでなることを特徴とし、
    前記シーンファイルは、
    前記オリジナルデータと、圧縮媒介因子と、前記オリジナルデータを圧縮したビットストリームを一時的に貯蔵するバッファと、を備え、
    前記muxファイルは、
    前記シーンファイルをBIFSエンコーダを通じて符号化されたファイル名と、ビットストリームのフォーマットの情報と、を備える請求項４に記載のグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法。
  10. 前記パーシング段階は、
    既に圧縮されたオブジェクトデータが一時貯蔵されているバッファ情報を備える圧縮ノードを含むXMT入力ファイルを受け取る段階と、
    前記XMTスキーマと前記XMT2BIFSスタイルシートおよびXMT2MUXスタイルシートを用いて前記XMT入力ファイルをパーシングしてシーンファイルおよびmuxファイルを生成する段階と、を含んでなることを特徴とし、
    前記シーンファイルは、
    オブジェクトデータを圧縮したビットストリームを伝送するバッファ情報を備え、
    前記muxファイルは、
    前記シーンファイルをBIFSエンコーダを通じて符号化されたファイル名と、ビットストリームのフォーマットの情報と、を備える請求項４に記載のグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法。
  11. 前記パーシング段階は、
    オリジナルデータと圧縮媒介因子およびurl情報を備える圧縮ノードと、圧縮ノードのURL IDのようなオブジェクト記述ID情報およびオブジェクトの圧縮されたビットストリームの位置情報を備えるBitWrapperEncodingHintsとを含むXMT入力ファイルを受け取る段階と、
    前記XMTスキーマと前記XMT2BIFSスタイルシートおよびXMT2MUXスタイルシートを用いて前記XMT入力ファイルをパーシングしてシーンファイルおよびmuxファイルを生成する段階と、を含んでなることを特徴とし、
    前記シーンファイルは、
    前記オリジナルデータと、圧縮媒介因子と、前記オリジナルデータを圧縮したビットストリームに関する情報をリンクするurl情報と、を備え、
    前記muxファイルは、
    前記BitWrapperEncodingHintsに明示されたオブジェクトの圧縮されたビットストリームの位置情報およびこのビットストリームのフォーマットの情報を備える請求項４に記載のグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法。
  12. 前記XMT入力ファイルは、
    前記BitWrapperEncodingHintsに現れたオブジェクトIDと同じオブジェクト記述ID情報およびパーシングの結果生成されるmuxファイル名情報を含んでいるObjectDescriptorUpdateをさらに備え、
    前記シーンファイルは、
    前記BitWrapperEncodingHintsに現れたオブジェクトIDと同じオブジェクト記述ID情報およびmuxファイル名情報をさらに備えることを特徴とする請求項１１に記載のグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法。
  13. 前記パーシング段階は、
    既に圧縮されたオブジェクトデータに関する情報とリンクされたURL情報とを備える圧縮ノードおよびURL IDのようなオブジェクト記述ID情報およびオブジェクトの圧縮されたビットストリームの位置情報を備えるBitWrapperEncodingHintsを含むXMT入力ファイルを受け取る段階と、
    前記XMTスキーマと前記XMT2BIFSスタイルシートおよびXMT2MUXスタイルシートを用いて前記XMT入力ファイルをパーシングしてシーンファイルおよびmuxファイルを生成する段階と、を含んでなることを特徴とし、
    前記シーンファイルは、
    前記圧縮ノードに明示されたオブジェクト記述IDと同一で、前記オリジナルデータを圧縮したビットストリームに関する情報とリンクするurl情報を備え、
    前記muxファイルは、
    前記BitWrapperEncodingHintsに明示されたオブジェクトの圧縮されたビットストリームの位置情報およびこのビットストリームのフォーマットの情報を備える請求項４に記載のグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法。
  14. 前記XMT入力ファイルは、
    前記BitWrapperEncodingHintsに現れたオブジェクトIDと同じオブジェクト記述ID情報およびパーシングの結果生成されるmuxファイル名情報を含んでいるObjectDescriptorUpdateをさらに備え、
    前記シーンファイルは、
    前記BitWrapperEncodingHintsに現れたオブジェクトIDと同じオブジェクト記述ID情報およびmuxファイル名情報をさらに備えることを特徴とする請求項１３に記載のグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法。
  15. 請求項１ないし請求項14のうち何れか１項に記載の発明をコンピュータにて実行させるためのプログラムを記録したコンピュータにて読取れる記録媒体。
  16. 少なくとも圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子を定義しているXMLスキーマと、
    XML入力ファイルを前記XMLスキーマを参照して所定のデータ圧縮符号化器に入力されるファイルへの変換を支援するスタイルシートと、
    XML入力ファイルを前記XMTスキーマおよび前記スタイルシートを参照してパーシングして所定のデータ圧縮符号化器に入力されるファイルを生成するXLMパーサと、を含むことを特徴とするグラフィックデータ圧縮に関するメタ言語を用いた入力ファイル生成システム。
  17. 前記圧縮媒介因子は、
    圧縮対象となるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、3次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子および位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含むことを特徴とする請求項１６に記載のグラフィックデータ圧縮に関するメタ言語を用いた入力ファイル生成システム。
  18. 圧縮するオブジェクトデータに関する情報を含んでいる圧縮ノードと、圧縮に必要な媒介因子、および少なくとも圧縮されたオブジェクトデータファイルの位置情報を含むBitWrapperEncodingHintsを定義しているXMTスキーマと、
    XMT入力ファイルを前記XMTスキーマを参照してシーンファイルへの変換を支援するXMT2BIFSスタイルシートと、
    XMT入力ファイルを前記XMTスキーマを参照してmuxファイルへの変換を支援するXMT2MUXスタイルシートと、
    XMT入力ファイルを前記XMTスキーマと前記XMT2BIFSスタイルシートおよびXMT2MUXスタイルシートを用いてパーシングしてシーンファイルおよびmuxファイルを生成するXMTパーサと、を含むことを特徴とするグラフィックデータ圧縮に関するメタ言語を用いた入力ファイル生成システム。
  19. 前記圧縮ノードは、
    圧縮するオブジェクトデータを含んでいるノードフィールドと、
    urlフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをイン-バンドとして伝送するバッファフィールドと、
    前記バッファフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをアウト-バンドとして伝送するurlフィールドと、を含んでなることを特徴とする請求項１８に記載のグラフィックデータ圧縮に関するメタ言語を用いた入力ファイル生成システム。
  20. 前記圧縮媒介因子は、
    圧縮対象となるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、3次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子および位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含むことを特徴とする請求項１８に記載のグラフィックデータ圧縮に関するメタ言語を用いた入力ファイル生成システム。
  21. 前記BitWrapperEncodingHintsは、
    圧縮ノードのURL IDのようなオブジェクト記述ID情報およびmuxファイルが提供する圧縮されたビットストリームを伝送するファイル名とこのビットストリームのフォーマットの種類に関する情報とをさらに備えることを特徴とする請求項１８に記載のグラフィックデータ圧縮に関するメタ言語を用いた入力ファイル生成システム。
JP2003407786A 2002-12-05 2003-12-05 グラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法およびシステム Expired - Fee Related JP3930851B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US43097702P 2002-12-05 2002-12-05
US51011803P 2003-10-14 2003-10-14
KR10-2003-0084216A KR100513736B1 (ko) 2002-12-05 2003-11-25 그래픽 데이터 압축에 관한 메타표현을 이용한 입력파일생성 방법 및 시스템

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2006251767A Division JP4384155B2 (ja) 2002-12-05 2006-09-15 グラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法

Publications (2)

Publication Number Publication Date
JP2004187308A true JP2004187308A (ja) 2004-07-02
JP3930851B2 JP3930851B2 (ja) 2007-06-13

Family

ID=32512145

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2003407786A Expired - Fee Related JP3930851B2 (ja) 2002-12-05 2003-12-05 グラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法およびシステム
JP2006251767A Expired - Fee Related JP4384155B2 (ja) 2002-12-05 2006-09-15 グラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2006251767A Expired - Fee Related JP4384155B2 (ja) 2002-12-05 2006-09-15 グラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法

Country Status (3)

Country Link
EP (1) EP1435738A1 (ja)
JP (2) JP3930851B2 (ja)
CN (1) CN1270237C (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7886223B2 (en) 2006-11-17 2011-02-08 International Business Machines Corporation Generating a statistical tree for encoding/decoding an XML document

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100763903B1 (ko) 2004-03-08 2007-10-05 삼성전자주식회사 Ｄｉｂｒ데이터를 위한 스키마 및 스타일 쉬트
JP2005276193A (ja) * 2004-03-08 2005-10-06 Samsung Electronics Co Ltd Ｄｉｂｒデータのためのスキーマ及びスタイルシート
US20060085737A1 (en) * 2004-10-18 2006-04-20 Nokia Corporation Adaptive compression scheme
KR100657940B1 (ko) * 2004-12-28 2006-12-14 삼성전자주식회사 깊이 영상 기반 표현 데이터 압축에 관한 메타표현을이용한 입력파일 생성 방법 및 시스템과, ａｆｘ부호화방법 및 장치
US7548657B2 (en) * 2005-06-25 2009-06-16 General Electric Company Adaptive video compression of graphical user interfaces using application metadata
CN104424319A (zh) * 2013-09-10 2015-03-18 镇江金钛软件有限公司 一种暂存通用数据的方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7886223B2 (en) 2006-11-17 2011-02-08 International Business Machines Corporation Generating a statistical tree for encoding/decoding an XML document

Also Published As

Publication number Publication date
CN1270237C (zh) 2006-08-16
JP4384155B2 (ja) 2009-12-16
JP3930851B2 (ja) 2007-06-13
EP1435738A1 (en) 2004-07-07
CN1514360A (zh) 2004-07-21
JP2007080274A (ja) 2007-03-29

Similar Documents

Publication Publication Date Title
KR100513736B1 (ko) 그래픽 데이터 압축에 관한 메타표현을 이용한 입력파일생성 방법 및 시스템
Puri et al. MPEG‐4: An object‐based multimedia coding standard supporting mobile applications
KR100695126B1 (ko) 그래픽 데이터 압축에 관한 메타표현을 이용한 입력파일생성 방법 및 시스템과, ａｆｘ부호화 방법 및 장치
JP4384155B2 (ja) グラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法
KR20190117675A (ko) 생성된 콘텐츠를 포함하는 미디어 데이터를 인코딩하기 위한 방법 및 장치
Panis et al. Bitstream syntax description: a tool for multimedia resource adaptation within MPEG-21
JP2001312741A (ja) 三次元シーンのノード処理方法及びその装置
US11967153B2 (en) Information processing apparatus, reproduction processing apparatus, and information processing method
JP4040577B2 (ja) スキーマ、構文解析法、およびスキーマに基づいてビットストリームを発生させる方法
CN101427571B (zh) 从mpeg-4中间格式创建mpeg-4文本表示的方法
KR100763903B1 (ko) Ｄｉｂｒ데이터를 위한 스키마 및 스타일 쉬트
CN100470535C (zh) 用于从mpeg-4文本表示创建mpeg-4中间格式的方法及系统
US20060139346A1 (en) Input file generating method and system using meta representation of compression of graphics data, and AFX coding method and apparatus
WO2023275013A1 (en) Methods, apparatus and systems for signaling preselections
JP2005176355A (ja) グラフィックデータ圧縮に関するメタ表現を用いた入力ファイルの生成方法およびシステムと、ａｆｘ符号化の方法および装置
KR101183861B1 (ko) 멀티미디어 콘텐트 처리 수행 방법
Eleftheriadis et al. Flavor: a formal language for audio-visual object representation
CN100496124C (zh) 使用图形数据压缩的元表示产生输入文件的方法
Thomas-Kerr et al. Format-independent rich media delivery using the bitstream binding language
JP2005276193A (ja) Ｄｉｂｒデータのためのスキーマ及びスタイルシート
Kim et al. Overview of Bitstream Syntax and Parser Description Languages for Media Codecs
Lee et al. Converting Macromedia/sup/spl reg//Flash/sup TM/Shockwave/sup/spl reg//to MPEG-4 BIFS
Hong et al. XFlavor: providing XML features in media representation
Kim et al. Conversion mechanism for MPEG-4 contents services on Web environment
Xiang et al. Combining the product of Interactive Multimedia Creator with MPEG4 technology

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20060309

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20060315

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20060613

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20060616

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060915

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20061004

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070104

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20070109

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20070112

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20070213

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20070309

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110316

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110316

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120316

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130316

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130316

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140316

Year of fee payment: 7

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees