MPEG 4系统浅谈

提要：

MPEG-4是1998年12月正式发布的，旨在为视、音频数据的通信、存取与管理提供一个灵活的框架及一套开发的编码工具，它用在64Kbit/s以下的低速率视音频编码十分有效。MPEG-4与MPEG-1、MPEG-2相比，最重要的特征有：(1)编码是基于对象的。它把图像和视频分割成不同的对象，对每一个对象的编码形成一个对象码流层，该码流中包含着对象的形状、位置、纹理及其他方面的属性。对一幅图像编码所形成的码流由一系列对象层码流构成，用户可直接对“对象层”进行存取操作，这样就使得操作、控制对象成为可能，而传统的编码都是基于帧的，无法对对象进行操作。(2)MPEG-4可根据现场带宽和误码率的客观条件在时域和空域有灵活的可扩展性。时域扩展是在带宽允许时在基本层上的增强层中增加帧率，在带宽窄时在基本层中减少帧率；空域扩展是指对基本层中的图像进行插值，增加或减少空间分辨率，以达到充分利用带宽，使图像质量更好。

为了实现上面所说的功能，MPEG-4将音视频码流的语法层次分为视频会话VS、视频对象VO、视频对象层VOL和视频对象平面VOP。一个完整的视频序列由若干个VS构成。VO是给定场景中的一些具体对象，是用户能够存取和操作的实体。若干个VO构成一个VS；VOL是表明VO的空间和时间分辨率的一个类型，与空间和时间分级性密切相关。每个VO可有多层VOL；VOP是VO在某一时刻的表象，即某一帧VO，MPEG-4对每个VOP独立进行编解码。

本文力求简明地阐述MPEG-4系统的内容和特点，并部分地与MPEG-2系统做了简要的比较。

0 引言

MPEG-4标准的目标与以往MPEG 1/2标准有了很大的不同，眼光更为远大，应用前景也更为广阔。MPEG-4的主要目标是：

a．基于对象的压缩标准；

b．具有可交互性；

c. 码率的宽范围适应性(5k~10Mbit／s)。

由于以上所确定的目标，给MPEG-4带来了许多变化，例如：强调了低码率(5～64kb／s)的编码标准，对H263的兼容扩展，加强了MPEG4标准在互联网上的应用适应性。这些目标所带来的变化在MPEG4系统中有了更多的体现。总之，MPEG4标准在使用技术的先进性上有了很大的提高，这一方面是由于多媒体技术发展成就的，另一方面也是用户需求不断提高推动的。

1 MPEG 4的主要技术概览

摘 要：简要介绍了MPEG－4标准的主要内容，并在此基础上着重介绍了音频对象的编码和视频对象的编码。

1、多媒体传输集成框架

多媒体传输集成框架(DMIF)主要解决交互网络中、广播环境下以及磁盘中多媒体应用的操作问题，通过传输多路合成比特信息，建立客户端和服务器端的握手和传输。与过去不同的是，由于MPEG-4码流中，包括许多的AV对象，一般而言，这些AV对象都有各自的缓冲器，而不仅仅是视频缓冲器和音频缓冲器。

2、语法描述

MPEG 4定义了一个句法描述语言来描述AV对象比特流表示和场景描述信息。这个句法描述语言是对C++的扩展，不仅易于表达其AV对象特性，而且也易于软件仿真实现与模型验证。与MPEG 4相比，MPEG 1和MPEG 2则采用一种类Ｃ语言的描述，MPEG－4描述语言反映了面向对象技术来描述对象。

3、音频对象的编码

视频音频的压缩编码自然仍是MPEG-4的核心所在。不过，与以前的MPEG-1、MPEG-2不同的是：MPEG-4不仅支持自然的声音(如语音和音乐)，而且支持基于描述语言的合成声音，支持音频的对象特征。即一个场景中，同时有人声和背景音乐，它们也许是独立编码的音频对象。

3．1、自然声音编码

MPEG-4研究比较了现有的各种音频编码算法，支持2~64Ｋ的自然声音编码。如8kHz采样频率的2~4kbit/s的语音编码，以及8或16kHz采样频率4~16kbit/s的音频编码，一般采用参数编码；6~24kbit/s的语音编码，一般采用码激励线性预测(CELP)编码技术；16kbit/s以上码率的编码，则可采用时频(T/F)变换编码技术。这些技术实质上借鉴了已有的音频编码标准，如G.723、G.728以及MPEG-1和MPEG-2等。图1是MPEG-4的可伸缩自然音频编码器示意图，包括了3种编码技术。

3．2 合成声音

