基于H.264的流媒体服务器的设计和实现

随着Internet和多媒体技术的迅速发展，音视频的流媒体传输成为网络应用的热点之一。目前市场上主流的流媒体技术有三种，分别是RealNetworks公司的RealMedia、Microsoft公司的Windows Media和Apple公司的QuickTime。它们都有自己的专利算法、专利文件格式甚至专利传输控制协议这些关键技术。

当前，IPTV、VoD（Video On Demand）、P2P等流媒体技术正在飞速发展，各个著名的IT公司如Apple、Cisco、Sony、SingleMedia等也投入了大量的人力物力开发流媒体相关的产品和提供相应的解决方案。

H.264是最新出现的视频编码标准，它具有比较高的编码效率和良好的网络适应性。目前，支持H.264的流媒体服务器还不是很多，如Apple公司的QuickTime Streaming Server、UT斯达康公司的流媒体视频传送平台MediaStation等。但是，QuickTime Streaming Server需要在传输之前对媒体文件进行处理，这会增加服务提供者的运营成本和系统的复杂度。本文设计的流媒体服务器，无需对多媒体文件进行预先处理，可以直接接受用户的请求并实现实时传输。

一 H.264视频编码标准

1. H.264标准

H.264是ITU-T最新的视频编码标准，被称作ISO/IEC14496-10或MPEG-4 AVC，是由运动图像专家组（MPEG）和ITU的视频编码专家组共同开发的新产品。制订H.264的目标主要有两个：

* 得到高的视频压缩比。最初提出的指标为压缩比提高到H.263、MPEG-4的两倍左右，现在已基本实现；

* 具有良好的网络适应性，即可适用于各种传输网络。

为此，H.264的功能分为两层，即视频编码层（VCL，Video Coding Layer）和网络提取层（NAL，Network Abstraction Layer）。在VCL和NAL之间定义了一个基于分组方式的接口，打包和相应的信令属于NAL的一部分。这样，高效率编码和网络适应性的任务分别由VCL和NAL来完成。VCL数据是编码处理后的输出，它表示被压缩编码后的视频数据序列。在VCL数据传输和存储之前，这些编码的VCL数据先被映射或封装进NAL单元中。

VCL包括基于块的运动补偿、混合编码和一些新特性。NAL负责针对下层网络的特性对数据进行封装，包括成帧、发信号给逻辑信道、利用同步信息等。NAL从VCL获得数据，包括头信息、段结构信息和实际载荷，NAL的任务就是正确地将它们映射到传输协议上。NAL下面是各种具体的协议，如H.323、H.324、RTP/UDP/IP等。NAL层的引入大大提高了H.264适应复杂信道的能力。

2. JM

JM是H.264的官方编解码器，它可以对YUV格式的图像进行编码，并且支持两种格式的H.264文件输出：RTP格式和Annex B格式。本文使用JM对标准的视频测试序列foreman进行编码并分别输出RTP格式和Annex B格式的文件。JM输出的RTP格式的文件结构如表1所示。

长度（LEN）是指除去前8个字节的长度。TS1是JM在编码的时候设置的，目前的值是0xFFFFFFFF，在实际传输数据的时候，这个字段没有用到；随后的12个字节是一个标准的RTP头部；特别要说明的是，H.264的负载类型（PT， payload type）是一个确定的值，为0x69（105）。SSRC的值被设置为0x12345678。

JM输出的Annex B格式的文件结构比较简单，一个起始码（0x00000001）后面是一个可变长度的NAL单元。Annex B详细规定了一种字节流格式的语法和语义，应用程序可以根据这种格式从数据中识别出NAL单元，然后按顺序传输这些NAL单元[1]。

一个H.264 Annex B文件的前两个NAL单元的类型是7和8，分别代表序列参数集（SPS, sequence parameter set）和图片参数集（PPS，picture parameter set）。这两个参数集用来在接收端解码之前对解码器的一些参数进行设置，然后解码器就可以依次解码后续到达的NAL单元。

二 H.264视频传输服务器

1. 服务器设计框架

