梁铁毅 上海三洲迅驰数字技术有限公司总工程师
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。
图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的巨大成功一样，会不断有更新更好并给用户以极大方便和乐趣的应用出现。（全文完）
摘自《中国CATV》
|