在合成声音编码当中，MPEG-4引入了2个极有吸引力的编码技术：文本到语音编码和乐谱驱动合成编码技术。这为网络上低比特率下交互的带有语音的游戏铺平了道路。事实上，合成声音编码技术即是一种基于知识库的参数编码。特别值得一提的是MPEG-4的乐谱驱动合成技术，在该技术中，解码器是由一种特殊的合成语言--结构化的音频管弦乐团语言(SAOL)驱动的。其中的"管弦乐团"是由不同的"乐器"组成的。当解码器不具有某一"乐器"时，MPEG-4还允许解码器从编码器下载该"乐器"到解码器，以便正确恢复合成声音。可见，MPEG-4不是提供一组角MIDI音乐标准中的"乐器"，而是提供了一个可随时扩充的"管弦乐团"，因此其可"演奏"乐谱自然更加丰富多彩。

4、视觉对象的编码

同样，MPEG-4也支持对自然和合成的视觉对象编码。合成的视觉对象如2D、3D动画，人的面部表情动画等，这些合成图像单独编码，不仅可有效压缩，而且还便于操作。

对自然视觉对象的编码，仍是MPEG-4的重点。相对于静止图像，MPEG-4采用零树小波算法(Zero tree Wavelet algorithm)以提供高压缩比，同时还提供多达11级的空间分辨率和质量的可伸缩性。

对于运动视频对象的编码，MPEG-4采用了如图2所示的编码框图，以支持图像的编码。可见，MPEG-4为了支持基于对象的编码，引入了形状编码模块。为了支持高效压缩，MPEG-4仍然采用了MPEG-1、MPEG-2中的变换、预测混合编码框架。对于一般的任意形状的视频对象，MPEG-4编码后的码流结构见图3。

对于实时的极低比特率的应用，如可视电话，MPEG-4视频编码采用极低比特率视频(VLBV)核进行编码，类似于ITU的H.263直接对矩形视频编码，而不采用形状编码模块。编码后的码流结构见图4。

可见，MPEG-4采取了向前兼容H.263，同时，也提供了一些高层特性，如基于内容的编码。其扩充的方式见图5。

MPEG－4支持有误码信道传输下的鲁棒性，提供了更好的同步和误码恢复机制。

5、场景描述

场景描述主要用于描述以上单个的AV对象如何在一个具体AV场景坐标下的组织与同步等问题。同时还有AV对象和AV场景的知识产权保护等问题。

6、MPEG-4展望

MPEG-4的应用将是广泛而深远的。这一新的标准将至少可以应用于以下场合：

² 实时多媒体监控；

² 极低比特率下的移动多媒体通信；

² 基于内容存储和检索多媒体系统；

² Internet/Intramet上的视频流与可视游戏；

² 基于面部表情模拟的虚拟会议；

² DVD上的交互多媒体应用；

² 基于计算机网络的可视化合作实验室场景应用；

² 演播室和电视的节目制作。

2 MPEG4系统

正是由于上述MPEG4标准目标的特点，决定了MPEG4系统的特殊性或者说是与以前MPEG 1/2系统的不同。可以说，MPEG4系统的内容和特点与上述MPEG4标准的目标是密不可分的。

MPEG4 System 规范了标准的整体结构，并且定义了MPEG4 Visual和MPEG4 Audio如何合成在一起，此外还包括多路复用、同步和缓存管理。MPEG4 System引入了BIFS的概念(Binary Format for Scence)。BIFS定义了MPEG4的许多交互性的内容。所有关于媒体对象、场景描述的信息或是控制信息都包含在基本码流中。基本码流是信息的载体。基本码流包含由标签或指针，叫做对象描述子。对象描述子描述了构成MPEG4流的基本元素并决定了MPEG4流是如何在接收端解码的。对象描述子能使接收端识别出送来的媒体类型并正确地重现它。这允许内容的作者决定媒体对象的层次并将无信息加入到媒体流中。所有基本流都在同步层中进行存储。同步层确保基本流使用公用的系统来传输时间和帧信息。这里先做一简单地介绍，后面再详细介绍。MPEG-4系统的组成内容如下：

² 系统解码器模型，这是每一个系统都应该有的特殊模型

² 场景描述(Scence DescriPtion)

² 对象描述框架(Object Description Framework)

² 基本码流同步(同步层)

² MPEG-J

² 基本码流的多路合成

这六大部分基本上概括MPEG-4的系统的主要内容。

2.1 系统解码器模型

系统解码器模型(SDM：System Decoder Model)提供了对MPEG4终端行为的一种抽象描述。目的是在接收端重构使场景得以重现的AV信息时，允许发送端能够预测接收端是如何根据缓冲区管理和同步信息进行动作的。系统解码模型包括定时模型和缓冲区模型。系统解码器模型定义了以下内容：

² DAI接口；

² 用于存储单个基本码流的解码缓冲区；

² 基本码流解码器的解码方式；

² 存储解码数据的合成存储区；

² 从各个合成存储区中将数据输出到合成器的方式。

