针对移动互联网的流媒体服务器的实现
毕柳成，张笑燕**
作者简介：毕柳成，北京邮电大学硕士，计算机科学与技术专业，河北省唐山市人。现主要从事流媒体方
面的开发工作
通信联系人：张笑燕，博士，副教授，硕士生导师。2004 年8 月—2005 年8 月到美国康奈尔（Cornell）大
学作访问学者一年，主要从事Ad hoc 和无线传感器网络方面的研究工作。目前研究方向：通信软件、软件
过程改进、移动互联网. E-mail: zhangxiaoyan@email.buptsse.cn
（北京邮电大学软件学院，北京 100876）
5 摘要：传统的流媒体服务器已经经过多年的发展，日益成熟完善。但面对新兴的移动互联网，
传统的流媒体服务器有其局限性和不适应性。本文探讨了3G 网络或者其他无线移动环境下，
以手机作为终端进行点播服务的流媒体服务器的设计与实现，由于移动互联网以及手持终端
的自身特点，必须解决相关问题，比如手机自身编解码能力问题，手机以及网络环境对协议
的支持等等。另外，在解决以上问题的基础，又需要保证服务器设计的合理性和并发的性能，
10 本文以boost C++库作为工具，对本文的系统进行了良好的设计与实现。
关键词：流媒体；移动互联网；服务器
中图分类号：TP37
 0 引言
30 流媒体是采用流式传输的方式在Internet 上传输的多媒体数据，它在传输的同时播放数
据，并且将播放过的数据丢弃，从而形成稳定的﹑连续的传输流和回放流，使得在低带宽的
环境下也能获得高质量的音频和视频信息。
3G 移动通信网作为日趋完善的无线网络，为流媒体的应用提供了一个崭新的平台，也
为流媒体技术更好的为使用者服务开辟了新的传输媒体。随着手机增值业务的不断发展，视
35 音频流媒体业务将会成为3G 增值业务的一个热点，通过手机实现视频点播、收看视频节目
成为最能吸引用户眼球的业务之一。
移动流媒体是从固网的流媒体发展而来的，但它不同于固网流媒体，其不同表现在以下
三个方面：先是终端，移动流媒体是通过手机或其他的移动个人终端获取流媒体服务；其次
是终端与服务器之间的承载网络，移动流媒体通过移动通信网接入、获取流媒体服务；最后
40 是应用，移动流媒体可以在移动通信网的覆盖范围内自由地获取流媒体服务。
移动流媒体业务的系统结构如图1 所示，它设计到流媒体终端、移动通信接入网、移动
 通信分组核心网、IP 网络、流媒体内容服务器等。其中，流媒体内容服务器（包括媒体制
作和内容管理）、内容缓冲／直播内容采集服务器是移动流媒体系统的核心功能实体。
45 图1 移动流媒体业务的系统结构
Fig.1 system structure of mobile streaming media business
关于流媒体服务器，已有darwin,live555 等开源服务器，已经苹果realplayer 等公司的商
业支持，但其特点都是针对internet 互联网的，而移动互联网又有其自身的点。本文根据移
50 动终端的协议支持，3G 移动通信网的接入特点，以及服务器的传输要求，对流媒体服务器
进行相关设计与实现。流媒体服务器的实现要兼顾到移动终端对于音视频格式的支持，对于
传输协议的支持，以及服务器自身并发性高效性的设计。由于iphone 手机有自身的协议及
格式支持，这里不做讨论，本文针对协议支持范围最广的rtsp/rtp 协议进行说明，并且已经
过android，symbian, windows mobile 等多个终端进行测试验证。
55 1 音视频格式介绍
1.1 音视频格式概述
根据调查，现在的手机终端硬件性能越来越高，对于视频的分辨率也支持的越来越多，
在视频格式上已经逐渐普及支持当今流行的h264 格式，同时也支持过去流行的mpeg4 格式,
除了编码格式外，视频分辨率帧率等相关信息也会关系到手机平台的支持与否，表1 仅列出
60 部分手机系统的支持格式。由于大量的已有机型的存在，为了适应更多的机型，这里针对
mpeg4 格式进行说明。音频格式以amr 为例。
表1 音视频格式
Table 1 video and audio
平台 iPhone OS Android Symbian Windows Mobile
机型 iPhone HTC-G3
Meizu-M8
Lephone
gPhone
N95
N97
5800
E71
HTC-Touch
Dopod-T8388
封装格式 Mpeg 2
ts/Mp4
Mp4
3gp
Mp4
3gp
Mp4
3gp
传输协议 HTTP RTSP RTSP RTSP
分辨率 480×320
320×240
320×240
320×180
320×240
480×320
320×176
480×800
320×176
176×144
视频编码 H.264
Mpeg-4
H.264
Mpeg-4
H.263
H.264
Mpeg-4
H.264
Mpeg-4
H.263
音频编码 AAC_LC
mp3, amr
AAC_LC
mp3,amr
AAC_LC
mp3 amr
AAC_LC
Mp3, amr
 1.2 视频格式mpeg-4
