2.2.3 媒体对象流数据的描述和同步

　　一个MPEG-4影音场景的例子媒体对象可能需要在一个或多个基本流中传输的流数据。对象描述符把与媒体对象相关的所有流中区分开来。这就允许处理分层编码数据、内容变化信息的联系（称?quot;对象内容信息"）和相关的知识产权。每个流自身由一套配置信息的描述符所区别，例如用来决定需要编码源和编码的时间信息精度。而且描述符可以携带传输需要的QoS的线索（例如最大位速率、位差错速率、优先级等）。基本流的同步是通过基本流内单个访问单元的时标实现的。同步层管碚庋?姆梦实ピ?褪北甑氖侗稹６懒⒂诿教謇嘈椭?猓?貌阍市硎侗鸪龇梦实ピ?睦嘈突指疵教宥韵蠡蚓跋竺枋龅氖被???夷茉谄浼涫迪滞?健８貌愕挠锓?梢远嘀址绞脚渲茫?市碓谛矶嘞低持惺褂谩?

2.2.4 流数据的传输

　　在不同QoS的网络中从源到目的的流信息的同步传输，是由上述的同步层和包含两子层的复合传输层确定的。第一个复用层根据MPEG-4标准的Part6中的DMIF规范进行管理。这种复用可在MPEG定义的FlexMux工具中体现，该工具允许以低复用费用组合基本流（ESS）。例如该层的复用可用来组合相似QoS需求的基本流，减少网络连接数或者端-端延迟，TransMux（传输复用）层搭建了提供匹配需求QoS的传输服务的层。MPEG-4仅确定了该层的接口而具体的数据包和控制信号的规划必须与各传输协议上有权的实体进行协商。任何现存的合适的传输协议栈，例如（RTP）/UDP/IP、（AAL5）/ATM或者MPEG-2在适合链路层上的传输流都可能成为TransMux的实例。选择权留给了最终用户和服务提供商，而允许MPEG-4用于广泛的运行环境中。
　　FlexMux复用工具的使用是可选的，如果下层的TransMux实例提供了所有要求的功能，该层必须为空。而同步层总是存在的。以下是可行的：
　　1． 识别访问单元，传输时标和时钟参考信息以及检测数据丢失；
　　2． 传输控制信息以实现：
　　* 为每个基本流和FlexMux流指示需要的QoS；
　　* 翻译这样的QoS需求为实际网络资源；
　　* 连接基本流到媒体对象；
　　* 转换基本流的映射为FlexMux和TransMux通道。
　　部分控制功能在和DMIF框架这样的传输控制实体联结后才可实现。

2.2.5 与媒体对象交互

　　总体来说用户看到的是依据作者设计组合而成的影象。然而，用户和影象交互的可能性依赖于作者所允许的自由度。用户可能被允许进行的操作包括：
　　* 改变景象的视/听点，例如在景象中漫游；
　　* 把景象中的对象拖到不同的位置上；
　　* 点击特定对象以触发一系列事件，例如开始或终止视频流；
　　* 多语言音轨时选择想要的语言。
　　更复杂的动作也能被触发，例如一个虚拟的电话铃响，用户接听并建立通信链路。

2.2.6 知识产权的管理和识别

　　能够在MPEG-4媒体对象中识别出知识产权是重要的。为支持这一点，MPEG与不同制造商的代表就语法定义和工具进行合作。MPEG-4通过存储唯一标识来实现识别，该标识由国际编号系统公布。该数字可用于识别媒体对象的当前所有者。因为并非所有的内容都由此数字识别，MPEG-4 Version1提供用关键值对来识别知识产权的可能。而且MPEG-4为想使用控制访问知识产权的系统的人提供一个紧密结合进系统层的标准化系统的人提供一个紧密结合进系统层的标准化接口。通过该接口，所有权控制系统可轻易地与解码器的标准化部分组合。
2.3 MPEG-4 标准的技术细节

