适应网络传输的复合多媒体数据格式

适应网络传输的复合多媒体数据格式车轶廖春元史元春清华大学计算机科学与技术系，北京，100084摘要：随着网络技术的不断提高，越来越多的多媒体数据在网络上传输。如何在传输、特别是自适应的传输中保证复合多媒体文档中的同步语义是一个难点问题。本文为此设计实现了一种集成数据流格式ISF（IntegratedStreamFormat），通过时间戳解决网络传输中各种数据的同步问题，并且支持多种媒体格式，扩展性非常好，特别考虑自适应传输的需求，可因不同的网络带宽、用户要求和终端处理能力，提供当前有限条件下最好的服务质量。关键词：多媒体复合文档自适应传输同步服务质量1．前言当今世界已经进入了网络时代，网络成为信息的主要载体，传输媒介更是多种多样，各种媒体格式的数据都被应用其中，如文本、图片、网页，以及音频、视频等等。目前，对于这些多样的媒体数据，都是分别处理的。而在应用中，复合的多媒体文档往往具有更实际的应用语义，因而我们希望有一种格式统一地组织和存储多媒体数据，以使传输的数据有一个完整的文件备份，可以方便地进行管理。另一方面，这个数据格式还要有比较好的扩展性，可以比较容易地加入新的数据类型，这样即便将来出现了更多种的数据，这种格式只需稍加扩展便可继续使用。同步问题被认为是多媒体系统的一个重要特征1，由于传输的复合文档是各种媒体的集成，所以保证同步是格式的一个重要内容。例如，在两个人进行讨论的一个计算机会议中，就存在音频/视频的唇同步，以及屏幕显示中鼠标指针的移动与讲话的同步，这都属于现场同步，目的是准确再现一个演示中在采集过程就存在的时间关系。又例如，在用来生成复合多媒体对象的系统中，我们要定义对象间的时间关系，这就属于合成同步，目的是在演示时保证以制定的同步关系按时显示各个对象。由于复合文档要在网络上传输，很可能丢帧、乱帧，就很容易导致同步出错。不管是现场同步，还是合成同步，丢帧、乱帧都有可能破坏了它们的时序关系。这就要求数据的格式应该有较好的容错能力，当出现丢帧、乱帧的情况能够很方便的判断，并且加以处理，不至于引起崩溃性的后果。随着Modern、ISDN、PDA等等的出现，上网方式呈现出多样化。但是技术的多样性和应用的普遍性带来了一系列新的问题，其中之一就是单一的信息源和相异的应用之间的矛盾2。应用的差异性表现于网络性能、终端设备和用户对信息的选择等三个方面。首先，数据传输网络的性能存在异构性，不同用户接入Internet方式不同，而且网络中各中间节点的处理能力和负载可能会随时间而动态变化。其次，网络终端设备多种多样，它们的性能和应用范围也各有千秋。此外，用户的职业、爱好、个性的差异使得他们对信息的选择也各不相同。而另一方面，现有的大部分网络信息资源却忽视了这些差异性，“一视同仁”地只提供“静态”的数据，而不是根据存在的异构性“动态”调整信息质量。使得高性能的终端不能获得更好的视频质量，而手机用户只能对网上的大量资源“望网兴叹”。这就要求我们考虑在网络传输时，对于不同的网络带宽、用户要求和终端处理能力，传输的数据质量做到有所不同，要在现有条件下提供昀佳的服务质量。而作为一个基础，数据格式本身就要提供相应的灵活性。比如，用户希望中途变换视频压缩算法，以便更好的适应网络环境时，格式可以方便地改变，而不影响文件的完整性和播放性能。2．相关研究由于在这种多媒体复合文档中，音频/视频数据在内容上占据较大比例，在处理上也相对复杂一些，所以，我们要以音频/视频为主线，在其功能完善的基础上再考虑添加其他格式的数据。我们对目前已有的媒体数据格式做了一些研究，一方面可以看到这些格式比较成熟的地方，从中得到启发，另一方面也可以发现现在格式的不足之处，从而进行弥补，昀终得到一个满足网络多媒体复合文档传输的要求的格式。2.1AVIAVI是一个成熟的视频格式，它是标准的RIFF结构，采用流的形式控制文件，采用帧做数据单元，接口很完善，通用性也很好，但在网络传输上有明显的不足之处：第一：AVI格式主要是针对视频和音频的数据而制定的，没有考虑文本、图形、超文本网页等等不同的格式。第二：AVI格式播放的帧率是固定的，一旦丢帧、乱序，就会同步出错，从而出现画面播放不连续不自然的情况。第三：在AVI文件中，经常是同一个流的保存在物理位置上是连续的，同一时间播放的不同流的数据，如音频数据和视频数据在文件存放的位置可能相隔比较远，这样有可能需要接收完整个AVI文件，才能够进行播放，这样就不适合网络上在线播放。第四：AVI文件中视频流和音频流压缩的格式是固定的，而用户也许会希望中途改变压缩算法以便更好的适应网络环境。这正是我们自适应传输的要求，而AVI是不满足的。2.2ASFMicrosoft提出了一种ASF3文件格式。ASF文件格式更加适合网络传输的特点，它不需要传输完整个文件，而是在传输的同时就可进行回放。同时ASF文件也加入了一些新的特性，比如可以播放幻灯片，可以有一些同步的事件发生。但是ASF与实际需求还是有一定差距。集中体现在：第一：ASF对文本、图片、超文本文件等的支持还不是很充分。第二：ASF没有考虑自适应传输时变换格式的需要。第三：ASF文件的一些API尚不够完善，给编程带来了一些不便。2.3MediaFormat7Microsoft推出的WindowsMediaFormat7SoftwareDevelopmentKit（SDK）4提供了一种文件格式以及相应的接口，以支持音频、视频和脚本数据的Internet和本地局域网上的传送和回放。由于这种格式增加了一些比较新的内容，有很多可以借鉴的地方，所以进行了比较详细地研究。它支持大多数的音频、视频格式，并包含其他的一些数据，如未压缩的脚本（Script），标记（Marker）和索引（Index）。脚本由两个字符串组成，一个是类型字符串，一个是参数字符串，都是Unicode编码的，而且是可任意长的空结束字符串。已经有一些预定义的类型：URL，FILE，CAPTION，OPENEVENT，EVENT。而且，我们可以自己定义类型。标记和索引是两个不同的概念。标记可以应用于任何类型的媒体文件（通常是音频和视频文件），它们是文件的作者所加上的，一般是为了标记某些比较特殊的位置，以便以后找到。而索引只能应用于视频文件，不包含其他的任何信息。索引是由SDK创建的，提供了一个基于时间的方便查找的方法。不管是什么类型的数据流，它们都有一些公共的特性。比如这些媒体样本数据在操作前，都存在INSSBuffers里面，这样数据就可以高效的被应用。这些数据也拥有一些相关的参数，比如说：流编号（streamnumber），时间戳（timestamp），标志（flag）。流编号用来识别媒体样本中正在处理的唯一的流；时间戳用来表明媒体播放的过程中样本数据何时播放；标志用来指示媒体样本的某些属性。MediaFormat7的文件格式很好的实现了媒体流在网络上的传输和在线播放；它增加了的时间戳的概念，比较好的解决了时间同步的问题；它对脚本数据的支持使一些文本文件可以在网络上输出；它还有索引功能并且支持各种编码格式。这些功能都比较好地满足了我们的要求，但是在其它方面，它还存在着不足之处：第一：MediaFormat7没有对图片和超文本文件等其他格式的支持，这与实际中我们会使用到这些格式的信息不符。第二：我们只能运用这种格式提供的接口编写应用程序，而看不到这种格式的内在结构，这在应用的灵活性和格式的扩展性上都有不便之处。第三：在网络自适应传输方面，这种格式也有所欠缺。它不能中途改变压缩编码的方式，而我们希望能够随着网络环境的变化动态的改变压缩编码，以更好地利用网络带宽资源。3．一种集成数据流格式：ISF根据前面的研究情况，我们可以发现已经开发出来的格式在某些方面多少都会有一些欠缺，虽然一些格式适应于网络的传输和播放，但是其对某些媒体数据的支持并不全面，而且对网络资源的自适应方面也不够灵活。但是，我们从中得到了一些启发，比如时间戳，视频音频交替存储，索引，流编号，等等，这都应用到我们昀终制定的数据格式：集成数据流格式IntegratedStreamFormat，即ISF中。3.1可扩展的格式结构ISF格式采用流的形式来组织多样的数据，目前我们定义了4种流：音频流、视频流、事件流和系统流。主要的音频、视频数据存储在音频流和视频流中；事件流则拥有播放同步的一些事件信息，它可以包括显示一段文本，调用某个网页，绘制某个图形等等；系统流在整个文件中只有一个，其作用是给出整个文件和其它所有流的相关信息，它包括有格式帧和信息帧。ISF格式的结构如图1。在ISF文件中，每个流都有一个流ID，唯一标识当前的流，并且指出流的类型。系统流在整个传输过程中只有一个，其ID是唯一固定的。数据的存储单元是一帧，所有的数据都存储在所属流的某一帧中。每一帧由两部分组成：多媒体数据描述符（帧头）和多媒体数据（帧数据）。多媒体数据描述符对多媒体数据进行了比较充分的描述，其中就有流ID一项，通过它可以判断出当前帧究竟是什么流，若是音频流、视频流或是事件流，就可以进一步在系统流的格式帧中读取对应的格式。这样，ISF格式便有很好的扩展性，从而可以对多种媒体的支持。由于每一帧都有帧头表明该帧属于何种流，而我们提供的接口都是针对不同的帧类型采取相应的处理方法，所以实际上，如果我们需要增加某种帧，只需增加一种类型的流，再有相应的处理方式就可以了。为了可以在网络上实时播放，ISF文件不像AVI那样会将一个流的帧都放在一起，以致于同一时间播放的视频帧和音频帧在物理存储位置上离的很远。我们总是将视频帧和音频帧，或是其他的事件帧，基本上按照播放的时间顺序在ISF文件中存储，这样用户就可以边下载边播放了。在流数据的后面还存有流定位信息，它的作用是定位所有的流及其对应的格式信息，为流控制提供接口。对于系统流，其格式帧数为零，也就不必有格式帧的信息了。如果文件已经录制好，我们还可以在昀后加上一个可选的索引块。根据索引块可以对索引的帧进行方便的定位和搜索。当然，在实时传输回放的过程中，不必也不可能传输索引块。文件头数据流定位信息索引（可选）Frame0Frame1Frame2Frame3．．．Framen-1多媒体数据描述符系统流帧格式描述符流ID格式帧信息帧说明性的信息指定流的具体格式若是属于系统流多媒体数据描述符若属非系统流多媒体数据同步字符流ID时间戳数据长度n为文件中帧的个数流ID对应格式帧数k格式帧0的信息流起始位置格式帧1的信息．．．格式帧k-1的信息流结束位置在文件中的位置有效期起始时间有效期结束时间第1个流的定位信息第2个流的定位信息第3个流的定位信息．．．第s-1个流的定位信息s为文件流的个数文件标识符版本号状态字流定位信息的位置索引块的位置索引块标识符索引块大小帧的流ID帧的时间戳帧在文件中的位置索引块头部距离文件末尾的相对偏移帮助从文件尾部定位索引块索引块头部索引项1索引块定位索引项2索引项i-1．．．i为索引项的个数图1ISF格式的结构3.2以时间戳控制同步同步问题是我们要解决的一个大问题，因为多媒体复合文档在播放时，总是会涉及现场同步，或是合成同步。同步一旦出现问题，会大大地影响播放质量，甚至可能引起崩溃性的后果。我们采用了时间戳，很好地解决了同步问题。对于每一帧，我们都在帧头中加入时间戳一项，用来表明帧数据的播放时间。全局使用一个时间轴，根据时间戳可以判断乱帧等情况并做相应的调整。对于音频、视频的帧数据，Render（我们基于DirectXMedia开发的可以播放一帧数据的播放器）可以按照时间戳进行播放；对于其他事件帧，也可根据时间戳按时显示。这样，就可以处理丢帧、乱帧的情况了。由于我们把每一帧都加上了时间戳，而播放器也是按照时间戳来播放的，所以帧的乱序自然不是什么问题。即便丢帧，播放器也不会在该播放这一帧的时间里，播放其他帧，而只是延续前一帧的状态，这样就不会产生时序的错误，比如提前播放了下一帧。总之，一切都遵循时间戳来操作，同步将不会成为问题。由于实际上，Render在播放音