JP2007080274A - グラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法 - Google Patents

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

Info

Publication number
JP2007080274A
JP2007080274A JP2006251767A JP2006251767A JP2007080274A JP 2007080274 A JP2007080274 A JP 2007080274A JP 2006251767 A JP2006251767 A JP 2006251767A JP 2006251767 A JP2006251767 A JP 2006251767A JP 2007080274 A JP2007080274 A JP 2007080274A
Authority
JP
Japan
Prior art keywords
compression
node
compressed
file
information
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
JP2006251767A
Other languages
English (en)
Other versions
JP4384155B2 (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 JP2007080274A publication Critical patent/JP2007080274A/ja
Application granted granted Critical
Publication of JP4384155B2 publication Critical patent/JP4384155B2/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で定義することによって、グラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法およびシステムを提 供することである。
本発明は、前記した目的を達成するために創案されたものであり、
前記技術的課題を達成するための本発明によるグラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法は、圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子、及び少なくとも圧縮されたオブジェクトデータファイルの位置情報を含む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４出力ファイル

Claims (5)

  1. 圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子、及び少なくとも圧縮されたオブジェクトデータファイルの位置情報を含むBitWrapperEncodingHintsを定義しているＸＭＴスキーマを格納する段階と、
    ＸＭＴ入力ファイルを取得する段階と、
    前記ＸＭＴ入力ファイルを、前記ＸＭＴスキーマを含む情報を参照してパーシングして所定のデータ圧縮符号化器に入力されるファイルを生成する段階を含み、
    前記圧縮ノードは、
    圧縮するオブジェクトデータを含むノードフィールドと、
    urlフィールドと相互排他的に使われ、ノードの圧縮されたビットストリームをイン−バンドとして伝送するバッファフィールドと、
    前記バッファフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをアウト−バンドとして伝送するurlフィールドと、
    ノード圧縮スキームの種類を示すタイプフィールドとを含み、
    前記圧縮媒介因子は、
    圧縮対象となるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、３次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子及び位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含み、
    前記BitWrapperEncodingHintsは、
    圧縮ノードのURL IDのようなオブジェクト記述ID情報及びmuxファイルが提供する圧縮されたビットストリームを伝送するファイル名とビットストリームのフォーマットの種類に関する情報とを含むこと、
    を特徴とするグラフィックデータ圧縮に関するメタ表現を用いた入力ファイル生成方法。
  2. 圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子、及び少なくとも圧縮された客体データファイルの位置情報を含むBitWrapperEncodingHintsを定義しているＸＭＴスキーマを格納する段階と、
    ＸＭＴ入力ファイルを取得する段階と、
    前記ＸＭＴ入力ファイルを、前記ＸＭＴスキーマを含む情報を参照してパーシングして所定のデータ圧縮符号化器に入力されるファイルを生成する段階を含み、
    前記圧縮ノードは、
    圧縮するオブジェクトデータを含むノードフィールドと、
    urlフィールドと相互排他的に使われ、ノードの圧縮されたビットストリームをイン−バンドとして伝送するバッファフィールドと、
    前記バッファフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをアウト−バンドとして伝送するurlフィールドと、
    ノード圧縮スキームの種類を示すタイプフィールドとを含み、
    前記圧縮媒介因子は、
    圧縮対象になるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、３次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子及び位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含み、
    前記BitWrapperEncodingHintsは、
    圧縮ノードのURL IDのようなオブジェクト記述ID情報及びmuxファイルが提供する圧縮されたビットストリームを伝送するファイル名とビットストリームのフォーマットの種類に関する情報を含み、
    前記ＸＭＴ入力ファイルの圧縮ノードに、既に圧縮されたデータに対する情報及び前記既に圧縮されたデータが一時貯蔵されるバッファ情報が含まれる場合、前記既に圧縮されたデータのビットストリームを、前記バッファ情報を使って伝送すること、
    を特徴とするグラフィックデータ圧縮に関するメタ表現により生成された入力ファイル伝送方法。
  3. 圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子、及び少なくとも圧縮されたオブジェクトデータファイルの位置情報を含むBitWrapperEncodingHintsを定義しているＸＭＴスキーマを格納する段階と、
    ＸＭＴ入力ファイルを取得する段階と、
    前記ＸＭＴ入力ファイルを、前記ＸＭＴスキーマを含む情報を参照してパーシングして所定のデータ圧縮符号化器に入力されるファイルを生成する段階を含み、
    前記圧縮ノードは、
    圧縮するオブジェクトデータを含むノードフィールドと、
    urlフィールドと相互排他的に使われ、ノードの圧縮されたビットストリームをイン−バンドとして伝送するバッファフィールドと、
    前記バッファフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをアウト−バンドとして伝送するurlフィールドと、
    ノード圧縮スキームの種類を示すタイプフィールドを含み、
    前記圧縮媒介因子は、
    圧縮対象となるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、３次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子及び位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含み、
    前記BitWrapperEncodingHintsは、
    圧縮ノードのURL IDのようなオブジェクト記述ID情報及びmuxファイルが提供する圧縮されたビットストリームを伝送するファイル名とビットストリームのフォーマットの種類に関する情報を含み、
    前記ＸＭＴ入力ファイルの圧縮ノードに、既に圧縮されたデータに対する情報及びリンクされたＵＲＬ情報が含まれる場合、前記既に圧縮されたデータのビットストリームを、前記ＵＲＬ情報を使って伝送すること、
    を特徴とするグラフィックデータ圧縮に関するメタン表現により生成された入力ファイル伝送方法。
  4. 圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子、及び少なくとも圧縮されたオブジェクトデータファイルの位置情報を含むBitWrapperEncodingHintsを定義しているＸＭＴスキーマを格納する段階と、
    ＸＭＴ入力ファイルを取得する段階と、
    前記ＸＭＴ入力ファイルを、前記ＸＭＴスキーマを含む情報を参照してパーシングして所定のデータ圧縮符号化器に入力されるファイルを生成する段階を含み、
    前記圧縮ノードは、
    圧縮するオブジェクトデータを含むノードフィールドと、
    urlフィールドと相互排他的に使われ、ノードの圧縮されたビットストリームをイン−バンドとして伝送するバッファフィールドと、
    前記バッファフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをアウト−バンドとして伝送するurlフィールドと、
    ノード圧縮スキームの種類を示すタイプフィールドを含み、
    前記圧縮媒介因子は、
    圧縮対象となるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、３次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子及び位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含み、
    前記BitWrapperEncodingHintsは、
    圧縮ノードのURL IDのようなオブジェクト記述ID情報及びmuxファイルが提供する圧縮されたビットストリームを伝送するファイル名とビットストリームのフォーマットの種類に関する情報を含み、
    前記ＸＭＴ入力ファイルの圧縮ノードに、圧縮されていないオリジナルデータ、圧縮媒介因子、及びバッファ情報が含まれる場合、前記圧縮されていないオリジナルデータを、前記圧縮媒介因子を使って圧縮することにより得られるビットストリームを、前記バッファ情報を使って伝送すること、
    を特徴とするグラフィックデータ圧縮に関するメタ表現により生成された入力ファイル伝送方法。
  5. 圧縮するオブジェクトデータに関する情報を含む圧縮ノードと、圧縮に必要な媒介因子、及び少なくとも圧縮されたオブジェクトデータファイルの位置情報を含むBitWrapperEncodingHintsを定義しているＸＭＴスキーマを格納する段階と、
    ＸＭＴ入力ファイルを受け入れる段階と、
    前記ＸＭＴ入力ファイルを、前記ＸＭＴスキーマを含む情報を参照してパーシングして所定のデータ圧縮符号化器に入力されるファイルを生成する段階を含み、
    前記圧縮ノードは、
    圧縮するオブジェクトデータを含んでいるノードフィールドと、
    urlフィールドと相互排他的に使われ、ノードの圧縮されたビットストリームをイン−バンドとして伝送するバッファフィールドと、
    前記バッファフィールドと相互排他的に使われ、前記ノードの圧縮されたビットストリームをアウト−バンドとして伝送するurlフィールドと、
    ノード圧縮スキームの種類を示すタイプフィールドを含み、
    前記圧縮媒介因子は、
    圧縮対象になるオブジェクトの頂点座標に対するキーフレームアニメーションデータに関する媒介因子、３次元メッシュ情報に関する媒介因子、回転移動キーフレームアニメーションデータに関する媒介因子及び位置移動キーフレームアニメーションデータに関する媒介因子のうち少なくとも１つを含み、
    前記BitWrapperEncodingHintsは、
    圧縮ノードのURL IDのようなオブジェクト記述ID情報及びmuxファイルが提供する圧縮されたビットストリームを伝送するファイル名とビットストリームのフォーマットの種類に関する情報を含み、
    前記ＸＭＴ入力ファイルの圧縮ノードに圧縮されていないオリジナルデータ、圧縮媒介因子、及びURL情報が含まれる場合、前記圧縮されていないオリジナルデータを、前記圧縮媒介因子を使って圧縮することにより得られるビットストリームを、前記ＵＲＬ情報を使って伝送すること、
    を特徴とするグラフィックデータ圧縮に関するメタ表現により生成された入力ファイル伝送方法。
JP2006251767A 2002-12-05 2006-09-15 グラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法 Expired - Fee Related JP4384155B2 (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 Parent Applications (1)

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

Publications (2)

Publication Number Publication Date
JP2007080274A true JP2007080274A (ja) 2007-03-29
JP4384155B2 JP4384155B2 (ja) 2009-12-16

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 Before (1)

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

Country Status (3)

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

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100763903B1 (ko) 2004-03-08 2007-10-05 삼성전자주식회사 Ｄｉｂｒ데이터를 위한 스키마 및 스타일 쉬트
EP1575296A3 (en) * 2004-03-08 2007-11-07 Samsung Electronics Co., Ltd. Schema and style sheet for DIBR data
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
US7886223B2 (en) 2006-11-17 2011-02-08 International Business Machines Corporation Generating a statistical tree for encoding/decoding an XML document
CN104424319A (zh) * 2013-09-10 2015-03-18 镇江金钛软件有限公司 一种暂存通用数据的方法

Also Published As

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

Similar Documents

Publication Publication Date Title
KR100513736B1 (ko) 그래픽 데이터 압축에 관한 메타표현을 이용한 입력파일생성 방법 및 시스템
JP4384155B2 (ja) グラフィックデータ圧縮に関するメタ言語を用いた入力ファイルの生成方法
KR100695126B1 (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) スキーマ、構文解析法、およびスキーマに基づいてビットストリームを発生させる方法
US7606428B2 (en) Schema and style sheet for DIBR data
JP2006517309A (ja) ＭＰＥＧ−４ＩｎｔｅｒｍｅｄｉａＦｏｒｍａｔからＭＰＥＧ−４ＴｅｘｔｕａｌＲｅｐｒｅｓｅｎｔａｔｉｏｎを作成する効率的な手段
US20040111677A1 (en) Efficient means for creating MPEG-4 intermedia format from MPEG-4 textual representation
US20060139346A1 (en) Input file generating method and system using meta representation of compression of graphics data, and AFX coding method and apparatus
JP2005176355A (ja) グラフィックデータ圧縮に関するメタ表現を用いた入力ファイルの生成方法およびシステムと、ａｆｘ符号化の方法および装置
KR101183861B1 (ko) 멀티미디어 콘텐트 처리 수행 방법
CN100496124C (zh) 使用图形数据压缩的元表示产生输入文件的方法
JP2002077789A (ja) 画像処理方法及び装置
Timmerer et al. Digital item adaptation–coding format independence
JP2005276193A (ja) Ｄｉｂｒデータのためのスキーマ及びスタイルシート
Hong et al. XFlavor: providing XML features in media representation
Kim et al. Overview of Bitstream Syntax and Parser Description Languages for Media Codecs
WO2023275013A1 (en) Methods, apparatus and systems for signaling preselections
CN117597937A (zh) 用于用信号传输预选的方法、装置和系统
KR20240107164A (ko) 미디어 컨테이너 파일 및 스트리밍 매니페스트에서의 픽처인픽처에 대한 시그널링
Lee et al. Converting Macromedia/sup/spl reg//Flash/sup TM/Shockwave/sup/spl reg//to MPEG-4 BIFS
Joung et al. XMT tools for interactive broadcasting contents description
Preda et al. 3D Graphics Standardization in MPEG-4

Legal Events

Date Code Title Description
RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20070115

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090427

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090512

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090812

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: 20090908

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090924

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

Free format text: PAYMENT UNTIL: 20121002

Year of fee payment: 3

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: 20131002

Year of fee payment: 4

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