中國科技論文在線中文稿件模板 - CHINAUNIX

2024年2月9日發(作者：才氣過人)

中國科技論文在線

針對移動互聯網的流媒體服務器的實現

畢柳成，張笑燕

作者簡介：畢柳成，北京郵電大學碩士，計算機科學與技術專業，河北省唐山市人?，F主要從事流媒體方面的開發工作

通信聯系人：張笑燕，博士，副教授，碩士生導師。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描述來進行反饋，反饋信息包括流數量、媒體類型等信息?？蛻舳嗽诜治鲈揝DP 描述，并為會話中的每一個流發送一個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 -