从图1的系统解码器模型中我们可以看出，MPEG-4系统解码缓冲区通过DAI(DMIF Application Interface)获得码流数据，DAI解复用得到同步层打包的数据包流，按其包头指示的类型送往相应的解码缓冲区，并在到解码缓冲区之前去除包头，累积成AU(Access Unit)单元(这一工作可以由ESI完成，AU单元由产生基本码流的实体决定，长度不定，例如对于H263来说，AU单元就是一帧图象的数据)后送入对应的解码器进行解码，每一AU单元解码后得到的媒体数据对应于一个或多个CU单元，将其送往合成存储区，在这里如果有必要就进行重新排序，最后再在CTS(合成时间标记)的时刻送往合成器。

2.1.1 DMIF和 DAI

在图1系统解码器模型中首先是DIMF应用接口(DAI)。要讲到DAI，必须要先提到DMIF(Delivery Multimedia Integration Framework)，译为：发送多媒体集成框架。从这一名称就可以猜到DMIF是集成了现有诸多相关发送协议的一个集成框架，目的是最大限度的利用这些协议标准并避免功能的重复定义。许多协议标准都已支持一些DMIF的概念，这一工作是与相应的标准组织协调完成的。让这些协议标准具有DIMF的可扩展件，可以使DIMF直接使用这些标准。DIMF提供了网络、广播和文件访问方式的抽象描述，以方便内容提供商们完成一次的内容对发就可以将其应用于不同的传输技术手段；而不再像MPEG-l/2那样必须有自己特殊的传输环境要求。为什么会产生这个DIMF呢？MPEG-4的设计目标之一是为了应用的广阔性和bit率的宽范围适应性，而MPEG组无法知道发送应用的具体情况，因此干脆将传送方式的决定权留给了根据特定网络传输方式的服务提供商。就是这个原因，标准将发送和压缩处理成两个独立的结构。DIMF规范了MPEG-4流与不同网络技术和协议的接口。DMIF提供了MPEG-4流的全面的发送结构。就其内容的范围而言，可以这么说：MPEG-4系统 DIMF=传统意义上的MPEG 1/2系统。DMIF并不在MPEG-4系统规范中，而是单独作为MPEG-4标准的一部分。原则上来说，所有的DIMF的原理已经被考虑到了适应接收端和发送端的操作。

而连通DMIF和MPEG-4 System之间的桥梁就是所谓的DAI(DMIF Application Interface)。DAI终于浮出水面了。DMIF定义的这个叫做DAI的接口，用来在应用的开发与发送技术分离开后作为它们之间的接口。通过DAI，应用可以从本地存储设备，从广播通道以及从远程服务器中无缝地访问内容。而且，不同地发送技术被隐藏起来，如IP和本地ATM、IP广播和MPEG2广播。系统终端解码器就通过DAI来访问媒体流。一个DAI滤波器处理请求并且决定DIMF的类型，对该DIMF的请求是基于由应用所提供的URL的基础之上的。相对于所需的传输技术类型，一个应用能够请求不止一种DIMF服务。例如，一个DMIF可以指定IP多点传送的同时另一个DIMF能够指定卫星广播，在这一点上DIMF被设计成支持在多种传输技术和协议之上同时传输多个流的技术。DMIF实现了相当于OSI的对话层。而DAI则代表话路服务程序访问点(SSAP：Session Service Access Points)，即，在DAI下面集成了不同的传输服务程序访问点(TSAP：Transport Service Access Points)。

将发送细节从对多媒体软件开发中分离出来，通过DAI无缝的访问本地存储和广播发送通道，可以使得多媒体软件的开发在继续研发和不断完善的同时不必关注或是担心新的发送技术的发展或成功。通过DAI接口传输与QoS有关的媒体，应用能够表达它们对QoS的需要而无需具备对专门发送技术的知识。DMIF中的这一规则使应用可以仅开发一次。然而MPEG-4终端并不是完全有必要遵循DAI，因为DAI将MPEG-4模型中与发送有关的部分(DMIF)和与发送无关的部分(系统)分离开来，从而允许应用脱离下面的发送技术而独立开发。然而，个仅仅专门用于本地存储的实现可以设计成最优化地使用其专门类别的发送媒体。机顶盒也会有同样的考虑，即可以将机顶盒专门设计成仅从 MPEG2 广播发送中获取内容。而如果应用的开发需很大的灵活性，例如，从不同发送媒体无缝的访问数据，包括本地存储和广播，DAI的使用将给开发者提供很有利的条件。

2.1.2 定时模型和缓冲区模型

与MPEG-2系统一样，MPEG-4系统也定义了定时模型和缓冲区模型，并且非常类似。

定时模型定义了时间参考机制，这样接收端就能够以此建立起时间的概念并处理与时间有关的事件。这样就允许接收端在跳过或不跳过某种特别媒体时仍可以保持同步，就如同在处理用户交互事件时一样。定时模型要求传输数据流中显示或隐式地包含时间信息。并定义了两种时间信息：时钟参考(CR)和时间标记(TS)。时钟参考常用来传输发送端相对于接收端的时间。时间标记用来传输特定事件的时间，例如，已编码的音视频信息的各个部分期望解码的时间，或是合成时间。

