中国科技论文在线中文稿件模板 - CHINAUNIX

2024年2月9日发(作者：才气过人)

中国科技论文在线

针对移动互联网的流媒体服务器的实现

毕柳成，张笑燕

作者简介：毕柳成，北京邮电大学硕士，计算机科学与技术专业，河北省唐山市人。现主要从事流媒体方面的开发工作

通信联系人：张笑燕，博士，副教授，硕士生导师。2004年8月—2005年8月到美国康奈尔（Cornell）大学作访问学者一年，主要从事Ad hoc和无线传感器网络方面的研究工作。目前研究方向：通信软件、软件过程改进、移动互联网. E-mail: zhangxiaoyan@

- 1 -

中国科技论文在线

5

10

（北京邮电大学软件学院）

摘要：传统的流媒体服务器已经经过多年的发展，日益成熟完善。但面对新兴的移动互联网，传统的流媒体服务器有其局限性和不适应性。本文探讨了3G网络或者其他无线移动环境下，以手机作为终端进行点播服务的流媒体服务器的设计与实现，由于移动互联网以及手持终端的自身特点，必须解决相关问题，比如手机自身编解码能力问题，手机以及网络环境对协议的支持等等。另外，在解决以上问题的基础，又需要保证服务器设计的合理性和并发的性能，本文以boost C++库作为工具，对本文的系统进行了良好的设计与实现。

关键词：流媒体；移动互联网；服务器

中图分类号：TP37

15

An Implementation of Streaming Media Server for mobile

Internet

BI Liucheng, ZHANG Xiaoyan

(School of Software Engineering,Beijing University of Posts and Telecommunications)

Abstract:

Traditional streaming media rver has been through years of development, increasingly

sophisticated. But to the growing mobile Internet, the traditional streaming media rver has its

limitations and inelasticity. This paper discuss in the 3G network or other wireless mobile

environment, how to design and implement a streaming media rver with handheld terminal.

Becau of the characteristics of mobile internet and handheld terminals, there are some existing

problems, such as cellphone decodec ability for video and audio , and protocols they support. In

addtion, the rver should also ensure the reasonableness of the rver design and concurrent

performance. A solution implement by boost C++ libraries is brougth up in this paper.

Key words:

streaming media; mobile internet; rver

20

25

0 引言

30 流媒体是采用流式传输的方式在Internet上传输的多媒体数据，它在传输的同时播放数据，并且将播放过的数据丢弃，从而形成稳定的﹑连续的传输流和回放流，使得在低带宽的环境下也能获得高质量的音频和视频信息。

3G移动通信网作为日趋完善的无线网络，为流媒体的应用提供了一个崭新的平台，也为流媒体技术更好的为使用者服务开辟了新的传输媒体。随着手机增值业务的不断发展，视音频流媒体业务将会成为3G增值业务的一个热点，通过手机实现视频点播、收看视频节目成为最能吸引用户眼球的业务之一。

移动流媒体是从固网的流媒体发展而来的，但它不同于固网流媒体，其不同表现在以下三个方面：先是终端，移动流媒体是通过手机或其他的移动个人终端获取流媒体服务；其次是终端与服务器之间的承载网络，移动流媒体通过移动通信网接入、获取流媒体服务；最后是应用，移动流媒体可以在移动通信网的覆盖范围内自由地获取流媒体服务。

移动流媒体业务的系统结构如图1所示，它设计到流媒体终端、移动通信接入网、移动通信分组核心网、IP网络、流媒体内容服务器等。其中，流媒体内容服务器（包括媒体制作和内容管理）、内容缓冲／直播内容采集服务器是移动流媒体系统的核心功能实体。

35

40

- 2 -

中国科技论文在线

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仅列出部分手机系统的支持格式。由于大量的已有机型的存在，为了适应更多的机型，这里针对mpeg4格式进行说明。音频格式以amr为例。

表1 音视频格式

平台

机型

iPhone OS

iPhone

Table 1 video and audio

Android Symbian

HTC-G3

Meizu-M8

Lephone

gPhone

Mp4

3gp

RTSP

320×240

320×180

H.264

Mpeg-4

H.263

AAC_LC

N95

N97

5800

E71

Mp4

3gp

RTSP

320×240

480×320

320×176

H.264

Mpeg-4

AAC_LC

Windows Mobile

HTC-Touch

Dopod-T8388

60

封装格式

传输协议

分辨率

Mpeg 2

ts/Mp4

HTTP

480×320

320×240

H.264

Mpeg-4

