胡開明,陳建華

(廣東松山職業(yè)技術(shù)學(xué)院計算機(jī)系,廣東韶關(guān)512126)

1 引 言

對于一個基本的流媒體系統(tǒng)而言,它的基本目的是把流媒體傳輸?shù)娇蛻舳?是一個典型的 S/C(Server/Client)架構(gòu)[1].在過去幾乎所有的S/C架構(gòu)中,出現(xiàn)了一個不可避免的問題,就是在客戶端數(shù)量過多的時候,出現(xiàn)了服務(wù)器端由于負(fù)載過重而導(dǎo)致系統(tǒng)性能急劇下降甚至崩潰.另一方面當(dāng)前的流式媒體系統(tǒng)還存在以下的問題：(1)格式的不統(tǒng)一性.各大流式媒體傳輸系統(tǒng)的流式媒體格式之間相互差別很大,不能進(jìn)行播放.(2)可擴(kuò)展性差.不能使用擴(kuò)展用戶定義的接口,造成了流媒體系統(tǒng)開發(fā)上的分立局面.(3)平臺的相關(guān)性.(4)目前的智能流技術(shù)只能靜態(tài)的反映在客戶端進(jìn)行請求的時候網(wǎng)絡(luò)的擁塞狀況.在數(shù)據(jù)流開始傳送的時候不能對網(wǎng)絡(luò)狀況進(jìn)行反饋,也不能采取任何措施來適應(yīng)這種網(wǎng)絡(luò)狀況的變化.使得流媒體傳輸過程中其QoS得不到保證[2].

為了解決這個問題,利用JAVA的JMF(Java Media Framework).利用其提供的多媒體功能加上對其原有接口的擴(kuò)展,實(shí)現(xiàn)了一種基于JMF的RTP/RTCP傳輸模型的整體設(shè)計.在對RTP/RTCP工作模型的詳細(xì)分析中,實(shí)現(xiàn)了一個動態(tài)的網(wǎng)絡(luò)反饋機(jī)制,并利用其提供的動態(tài)的反饋信息實(shí)現(xiàn)了對發(fā)送端和接收端Buffer的控制,保證流媒體傳輸?shù)腝oS,以提高流媒體傳輸?shù)男?

2 JM F架構(gòu)及流媒體的基本功能模塊

2.1 JMF架構(gòu)

JMF(Java Media Framework)是Sun公司提出的Java媒體架構(gòu)[3].它是對應(yīng)Java2平臺標(biāo)準(zhǔn)版(J2SE)的一種可選用的應(yīng)用編程接口 (API)軟件.JMF的源代碼將通過SCSL(Sun社團(tuán)源代碼許可模式)發(fā)布.這一強(qiáng)大的媒體工具包可以在任何版本 (1.1.x及以上版本)的Java平臺上運(yùn)行[4].

JMF2.1.1技術(shù)提供了先進(jìn)的媒體處理能力,從而擴(kuò)展了Java平臺的功能[5].JMF所提供多媒體功能如下：

(1)可以在Java Applet和應(yīng)用程序中播放各種媒體文件.它提供了對對各種主要媒體形式和編碼的支持,如 M-JPEG、H.263、MP3、Macromedias Flash、IBM 的 HotMedia和 Beatniks的 Rich Media Format(RMF)等.JMF2.1.1還支持多種媒體類型,如Quicktime MOV、Microsoft AVI和MPEG-1[6].

(2)可以播放從互聯(lián)網(wǎng)上下載的流媒體.

(3)可以利用麥克風(fēng)和攝像機(jī)一類的設(shè)備截取音頻和視頻,并保存成多媒體文件.

(4)處理多媒體文件,轉(zhuǎn)換文件格式.

(5)向互聯(lián)網(wǎng)上傳音頻和視頻數(shù)據(jù)流.

(6)在互聯(lián)網(wǎng)上廣播音頻和視頻數(shù)據(jù).

JMF架構(gòu)中還包括了一個開放和統(tǒng)一的媒體架構(gòu),可使開發(fā)人員靈活采用各種媒體回放、捕獲組件,或采用他們自己的定制的內(nèi)插組件.

2.2 流媒體的基本功能模塊

在對流媒體技術(shù)進(jìn)行分析和研究以前,首先我們要明確整個流媒體的系統(tǒng)架構(gòu)以及在流媒體架構(gòu)中采用的各種技術(shù),然后再對其進(jìn)行進(jìn)一步的探討、改進(jìn)和研究.一個典型的流媒體系統(tǒng)的功能模塊如圖1所示：

流媒體系統(tǒng)包括以下5個功能模塊：