65 MPEG-4 通过层次结构进行管理，层次结构分别是视频场景、视频对象、视频对象层、
视频对象平面组和视频对象平面，层次结构如图2 所示。
VS（Video Session）：视频场景，它位于层次结构的最高层，一个完整的视频序列可以
由几个VS 组成。
VO（Video Object）：视频对象，它是场景中的某个物体，最简单的情况下就是矩形框，
70 它是有生命期的，由时间上连续的许多帧构成。
VOL（Video Object Layer）：视频对象层，VO 的三种属性信息在该层进行编码，该层
主要用来扩展VO 的时域和空域分辨率，实现分成编码。
GOV：视频对象平面组，由视频平面组合，是可选成分。视频对象层即可以由VOP 直
接组合，也可以由GOV 组合而成。
75 VOP（Video Object Plane）：视频对象平面，它可以看作是VO 在某一时刻的采样，即
一帧VO。
图2 视频流结构图
Fig.2 streaming video char
80
1.3 音视格式AMR
AMR 全称Adaptive Multi-Rate，自适应多速率编码，主要用于移动设备的音频，压缩
比比较大，但相对其他的压缩格式质量比较差，由于多用于人声，通话，效果还是很不错的。
首先可分为2 类：
85 1. AMR: 又称为AMR-NB，相对于下面的WB 而言，
语音带宽范围：300－3400Hz，
8KHz 抽样
2. AMR-WB:AMR WideBand，
语音带宽范围： 50－7000Hz
90 16KHz 抽样
本系统采用amr-nb,本文中所提的amr 没有特殊说明，均为AMR-NB。
AMR 有多种编码方式，每种编码方式的采样频率不同：
VS1
VO1 VOn
VOL1 VOLn
GOV1 GOVn
VOP VOP VOP VOP
 表2 不同规格的AMR
Table 2 different specification of the AMR
规格 比特率（kbps） 音频帧大小（字节） 帧头（字节） FT
0 AMR 4.75 13 04 00000100 0000
1 AMR 5.15 14 0C 00001100 0001
2 AMR 5.9 16 14 00010100 0010
3 AMR 6.7 18 1C 00011100 0011
4 AMR 7.4 20 24 00100100 0100
5 AMR 7.95 21 2C 00101100 0101
6 AMR 10.2 27 34 00110100 0110
7 AMR 12.2 32 3C 00111100 0111
95
2 流媒体传输相关协议
2.1 RTSP 协议
RTSP(Real-Time Stream Protocol) [1]是一种基于文本的应用层协议，在语法及一些消息参
数等方面，RTSP 协议与HTTP 协议类似。在rfc2326 中对rtsp 协议进行描述。
100 RTSP 被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。
尽管有时可以把RTSP 控制信息和媒体数据流交织在一起传送，但一般情况RTSP 本身并不
用于转送媒体流数据。媒体数据的传送可通过RTP/RTCP 等协议来完成。
一次基本的RTSP 操作过程是:首先，客户端连接到流服务器并发送一个RTSP 描述命令
（DESCRIBE）。流服务器通过一个SDP 描述来进行反馈，反馈信息包括流数量、媒体类
105 型等信息。客户端在分析该SDP 描述，并为会话中的每一个流发送一个RTSP 建立命令
(SETUP)，RTSP 建立命令告诉服务器客户端用于接收媒体数据的端口。流媒体连接建立完
成后，客户端发送一个播放命令(PLAY)，服务器就开始在UDP 上传送媒体流（RTP 包）到
客户端。 在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。最后，
客户端可发送一个终止命令(TERADOWN)来结束流媒体会话。
110 RTSP 请求消息格式：
方法 URI RTSP 版本 CR LF
消息头 CR LF CR LF
消息体 CR LF
其中RTSP 版本一般都是RTSP/1.0,状态码是一个数值，用于表示Request 消息的执行结
115 果,比如200 表示成功,解释是与状态码对应的文本解释。
2.2 RTP 协议
RTP[2]是一种提供端对端传输服务的实时传输协议，用来支持在单目标广播和多目标广
播网络服务中传输实时数据，而实时数据的传输则由RTCP 协议来监视和控制。
RTP 定义在RFC 1889 中,RTP 协议格式如下：
 前12 个字节出现在每个RTP 包中，仅仅在被混合器插入时，才出现CSRC 识别符列表。
这些域有以下意义：
版本(V)：2 比特 此域定义了RTP 的版本。此协议定义的版本是2。(值1 被RTP 草
案版本使用，值0 用在最初"vat"语音工具使用的协议中。)
145 填充(P)：1 比特 若填料比特被设置，则此包包含一到多个附加在末端的填充比特，
填充比特不算作负载的一部分。填充的最后一个字节指明可以忽略多少个填充比特。填充可
能用于某些具有固定长度的加密算法，或者用于在底层数据单元中传输多个RTP 包。
扩展(X)：1 比特 若设置扩展比特，固定头(仅)后面跟随一个头扩展。
CSRC 计数(CC)：4 比特 CSRC 计数包含了跟在固定头后面CSRC 识别符的数目。
150 标志(M)：1 比特 标志的解释由具体协议规定。它用来允许在比特流中标记重要的事
件，如帧边界。
负载类型(PT)：7 比特 此域定义了负载的格式，由具体应用决定其解释。协议可以规
定负载类型码和负载格式之间一个默认的匹配。
序列号（sequence number）：16 比特 每发送一个RTP 数据包，序列号加1，接收端
155 可以据此检测丢包和重建包序列。序列号的初始值是随机的(不可预测)，以使即便在源本身
不加密时(有时包要通过翻译器，它会这样做)，对加密算法泛知的普通文本攻击也会更加困
难。
时间戳（timestamp）： 32 比特 时间戳反映了RTP 数据包中第一个字节的采样时间。
SSRC：32 比特 用以识别同步源。标识符应该被随机生成，以使在同一个RTP 会话期
160 中没有任何两个同步源有相同的SSRC 识别符。
CSRC 列表：0 到15 项，每项32 比特CSRC 列表指出了对此包中负载内容的所有贡献
学术论文网Tag：代写论文 代写代发论文 论文发表 职称论文发表