用于移動(dòng)學(xué)習(xí)的流媒體服務(wù)器研究＊

陳建明，張翼翔

（浙江廣播電視大學(xué) 網(wǎng)絡(luò)中心，浙江 杭州 310012）

建設(shè)浙江開放大學(xué)，是要把終身學(xué)習(xí)數(shù)字化公共服務(wù)平臺(tái)建設(shè)成為統(tǒng)一架構(gòu)、整體部署、多功能、開放式和工具型的信息平臺(tái)，并構(gòu)建信息系統(tǒng)運(yùn)行、開發(fā)、使用和管理的良好環(huán)境，為各類學(xué)習(xí)者提供方便、靈活、個(gè)性化的學(xué)習(xí)環(huán)境；為全面推進(jìn)繼續(xù)教育和終身教育體系建設(shè)，加快建設(shè)人人皆學(xué)、處處可學(xué)、時(shí)時(shí)能學(xué)的學(xué)習(xí)型社會(huì)提供有效的平臺(tái)技術(shù)支撐。

隨著網(wǎng)絡(luò)技術(shù)與通信技術(shù)的迅速發(fā)展，移動(dòng)數(shù)字設(shè)備（如智能手機(jī)，平板電腦等）具備了較強(qiáng)的多媒體處理能力，擁有高分辨率、高色彩數(shù)的顯示屏，支持音視頻的播放及各種娛樂、辦公、學(xué)習(xí)等應(yīng)用軟件擴(kuò)展功能，同時(shí)還可通過移動(dòng)通信網(wǎng)絡(luò)實(shí)現(xiàn)無線網(wǎng)絡(luò)接入。而終身學(xué)習(xí)平臺(tái)如果僅僅依靠臺(tái)式電腦和電視作傳播媒介正面臨極大的局限性，已無法滿足廣大學(xué)習(xí)者對(duì)“人人皆學(xué)、處處可學(xué)、時(shí)時(shí)能學(xué)”的需求。

針對(duì)個(gè)性化學(xué)習(xí)的需求，移動(dòng)學(xué)習(xí)應(yīng)運(yùn)而生。移動(dòng)學(xué)習(xí)是指利用無線移動(dòng)通信網(wǎng)絡(luò)技術(shù)以及無線移動(dòng)通信設(shè)備（如移動(dòng)電話、個(gè)人數(shù)字助理PDA、Pocket PC等）獲取教育信息、教育資源和教育服務(wù)的一種新型學(xué)習(xí)形式[1]。學(xué)習(xí)者只要擁有智能終端和無線網(wǎng)絡(luò)就能進(jìn)入學(xué)習(xí)環(huán)境，充分體現(xiàn)學(xué)習(xí)的便捷性、教學(xué)個(gè)性化、交互豐富性等特點(diǎn)。它的出現(xiàn)不僅給人們帶來觀念的轉(zhuǎn)變，還會(huì)改變傳統(tǒng)的學(xué)習(xí)模式，教材將由紙質(zhì)書本向電子文檔、教學(xué)視頻轉(zhuǎn)變，學(xué)習(xí)場(chǎng)地也由教室向各個(gè)能連接網(wǎng)絡(luò)的場(chǎng)所延伸。移動(dòng)學(xué)習(xí)流媒體服務(wù)器正是在這背景下的技術(shù)產(chǎn)物，讓學(xué)習(xí)者通過智能終端網(wǎng)絡(luò)接入，進(jìn)行教學(xué)視頻資源的點(diǎn)播學(xué)習(xí)。基于此，本文移植并搭建了基于Live555的開源視頻點(diǎn)播系統(tǒng)。由于Live555良好的設(shè)計(jì)非常容易擴(kuò)展對(duì)其他格式的支持，能快速、有效地搭建流媒體服務(wù)器服務(wù)于移動(dòng)學(xué)習(xí)平臺(tái)。該系統(tǒng)使遠(yuǎn)程教育的接入途徑更多、覆蓋面更廣、提供了更便捷的學(xué)習(xí)方法，以吸引更多的學(xué)習(xí)愛好者，激發(fā)他們的學(xué)習(xí)欲望。

1 流媒體服務(wù)器傳輸系統(tǒng)

流媒體服務(wù)器與移動(dòng)終端是通過RTSP（Real Time StreamingProtocol）建立連接， 通過 RTP （RealTime Protocol）網(wǎng)絡(luò)傳輸協(xié)議將多媒體數(shù)據(jù)封裝后發(fā)送到網(wǎng)絡(luò)，并用 RTCP（Real Time Control Protocol）協(xié)議進(jìn)行QoS控制。主要的流媒體協(xié)議棧如圖1所示。