(1)信息采集和播放設(shè)備：信息采集設(shè)備負(fù)責(zé)將音視頻信息源輸入計算機(jī).

(2)編碼和解碼工具：它由普通計算機(jī)和流媒體編碼軟件組成.視頻采集設(shè)備,供編碼軟件處理；編碼軟件負(fù)責(zé)將流媒體采集卡傳送過來的數(shù)字音視頻信號壓縮成流媒體格式.而解碼工作與之相反,負(fù)責(zé)將媒體數(shù)字信號轉(zhuǎn)化成終端可識別的信息.

(3)數(shù)據(jù)壓縮模塊：多媒體數(shù)據(jù)量巨大,為了適應(yīng)其傳輸?shù)木W(wǎng)絡(luò)環(huán)境,必須多于原來的多媒體數(shù)據(jù)進(jìn)行高效的壓縮,然后將壓縮后的數(shù)據(jù)在網(wǎng)絡(luò)上傳遞.其相應(yīng)的解壓模塊將負(fù)責(zé)將數(shù)據(jù)還原成多媒體播放程序可以識別的信息.

(4)相關(guān)協(xié)議：流媒體數(shù)據(jù)由于自身的特點(diǎn),在網(wǎng)絡(luò)上傳輸時將采用和過去諸如文字,靜態(tài)圖像等不同的網(wǎng)絡(luò)協(xié)議來進(jìn)行傳輸.

(5)傳輸網(wǎng)絡(luò)：一般來說,流媒體傳輸可以在現(xiàn)有任何網(wǎng)絡(luò)上進(jìn)行傳輸.更高的帶寬將有利于流媒體傳輸效率的提高,也能夠保證其質(zhì)量.

3 支持流媒體傳輸?shù)木W(wǎng)絡(luò)協(xié)議

流媒體采用流式傳輸方式在網(wǎng)絡(luò)服務(wù)器與客戶端之間進(jìn)行傳輸.前面提到,流媒體可以進(jìn)行用順序流和實(shí)時流的方式進(jìn)行傳輸.流式傳輸?shù)膶?shí)現(xiàn)需要合適的傳輸協(xié)議.IETF(Internet Engineering Task Force,因特網(wǎng)工程任務(wù)組)制訂的很多協(xié)議可用于實(shí)現(xiàn)流媒體技術(shù).目前,針對流媒體傳輸主要的工作在OSI七層中的網(wǎng)際層和傳輸層展開,當(dāng)然也涉及到七層協(xié)議中的2.5層協(xié)議網(wǎng)絡(luò) (ATM、FR網(wǎng)絡(luò))[7].適合流媒體相關(guān)協(xié)議包括：

(1)RT P/RTCP協(xié)議：實(shí)時傳輸和實(shí)時傳輸控制協(xié)議；

(2)RSVP協(xié)議：資源預(yù)留協(xié)議；

(3)RTSP協(xié)議：實(shí)時流協(xié)議.

4 RTP/RTCP模型及動態(tài)網(wǎng)絡(luò)反饋機(jī)制

4.1 RTP/RTCP基本模型

RTP協(xié)議是一種應(yīng)用型的傳輸層協(xié)議,它并不提供任何傳輸可靠性的保證和流量的擁塞控制機(jī)制.RTP協(xié)議位于UDP協(xié)議之上,在功能上獨(dú)立于下面的傳輸層 (UDP)和網(wǎng)絡(luò)層,但不能單獨(dú)作為一個層次存在,通常是利用低層的UDP協(xié)議對實(shí)時視音頻數(shù)據(jù)進(jìn)行組播 (Multicast)或單播 (Unicast),從而實(shí)現(xiàn)多點(diǎn)或單點(diǎn)視音頻數(shù)據(jù)的傳輸.

RTP協(xié)議被設(shè)計成能夠?yàn)槟撤N特定的應(yīng)用提供服務(wù)的一種協(xié)議.實(shí)際上,RTP協(xié)議的實(shí)現(xiàn)已經(jīng)被融合到應(yīng)用程序中來.RTP沒有連接的概念,它既可以建立在面向連接的底層協(xié)議上,也可以建立在面向無連接的底層協(xié)議上,因此RTP協(xié)議對傳輸層是獨(dú)立的.RTP協(xié)議一般由兩個部分組成：數(shù)據(jù)報文部分(RTP報文)和控制報文部分 (RTCP).與傳統(tǒng)的注重的高可靠的數(shù)據(jù)傳輸?shù)倪\(yùn)輸層協(xié)議相比,RTP更加側(cè)重的數(shù)據(jù)傳輸?shù)膶?shí)時性.此協(xié)議提供的服務(wù)包括時間載量標(biāo)識、數(shù)據(jù)序列、時戳、傳輸控制等.RTP與輔助控制協(xié)議RTCP一起得到數(shù)據(jù)傳輸?shù)囊恍┫嚓P(guān)的控制信息.其基本模型如下圖所示：

