MPEG4 Systems 解説

MPEG4 Systems 解説
1998 年
電子情報通信学会
画像工学研究会
まえがき
1997 年 11 月に CD (Committee Draft) の発行された
MPEG-4 システム (ISO/IEC CD 14496-1) について概
説する。現在はバージョン 1 の CD 化が終了し、11 月に
はバージョン 2 の CD 化が予定されている。
Display and
User
Interaction
Audiovisual Interactive
Scene
1. 概要
Composition and Rendering
MPEG-4 システムは、CD 化までに紆余曲折を繰り返して
いる。当初の活動では、符号化アルゴリズムのダウンロ
ードやフレキシブルな API 定義が議論の中心であった。
ビットストリームの多重化に関しても、当初は ITU-T で
PSTN 向けの多重化方式として検討されている H.223 が
参照モデルとされた。しかし、これらの議論は結果的に
立ち消えとなり、自由度の高い多重化方式とシーン合
成を核とする現在の構成に至っている。
図 1 に、MPEG-4システムのアーキテクチャを示す。従来
のオーディオ、ビデオ信号に加えて、シーン記述 (コン
ピュータグラフィクス、テキストを含む)、静止画像、合成
オーディオなどがそれぞれ一つのメディアオブジェクト
(エレメンタリストリーム) として統合的に扱われ、多重化
される。MPEG-4 端末は、これらを分離、復号し、合成す
る。各種制御情報からなるオブジェクトディスクリプタや
オブジェクト毎の付加的なコンテント情報なども、一つの
エレメンタリストリームとして扱うことになっている (どれが
制御用でどれがメディア転送用、という区別が無い)。
Object
Descriptor
FlexMux FlexMux
AL
Elementary Stream Interface
...
AL
AccessUnit
Layer
AL
FlexMux
Stream Multiplex Interface
FlexMux
FlexMux Streams
(PES)
MPEG-2
TS
(RTP)
UDP
IP
AAL2
ATM
H223
PSTN
DAB
Mux
FlexMux
Layer
TransMux Interface
...
...
TransMux
Layer
TransMux Streams
Transmission/Storage Medium
図 1: MPEG-4 端末のアーキテクチャ
DMIF Application Interface
Decoding
Buffer DB1
Decoding
Buffer DB2
Decoding
Buffer DB3
(encapsulates
Demultiplexer)
Decoding
Buffer DB
n
Media Object
Decoder 1
Media Object
Decoder 2
Media Object
Decoder n
Composition
Memory CB 1
Composition
Memory CB 2
Compositor
Composition
Memory CB n
Elementary Stream Interface
図 2: システムデコーダモデル
•
アクセスユニット (AU, Access Unit) : 時間属性が
定義される最小の処理単位。ES を分割して得られ
る。ビデオの場合、1 フレームの符号化データに相
当する。
•
復号バッファ (DB, Decoding Buffer) : AU を保持
するバッファ。サイズは送出側で設定可能である。
•
デコーダ (Decoder) : AU を入力とし、復号し、コン
ポジションユニット(後述)を出力する。スケーラビリテ
ィ等を考慮し、複数の DB が接続されてもよい。
3.1.1. 構成要素
構成要素は以下の通りである。これらに基づき、後述す
るタイミングモデルとバッファモデルが定義される。
AL
AL-Packetized Streams
3. CD 14496-1 (システム)
MPEG-4 端末の挙動を定義するために、構成を抽象化
したシステムデコーダモデル (図 3) が定義されている。
基本的に、MPEG-2 システムの一定遅延モデルに倣っ
ている。
...
Compression
Layer
Primitive
AV Objects
Elementary Streams
AL
そして、MPEG-4 システムは、自然・合成を問わず、さま
ざまな AV オブジェクトを同期合成するためのルールの
提供を目的としている。CD 14496-1 には、MPEG-4 端末
のモデル (3.1)、各ストリームの符号化特性の定義と関
連付け (3.2)、複数ストリームの同期と多重化 (3.3, 3.4)、
シーン記述 (3.5)、等が規定されている。
3.1. システムデコーダモデル
Return
Channel
Coding
...
Scene
Description
Information
•
エレメンタリストリーム (ES, Elementary Stream) : メ
ディアオブジェクト個々の符号化ビットストリーム。
•
•
DAI (DMIF Application Interface、4 章参照) : 入
力ビットストリームを分離し、ES 毎にアクセスユニット
(後述)を復号バッファに出力する。CD 化以前はデ
マルチプレクサだったが、DMIF の役割を明確化す
る意味で、DAI に置き換えられた。
コンポジションユニット (CU, Composition Unit) :
合成 (コンポジション) が適用される処理単位。ビ
デオの場合、復号されたフレームに相当する。
•
コンポジションメモリ (CM, Composition Memory) :
CU を保持するメモリ。サイズは規定されない。
•
コンポジタ (Compositor) : シーン記述に従い、CU
を合成する。具体的な挙動は規格外である。
-
3.1.2. タイミングモデル
タイミングモデルは、メディア同期を定義するために用い
られる。コンセプトは MPEG-2 システムに倣っており、送
出側と受信側の同期を確保するための参照クロックと、メ
ディア毎の動作タイミングを示すためのタイムスタンプが
用いられる。関連する用語を以下に示す。
•
•
•
•
•
システム時間基準 (STB, System Time Base) :
MPEG-4 端末の時間基準。
オブジェクト時間基準 (OTB, Object Time Base) :
各メディアオブジェクトの時間基準。
オブジェクト参照クロック (OCR, Object Clock reference) : 各メディアオブジェクトの参照クロック。送
出側の OTB を受信側に定期的に伝える。
復号タイムスタンプ (DTS, Decoding Time Stamp) :
AU が DB に存在していなければならない時刻。復
号タイミングを与える。DTS=CTS の場合、使用され
ない。
合成タイムスタンプ (CTS, Composition Time
Stamp) : CU が CB に存在していなければならない
時刻。合成タイミングを与える。
OCR、DTS、CTS が後述する AL_PDU_Header によって
転送される。OCR によって時間基準を回復し、DTS、
CTS に従って同期合成再生を実現する。各メディアオブ
ジェクトの時間基準を、一つの OCR に合わせることも可
能である（実際にはこれが通常の運用になるであろう）。
尚、時刻情報の利用はオプションであり、アプリケーショ
ンはクロックを自走させても構わない。
MPEG-2 システムの PTS (Presentation Time Stamp) に
対応するタイムスタンプは存在していない。このため、表
示タイミングのずれの弊害が一部で懸念されている。一
方、以前存在していた ETS (Expiration time Stamp) は
廃止されている。
3.1.3. バッファモデル
バッファモデルは、送出側主導のシナリオ (プッシュ型)
を前提に、MPEG-4 端末におけるバッファのオーバーフ
ロー/アンダーフローを防ぐための、送出側、受信側双方
に求められる動作を示している。モデルとして、符号化
入力から復号出力までが一定遅延であること、復号、合
成は瞬時に終了すること、等が仮定されている。
•
•
送出側は MPEG-4 端末に DB の必要サイズ (バイ
ト数)を伝える。ES_Descriptor (後述) によって陽に
伝える場合と、Profile/Level によって暗黙的に伝え
る場合がある、とされる。
送出側は MPEG-4 端末が以下の動作をすることを
前提に、ビットストリームの送出を行う (端末の動作
を予測する)。
•
AU は時刻 DTS で即座に CU に変換され、DB か
ら取り除かれる。
CU は時刻 CTS で合成可能になり、後続する CTS
まで使用される。
図 3 には、バッファの動作例を示す。
Arrival(AU1 )
Arrival(AU0)
DTS (AU0)
Decoding
Buffer
Composition
Memory
DTS (AU1 )
...................
AU0
AU1
...................
CU0
CU1
CTS (CU0 )
CTS (CU1 )
= available for
composition
図 3: バッファの動作例
3.2. Object Descriptor
各エレメンタリストリームの制御情報として、オブジェクト
ディスクリプタ (OD: Object Descriptor) が定義される。
図 4 は OD のシンタクス構造の概要を示したものである
(詳細は[1]を参照されたい)。
3.2.1. ObjectDescriptor()
エレメンタリストリームの属性と関連付けを定義する。スケ
ーラビリティ等を考慮し、複数のエレメンタリストリームが
グループ化される。また、シーン記述にエレメンタリストリ
ームを関係付ける役割も持つ。
ObjectDescriptorId (10bit) は、一つのオブジェクトディ
スクリプタを同定する。シーン記述中のオブジェクトで同
じ ObjectDescriptorId を持つものは、このオブジェクトデ
ィスクリプタに関連付けられる。
streamCount (5bit) は、後続する ES_Descriptor() の個
数を示す。
3.2.2. ES_Descriptor()
各エレメンタリストリームの特性の詳細を定義する。オプ
ションとして URL が用いられる場合には、別のオブジェ
クトディスクリプタ、またはエレメンタリストリームへのポイ
ンタが与えられる。
ES_Number (5bit) は、エレメンタリストリームに番号を与
える。さらに、オブジェクトディスクリプタで与えられる
ObjectDescriptorId と共に
ES_Id = ObjectDescriptorId << 5 | ES_Number
によって、セッション中で固有の番号が割り当てられる。
URLstring (n*8bit) は、オプションとしてURLアドレスを
与える。
dependsOn_ES_Number (5bit) は、スケーラビリティ等
に従い、同じオブジェクトディスクリプタの中で、関係付
けられる別のエレメンタリストリームの ES_Number を与え
る。
ObjectDescriptorUpdate ( )
0x08-0x09
0x0A
0x0B-0x1F
0x20-0x3F
reserved
ObjectContentInfoStream
reserved
user private
objectCount
ObjectDescriptor ( )
ObjectDescriptorID
streamCount
シーン(BIFS)
ES_Descriptor ( )
ES_Number
URLstring (option)
dependsOn_ES_Number (option)
DecodeConfigDescriptor ( )
ストリーム (ES)
profileAndLevelIndication
streamType
upStream
bufferSizeDB
maxBitrate
avgBitrate
ALConfigDescriptor ( ) … 3.3節参照
IPI_Descriptor ( )
QoS_Descriptor ( )
streamPriority
upStream (1bit) は、値が 1 の場合、当該するエレメンタ
リストリームがバックチャネルで用いられていることを示
す。
bufferSizeDB (24bit) は、復号バッファのサイズを与え
る（バイト数）。
maxBitrate (32bit) は、1 秒当たりの瞬間最大レートを
与える。
avgBitrate (32bit) は、1 分当たりの平均レートを与える。
値が 0 の場合、当該するエレメンタリストリームは固定レ
ートではないことを示す。
3.2.4. Object Descriptor Stream
図 4: オブジェクトディスクリプタのシンタクス構造
このほか、以下のディスクリプタが定義される。
-
DecodeConfigDescriptor () : 3.2.3 節参照
-
ALConfigDescriptor () : 3.3 節参照
-
IPI_Descriptor ()
-
QoS_Descriptor ()
IPI_Descriptor() は、コンテントの知的所有権に関する
情報を運ぶ。 QoS_Descriptor() は、エレメンタリストリー
ム伝送時のサービス品質を定める。QoS_Descriptor（）に
含まれる streamPriority (5bit) は、ストリーム毎のプライ
オリティの相対的な尺度を与える。値が大きいほど、品
質要求が高い、とされる。
3.2.3. DecodeConfigDescriptor ( )
個々のエレメンタリストリームの復号器に求められる情報
を定義する。
profileAndLevelIndication (8bit) は、復号器がサポー
トすべきプロファイルとレベルを定める。現在、MPEG-1
と MPEG-2/4 のすべてのプロファイル・レベルがサポート
されている。
streamType (6bit) は、エレメンタリストリームのタイプを
定める。現在、表 1 に示すタイプが定義されている。
表 1: ストリームタイプ
value
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
description
reserved
initialObjectDescriptor
ObjectDescriptorStream
ClockReferenceStream
SceneDescriptionStream
VisualStream
AudioStream
MPEG7Stream
後述するセッション開始時を除き、セッション中はオブジ
ェクトディスクリプタ自身もメッセージにカプセル化し、エ
レメンタリストリームとして転送ことになっている (表 1 中
の ObjectDescriptorStream)。
現在定義されているメッセージを表 2 に示す。上から順
に、セッション中のオブジェクトディスクリプタの更新と無
効化、エレメンタリディスクリプタの更新と無効化、に使用
する。
表 2: メッセージ
tag
0
1
2
3
4
0x05-0xFF
Descriptors
reserved
ObjectDescriptorUpdate
ObjectDescriptorRemove
ES_DescriptorUpdate
ES_DescriptorRemove
reserved for ISO use
セッション開始時には、エレメンタリストリームとしてでは
なく、特殊なオブジェクトディスクリプタ (initialObjectDescriptor) を受け取り、MPEG-4 端末を初期化する、とさ
れる。初期化を終了し、必要なオブジェクトディスクリプタ
を受け取り、適切なチャネルを開いてから、通常のエレメ
ンタリストリームを介したセッションが開始される。
3.3. AL_PDU
送信側において、各アクセスユニットはアクセスユニット
レイヤ (図 1 参照)で分割され、各々AL_PDU ヘッダが
付加されてパケットを構成する (AL-PDU: Access Unit
Layer Protocol Data Unit)。そのパケットは、さらに
FlexMux レイヤ、Transmux レイヤに渡される (注 :
TransMux は MPEG-4 Systems の規格化対象外である)。
AL_PDU ヘッダには 2 章に述べた時刻情報などが含ま
れる。これは、受信側におけるエレメンタリストリームの同
期再生などに利用される。ただし、AL_PDU ヘッダの全
てのフィールドはオプションである (すなわち、AL_PDU
ヘッダ自体がオプションである)。使用されるフィールドは、
オブジェクトディスクリプタ内のALConfigDescriptor () に
よって、ストリームを受ける以前に前もって指定される。
表 3 には AL_PDUの構成を示す。AL_PDU ペイロード
はアクセスユニットを分割して得られるものであり、これに
AL_PDU ヘッダを付加する。ペイロードの長さは自由で
あり、下位の FlexMux、TransMux にまかせてフレーミン
グは行わない。なお、ヘッダ、ペイロード共にバイトアライ
ンされる。
表 3: AL_PDU のシンタクス
AL_PDU {
AL_PDU Header ( )
AL_PDU Payload ( )
}
byte aligned
byte aligned
3.3.1. ALConfigDescriptor ( )
オブジェクトディスクリプタの中で、AL_PDU ヘッダで使
用するフィールドを指定する。表 4 にその構成を示す。
表 4: ALConfigDescriptor ( ) のシンタクス
ALConfigDescriptor ( ) {
predefined
if ( ! predefined ) {
useAccessUnitStartFlag
useAccessUnitEndFlag
useRandomAccessPointFlag
usePaddingFlag
useTimeStampFlag
timeStampResolution
OCRResolution
timeStampLength (= tsl)
OCRLength
useWallClockTimeStampFlag
if ( ! useTimeStampFlag ) {
accessUnitRate
compositionUnitRate
startDecodingTimeStamp
startCompositionTimeStamp
wallClockTimeStamp
}
AL_Length
instantBitrateLength
degradationPriorityLength
seqNumLength
}
OCRstreamFlag
if ( OCRstreamFlag ) {
OCR_ES_Id
}
}
8bit
1bit
1bit
1bit
1bit
1bit
32bit
32bit
6bit
6bit
1bit
16bit
16bit
tsl bit
tsl bit
64bit (float)
5bit
8bit
4bit
4bit
1bit
16bit
predefined (8bit) は、デフォルト設定の使用を可能にす
る (値が 0 以外の場合)。この場合、AL_PDUヘッダは使
用されず、オーバーヘッドが削減される。現在は、null
だけが規定されている (表 5 参照)。
表 5: predefined
predifined value
0x00
0x01
0x02-0xFF
description
custom
null AL_PDU Header
reserved
use-xxx (1bit) は、AL_PDU ヘッダにおけるフィールド
xxx の使用・不使用を定める。特に、
useAccessUnitStartFlagと useAccessUnitEndFlag が共
に 0 (不使用) の場合、AL_PDU は常に分割されない一
つのアクセスユニットから構成されることを示唆している。
xxx-Resolution、xxx-Length は、時刻情報 xxx (参照ク
ロック、タイムスタンプ) の解像度 (1 秒当たりのサイクル
数) とビット長を定める。すなわち、MPEG-4 システムで
は、各時刻情報が可変ビットで表せる。ただし、
wallClockTimeStamp は例外であり、VRMLとの互換性
を重視して浮動小数点 64bit で絶対時間を運ぶ。
accessUnitRate と compositionUnitRate は、それぞれタ
イムスタンプを用いない場合の復号周期、合成周期を与
える (単位 Hz)。
xxx-Length は、AL_PDU ヘッダ中のフィールド xxx のビ
ット長を与える。
OCRstreamFlag (1bit) は共通クロック源としての参照ク
ロックストリーム (表 1:の ClockReferenceStream) の使用
を示唆する。OCR_ES_ID (16bit) は、そのクロックストリ
ームを同定する ES_ID 番号を表す。
3.3.2. AL_PDU ヘッダ
事前に ALConfigDescriptor() に示されたフラグ情報に
従い、指定されたフィールドから AL_PDU ヘッダが構成
される。シンタクスは省略するが、各フィールドは
ALCondigDescriptor() の中で接頭辞 use-、接尾語
–Length の付くフィールドにそのまま対応する。詳細は
[1]を参照されたい。
accessUnitStartFlag、accessUnitEndFlag ( 共に 1bit)
は、それぞれ AL_PDU 中のアクセスユニットが開始、終
了の場合、1 にセットされる。
randomAccessPointFlag (1bit) は、当該 AL_PDU がラ
ンダムアクセスポイントであるか否かを示す。
paddingFlag (1bit)、paddingBits (3bits) は、AL_PDU
のパディングの制御に使われる。
sequenceNumber (可変) は、インクリメントされる整数値
として AL_PDU に番号を付ける。これは AL_PDU の廃
棄検出・順序制御に使われる。
objectClockReference
、
decodingTimeStamp
、
compositionTimeStamp (それぞれ可変) は、それぞれ
2 章に述べた OCR、DTS、CTS に対応する。
wallClockTimeStamp (64bit) は、VRML の SFTime の
定義に従う絶対時間を運ぶ。
accessUnitLength (可変) は、バイト単位でアクセスユニ
ットの長さを与える (注: AL_PDU の長さではない。
AL_PDU のフレーミングは、FlexMux レイヤ以下の仕事
とされる)。
instantBitrate (可変) は、当該するエレメンタリストリー
ムの瞬間ビットレートを示す。
degradationPriority (可変) は、当該アクセスユニットの
重要度を表す。 QoS_Descriptor() 中の streamPriority
フィールドと組み合わせ、
AccessUnitPriority = streamPriority – degradationPriority
に従って、サービス要求を適応的に更新する。
3.4. FlexMux
アクセスユニットレイヤから渡される AL_PDU は、
FlexMux レイヤで多重化 (フレーミング) される。目的
は、メディア依存の AL_PDU をネットワーク (もしくは蓄
積媒体)に適合したパケットにすること、あるいは同じサ
ービス品質を要求する AL_PDU を一つのパケットにまと
めること、などである。ただし、FlexMux もオプションであ
る。
表 6: FlexMux のシンタクス
FlexMux_PDU ( ) {
index;
length;
if (index > 239) {
version;
reserved;
m * AL_PDU // MuxCode mode
} else {
AL_PDU
// Simple mode
}
}
表 6 にある通り、一つの FlexMux パケットの長さは最大
256 バイトに限定されている (length フィールドが8 bit)。
現在、この制約が短すぎるのでは、との議論があり、
length フィールドとして 16 bit を選択できるようにするモ
ードが議論されている。
3.5. シーン記述
3.5.1. 背景
従来の MPEG には無い規格として、MPEG-4 ではシー
ンの記述がサポートされる。すなわち、ビデオ、オーディ
オ規格に従って生成されるメディアオブジェクトを、複数
個まとめて空間的・時間的に配置するためのシンタクス・
セマンティクスを提供する。そのために用いられるシーン
記述フォーマットは BIFS (BInary Format for Scene description) と呼ばれ、別途 ISO/IEC SC24 で標準化が進
められている VRML (Virtual Reality Modeling Language) をベースとしている。
VRML とは、「インタラクティブな三次元グラフィクスのイ
ンタネット上の転送フォーマット」、として定義される。簡
潔に言えば、HTML の三次元版である。基本となる概念
は、図 5 に示すシーングラフである。シーングラフでは、
ノードと呼ばれる構成単位を階層的に組み合わせること
で一つのシーンを構成する。ノードとは、光源、形状、材
質、色、座標などをフィールドとして有するシーンの構成
単位であり、さらにそれが子供のノードを持つことでシー
ン記述の階層化を実現する。これらはコンピュータグラフ
ィクスの世界で広く用いられている手法である。
scene
uint(8)
uint(8)
person
uint(4)
uint(4)
byte_aligned
byte_aligned
FlexMux には Simple モードと MuxCode モードの二つが
用意されている。表 6 の中の index が 240 未満である場
合 FlexMux は Simple モードとなり、240 以上の場合は
MuxCode モードとなる。
Simple モードの場合、index の値は FlexMux のチャネル
番号となる。MucCode モードの場合、index から 240 を引
いた値が MuxCode を指す。この MuxCode は ITU-T
H.223 に倣って採用されたものであり、あらかじめ
MuxCodeTableEntry によって定義された多重化テーブ
ルを指定する。これは、多重化のパターンを定義したも
のである。 MuxCodeTableEntry の転送は、後述する
DMIF が担当する、とされている。
voice
2D background
sprite
furniture
globe
audiovisual
presentation
desk
図 5: シーングラフ
BIFS は、当初 VRML を MPEG ライクなフォーマット (バ
イナリフォーマット) に変換するシンタクスを定義すること
からスタートした。ノードも、既存の VRML ノードを部分
的にサポートすることで合意が取られていた。ただし、現
在では、逆にさまざまな独自の拡張ノードを定義するに
至っている。VRML 側ではもともと独自のバイナリフォー
マットを決めるグループがあったのだが、両者合意の上、
これらは MPEG-4 の下で BIFSとして規格化することにな
っている。
参考までに、MPEG-4と VRML の間にはこの他にもいく
つかの共同作業がある。VRML のストリーミング転送、ス
クリプトインタフェース、ブラウザの外部インタフェース、
顔と人体のアニメーション、等が挙げられる。
} else {
predefined;
if (predefined)
nodeType;
isUpdatable;
if (isUpdatable)
nodeID;
maskAccess;
if (maskAccess)
MaskNodeDescription ( )
else
ListNodeDescription ( )
}
3.5.2. BIFS ノード
MPEG-4 のシーン記述ツールとして、基本的には BIFS
は VRML に等価である。しかし、MPEG-4 側で独自のノ
ード拡張を行ったために、VRML とは必ずしも一対一に
対応しないかなり複雑な構成になっている。 BIFS を
VRML の唯一のバイナリフォーマットとする合意の観点
からも、BIFS と VRML の不整合が問題視されている。
BIFS ノードは以下のように分類される。
•
•
•
•
-
共通ノード
VRML ノード (17 個)
MPEG-4 ノード (11 個)
2D ノード (二次元シーン)
MPEG-4 ノード (24 個)
3D ノード (三次元シーン)
VRML ノード (29 個)
MPEG-4 ノード (9 個)
2D/3D 合成ノード
MPEG-4 ノード (5 個)
variable
bit(1)
bit(10)
bit(1)
}
(b) MaskNodeDescription
MaskNodeDescription ( ) {
for(i=0; i<numberOfFields; I++) {
mask;
if (mask)
value;
}
}
上記の分類は、そのまま後述するシステムプロファイル
に関係する。共通ノードは、2D、3D 共通に使われるノー
ドである。2D ノードは、本来 3D である VRML を、
MPEG-4 で二次元のシーン記述用に定義し直したもの
である。ノード名は、接尾に –2D と付けることで判別さ
れる。3D ノードは、三次元のシーン記述に使われる。こ
れには MPEG-4 独自拡張として、人工の顔画像のアニメ
ーションに使うノードが含まれる。2D/3D 合成ノードは、
三次元シーンの中に二次元シーンをはめ込むのノード
で、MPEG-4 独自拡張である。これに対しては VRML 側
からシーングラフの概念を崩すとの批判があったが、CD
には記載されている。
ただし、VRMLノードの Anchor, CylinderSensor, Extrusion, Fog, NavigationInfo, PixelTexture, PlainSensor,
Script, SphereSensor, VisibilitySensor, および PROTO,
EXTERNPROTO は、現在の CD には記載されていな
い。一部はインタネット依存性の排除のためであり、一部
は複雑性の排除のためである。また、 AudioClip ノードと
Sound ノードは、MPEG-4 Audio 用途に変更が加えられ
ている。
3.5.3. BIFS シンタクスの例
表 7 に BIFS のシンタクスの例を示す。基本的に VRML
に準ずるノード記述を MPEG ライクなシンタクスにマッピ
ングする。
表 7: BIFS シンタクス例, (a) SFNode
SFNode ( ) {
isReused;
if (isReused) {
nodeID;
bit(1)
bit(1)
bit(10)
bit(1)
variable
(c) ListNodeDescription
ListNodeDescription ( ) {
endFlag;
while (!endFlag) {
fieldReference;
value;
endFlag;
}
}
bit(1)
variable
variable
bit(1)
isReusedは、VRMLの DEF、USEに対応して使われる。
nodeID はノード名を示す。predefined は、現在の BIFS
で規定されているノードか否かを示す。nodeType は、そ
れが BIFS で規定されているノードの場合、そのノードの
型 (SF-xxx, MF-xxx) を示す。isUpdatable は、そのノー
ドが更新可能であるか否かを示し、更新可能な場合には
前述の nodeID を割り当てる (nodeID がノード更新時の
タグとなる)。maskAccess は、そのノードのフィールドの
符号化に、以下に述べる MaskNodeDescription()と
ListNodeDescription() のどちらのモードを使用するかを
示す。
まず MaskNodeDescription モードを使用する場合、
mask の値に応じて各フィールドの値が符号化されるか
否かが決まる。このモードの場合、フィールドの順番はノ
ード定義に示されている順番に従う。
ListNodeDescription モードを使用する場合、
fieldReference が符号化されるフィールドを明示する。こ
のため、フィールドを符号化する順番は自由である。符
号化の終了は、endFlag によって決定される。
VRML 記述で用いられる整数、浮動小数点、倍精度浮
動小数点などは、そのまま 32 bit、ないし 64 bit で符号
化される。量子化を行うためのノード
QuantizationParameters も定義されているが、後述する
IM1 では今のところサポートされていない。
tion Framework)は、形式上 MPEG-2 DSM-CC の拡張
版としてスタートした。実質的にはシステムパートからネッ
トワーク的な要素を分離・吸収する形で議論が進められ、
ネットワーク (もしくは蓄積媒体) へのインタフェースとし
て機能することになっている。
3.5.4. Object Descriptor との関連付け
図 6 には、MPEG-4 デリバリの役割を示す。MPEG-4シス
テムは、コンテントの具体的な伝送・蓄積形態 (Transmux ) については何ら言及しない。すなわち、これらは
サービス提供者が任意に選択する、としている。そこで
MPEG-4 デリバリは、アプリケーションには透過に、多種
多様な Transmux に共通して用いられるインタフェースの
提供を目的とする。図 1 との対応で言えば、DMIF は
Stream Multiplex Interface を提供する、とされる。CD
14496-6 には、アプリケーションインタフェース (normative)、ネットワークインタフェース (informative)、DMIF と
ATM、H.323、H.245 との関係、などが記述されている。
MPEG-4 Systems では、BIFS 自身が一つのエレメンタリ
ストリームとして扱われる。BIFS のストリーム情報は、セッ
ション開始時に送られる initialObjectDescriptor に含まれ
る。その後、BIFS 用のチャネルが開かれ、 BIFS が転送
される。それから、個々のストリームのオブジェクトディス
クリプタが転送される。
BIFS 中のオブジェクトにはurlフィールドを持つものがあ
る (MovieTexture, AudioClip 等)。このurlフィールドを介
して、シーン中のオブジェクトとオブジェクトディスクリプタ
(さらにはエレメンタリストリーム) が関連付けられる。表 8
に、url フィールドの BIFS シンタクスを示す。 isOD フラ
グに応じて、オブジェクトディスクリプタの ID 番号、もしく
は URL そのものが符号化される。
media related
ESI
表 8: BIFS シンタクス例 (SFUrl)
SFUrl ( ) {
isOD;
if (isOD)
ObjectDescriptorId;
else
url;
}
Systems Layer
DAI
bit(1)
delivery related
Delivery Layer
bit(10)
図 6: MPEG-4 デリバリの役割
variable
3.6. 参照ソフトウェア (IM1)
ビデオ、オーディオグループと同様に、システムでも参
照ソフトウェアの作成が進められている。これは IM1 と呼
ばれ (implementation 1 の略)、二次元、三次元それぞ
れについて C++ベースの開発が進められている。San
Jose 会合では、さらにすべてのサブグループを含んだ形
で作成を進めることが決定された。
3.7. システムプロファイル
システムプロファイルは、シーン記述能力に基づいて以
下の 5 つが定められている。さらに San Jose 会合におい
て、簡易なシーン記述のみをサポートする Ultra Simple
BIFS profile の追加が合意されている。
•
•
•
•
•
Compression Layer
オーディオ (オーディオ関連ノードのみ)
2D (共通ノード+2D ノード)
3D (共通ノード+3D ノード)
VRML (VRML ノード、互換性のため)
コンプリート (すべてのノード)
4. CD 14496-6 (デリバリ)
MPEG-4 デリバリ (DMIF: Delivery Multimedia Integra-
5. バージョン２
バージョン 2 では、以下の項目が検討対象になる。
•
Intermedia Format (旧ファイルフォーマット): ラ
ンダムアクセス機能他を備え、伝送手段とは独立
に定められるサーバ上のストリームデータの共通
フォーマット。San Jose 会合で提案評価が行わ
れ、Quick Time をコアとするドラフト案が採択され
た。
•
AAVS (Adaptive Audio-Visual Session Format): MPEG-4 端末に対する各種プログラムイン
タフェースの規定を目的とする。VRML の EAI
(External Authoring Interface) などとの関係も議
論されている。
6. むずび
MPEG-4 システムについて概説した。MPEG-4 システム
は、明確なアプリケーションを想定した規格ではない。逆
に汎用性を想定した、きわめて自由度 (抽象度) の高
い構成になっている。筆者の予想では、アプリケーション,
ネットワークに依存しない共通フォーマットとしての使用
が、実際の運用形態になるものと思われる。
参考文献
[1] ISO/IEC JTC1/SC29/WG11 N1901: “Text for CD
14496-1 Systems,” Nov.1997.
[2] ISO/IEC JTC1/SC29/WG11 N1906: “Delivery Mult imedia Integration Framework,” Nov.1997.

Download Report