圖1 流媒體協(xié)議棧

1.1 點(diǎn)播流程分析

實(shí)時(shí)流協(xié)議RTSP是由Real Networks和Netscape共同提出的，在流媒體協(xié)議中位于RTP和RTCP之上，使用TCP或UDP完成數(shù)據(jù)傳輸。RTSP作為應(yīng)用層協(xié)議，建立并控制一個(gè)或幾個(gè)時(shí)間同步的連續(xù)流媒體，協(xié)議本身并不發(fā)送多媒體數(shù)據(jù)流。此外，RTSP為服務(wù)器和客戶端建立會(huì)話控制連接，為多媒體流提供遠(yuǎn)程控制功能，定義了諸如播放、暫停、停止等11種方法。一次簡(jiǎn)單的RTSP交互過程如圖2所示[2]。

客戶端首先向服務(wù)器發(fā)送包含了點(diǎn)播文件的URL（Uniform Resource Locator），連接服務(wù)器端的 RTSP端口，建立RTSP連接。具體交互過程如下：

（1）客戶端發(fā)送Option消息請(qǐng)求，服務(wù)器端響應(yīng)所支持的所有交互的方法信息。

（2）客戶端發(fā)送Describe請(qǐng)求 （主要包含流媒體名字、解碼器類型、視頻分辨率、解碼能力等描述），服務(wù)器對(duì)Describe請(qǐng)求作出響應(yīng)，發(fā)送必要的媒體參數(shù)（即SDP文件，包括媒體名、幀速率、編碼類型、傳輸協(xié)議等）。響應(yīng)成功后會(huì)話進(jìn)入INIT狀態(tài)。

（3）客戶端發(fā)送 Setup請(qǐng)求，其中包括協(xié)議集和端口號(hào)（或者是端口號(hào)的一個(gè)范圍）。服務(wù)器從中選擇一個(gè)協(xié)議和端口，然后作出應(yīng)答。啟動(dòng)成功后會(huì)話進(jìn)入READY態(tài)。

（4）客戶端發(fā)送 Play請(qǐng)求，請(qǐng)求消息主要是播放媒體的起始時(shí)間。服務(wù)器啟動(dòng)RTP包發(fā)送線程并發(fā)送多媒體數(shù)據(jù)。此時(shí)，會(huì)話進(jìn)入PLAYING態(tài)。

（5）在播放過程中，客戶端可隨時(shí)發(fā)出 Teardown請(qǐng)求關(guān)閉會(huì)話，服務(wù)器端響應(yīng)后關(guān)閉連接，停止傳輸。

1.2 多媒體數(shù)據(jù)傳輸

RTP協(xié)議是IETF在1996年提出的、適用于實(shí)時(shí)數(shù)據(jù)傳輸?shù)男滦蛥f(xié)議，由實(shí)時(shí)傳輸協(xié)議RTP和實(shí)時(shí)傳輸控制協(xié)議RTCP兩部分組成。RTP為用戶提供連續(xù)媒體數(shù)據(jù)的實(shí)時(shí)傳輸服務(wù)，主要承載在UDP上，并不直接保證傳輸?shù)膶?shí)時(shí)性，而依賴底層網(wǎng)絡(luò)提供的QoS服務(wù)來真正達(dá)到實(shí)時(shí)性的要求。而RTCP協(xié)議是控制部分，用于實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)傳輸質(zhì)量，為系統(tǒng)提供擁塞控制和流控制。在RTP會(huì)話期間，各參與者會(huì)周期性地傳送包含數(shù)據(jù)包已發(fā)送的數(shù)量、丟失的數(shù)量等統(tǒng)計(jì)信息的RTCP包。

在流媒體應(yīng)用場(chǎng)合，流媒體服務(wù)器一方面會(huì)周期性地產(chǎn)生發(fā)送端報(bào)告，該RTCP數(shù)據(jù)包包含不同媒體流之間的同步信息以及已經(jīng)發(fā)送的數(shù)據(jù)包和字節(jié)的計(jì)數(shù)，接收端可以根據(jù)這些信息估算出實(shí)際的數(shù)據(jù)傳輸速率；另一方面，接收端也會(huì)向服務(wù)器發(fā)送接收端報(bào)告，該RTCP數(shù)據(jù)包含有已接收數(shù)據(jù)報(bào)的最大序列號(hào)、丟失的數(shù)據(jù)報(bào)數(shù)目、延時(shí)抖動(dòng)和時(shí)間戳等信息。服務(wù)器根據(jù)這些信息可以估算出往返時(shí)延，并且根據(jù)這些信息調(diào)整發(fā)送速率，以改善網(wǎng)絡(luò)擁塞，或者根據(jù)網(wǎng)絡(luò)狀況平滑地調(diào)整服務(wù)質(zhì)量[3]。