圖1 型的流媒體系統(tǒng)的功能

圖2 RTP/RTCP基本工作模型

4.2 基于RTCP的動態(tài)網(wǎng)絡(luò)反饋機(jī)制

RealSystem的SureStream技術(shù)是實(shí)現(xiàn)流式媒體傳輸關(guān)鍵技術(shù)之一,可以根據(jù)不同連接速率創(chuàng)建多個文件和采用一種復(fù)雜客戶/服務(wù)器機(jī)制探測帶寬變化.但是,對于網(wǎng)絡(luò)環(huán)境而言,網(wǎng)絡(luò)的狀況是不斷變化的,SureStream技術(shù)顯然沒有能夠?qū)W(wǎng)絡(luò)狀況的變化進(jìn)行任何的響應(yīng),即使網(wǎng)絡(luò)狀況發(fā)生變化,它對客戶端發(fā)送的文件仍是在針對客戶端請求時連接速率創(chuàng)建的.對于一個變化不大的網(wǎng)絡(luò)而言,這種方法當(dāng)然是行之有效的,但是對于一個不斷變化的網(wǎng)絡(luò)而言,建立動態(tài)的帶寬偵測和反饋機(jī)制將是解決問題的有效途徑.

利用RTCP的報告來偵測網(wǎng)絡(luò)變化的趨勢,根據(jù)網(wǎng)絡(luò)變化的趨勢,可以對系統(tǒng)其他部分進(jìn)行調(diào)整.

首先,通過RR控制包獲取反饋信息.即讀取RTCP的RR(接收者報告)包并做統(tǒng)計分析,必須利用RTCP提供的3個性能指標(biāo)來確定網(wǎng)絡(luò)當(dāng)前狀況：

(1)傳輸時延抖動估計Interarrival jitter：記作J.傳輸時延抖動估計是指兩個相鄰數(shù)據(jù)包到達(dá)事件的平均偏差 (Mean Deviation)估算,若到達(dá)時間比較規(guī)律,則該值為零,否則該數(shù)值比較大.網(wǎng)絡(luò)狀況的變化并非毫無規(guī)律,在大體上,網(wǎng)絡(luò)狀況的變化只是一個狀態(tài)到另外一個狀態(tài)的轉(zhuǎn)換過程.而Interarrival jitter必然體現(xiàn)這個狀態(tài)的轉(zhuǎn)換過程,即由0到非0再到0的所代表的穩(wěn)定到變化再到穩(wěn)定的過程.

(2)連續(xù)數(shù)據(jù)包傳送的時延差值.記作D.RTCP定義的公式為：

其中Ri、Si分別代表第i個數(shù)據(jù)包接收和發(fā)送的RT P時間戳,因此Ri-Si就代表第i個數(shù)據(jù)包的相對發(fā)送時間,D(i,i-1)則代表相鄰兩個數(shù)據(jù)包的時延差.當(dāng)D(i,i-1)不斷增大時,我們可以得到結(jié)論,即網(wǎng)絡(luò)可用帶寬正在變小,反之變大.

根據(jù)這個變化趨勢,可以在JMF平臺上實(shí)現(xiàn)一個基于動態(tài)偵測帶寬變化的智能流機(jī)制.

5 構(gòu)建基于JMF架構(gòu)的流媒體傳輸

通過對RTP/RTCP的分析,已經(jīng)了解了流媒體傳輸?shù)恼w協(xié)議模型,如圖3所示.在這個模型的基礎(chǔ)上,就可以建立自己的流媒體傳輸系統(tǒng).

圖3 流式媒體傳輸系統(tǒng)的整體協(xié)議模型

5.1 Session Manager接口

SessionManager接口定義了應(yīng)用程序之間建立、參與一個會話和釋放資源并退出整個會話的一整套方法.同樣可以利用其來建立在 RTP傳輸中的 RT PSession.通過建立兩個端口的Session對話,為RTP,RTCP建立了兩個Port的連接.分別用來進(jìn)行RTP的數(shù)據(jù)傳送和RTCP的反饋和控制信息的傳送.下面將利用JMF中的SessionManager來實(shí)現(xiàn)RTP Session：

(1)Session Statistics

通過SessionManager中的Session Statistics,可以保存每個會話的信息,即每個RTP/RTCP包的發(fā)送和接收信息.SessionManager保存了兩個可以用來記錄發(fā)送和接收信息包的屬性：