缓冲区能使发送端监视和控制在对话期间每一单独基本码流解码所需要的缓冲区的资源。所需要的缓冲区资源在对话开始前以基本流描述子的方式被送到接收端，这样接收端就可以决定是否有能力处理这一对话。在某些信息从缓冲区删除时，本模型允许发送端指定和调整数据的传输，使接收端的缓冲区不出现溢出。

2.1.3 基本码流接口(ESI)

基本码流接口(ESI：Elementary Stream Interface)是一个概念上的接口，规范了哪些数据是要在生成基本码流的实体与同步层之间进行交换的。在编码层和同步层之间传递的不仅仅是压缩的媒体，还有附加的信息，如时间码，AU单元的长度等。

然而，ISO/IEC 14496-l的一个实现不是必须要有ESI的。也可以是将SL－pscketized 流(后面会讲到)的解析和媒体数据的解压缩在同一个解码器中综合完成。要注意的是，即使这样，解码器在输入端通过DAI接收到的是打包序列而不是数据流。

欲从同步层接收基本流数据的ESI接口有许多参数，这些参数反映了在解析输入的SL-packetized流时接收到的一端的信息：

ES.receiveData (ESdata，dataLength，idleFlag，objectClockReference，decodingTimeStamp，compositionTimeStamp，accessUnitStartFlag，randomAccessFlag，accessUnitEndF1ag，accessUnitLength，degradationPriority，errorStatus)

对于将基本码流发送到同步层有类似的接口，它要求下列参数随后会在同步层上被编码：

ESI．sendData(ESdata，dataLength，idleFlag，objectClockRefence，decodingTimpStamp，compositionTimeStamp，accessUnitStartFlag，randomAccessFlag，accessUnitEndFlag，accessUnitLength，degradationPriority)

解码器及时准确地于定义的时刻从解码缓冲区中抽取AU单元后进行解码，解码得到一个和多个CU(Composition Unit)单元，送入合成器。一个解码器和多个解码缓冲区对应，即单个解码器可以解码多个同类型的基本码流。特别注意的是，因为MPEG-4标准支持多种类型的媒体，这里的解码器就不仅仅指MPEG-4视频格式的解码器了，也可以是其它视频格式的解码器、如MPEG2和MPEG1，还可能是静止图象地解码器，如Jpeg的解码器，音频的解码器或是其它格式媒体的解码器。不管传送任何一种格式媒体，都可以在这里挂上相应的解码器，这也是一种很好的扩展方式。例如，现在目前非常流行的Flash媒体格式，MPEG-4标准中没有定义支持这种格式，但是第三方可以较容易的将支持Flash的解码器挂到系统上，作为自己独特的应用，目前此项工作正在进行中。

2.1.5 合成器

合成器从合成存储区中获得CU单元，或处理之或略弃之，例如，对AV数据来说就要合成并显示。ISO/IEC 14496-l标准(系统)并没有规范合成器，因为合成器的具体过程与系统解码模型没有关系。合成器在具体应用时，采用软件或硬件手段将AV数据合成显示来达到实现的目的，例如在软件实现时采用OpenGL的方式来完成AV数据的合成与重现。

2.2 现场描述

MPEG-4的最大的特点是基于对象，即将媒体元素，例如跑动的汽车，行动的人，背景，声音等等作为对象来进行单独的编码。而场景描述就是用来说明如何有效的根据AV对象的时间和空间属性将它们有效的组织起来。场景描述就是规定了场景中AV对象的组织方式，即通过空间和时间位置的方式实现之。这样的信息足以使得将各个AV对象分别解码重构后，组合和重现它们。在编码端，将场景描述的信息进行编码，在解码端再将场景描述信息恢复出来，AV对象就可以根据这些信息恢复原始的AV场景了。为什么要将场景描述信息与AV对象分离开来呢？这是因为场景描述信息是场景结构的属性而不是单独AV对象的属性。因此，它也要用单独的流来传输。这对于bitstream的编辑和本质上讲是基于内容MPEG-4的功能实现都是非常重要的。对于bitstream的编辑，可以在不解码bitstream的情况下就改变AV对象的组合以及它们的内容。而如果对象的位置是对象bitstream的一部分，这一点就很难做到。

2.2.1 场景描述原理