AAC_LC

Mp4

3gp

RTSP

480×800

320×176

176×144

H.264

Mpeg-4

H.263

AAC_LC

视频编码

音频编码

- 3 -

中国科技论文在线

mp3, amr mp3,amr

mp3 amr Mp3, amr

65

1.2 视频格式mpeg-4

MPEG-4通过层次结构进行管理，层次结构分别是视频场景、视频对象、视频对象层、视频对象平面组和视频对象平面，层次结构如图2所示。

VS（Video Session）：视频场景，它位于层次结构的最高层，一个完整的视频序列可以由几个VS组成。

VO（Video Object）：视频对象，它是场景中的某个物体，最简单的情况下就是矩形框，它是有生命期的，由时间上连续的许多帧构成。

VOL（Video Object Layer）：视频对象层，VO的三种属性信息在该层进行编码，该层主要用来扩展VO的时域和空域分辨率，实现分成编码。

GOV：视频对象平面组，由视频平面组合，是可选成分。视频对象层即可以由VOP直接组合，也可以由GOV组合而成。

VOP（Video Object Plane）：视频对象平面，它可以看作是VO在某一时刻的采样，即一帧VO。

VS1

70

75

VO1 VOn

VOL111

GOV1 GOVn

VOLn

VOP VOP VOP

图2 视频流结构图

VOP

80

Fig.2 streaming video char

1.3 音视格式AMR

AMR全称Adaptive Multi-Rate，自适应多速率编码，主要用于移动设备的音频，压缩比比较大，但相对其他的压缩格式质量比较差，由于多用于人声，通话，效果还是很不错的。

首先可分为2类：

85 1. AMR: 又称为AMR-NB，相对于下面的WB而言，

语音带宽范围：300－3400Hz，

8KHz抽样

2. AMR-WB:AMR WideBand，

语音带宽范围： 50－7000Hz

16KHz抽样

本系统采用amr-nb,本文中所提的amr没有特殊说明，均为AMR-NB。

AMR有多种编码方式，每种编码方式的采样频率不同：

表2 不同规格的AMR

- 4 -

90

中国科技论文在线

0

1

2

3

4

5

6

7

规格

AMR 4.75

AMR 5.15

AMR 5.9

AMR 6.7

AMR 7.4

AMR 7.95

AMR 10.2

AMR 12.2

Table 2 different specification of the AMR

帧头（字节）

比特率（kbps）

音频帧大小（字节）

13

14

16

18

20

21

27

32

04 00000100

0C 00001100

14 00010100

1C 00011100

24 00100100

2C 00101100

34 00110100

3C 00111100

FT

0000

0001

0010

0011

0100

0101

0110

0111

95

2 流媒体传输相关协议

2.1 RTSP协议

RTSP(Real-Time Stream Protocol) [1]是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似。在rfc2326中对rtsp协议进行描述。

RTSP被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。100 尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于转送媒体流数据。媒体数据的传送可通过RTP/RTCP等协议来完成。

一次基本的RTSP操作过程是:首先，客户端连接到流服务器并发送一个RTSP描述命令（DESCRIBE）。流服务器通过一个SDP描述来进行反馈，反馈信息包括流数量、媒体类型等信息。客户端在分析该SDP 描述，并为会话中的每一个流发送一个RTSP建立命令(SETUP)，RTSP建立命令告诉服务器客户端用于接收媒体数据的端口。流媒体连接建立完成后，客户端发送一个播放命令(PLAY)，服务器就开始在UDP上传送媒体流（RTP包）到客户端。 在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。最后，客户端可发送一个终止命令(TERADOWN)来结束流媒体会话。

RTSP请求消息格式：

方法 URI RTSP版本 CR LF

消息头 CR LF CR LF

消息体 CR LF

其中RTSP版本一般都是RTSP/1.0,状态码是一个数值，用于表示Request消息的执行结果,比如200表示成功,解释是与状态码对应的文本解释。

105

110

115

2.2 RTP协议

RTP[2]是一种提供端对端传输服务的实时传输协议，用来支持在单目标广播和多目标广播网络服务中传输实时数据，而实时数据的传输则由RTCP协议来监视和控制。

RTP定义在RFC 1889中,RTP协议格式如下：

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V=2|P|X| CC |M| PT | quence number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| timestamp |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| synchronization source (SSRC) identifier |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

| contributing source (CSRC) identifiers |

| .... |

- 5 -

120

125

中国科技论文在线

130

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