GlobalReceptionStats：保存了會話中全局的接收信息.

GlobalTransmissionStats：保存了所有發(fā)送者的累計發(fā)送信息.

它們將被用來和RTCP包中的Sender＇spacketcount等字段對應(yīng).

(2)Session Participants(會話參與者)

JMF的Session Manager能夠記錄一個會話中所有參與者的信息.每個參與者是通過一個類的實(shí)例(Instance)來確認(rèn)的.該實(shí)例使用了會話中Participant接口.當(dāng)SessionManager收到一個以前從未收到包含了SDES(Source Description)和CNAME的RTP數(shù)據(jù)包時,將創(chuàng)建一個Participant接口.參與者這是就可以加入一個會話.

在SessionManager中還有一個LocalParticipant屬性,可以用來表示本地參與會話的Client或Server.本地參與者可以發(fā)送RTCP控制信息.

每個會話參與者可以由參于多個數(shù)據(jù)流,每個數(shù)據(jù)流將通過RTP中的SSRC來區(qū)分?jǐn)?shù)據(jù)流的源.

(3)Session Streams

通過SessionManager,還為每個RTP數(shù)據(jù)流保持一個RTPStream對象.ManagerSession將RTP數(shù)據(jù)流分兩類：ReceiveStream表示從遠(yuǎn)端參與者接收到的數(shù)據(jù)流.SendStream將表示通過Prosessor或者輸入DataSource向網(wǎng)絡(luò)發(fā)送的數(shù)據(jù)流.當(dāng)SessionManager偵測到一個新的RTP數(shù)據(jù)包的時候,將自動建立一個 ReceiveStream.而如果要向外發(fā)送 RTP數(shù)據(jù)流,將調(diào)用SessionManager中的 createSend-Stream方法.

5.2 RTP事件

通過繼承JMF中MediaEvent的類,可以創(chuàng)建響應(yīng)的RT P事件.為了得到RTP事件,必須相應(yīng)的RTPListener和SessionManager結(jié)合.

(1)SessionListener：通過它得到一個會話狀態(tài)的改變.包括：

NewParticipantEvent：表示一個新的參與者加入會話.

LocalCollisionEvent：表示參與者請求的同步資源正在使用.

(2)SendStreamListener：通過它得到一個正在傳送的RTP數(shù)據(jù)流的狀態(tài)的改變.

NewSendStreamEvent：表示本地參與者已經(jīng)創(chuàng)建一個新的發(fā)送數(shù)據(jù)流.

ActiveSendStreamEvent：表示從DataSource創(chuàng)建的數(shù)據(jù)流已經(jīng)開始發(fā)送.

InactiveSendStreamEvent：表示從本地DataSource創(chuàng)建的數(shù)據(jù)流已經(jīng)停止.

LocalPayloadChangeEvent：表示數(shù)據(jù)流格式已經(jīng)開始改變.

StreamClosedEvent：表示數(shù)據(jù)流已經(jīng)停止.Indicatesthatthestreamhasbeenclosed.

(3)ReceiveStreamListener：通過它得到一個正在接收的RTP數(shù)據(jù)流的狀態(tài)的改變.

New ReceiveStreamEvent：表示SessionManager已經(jīng)創(chuàng)建了一個從新偵測到的地址來的接收數(shù)據(jù)流.

InactiveReceiveStreamEvent：表示數(shù)據(jù)的傳送已經(jīng)停止.

TimeoutEvent：表示數(shù)據(jù)傳送超時.

RemotePayloadChangeEvent：表示接收到的數(shù)據(jù)流格式已經(jīng)改變.

ApplicationEvent：表示收到了一個RTCPApp數(shù)據(jù)包.

(4)RemoteListener：通過它得到遠(yuǎn)端會話參與者的時間或RTP控制信息.

ReceiverReportEvent：表示接受到一個RTCP的RR包.

SenderReportEvent：表示收到RTCP的SR包.

RemoteCollisionEvent：表示兩個遠(yuǎn)端的參與者使用了相同的SSRC,出錯.

5.3 RTP會話控制及基于反饋的智能流機(jī)制的實(shí)現(xiàn)

JMF架構(gòu)中的SessionManager同樣提供了對會話的控制功能.SessionManager中的控制功能是繼承了JMF中的Control.這樣,通過GetControls方法,就可以的到例如BufferControl的接口.