为了通过RTP进行H.264视频传输，需要把H.264视频数据根据RTP规范封装成数据包。根据RTP的封装规范，H.264采用简单打包的方案，即将每个NALU（包括同时作为载荷头标的NALU头）单独封装成一个RTP包。发送端按照RTP数据包的格式放入数据，并且配置RTP包头的负载类型、序列号、时间戳等参数，形成一个完整的RTP数据包，通过网络发送给接收端，实现端到端的视频流传输[2]。接收端收到RTP包以后，取出包里的NAL单元送给解码器进行解码播放。

本文设计的H.264视频传输框架如图1所示。

视频传输的主要工作为：

* 按照传输的视频文件的特定格式从文件中判断NAL单元的位置，从而读取NAL单元；

* 按照NAL单元的语法，对NAL单元中的头标进行分析，根据NAL单元的类型提取出序列参数集（SPS）和图片参数集（PPS），接收端解码器的初始化中要用到这两个参数；

* 根据RTP协议规范，将NAL单元加上负载类型、序列号、时间戳，形成完整的RTP包；

* 如果NAL单元大于某个给定的数值，还要完成NAL单元的分片[FS:Page]工作。

2. 服务器的主要流程

服务器端的具体流程为：服务器首先根据流的名称和准备传输的文件的类型等信息创建一个会话，并且把这个会话加入到列表中，然后进入监听状态，等待客户端的请求。

当服务器收到客户端的请求时，对请求进行处理，向客户端发送请求响应信息，并且进行传输数据的准备工作。对客户端发出的播放（PLAY）请求中一些字段的值分析完成后，服务器开始向客户端发送数据。

服务器根据得到的客户端的地址，用创建的接收器开始取得数据，这个接收器以字节流模式打开要传输的文件，根据这种文件的特定格式（RTP格式或者Annex B格式）从中读取数据，对头部、数据类型、长度等字段进行计算和解析，然后构建符合RTP标准的数据包，接着通过RTP接口发送到目的地址。这个过程不断继续，直到文件中的数据发送完毕。

数据发送完毕以后，服务器向客户端发送RTCP的“BYE”消息，然后客户端向服务器发送拆除连接的请求，服务器响应这个请求后便结束此次会话。

3. 服务器的实现

根据本文实际传输的H.264的视频文件的具体情况，对RTP包头的设置情况如表2所示。

RTCP用来配合RTP工作，它向发送端提供接收端关于数据包的统计信息，发送端可以利用这些信息进行拥塞控制和流量控制。RTSP协议可以使接收端和发送端进行数据传输过程中的交互，提供诸如播放、暂停、快进、快退等操作。

服务器中与H.264传输有关的几个主要的类为H264ServerMediaSession、H264VideoRTPSink和H264VideoStreamFramer。服务器传输数据时，数据的流向如图2所示。

本文设计的传输H.264文件的过程如下：

* 服务器打开要传输的H.264视频文件，把它作为一个数据源；

* H264StreamFramer取出数据源中的NAL单元，作为一个数据帧，递交给H264VideoRTPSink；

* H264VideoRTPSink给NAL单元，加上RTP包头，通过网络接口发送到接收端，然后调度发送下一个RTP包的任务；

* 重复前两步，直到所有的数据发送完毕。

4. 系统功能测试

服务器运行在Microsoft Windows XP Professional （SP2）操作系统下，硬件配置如下：CPU为AMD Sempron（tm）Processor 2600＋；主频1.6GHz；256MB内存。服务器运行后，客户端可以用VLC[3]和MPlayer[4]播放服务器上的视频文件。

我们用五台计算机同时点播服务器上的H.264视频文件，测试表明：播放器的启动延时在3秒～4秒之间，画面的主观质量较好，与本地播放视频文件时的主观画面质量相比无明显不同，可以满足视频点播的要求。在同时为五个客户端提供服务时，服务器占用的CPU资源不到1%，占用的内存为670KB左右，说明本文设计的H.264视频传输服务器对系统的要求不高，可以同时为较多的用户提供服务。

四 结论

H.264是非常高效的视频编码标准，它将在IPTV、手机流媒体、视频监控等各个领域有广泛的应用。本文针对H.264的两种文件格式（RTP格式和Annex B格式）开发了相应的服务器软件，对于实际应用具有一定的参考价值。下一步的工作包括采用各种方法如自适应编码、多级编码、拥塞控制等来改进视频的传输质量。