前12个字节出现在每个RTP包中，仅仅在被混合器插入时，才出现CSRC识别符列表。这些域有以下意义：

版本(V)：2比特 此域定义了RTP的版本。此协议定义的版本是2。(值1被RTP草135 案版本使用，值0用在最初"vat"语音工具使用的协议中。)

填充(P)：1比特 若填料比特被设置，则此包包含一到多个附加在末端的填充比特，填充比特不算作负载的一部分。填充的最后一个字节指明可以忽略多少个填充比特。填充可能用于某些具有固定长度的加密算法，或者用于在底层数据单元中传输多个RTP包。

扩展(X)：1比特 若设置扩展比特，固定头(仅)后面跟随一个头扩展。

140 CSRC计数(CC)：4比特 CSRC计数包含了跟在固定头后面CSRC识别符的数目。

标志(M)：1比特 标志的解释由具体协议规定。它用来允许在比特流中标记重要的事件，如帧边界。

负载类型(PT)：7比特 此域定义了负载的格式，由具体应用决定其解释。协议可以规定负载类型码和负载格式之间一个默认的匹配。

145 序列号（quence number）：16比特 每发送一个RTP数据包，序列号加1，接收端可以据此检测丢包和重建包序列。序列号的初始值是随机的(不可预测)，以使即便在源本身不加密时(有时包要通过翻译器，它会这样做)，对加密算法泛知的普通文本攻击也会更加困难。

时间戳（timestamp）： 32比特 时间戳反映了RTP数据包中第一个字节的采样时间。

150 SSRC：32比特 用以识别同步源。标识符应该被随机生成，以使在同一个RTP会话期中没有任何两个同步源有相同的SSRC识别符。

CSRC列表：0到15项，每项32比特CSRC列表指出了对此包中负载内容的所有贡献源。识别符的数目在CC域中给定。

2.3 NAT协议

155 互联网即将用完IPv4地址，这是没有争议的。但是，争议的问题是互联网服务提供商是直接迁移到IPv6以解决这个问题，还是将采用运营商级网络地址转换(NAT)等替代方法在其新用户中共享剩余的IPv4地址。

到目前为止最成功的是网络地址转换(NAT)方法。尤其是NAT44，该技术将一个IPv4地址转换成了另一个IPv4地址。私有 IPv4地址要在所给网络中使用;这里是假设在一个网160 络中，大多数IP设备都只需要和相同网络中的其他IP设备进行连接。

NAT44(通常位于路由或防火墙之中)放在与公共互联网相接的网络边缘。NAT拥有若干独特的IPv4地址。随着数据包从内部或私有界面发送到外部或公共界面，NAT用其公共IPv4地址中的一个代替了数据包的私有IPv4地址。NAT技术通过映射内部地址到外部地址的路径来记住数据包源自哪个内部设备。

165

网络地址转换(NAT,Network Address Translation)属接入广域网(WAN)技术,是一种将私有(保留)地址转化为合法IP地址的转换技术,它被广泛应用于各种类型Internet接入方式和各种类型的网络中。原因很简单，NAT不仅完美地解决了lP地址不足的问题，而且还能够有效地避免来自网络外部的攻击，隐藏并保护网络内部的计算机。

NAT可以分为Basic NAT和PAT：

170 - Basic NAT只转化IP，不映射端口。

- 6 -

中国科技论文在线

部地址。

NAT还可以分为静态NAT和动态NAT：

- PAT除了转化IP，还做端口映射，可以用于多个内部地址映射到少量（甚至一个）外 - 静态NAT，将内部网络中的每个主机都永久映射成 外部网络中的某个合法的地址，175 多用于服务器。

- 动态NAT，则是在外部网络中定义了一个或多个合法地址，采用动态分配的方法映射到内部网络。

3 流媒体服务器设计与实现

3.1 主要数据结构及算法

180 3.1.1 RTP数据包头部定义

typedef struct

{

/**//* byte 0 */

uint8_t csrc_len:4; /**//* expect 0 */

uint8_t extension:1; /**//* expect 1, e RTP_OP below */

uint8_t padding:1; /**//* expect 0 */

uint8_t version:2; /**//* expect 2 */

/**//* byte 1 */

uint8_t payload:7; /**//* RTP_PAYLOAD_RTSP */

uint8_t marker:1; /**//* expect 1 */

/**//* bytes 2, 3 */

uint16_t q_no;

/**//* bytes 4-7 */

uint32_t timestamp;

/**//* bytes 8-11 */

uint32_t ssrc; /**//* stream number is ud here. */

} RTP_FIXED_HEADER;