H.264視頻編解碼是兩大國(guó)際標(biāo)準(zhǔn)組織ITU-T視頻編碼專家組 VCEG（Video Coding Experts Group）和 ISO/IEC運(yùn)動(dòng)圖像專家組MPEG （MovingPictureExperts Group）共同制定的視頻編碼標(biāo)準(zhǔn)。H.264最大的優(yōu)勢(shì)是具有很高的數(shù)據(jù)壓縮比率，在同等圖像質(zhì)量的條件下，H.264的壓縮比是 MPEG-2的 2倍以上，是 MPEG-4的1.5～2倍。良好的壓縮技術(shù)將大大節(jié)省用戶的下載時(shí)間和數(shù)據(jù)流量，同時(shí)還擁有高質(zhì)量流暢的圖像。經(jīng)過H.264壓縮的視頻數(shù)據(jù)，特別適合在低延時(shí)模式下的實(shí)時(shí)通信應(yīng)用（如視頻會(huì)議）的場(chǎng)合和沒有延時(shí)的視頻存儲(chǔ)或視頻流服務(wù)器，也適用在高誤碼率傳輸?shù)臒o線網(wǎng)絡(luò)中傳輸視頻數(shù)據(jù)。當(dāng)前所有的視頻應(yīng)用都可以通過H.264獲得高質(zhì)量地實(shí)現(xiàn)，例如數(shù)字電視廣播、在線視頻的存儲(chǔ)和點(diǎn)播、3G視頻電話等。為了配合3G網(wǎng)絡(luò)的高傳輸速度，開發(fā)的移動(dòng)設(shè)備流媒體的視頻編碼格式3GP/MP4，就是采用了H.264視頻壓縮標(biāo)準(zhǔn)。

H.264定義了視頻編碼層 VCL（Video Coding Layer）以及網(wǎng)絡(luò)提取層 NAL（Network Abstraction Layer），以便能夠適應(yīng)不同的網(wǎng)絡(luò)結(jié)構(gòu)。VCL中包括VCL編碼器與VCL解碼器，其主要功能是實(shí)現(xiàn)視頻數(shù)據(jù)的壓縮編碼和解碼；NAL則用于為VCL提供一個(gè)與網(wǎng)絡(luò)無關(guān)的統(tǒng)一接口，負(fù)責(zé)對(duì)VCL處理后的視頻數(shù)據(jù)進(jìn)行封裝 （經(jīng)RTP、UDP、IP協(xié)議逐層封裝）后發(fā)送到網(wǎng)絡(luò)。RTP承載H.264視頻數(shù)據(jù)的傳輸格式如圖3所示，可分為兩部分：RTP固定包頭和RTP載荷H.264視頻流。RTP固定包頭為RTCP進(jìn)行相應(yīng)監(jiān)測(cè)和控制提供了基礎(chǔ)，各字段含義如下：V為版本號(hào)，P表示包是否有堵塞數(shù)據(jù)，X表示是否含有擴(kuò)展頭，M表示保留字段可由用戶決定，PT表示媒體類型。

圖3 H.264視頻流的組包格式

組包格式的后半部分是RTP承載H.264視頻流數(shù)據(jù)。組包格式載荷第一字節(jié)的各字段含義如下：

F：1 bit，默認(rèn)值為 0，當(dāng)網(wǎng)絡(luò)檢測(cè)到 NAL單元中存在比特錯(cuò)誤時(shí)可將其置1。

NRI：2 bit，為 00表示 NAL單元的內(nèi)容不用于重建幀間預(yù)測(cè)的參考圖像；非00則相反。

TYPE：5 bit，指示NAL單元載荷類型。接收端通過判斷RTP載荷類型字節(jié)來辨識(shí)三類不同的載荷結(jié)構(gòu)：?jiǎn)蝹€(gè)NAL單元分組、聚合分組、分片組。

流媒體服務(wù)器在RTP組包設(shè)計(jì)需考慮以下幾點(diǎn)：

（1）根據(jù) IP層 MTU的大小，對(duì)大尺寸的 NAL單元進(jìn)行分割，可以分別在兩個(gè)層次上進(jìn)行分割：視頻編碼層VCL上的分割和網(wǎng)絡(luò)提取層NAL上的分割。