　　显示了从网络（或存储设备）来的流作为TransMux流，复用为FlexMux流并传给适当的获取基本流的FlexMux解复器的。基本流（ES）被解析并传递给适当的解码器。解码是从编码形式中恢复出AV对象中的数据并进行必要的操作以重建初始的AV对象以备在适当设备上演示。重建的AV对象可为影象演示中的潜在需要组合成层。解码的AV对象和影象描述信息都被用来组合作者所描述的影象。用户可在作者允许的程度上与最终演示展现的影象交互。

2.3.1 传输多媒体集成框架DMIF

　　传输多媒体集成框架DMIF（Delivery Multimedia Integration Framework）是在通用传输技术上的管理多媒体流的会话协议。原理上与FTP相似，唯一也是基本的差别是FTP返回数据，DMIF返回获取（流）数据的指针。类似地，当DMIF运行时，第一个动作是和远端建立会话。然后，选择流并发要求（request）流注，DMIF对端将返回连接流注点的指针，并建立连接。
　　MPEG-4终端（接收侧）的主要部分与FTP相比，DMIF既是框架又是协议。DMIF提供的功能是由称为DMIF应用接口（DAI）的接口来表达，并翻译为协议消息。这些协议消息可能基于运行的网络而不同。服务质量同样为DMIF设计所考虑，DAI允许DMIF用户为所需的流指定要求。这样就要求DMIF执行时保证要求得以实现。DMIF规格提供了在几个新网络类型，例如Internet上实现该任务的线索。
　　DAI也用来访问广播介质和本地文件，这意味着在多传输技术上定义访问多媒体内容的单一、统一的接口 。
　　因此，我们适合这样说，DMIF的集成框架涵盖了三种主要技术，交互网络技术、广播技术和磁盘技术。DMIF如此以至依赖于DMIF通信的应用不必关心底层的通信方法。DMIF执行以处理关于简单应用接口的传输技术细节。应用通过DMIF应用接口访问数据，无论该数据来自广播源、本地存储器或远端服务器。在所有的情况下本地应用只通过统一接口（DAI）交互。不同的DMIF实例考虑到采用传输技术的特性把本地应用翻译为送至远端应用的特定消息。类似地，（从远端服务器、广播网络或消息。类似地，（从远端服务器、广播网络或本地文件）进入终端的数据通过DAI统一地传给本地应用。不同的、特定的DMIF实例被管理各种特定传输技术的应用唤醒，虽然这对于应用是通明的，它只是和单一的"DMIF过滤器"交互。该过滤器负责为特定DAI向正确的实例粗定向。DMIF不规定该机制，只假设它是运行的。这在该图的阴影框内有所强调，目的是澄清DMIF应用的边界，此时DMIF通信构架定义了若干模块，实际的DMIF应用只需要在边界上保持他们的表现。这样，通过例如基于IP的或ATM的网络访问的"真实的"远程应用，和从广播源或磁盘获取内容的模拟远端制造者应用。然而在前一种情况中，两实体间交换的信息必须规范定义以确保互操作性。在后一种情况中，两个DMIF实体间的接口和模拟远端应用在单一实现中不需考虑该规范。对于广播和本地存储，该图展示了一条"本地DMIF、远端DMIF（模拟）、远端应用（模拟）"的链条。该链条只表达概念化模型而不需对应为实际实现（全部在阴影区内）。
　　DMIF构架考虑广播和本地存储时，假设模拟远端应用了解数据如何发送和存储。如何可以得到处理中的应用种类的信息。对于MPEG-4，这实际就是如基本流ID、首对象描述符、服务名之类的概念。虽然DMIF层理论上不了解正提供支持的应用，由于（模拟）远端应用的存在，对广播和本地存储等特殊情况该概念并不完全正确 。因为（模拟）远端应用不了解数据是如何传送/存储的，对于这样的DMIF应用数据传送/存储的细致描述是无意义的。
　　而当考虑远端交互时，DMIF层是完全不了解应用的。引入附加接口-DMIF网络接口（DNI ）以确定DMIF对需要交换何种信息。该附加模块负责把DNI原语映射为特定网络使用的消息。应当注意DNI原语只是为信息目的所指定，并不需要在实际应用中表现DNI接口。为了支持相同的终端多传输技术甚至多场景（广播、本地存储器、远端交互），DMIF支持允许一个或多个DMIF实例同时出现，每个面对特定的传输技术。多传输技