3.1.2

200

MPEG-4打包rtp算法

185

190

195

205

Mpeg-4打包rtp的算法[3]的伪代码如下：

While(MPEG-4数据流结束前)

{If(发现下一个VOP起始码)

{If(当前分段长度≤去除头部字段长度的路径MTU值)

{把此段数据打入RTP包}

el

{把尽可能多的宏块打入RTP包}

}

el

{对剩余数据打包}

｝

3.1.3 AMR打包rtp算法 210

AMR打包rtp算法[4]，以流程图表示如下：

- 7 -

中国科技论文在线

图3 视频流结构图

Fig.3 streaming video char

215

3.2 系统设计

本系统采用了boost C++库的asio异步通信库和线程库进行设计和实现，保证了系统的并发性，高效性以及跨平台性。系统设计如图4所示。

图4 系统设计图

220

Fig.4 system design chart

- 8 -

中国科技论文在线

Server:系统主程序，负责初始化环境变量，线程池，异步通信机制。

RtspServicer:主要负责与客户端进行协商，并为rtprvicer进行相关初始化和控制。

Request和reply分别代表客户端请求和服务器回复的类抽象。

RequestParr:解析request。

225 RequestHandler：对不同request进行不同的处理。

RtpServicer:负责往客户端发送rtp数据。

FileParr:负责解析媒体文件，提取帧数据

RtpPacketer：对媒体帧进行处理，打包成rtp包。

本系统主要使用了rtsp协议和rtp协议，其主要工作机制[5]如图所示：

Rtsp协商

音频流

流媒体文件或者流

Demux

视频流

rtp数据包

发送客户端

230

图5系统工作流程

Fig.5 system work flow chart

3.3 协议交互过程

RTP协议并没有规定其传输层的实现，传输层主要有tcp和udp协议。但是基于tcp有235 以下特点.

·TCP重传机制

·TCP拥塞控制机制

·TCP报文头比UDP保文头要大

·TCP的启动速度慢

240 TCP协议不适合传输实时的多媒体数据,新的为实时传输多媒体数据的RTP协议也就应面对ip地址的减少，很多运营商或者局域网都使用了内网ip，这里就涉及到了在对内网ip客户端进行udp传输时，需要对内网ip进行穿透—也就是udp打洞，NAT穿越技术。这样做的前提是该路由器支持NAT协议。协议交互过程如图6所示。

运而生。流媒体技术采用RTSP-on-TCP/RTP-on-UDP的方式进行交互和数据传输[6]。

- 9 -

中国科技论文在线

245

图6系统交互图

Fig.6 system interaction chart

4 结论

250

3G移动通信网作为日趋完善的无线网络，为流媒体的应用提供了一个崭新的平台，也为流媒体技术更好的为使用者服务开辟了新的传输媒体。随着手机增值业务的不断发展，视音频流媒体业务将会成为3G增值业务的一个热点，通过手机实现视频点播、收看视频节目成为最能吸引用户眼球的业务之一。

本文针对移动互联网和手持终端的特点，对流媒体协议和原理进行了详细的分析，并提出了一套跨平台的服务端实现方案，并且给出了程序的具体实现。本系统已经过实际测试，服务器测试平台为ubuntu,opensu及windows，客户端测试系统包括android,symbian,windows mobile.

由于本人能力和时间有限，可能本系统仍存在不足之处，比如对于系统流量的监控措施，希望以后继续改进。

255

致谢

260 在本文的撰写及系统的开发过程中，感谢我的导师张笑燕以及杜晓峰老师给我提供的帮助与指点。

[参考文献] (References)[1] Henning Schulzrinne,rfc2326. Real Time Streaming Protocol[s]. /rfc/,1998

[2] Henning Schulzrinne, rfc3550. A Transport Protocol for Real-Time Applications.

/rfc/,2003

[3] Yoshihiro Kikuchi, rfc3016. RTP Payload Format for MPEG-4 Audio/Visual

Streams ./rfc/,2000

[4] Johan Sjoberg, rfc4867. RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and

Adaptive Multi-Rate Wideband (AMR-WB) Audio :///rfc,2007CABR, JGJ101-96.

Specification of testing methods for earthquake resistant building[S]. Beijing: China Architecture & Building Press,

1997.

[5] 蔡安妮,孙景鳌. 多媒体通信技术基础[M]. 北京:电子工业出版社，2008.

[6] Colin Perkins, RTP: Audio and Video for the Internet, 2001

265

270

- 10 -