场景描述作为MPEG-4 System规范的一部分，描述了用于传输时空位置信息的格式，这些信息描述了个别AV对象如何组成一个场景，它说明了对象如何在时间和空间上组合成MPEG-4场景；场景于何时、如何进行更新。这其中当然也包括属于用户交互的信息，如场景中的某一对象如何响应用户的交互行为。这些信息构造的层次方式可以用一颗树来表示。这样一棵树的叶节点总是表示AV对象，还有其它节点用来实现分组，空间转移等功能。这样的分层结构使得场景的构造和内容的编辑简单化。这一结构和场景描述性能惜助于VRML的一些概念，并包括所有VRML的节点和一些MPEG-4自己特有的节点，MPEG-4所定义的附加节点可以适用于纯2D环境。只要熟悉VRML，就很容易理解场景描述这一部分，它们的原理，用法和用途几乎是一样的。只不过MPEG-4在VRML的基础上做了补充和改进。VRLM有着优秀的场景描述的机制，MPEG-4正是看中 VRLM的这种优势，而的确VRML技术给MPEG-4带来了很大的方便。

图2就是场景描述的一个具体实例的结构，它带给我们的这样一个场景：一个正在讲话(voice)的老师(person)站在黑板(2D background)前，旁边有一张放有地球仪(globe)的桌子(desk)，该图包括了由一些基本媒体对象组成的混合媒体对象。基本对象对应于树的叶片，而合成媒体对象则包含了整棵树或是某个枝条。就像图中所示：如果那位在讲话的"老师(person)"这一视频对象和"配音声(voice)"这一音频对象结合在一起，就构成了一个"老师在讲话"的音视频混合对象。这样的分组允许创作者构建复杂的场景，也使得客户对这些对象作自己有意义的操作。场景描述采用如图2所示的树状结构，是为了便于增加场景的编辑和交互功能。树的每个叶节点都是一个基本节点，它对应一个基本流，任何一个子(叶片)节点的父节点是混合节点，混合节点主要用于场景的编辑和组合。在实际的应用中这种结构并不是"静态结构"(VRML就是"静态结构")而是"动态结构"，即用户能够实施添加、删除和改变节点的操作。与VRML相比，MPEG-4有了更大灵活性。

为了允许用户对显示的AV信息进行更有效的操作，MPEG-4系统规范提供对交互操作的支持。交互机制与场景描述综合在一起，通过连接事件源和目的地的方式实现，就如同连接了一条路线，又好比传感器一样(特殊的节点在特殊的条件下可以发出事件)。这些事件源和目的地是场景描述节点的一部分，因而允许停止即将到来的特定场景的动态和交互的行为联结。MPEG-4标准并没有规定专门的用户接口或是机制来进行用户行为(如：敲击键盘或鼠标移动)对事件的映射。本地或用户端的交互行为通过BIFS的路由和传感其机制来实现。像这样的交互性行为不需要上传通道。MPEG-4标准叶也提供了用于客户一服务器对话交互的手段，这通过建立上传基本流通道来实现。

2.2.2 场景描述内容

MPEG-4根据VRML开发了一种自己的二进制语言用来进行场景描述，这就是BIFS-BInary Format for Scenes(二进制场景格式)。MPEG-4的BIFS就是VRML交互机制在MPEG-4中应用的体现。BIFS使用的是参数方法，场景描述由一些带有属性和其它信息(包括事件源和目标)的节点构成的编码层次(树)组成。树中的叶节点表示特定的AV对象(媒体对象)，但是有一些媒介节点来实现分组，空间转移和其它操作(场景描述节点)。BIFS可以随着其更新升级而不断改进。BIFS目的就是携带场景描述信息，它实际上就是一个协议：首先它规定了如何重现MPEG-4对象的场景图(在任意时间和空间上放置MPEG-4对象)，实现对象的动画和可交互行为以及对这些元素的发送加以时序化和同步化；其次，它还是一种有效的对数据进行重现和发送的压缩工具；另外，它还定义了事件处理、对象组合的节点和运行规则。

图3显示了"BIFS内容"，从中我们可以看出BIFS进行场景描述的大体流程。这里值得注意的是，从图中"场景图管理"部分我们可以看到，BIFS在对VRML节点支持的基础上进行了扩充。MPEG-4传送的对象包括VRML节点和MPEG-4独有的MPEG-4节点，这就进一步说明了MPEG-4对VRML的兼容和改进。

BIFS采用了BIFS-Command机制，它能够改变场景图的任何属性。例如：Transform节点可以修改对象在空间中的移动，Material节点能够改变对象的外观，几何节点的域可以整体或部分的改变对象的几何外形等。总之，节点和行为可以增加和删除。为了修改场景，发端必须发送一BIFS-Command帧，其中包括一条或多条更新的命令，这其实就是图3中的BIFS-Update ES，它用于在给定的时刻及时地修改场景的一系列属性。BIFS提供了两种描述场景变化的机制，对于修改场景连续变化的参数就需要用到动画方案来解决--"BIFS-Anim"机制，这一机制可以对特殊节点的域作连续的更新，整合不同类型的动画，如对带有网格、2D/3D位置、旋转、伸缩因子和颜色属性的脸部模型完成动画的能力。

