流媒体文件格式在流媒体系统中占有重要地位，设计合理的文件格式是提高流媒体服务器工作效率最直接和最有效的办法。该文在剖析常用流媒体系统和文件格式的基础上，特别地对美国xiph.org基金会的开源流媒体工程Ogg文件格式子项目做了深入的分析，指出Ogg格式对媒体编码数据的存储读取和传输具有简洁性，Ogg格式的映射与逆映射与媒体编码数据具有相对独立性，能够有效提高流媒体服务器的工作效率。
摘 要 流媒体文件格式在流媒体系统中占有重要地位，设计合理的文件格式是提高流媒体服务器工作效率最直接和最有效的办法。该文在剖析常用流媒体系统和文件格式的基础上，特别地对美国xiph.org基金会的开源流媒体工程Ogg文件格式子项目做了深入的分析，指出Ogg格式对媒体编码数据的存储读取和传输具有简洁性，Ogg格式的映射与逆映射与媒体编码数据具有相对独立性，能够有效提高流媒体服务器的工作效率。
1 引言
流媒体是指在Internet/Intranet中使用流式传输技术的连续时基媒体，如音频、视频等多媒体文件。文件格式和传输协议是流媒体应用的主要技术。从不同的角度看，流媒体数据有三种格式：压缩格式、文件格式、发布格式。其中压缩格式描述了流媒体文件中媒体数据的编码、解码方式；流媒体文件格式是指服务器端待传输的流媒体组织形式，文件格式为数据交换提供了标准化的方式；流媒体发布格式是一种呈现给客户端的媒体安排方式。本文所讨论的格式是指第二种：流媒体文件格式。特别地分析了一种开源流媒体文件格式：Ogg。它是美国xiph.org基金会开发的开源流媒体工程的一个子项目，它是应其开源音/视频媒体压缩编码格式Vorbis/Theora等的存储与传输需要而设计的。
本文在研究和分析已有流媒体系统的基础上，结合在研发新的流媒体系统中的经验和教训，对流媒体文件格式做系统和深入的剖析，旨在深入理解流媒体系统和找到提高流媒体系统工作效率的方法。
2 流媒体文件格式分析
2.1 文件格式在流媒体系统中的重要性
一个简化的流媒体系统由流媒体服务器、客户端和传输网络组成，流媒体系统的核心是流媒体服务器。随着流媒体技术研究的深入和流媒体应用的扩展，如何提高流媒体系统的工作效率，主要指标体现为如何提高服务器并发媒体流的数量，这是一个被广泛关注的课题。它取决于服务器处理每个流的效率，决定了一个服务器能够同时为多少客户服务，其成果不但具有理论价值，更具有极大的经济价值。
图1的圆圈内标出了影响流媒体系统性能的一些主要因素。如果对其中每个因素仔细分析判断，可以发现对于一个现有的流媒体服务器而言，能有效提高其效率的手段并不多。例如：提升客户端、服务器端的硬件配置，只能获得性能提高，工作效率没有得到提高；实时传输、控制协议是人们经过多年的大量应用实践总结，由IETF因特网工程任务组确认的媒体流传输共同标准，是必须遵守的标准，是无法轻易改变的；节目源的质量、压缩方式等因素对于服务器而言是不可预知或者是不可控制的。那么在这些客观因素无法改变的情况下，优化流媒体文件格式为提高流媒体服务器的工作效率提供了可能。
流媒体文件格式能够对服务器的工作效率产生影响是由流服务器工作方式的特点决定的。流服务器的主要工作任务是通过直播或点播的方式向用户提供流媒体内容，它输入磁盘上存储的流媒体文件，然后进行实时传输协议封装后再通过 IP网络输出给客户端。简言之，其工作流程为3 步：读取、封装、发送。由于每发送一个媒体流都需要启动一个流程，并且所有流程都需要实时进行，可见当一个流服务器并发几千个流时，每个流程工作效率的细小区别都会对服务器工作效率造成很大的影响。
图1 简化的流媒体系统结构及其影响因素
每个工作流程的输入是流媒体文件，输出是媒体数据包。输入、输出数据的内容是没有改变的，都是多媒体压缩码流，两者之间只有格式的不同，所以从数据流角度来看，服务器的主要工作其实是一个格式转换的过程。由于媒体数据包的格式是由传输协议事先确定的，那么流媒体文件格式是否能够方便服务器读取、封装就决定了服务器的工作量。
2.2 流媒体文件格式的分析与比较
流媒体文件在流媒体系统中具有重要地位，文献[2]分析了具有代表性的QuickTime电影文件(mov)和 Microsoft Media Server的电影文件（asf），对其文件格式和相关环节做了深入剖析。发现这些文件格式对服务器工作效率存在如下负面影响：
(1)磁盘控制器访问吞吐量低。每次封装一个媒体数据包需要读取一帧数据,一般每帧大小为1K左右,每秒需要25帧,这造成对磁盘频繁访问,吞吐量低。
(2)对于QuickTime Mov文件格式,媒体数据没有经过预处理,服务器每发一个包都需要从hint轨中获得打包时需要的相关参数,实时读取媒体数据、封装、发送,对CPU占用率很大。
(3)对于Microsoft Asf文件格式,媒体数据在Packet中时已经是mms包的半成品,服务器节省了截取媒体流的时间,但仍然需要服务器选择媒体流来组织mms包。并且,Packet中的数据不全是需要发送的数据,浪费了内存空间和磁盘IO时间。
文献[3]提出了一种新的流媒体文件格式NMF,该格式具有如下基本结构(如图2所示)和特点:
图2 NMF文件结构
NMF流媒体文件由头文件和体文件构成。头文件主要包含文件描述、媒体描述、流描述等必要的信息；体文件包含全部的媒体数据。一个NMF由一个头文件和若干个体文件构成,同一媒体源不同的流(不同的传输协议或不同的码速率)存放在不同的体文件中,此结构用来实现多码速率切换/智能流技术和兼容现有的流媒体播放器。头文件和体文件的功能划分原则是：当服务器和客户建立连接时(在发送媒体数据之前),只需要从头文件中读数据；当服务器和客户建立连接后,只需要从文件体中读取媒体数据。这样,服务器中各个模块间耦合减少,效率提高。由于头文件和体文件的相对独立,使文件具有很强的可扩展性,并且使得利用硬件进行封装、发送也成为可能。
NMF的核心思想就是充分利用预处理过程,将原始媒体文件组织成方便服务器处理的格式,减少实时封装和发送时的工作量,同时增加文件结构的兼容性和可扩展性,以提高流服务器的工作效率,增加并发流数量。
3 Ogg 文件格式结构
3.1 文件格式在流媒体系统中的重要性
逻辑流以页（page）为单位组织链接成物理流,如图3所示：
图3 Ogg 文件的组织形式
图3中的文件链接了两个物理流，A、B和C三个逻辑流组成一个物理流，逻辑流D单独是一个物理流。一个物理流中的所有逻辑流的bos_page都必须在物理位置上相邻，如图3所示*A*、*B*、*C*三个bos_page的位置。
bos：beginning of stream; eos：end of stream
映射到Ogg格式的媒体(如vorbis音频,Theora视频)有相关详细定义，这些定义使得这些媒体之间有更具体的约束关系。Ogg 本身并没详细说明多个并发媒体流之间的时间关系，这需要并发媒体流在映射到Ogg格式的时刻来指定，通常他们之间的交错关系是按他们产生的时间先后顺序来排列。
3.2 Ogg page 页结构
每个页之间相互独立，都包含了各自应有的信息，页的大小是可变的，通常为4K－8KB，最大值不能超过65307bytes（27＋255＋255*255=65307）。页头部格式如图4。
页头部各字段域详细说明参见文献[4]：（小端字节序列格式LSB）。
⑴ capture_pattern: 模式捕获域，4个字节,表示页的开始，其作用是分离Ogg封装格式还原媒体编码时识别新页的作用，它包含了四个幻数（ASCII字符集）：
0x4f 'O' 0x67 'g' 0x67 'g' 0x53 'S'
⑵ stream_structure_version:1个字节，表示当前Ogg文件格式的版本,目前为0。
图4 Ogg页头部结构
⑶ header_type_flag:头部类型标识，1个字节。标识当前页具体类型。其设置分三种情况：
* bit 0x01 若已设置，页包含的媒体编码数据于前一页同属于一个逻辑流的同一packet。若未设置，本页是一个新的packet。
* bit 0x02 设置，表示逻辑流的第一个页bos。未设，不是第一个页。
* bit 0x04 设置，表示逻辑流的最后一页eos。未设，不是最后一页。
⑷ granule_position:8个字节（字节6－字节13），包含了媒体编码相关参数信息。对于音频流，包含了到本页为止逻辑流在PCM中采样编码的总次数。对于视频流，包含了逻辑流到本页为止视频帧编码的总次数。其值若为－1，则说明到此页为止，逻辑流的packet还未结束。
⑸ bitstream_serial_number:流序列号，4字节，表示本页所属逻辑流与其他逻辑流相区别的序号。
⑹ page_sequence_number: 表明了本页在逻辑流中的序列号，Ogg解码器能据此识别有无页丢失。
⑺ CRC_checksum: 循环冗余校验码校验和，4字节域，包含页的32bit CRC校验和（包括页头部零CRC校验和页数据校验），它的产生多项式为：0x04c11db7。
⑻ number_page_segments:1字节，给定了在本页的segment_tabale域中所出现的segement个数，其最大值为255segments(每片255个字节)，即页头部第26个字节的取值范围为:0x00-0xff (0-255)。页最大物理尺寸为65307bytes,小于64KB。
⑼ segment_table:逻辑流中的每个packet每个segment长度的取值（lacing values，除了每个packet的最后一个segment小于255外，其它segment都为255），这些值以segment出现的先后顺序依次排列。此域的字节数为number_page_segments域所表示的数字（即在0－255之间）。
byte value
27 0xff (255)
[................. ]
n-1 0xff (255)
n 0x00-0xfe (0-254, n=num_segments+26)
页头部长度的字节数:
header_size = 27 + number_page_segments [Byte]
即页头部长度为上述9个域名所表述占据的字节数之和。
页的总长度：
page_size = header_size + sum(lacing_values: 1...number_page_segments) [Byte]
即页的总长度为页头部长度加上紧随其后的若干segments长度之和（净载荷长度）。
3.3 Ogg封装处理过程
(1)音视频编码在提供给Ogg封装之前是以具有包边界的“Packets”形式呈现的，包边界依赖于具体的编码格式。如图5所示。
(2)将逻辑流的各个包进行分片segmentation，每片大小固定为255Byte,但包的最后一个segment通常小于255字节。因为packet的大小可以是任意长度，由具体的媒体编码器来决定。
(3)进行页封装，每页都被加上页头，每页的长度可不等，由具体情况而确定。页头部segment_table域告知了 “lacing_value”值的大小，即页中最后一个segment的长度（可以为0，或小于255）。一次处理一个packet，此packet被封装成一个或多个page页（page的长度设定了上限，一般为4kB）；下一个packet必须用新的page开始封装，由首部字段域header_type_flag的设置规定来表示。
(4)多个已被页格式封装好的逻辑流（如语音、文本、图片、音频、视频等）按应用要求的时序关系合成物理流。
3.4 Ogg文件的映射与逆映射
用Ogg文件格式封装好压缩编码媒体流可用于存储（磁盘文件）或直接传输（TCP或管道），这是因为Ogg比特流格式提供了封装/同步、差错同步捕获、寻找标记以及其它足够的信息使得这种分散开的数据能够完全地还原为封装之前的具有包边界“packet”形式的压缩编码媒体流，恢复到这种原来媒体流就具有的包边界形式不需要依赖于针对压缩编码的解码器。也就是说Ogg映射与逆映射和媒体流的压缩编码、解码具有相对独立性。
图5 Ogg封装流程示意图
Ogg文件需要解封装的情况有两种：（1）播放器要对媒体流解码之前；（2）对媒体流进行RTP/UDP传输之前。解封装的过程就是ogg逆映射过程，即还原为具有包边界“packet”形式的媒体流，同时以预先填充好了的RTP首部字段与相应一段媒体数据捆绑，形成RTP封包。此过程便是媒体流从Ogg格式到RTP格式的转换过程。
将以packet为单元的媒体流映射为以page为单元的Ogg格式比特流，其中间经过了segment的划分和重组环节，但方便了对媒体流的存储与传输（TCP）。对源缓冲区媒体数据(packet)的操作，需建立几个中间环节的数据结构，只需将切割的媒体数据在内存移动一次，操作指向媒体数据的指针便能达到媒体数据迁移到目的缓冲区（page）的意图,其过程可用两个函数转换来表述：
ogg_stream_packetin()àogg_stream_pageout()。 将Ogg格式比特流逆映射还原为packets媒体流，以备播放解码或以RTP封装进行UDP传输 。其中间环节是把page中的segment单元数据按顺序重组为packet,同样媒体数据在内存中的复制只有一次，其过程可用三个函数转换来表述：ogg_sync_pageout（）à ogg_stream_pagein （）à ogg_stream_packetout（）,媒体数据复制发生在第一个函数ogg_sync_pageout（）。
Ogg映射与逆映射的功能都体现在ogg函数库中,当前最新版本为libogg-1.1.3。
4 结束语
Ogg格式是在吸收其它流媒体文件格式优点的基础上针对具有“packet”包边界形式的媒体流而制定的利于其存储和传输的开源流媒体文件格式，在icecast流服务器的传输中得到了很好的应用；根据icecast官方网站公布其测试结果，在GB主干网的条件下对Oggvorbis音频传输的客户端并发流可达14000个。更为重要的是,作为流媒体技术的核心环节，大多数流媒体文件格式至今仍没有完全公开，且受专利保护。要在流媒体技术和应用飞速
发展的今天占得一席之地，遵从GNU/GPL协定，走开源之路，发展不受知识产权约束的流媒体文件格式是紧追先进流媒体技术的较佳选择。
几种常见的流媒体格式文件：
微软高级流格式ASF简介
Microsoft公司的Windows Media的核心是ASF（Advanced Stream Format）。微软将ASF 定义为同步媒体的统一容器文件格式。ASF是一种数据格式，音频、视频、图像以及控制命令脚本等多媒体信息通过这种格式，以网络数据包的形式传输，实现流式多媒体内容发布。
ASF最大优点就是体积小，因此适合网络传输，使用微软公司的最新媒体播放器（Microsoft Windows Media Player）可以直接播放该格式的文件。用户可以将图形、声音和动画数据组合成一个ASF格式的文件，当然也可以将其他格式的视频和音频转换为ASF格式，而且用户还可以通过声卡和视频捕获卡将诸如麦克风、录像机等等外设的数据保存为ASF格式。另外，ASF格式的视频中可以带有命令代码，用户指定在到达视频或音频的某个时间后触发某个事件或操作。
ASF的特征
可扩展的媒体类型- ASF文件允许制作者很容易地定义新的媒体类型。ASF格式提供了非常有效的灵活地定义符合ASF文件格式定义的新的媒体流类型。任一存储的媒体流逻辑上都是独立于其他媒体流的，除非在文件头部分明显地定义了其与另一媒体流的关系。
部件下载-特定的有关播放部件的信息（如，解压缩算法和播放器）能够存储在ASF 文件头部分，这些信息能够为客户机用来找到合适的所需的播放部件的版本---如果它们没有在客户机上安装。
可伸缩的媒体类型- ASF是设计用来表示可伸缩的媒体类型的"带宽"之间的依赖关系。ASF存储各个带宽就像一个单独的媒体流。媒体流之间的依赖关系存储在文件头部分，为客户机以一个独立于压缩的方式解释可伸缩的选项提供了丰富的信息流的优先级化- 现代的多媒体传输系统能够动态地调整以适应网络资源紧张的情况（如，带宽不足）。多媒体内容的制作者要能够根据流的优先级表达他们的参考信息，如最低保证音频流的传输。随着可伸缩媒体类型的出现，流的优先级的安排变得复杂起来，因为在制作的时候很难决定各媒体流的顺序。ASF允许内容制作者有效地表达他们的意见（有关媒体的优先级），甚至在可伸缩的媒体类型出现的情况下也可以.
多语言- ASF设计为支持多语言。媒体流能够可选地指示所含媒体的语言。这个功能常用于音频和文本流。一个多语言ASF文件指的是包含不同语言版本的同一内容的一系列媒体流，其允许客户机在播放的过程中选择最合适的版本。
目录信息- ASF提供可继续扩展的目录信息的功能，该功能的扩展性和灵活性都非常好。所有的目录信息都以无格式编码的形式存储在文件头部分，并且支持多语言，如果需要，目录信息既可预先定义(如,作者和标题)，也可以是制作者自定义。目录信息功能既可以用于整个文件也可以用于单个媒体流。
RealSystem的RealMedia文件格式
RealNetworks公司的RealMedia包括RealAudio、RealVideo和RealFlash三类文件，其中RealAudio用来传输接近CD音质的音频数据，RealVideo用来传输不间断的视频数据，RealFlash则是RealNetworks公司与Macromedia公司新近联合推出的一种高压缩比的动画格式RealMedia文件格式的引入了，它使得RealSystem可以通过各种网络传送高质量的多媒体内容。第三方开发者可以通过RealNetworks公司提供的SDK将它们的媒体格式转换成RealMedia文件格式。
QuickTime电影(Movie)文件格式
Apple公司的QuickTime电影文件现已成为是数字媒体领域的工业标准。 QuickTime电影文件格式定义了存储数字媒体内容的标准方法，使用这种文件格式不仅可以存储单个的媒体内容(如视频帧或音频采样)，而且能保存对该媒体作品的完整描述；QuickTime文件格式被设计用来适应为与数字化媒体一同工作需要存储的各种数据。因为这种文件格式能用来描述几乎所有的媒体结构，所以它是应用程序间（不管运行平台如何）交换数据的理想格式。QuickTime文件格式中媒体描述和媒体数据是分开存储的，媒体描述或元数据（meta-data）叫做电影（movie）,包含轨道数目、视频压缩格式和时间信息。同时movie包含媒体数据存储区域的索引。媒体数据是所有的采样数据，如视频帧和音频采样，媒体数据可以与QuickTime movie存储在同一个文件中，也可以在一个单独的文件或者在几个文件中。
