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.