無論對于Stream Server還是Client而言,對于一個發(fā)起的流媒體傳輸會話,都會在系統(tǒng)資源中占用一定的Buffer資源.一般來說,一個Session的Buffer是固定不便的.JMF的會話控制提供了對Buffer的控制能力.同時,JMF對RTP/RTCP協(xié)議的支持使得能夠獲得RTCP包中包含的信息.在上面對RTCP協(xié)議進(jìn)行分析的時候,已經(jīng)得到了一個基于RTCP報告、可獲取對網(wǎng)絡(luò)狀況變化趨勢的反饋機(jī)制,使得能夠根據(jù)網(wǎng)絡(luò)狀況,改變相應(yīng)Session的Buffer大小,使其適應(yīng)當(dāng)前網(wǎng)絡(luò)的狀況.實(shí)現(xiàn)智能流,其模型如圖4所示.

6 JM F架構(gòu)上RTP/RTCP模型的實(shí)現(xiàn)

通過對JMF架構(gòu)的系統(tǒng)分析和對SessionManager等接口的擴(kuò)展,可以用JMF架構(gòu)實(shí)現(xiàn)基于RTP數(shù)據(jù)流的傳輸.可以利用SessionManager對一個會話的創(chuàng)建和控制來進(jìn)行網(wǎng)絡(luò)流媒體的傳輸.數(shù)據(jù)將從DataSource獲取.例如,為了傳送實(shí)時捕捉的數(shù)據(jù).可以按如下步驟進(jìn)行：

(1)為該會話創(chuàng)建并初始化一個SessionManager.

(2)構(gòu)建一個處理器 (Processor),它將使用相應(yīng)的DataSource,這個DataSource將是由捕捉設(shè)備輸入的.

(3)將輸出格式定義為RTP格式,并加入相應(yīng)的RTP解碼.

(4)從Processor得到輸出DataSource.

(5)調(diào)用SessionManager的CreateSendStream方法發(fā)送輸出DataSource中的數(shù)據(jù).

(6)不斷獲取RTCP報告信息,對 Buffer大小控制,以保證傳輸效率.

可以通過SendStream中的 Start和Stop方法來對數(shù)據(jù)的發(fā)送進(jìn)行控制.當(dāng)?shù)谝淮伍_始發(fā)送數(shù)據(jù)時,SessionManager將充當(dāng)一個接受者的角色 (發(fā)送RTCP的 RR數(shù)據(jù)包).一旦創(chuàng)建了 SendStream.將發(fā)送RTCP的SR數(shù)據(jù)包,并在數(shù)據(jù)流傳送期間以致充當(dāng)一個發(fā)送者的角色.當(dāng)所有數(shù)據(jù)包發(fā)送完畢,可以關(guān)閉該SessionManager.

在接收方要做的工作是同樣的,用SessionManager來創(chuàng)建一個RTP會話以接收數(shù)據(jù)包并交換控制信息.并創(chuàng)建接收 Data-Source,同時創(chuàng)建一個Player對接受中的 Data-Source.

圖4 JMF架構(gòu)上的基于RTCP報告的智能流模型

圖5 基于JMC的RTP/RTCP傳輸模型的設(shè)計

7 結(jié)束語

通過在分析 RTP/RTCP協(xié)議時得出的反饋機(jī)制的方向,實(shí)現(xiàn)一種基于JMF的RTP/RTCP傳輸模型的整體設(shè)計.在對RTP/RTCP工作模型的詳細(xì)分析中,實(shí)現(xiàn)了一個動態(tài)的網(wǎng)絡(luò)反饋機(jī)制,并利用其提供的動態(tài)的反饋信息實(shí)現(xiàn)了對發(fā)送端和接收端Buffer的控制,保證流媒體傳輸?shù)腝oS,以提高流媒體傳輸?shù)男?

[1] 董曉捷.流媒體應(yīng)用技術(shù)淺談[J].河北北方學(xué)院學(xué)報：自然科學(xué)版,2007,(04)：50-53

[2] 王銳,郭喜鳳.基于遺傳算法的DSR路由協(xié)議的優(yōu)化[J].河北北方學(xué)院學(xué)報：自然科學(xué)版,2008,(01)：59-62

[3] 胡澤,趙新梅.流媒體技術(shù)與應(yīng)用[M].北京：中國廣播電視出版社,2006：145-147

[4] 莊捷.流媒體原理與應(yīng)用[M].北京：中國廣播電視出版社,2007：98-100

[5] 肖磊,陳卓.流媒體技術(shù)與應(yīng)用完全手冊[M].重慶：重慶大學(xué)出版社,2003：201-304

[6] 梁振軍.計算機(jī)網(wǎng)絡(luò)通信與協(xié)議[M].北京：石油工業(yè)出版社,1990：135-136

[7] 彭波,孫一林.Java多媒體技術(shù)[M].北京：清華大學(xué)出版社,2004：187-189