MPEG-4容许用户交互式地操作各种对象，这种交互式可以分为两类：客户端交互和服务端交互。客户端交互就是改变场景描述节点的属性，如使某个对象可见或消失、通过鼠标或键盘改变对象的位置或3D对象的视点以及文本对象的字体和尺寸等，这些操作都是在解码端完成，不需要改变码流的内容。客户端的交互性可以进一步分为简单目标操作类型和事件常规类型。前者(如重新定位，隐藏，改变属性等)不需要来自于MPEG-4的标准化支持。后者(如超链接．触发等)就需要MPEG-4的标准化支持。当服务端在终端和发送端间要求通信时，位于一个MPEG-4的本地终端的客户端就响应。服务器端交互是通过用户在解码端进行操作而服务端对该操作进行相应的反映来实现的，显然这种交互需要上行通道。注意，服务端的交互性也需要MPEG-4的支持。MPEG-4的系统组目前正致力于将需求特性最小化，且不限制应用场合和在主机上的应用不对操作环境有特殊要求，这样将有利于交互性更好的实现。这一切就正是使用了VRML模式的路由机制。

图4展示了一个完整的MPEG-4多媒体系统，从图中可以看到，MPEG-4将AV对象、场景描述信息、对象描述子等作为基本码流进行传输，依靠场景描述信息和对象描述子将AV对象组合、生成多媒体交互式的场景。注意：场景描述仅仅描述场景的结构。将这些目标放置在同一显示空间的行为称作组合。将来自于同一显示空间的对象传输到专门的播放设备(即扬声器和显示窗口)的行为称作生成。但是在MPEG-4系统规范中，并没有规定专门的组合和重现算祛和结构，因为他们是依赖于具体的应用实现的，例如，就PC应用来说，在Windows系统下和在Linux系统下，不同软件应用都会有各自的组合生成算法实现。注意，图2所示的"场景描述树状结构"就是图4中的“场景描述信息”部分。

2.3 对象描述框架

前面讲到，为了方便创作、操作和交互工具的开发，场景描述与基本媒体对象的码流应该分开独立编码。对用于场景描述的参数的确认要进行专门的处理。这就要靠不同的参数来做到。就像一些参数用来提高一个对象的编码效率(如视频编码算祛中的运能动矢量)，还有一些用来修饰一个对象(如该对象在场景中的位置)。因此MPEG-4应该允许，在使用后面这些参数作修饰时，不需要将基本的媒体流解码，这些参数置于场景描述中而不是原始媒体对象中。

为了实现上述的独立编码，MPEG-4增加了VRML没有的"对象描述子"(OD:Object Descriptor)来增强其功能的灵活性。场景描述并不直接从其基本流参考，而是从专门制定的这一媒体对象--对象描述子。

MPEG-2系统中也有描述子的概念。MPEG-4系统中的描述子与MPEG-2系统中的描述子在形式上差不多，都是以8位标签值开始，标签值之后是各自的数据字段，只是少了描述子长度这一字段。两者在作用上有相同之处也有区别。MPEG-2系统中的描述子是原始流描述子，用来扩展原始流定义的结构，提供了一种可扩展定义的识别方式。因为使用8位标签故总共可定义256个描述子，而标准有明确定义的只有15个。这15个描述子更具有“描述”的含义。例如：视频流描述子用以识别视频编码标准(ITU-T Rec．H．262 ISO/IEC 13818-2或ISO/IEC 11172-2)中描述的视频原始流编码参数；多路复用缓冲区描述子用以识别所描述的多路复用缓冲区的配置信息。

而MPEG-4系统中所用到的描述子叫做对象描述子(OD)，虽然也是描述子，但是前面的定语已经不同，这就决定了它的性质和作用起了变化。MPEG-4系统中，对象描述子的主要作用是提供一种间接的机制便于将场景结构、媒体对象同所用传输设备分离开来，这样他们之间的运行不会相互影响。这些描述子用来识别、描述和将有关的基本码流联系起来，还可以将基本码流和场景描述中的AV对象联系起来。OD也使用8位的标签即总共256个描述子，标准有明确定义的是32个(还可能有扩充)。MPEG-4的描述子有一大特点就是可以嵌套：一个描述子可以包括多种类型的描述子(如：OCI，IPMP，Language描述子)，而每一类型的描述子可以多达几十上百，这样做的目的是在描述基本码流及其属性时，基于码流所对应的对象描述子可以包含不同的附加描述子，等效于将这些描述子看作其部件，因此，标准将这些描述子称作对象描述子的部件。而正是由于可以嵌套的缘故，所有的描述子都被看作对象描述子的部件。另外，MPEG-4中对象描述子也以相同和不同的方式实现了MPEG-2系统中流描述子的部分功能，例如，MPEG-2系统中注册描述子的语法：

语法