（2）一些 H.264的 NAL單元的大小，如 SEI NAL單元、參數(shù)集等都非常小，有些只有幾個(gè)字節(jié)，可以將多個(gè)這類NAL單元聚合在一個(gè)RTP分組中，以減小包頭（RTP/UDP/IP）開銷。

（3）一般的NAL單元封裝進(jìn)一個(gè)包中，即RTP負(fù)載中只包含一個(gè)NAL單元，NAL頭部兼作RTP頭部。

2 Live555編譯及資源部署

Live555是一個(gè)開源、免費(fèi)、跨平臺(tái)的視頻和音頻流方案，實(shí)現(xiàn)了對(duì)標(biāo)準(zhǔn)流媒體傳輸協(xié)議如RTP/RTCP、RTSP、SIP等的支持，實(shí)現(xiàn)了對(duì)多種音視頻編碼格式的音視頻數(shù)據(jù)的流化、接收和處理等支持，包括MPEG、H.264、DV、JPEG視頻和多種音頻編碼。下面介紹live555在win7環(huán)境下 Microsoft Visual Studio 10.0的編譯 過 程 。 首 先 從 http：//live555.com/liveMedia/public/live555-latest.tar.gz下 載 live555工程 ，利 用genWindowsMakefiles.cmd可生成編譯器可用的Makefile文件。

（1）修 改 livew in32config文 件 中 TOOLS32=E：Program FilesMicrosoftVisualStudio10.0VC為系統(tǒng)VS2010 安裝路徑，LINK_OPTS_0=$（linkdebug）msvcrt.lib。

（2）新增 Makefile設(shè)定，修改 livegroupsockMakefile.head文件中INCLUDES=-Iinclude-I../UsageEnvironment/include-DNO_STRSTREAM。

（3）在命令行運(yùn)行 livegenWindowsMakefiles.cmd，相應(yīng)文件夾下會(huì)生成VS能夠編譯的*.mak文件，如liveMedia.mak、mediaServer.mak等。

（4）為方便編譯可新建 livecomplie.bat批處理腳本，編輯內(nèi)容如下：

（5）執(zhí)行complie.bat腳本編譯工程，編譯完成后會(huì)在相應(yīng)文件下生成obj文件、可執(zhí)行文件和lib庫(kù)，包 括 libBasicUsageEnvironment.lib、libgroupsock.lib、libUsage Environment.lib、libliveMedia.lib，其中 live555MediaServer.exe即為流媒體服務(wù)器運(yùn)行軟件。

由于浙江電大在線學(xué)習(xí)平臺(tái)使用的視頻資源后綴都是asf，屬于Windows Media格式，主要適用于PC機(jī)上點(diǎn)播播放。為此，考慮到網(wǎng)絡(luò)傳輸帶寬和智能終端的解碼支持，需要將asf文件格式轉(zhuǎn)換為適合流媒體傳輸?shù)囊曨l壓縮標(biāo)準(zhǔn)H.264格式?？梢允褂肕edia Codec轉(zhuǎn)換工具來實(shí)現(xiàn)，將轉(zhuǎn)換后的文件放于live555MediaServer.exe目錄下，客戶端即可通過RTSP URL訪問到流媒體服務(wù)器下的教學(xué)資源。

基于Live555的流媒體服務(wù)器可以迅速而有效地部署到移動(dòng)學(xué)習(xí)平臺(tái)，作為數(shù)字化學(xué)習(xí)的延伸。通過格式處理后可重用浙江電大原有的教學(xué)視頻資源，可滿足廣大學(xué)習(xí)愛好者對(duì)移動(dòng)學(xué)習(xí)的需求。下一步的工作是擴(kuò)展基于Live555的流媒體服務(wù)器的用戶登錄管理、訪問權(quán)限控制、資源文件管理等功能，進(jìn)一步完善移動(dòng)學(xué)習(xí)平臺(tái)的穩(wěn)定性和功能完備性。

[1]葉成林.移動(dòng)學(xué)習(xí)研究綜述[J].電化教育研究，2004（3）：12-18.

[2]陳國(guó)陽.基于RTSP/RTP的嵌入式流媒體服務(wù)器設(shè)計(jì)[J].科技情報(bào)開發(fā)與經(jīng)濟(jì)，2007，17（34）：226-227.

[3]樊珊.基于 RTP的 H.264視頻傳輸技術(shù)的研究 [D].濟(jì)南：山東大學(xué)，2008.