MPEG—4 系统浅谈(二)
发布时间:2006-10-14 4:15:32   收集提供:gaoqian
梁铁毅 上海三洲迅驰数字技术有限公司总工程师
  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

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

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

摘自《中国CATV》
 
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50