因为MPEG-4是基于对象的，所以用面向对象的语言来描述。但不难看出两者对注册描述子的定义相差无几。而且对语义的说明也是类似的。当然MPEG-4增加了许多新的描述子的内容。

负责有效组织描述子的机制正是对象描述子框架。其目的是识别，描述和关联AV场景的各种部件的基本流。一个对象描述于集合了一个或多个基本流描述子，因此这些基本流描述子都与这一对象描述子有关，它们提供了单个对象(媒体对象或场景描述)流的配置及其它信息。每一个媒体对象都必须要有指向一个对象描述子的基本流数据，这通过数字标识符-ObjectDescriPtorID方式实现。基本流描述子包含流来源的信息，其方式可以使用唯一数字识别符(the Elementary Stream ID)或URL来指向流的远程来源。ES Ids在传输复用层(TransMux layer)分派给特定的传输通道。ES描述子还包含编码格式的信息，解码处理和同步层打包的配置信息，以及流传输的服务质量(QoS)需求和智能属性识别信息。流之间的依赖关系也可以表示，例如，在可分级的音视频重现情况下就要指示增强层对其基本层的依赖关系，又或者是同一语音内容在不同种语言下的有效性应用。

初始化对象描述子是对象描述子的部件之一，在最初访问符合MPEG-4标准的内容时就要利用它。在它被接收以后，客户端就会根据其指向接收BIFS流和OD(对象描述于)流，该OD流中的许多对象描述子解码后有很多的用途：用于建立场景中某一对象同实际媒体流的联系；用于识别媒体流的类型，用于设置缓冲器的大小等等。一句话，对象描述子框架的目地就是使得基本流相互之间以及媒体对象之间可以识别开并正确地建立联系。

对象描述子同场景描述和AV对象一样都在其专门的基本码流(对象描述码流)中传输。该码流可以动态的地传输更新和删除完整的对象描述于，或是其描述子部件。更新和删除行为的发生是靠基本码流结构中除描述子之外的另一内容：对象描述子命令(OD Command)。一个对象描述码流的AU单元由一个和多个对象描述子命令，或者说要在同一时刻进行处理的所有OD命令组成了单独的一个AU单元。对象描述子和其部件都作为描述子命令的一部分进行传输，命令执行了对这些对象描述于和其部件的“更新”或“删除”操作。标准定义了6条OD命令：

命令

MPEG-4中提供了智能属性管理和保护(IPMP)框架，允许MPEG-4终端使用一个或多个IPMP系统。一个IPMP系统是非标准部件，其利用IPMP基本码流和描述子所带的信息，保护那些对终端有效的符合国际标准14496的内容。IPMP系统的语义和解码过程不在系统中规范，只规范了IPMP系统的接口。

2.4 MPEG-J

MPEG-J是MPEG-4的扩展，允许在MPEG-4的内容中使用Java语言。Java的代码可以修改场景，部分的参与场景交互机制以及控制媒体的解码。它还能够产生图形用户界面(GUI)的部件直接实现应用功能。但是Java代码不能放入实时媒体数据流中。例如，在实现视频解码时，Java代码不能加入，这是为了确保媒体解码的高质量。Java代码将在自己的基本码流中传输并由MPEG-4终端接收，而且使用专门的节点和规则的对象描述子工具来与场景进行关联。

因为MPEG-J只是辅助工具，本文只做简单介绍。MPEG-J在标准规范中有相当长的篇幅，其详细内容，请参见标准。

2.5 基本码流同步(同步层)

同步层(SL)指定基本码流数据打包成AU单元或是AU单元的一部分的语法。这样的数据包成为SL数据包。基本码流是任意数据源的基本抽象。同步层中，一个基本码流产生的一个数据包序列，就称为同步层打包流(SPS：SL-packetized stream)。打包信息用来在生成基本码流的实体和同步层之间交换信息，这两层之间的抽象接口就是前面讲到的基本码流接口(ESI)。同步层打包流通过在DAI中描述的传输机制来传输，传输机制指明同步层与与其之间需要交换的信息，这一传输数据的基本特征是同步层产生数据的成帧方式。基本流在码流多路复用接口处以同步层打包流的方式传输。这种打包方式附加了时间和同步信息，碎片和随机访问信息。从SL中提取时间信息能够使解码同步化，并且随后将基本流数据合成。同步层和ESI以及DAI的关系见图5。

AU单元是同步层中唯一需要在端到端保护的语义数据。它们的内容是不透明的，这也就是说同步层对基本码流数据打包以AU单元为单位。一个SL数据包有一个SL包头和一个有效载荷(payload)组成。SL包头提供防止数据丢失的连续性检测方祛，并且携带有编码表示的时间标记和相关信息。SL包头不是固定，而是可以配置的。一个SL数据包中并没有其长度指示，因此组帧方法即AU单元的恢复就必须用一个低层协议来实现，例如用MPEG-4提供的FlexMux工具。因此SPS不是一个自包含的数据流，不能靠自身解包，如果不重新组帧恢复AU单元是不能存储和解码的。

前面说过，SL包头的目的是防止数据有效载荷丢失，并携带有编码表示的时间标记和相关信息，而不与数据有效载荷的内容发生直接关系。有效载荷是不透明的。因此一个SPS并不能在SL包头中提供识别标识基本码流的ES_ID功能。而这种关联就必须靠传输机制中适当的发送信号的方法通过一个码流映射表来表达。

2.6 基本码流的多路合成

解复用提供了提供了传输/存储工具和其它系统层之间的接口。其基本的功能是从下载流通道(到达终端)中恢复基本流以及复用上传流数据到上传通道(离开终端)。这些基本流载有对象数据，场景描述信息，或是对象描述子。系统设计了两层的复用：传输复用(TransMux：transport multiplex)和MPEG-4复用(FlexMux)。

TransMux不在MPEG-4规范之中，它可以是现存的或是将来任意一种复用工具。TransMux是第一层(最底层)的复用层，是为了数据的交织并确保它们通过通讯媒质的传输。为了建立服务的最大灵活性和应用设计，该层并没有规范在MPEG-4系统中。然而对这一层的接口却被很好的定义了，这样就允许MPEG-4内容的传输通过任意类型的传输层工具(例如，ITU-T推荐的H．22x，MPEG-2 Transport Stream，IETF RTP，MPEG-2 TS)。

FlexMux层提供了一种数据交织的灵活方式并且是一种用以识别数据流的AU单元的最小工具。它并不意味着能够抗差错，因为它可以放置于具有抗差错性能的TransMux层的上面。FlexMux层完全定义MPEG-4中，但它的使用具有可选性并不带有标准的强制性：如果愿意，应用可以直接操作在传统的传输层(TransMux)上，不使用它，仍然是完美合格的MPEG-4系统。但是该结构对于各种通讯环境中配置MPEG-4提供了显著的灵活性。FlexMux是系统设计者们可能乐意使用的应用级别的复用工具。

FlexMux是ISO/IEC 14496-1(系统)中规范的工具，但是它也可以有效地使用ISO/IEC 14496-6(DMIF)的实现中。DMIF为配置FlexMux提供了信号方式。DAI在控制平面和使用平面中提供了原始方法，这种原始方法将发送技术细节和FlexMux细节隐藏与DAI之上：即在DAI之上的应用仅管理基本码流而不包括FlexMux码流，从而意识不到FlexMux的存在。该模型在接收端已经证明是有效的了，但还需要在发送端进行进一步的考虑。

FlexMux作为一种灵活的复用工具，能够容纳瞬时bit率变化的多个SPS的交织。FlexMux的基本数据实体是一个FlexMux数据包，其长度是可变的，并可内嵌一个或多个SL数据包。FlexMux 工具提供了识别来自不同基本码流的SL数据包的能力，这一点是通过定义FlexMux通道数目的方式做到的。每个SPS都被映射到一个FlexMux信道，因此包含来自不同SPS数据的FlexMux数据包就可以任意的交织。交织在同一码流中的FlexMux数据包序列就称为一个FlexMux码流。

FlexMux提供了两种特征和复杂度的操作模式，它们是Simple模式和MuxCode模式。用Simple模式和MuxCode模式可以使得FlexMux包含任意混合的FlexMux数据包。在Simple模式中，一个FlexMux数据包只封装一个SL数据包；而在MuxCode模式中，一个FlexMux数据包可以封装一个或多个SL数据包。

3 结束语

MPEG-4系统是MPEG-4标准得以实现的重要部分，由于MPEG-4的应用实现不仅仅只涉及到MPEG-4 AV格式的自然媒体对象，还有人造媒体对象，以及场景环境和交互性，这就使得包含这些内容的MPEG-4系统显得特别重要。

MPEG-4系统与传统的MPEG-l/2系统有了许多区别。基本的区别在于MPEG-4的主要任务在于将自然/人工AV对象的显现进行编码。因此，系统层就必须解决这些对象如何组合成一幅场景，以及用户如何与这些对象进行交互。此外，基于对象的这种结构有必要使得AV信息可以在进行多路复用时得到修改。MPEG－4系统将发送机制分离出去，形成独立的DMIF标准规范之一，使得MPEG-4有着非常灵活的复用结构并且不需要像MPEG-2一样的传输层的工具(即MPEG-2的TS和PS结构)，这用灵活的复用结构依靠"对象描述子(Object Descriptor)"来实现，正是这种结构用以描述基本流，并将基本流联系起来以构成场景描述。

系统部分是直接与应用紧密联系的。相信MPEG-4会象MPEG-1和MPEG-2的巨大成功一样，会不断有更新更好并给用户以极大方便和乐趣的应用出现。