任從容

[摘要]本文在分析了通用流媒體協(xié)議RTP/RTCP/RTSP的工作原理,以及傳統(tǒng)C/S結(jié)構(gòu)的流媒體系統(tǒng)的應(yīng)用模式的基礎(chǔ)上,結(jié)合P2P下流傳輸?shù)奶攸c提出P2P流媒體點播系統(tǒng)的應(yīng)用模式。

[關(guān)鍵詞]點播系統(tǒng) 流媒體傳輸協(xié)議 應(yīng)用模式

點播系統(tǒng)的應(yīng)用模式是指點播系統(tǒng)與用戶的直接交互方式,在傳統(tǒng)C/S結(jié)構(gòu)的流媒體系統(tǒng)的應(yīng)用模式是:用戶通過通用播放器與流媒體服務(wù)器進行交互,二者之間的通信由一系列標(biāo)準(zhǔn)流媒體傳輸協(xié)議提供保證。在P2P環(huán)境下我們?nèi)匀幌Ｍ芡ㄟ^通用播放器將流媒體內(nèi)容展現(xiàn)給用戶。為此,我們跟據(jù)P2P的特點,對傳統(tǒng)的應(yīng)用模式進行了一些改動。以下我們先介紹流媒體協(xié)議族以及傳統(tǒng)C/S模式下的應(yīng)用模式。最后,討論怎樣在P2P下利用流媒體協(xié)議與用戶交互。

一、流媒體傳輸協(xié)議

1.實時傳輸協(xié)議(RTP)

實時傳輸協(xié)議 RTP (Real Time Transport Protocol)為數(shù)據(jù)提供了具有實時特征的終端對終端傳送服務(wù),如在組播或單播網(wǎng)絡(luò)服務(wù)下的交互式視頻音頻或仿真數(shù)據(jù)。應(yīng)用程序在 UDP上執(zhí)行 RTP,以便使用其多路技術(shù)和檢驗和服務(wù);還有傳輸協(xié)議函數(shù)的協(xié)議捐助部分。但是 RTP可以與其它適合的底層網(wǎng)絡(luò)或傳輸協(xié)議共同使用。如果底層網(wǎng)絡(luò)提供組播分配,那么 RTP可以使用該組播分配支持多路目標(biāo)文件的數(shù)據(jù)傳輸。

RTP本身并沒有為及時傳送提供任何機制或其它質(zhì)量服務(wù) QoS保證,但它依賴于低層服務(wù)去實現(xiàn)這一過程。RTP并不能保證傳送過程或防止無序傳送,也不能確定底層網(wǎng)絡(luò)的可靠性。RTP實行有序傳送,RTP中的序列號允許接收方重建發(fā)送方的包序列,同時序列號也能用于決定適當(dāng)?shù)陌恢?例如在視頻譯碼中,不需要順次解碼。完整的RTP由兩個具體的協(xié)議組成。

(1)RTP。傳送具有實時屬性的數(shù)據(jù)。

(2)RTP控制協(xié)議 (RTCP)。監(jiān)控服務(wù)質(zhì)量并傳送正在進行的會話參與者的相關(guān)信息。

RTP協(xié)議頭的結(jié)構(gòu)如圖1所示。

V―版本。識別 RTP版本。

P―間隙(Padding)。設(shè)置時,數(shù)據(jù)包包含一個或多個附加間隙位組,其中這部分不屬于有效載荷。

X―擴展位。設(shè)置時,在固定頭后面,根據(jù)指定格式設(shè)置一個擴展頭。

CSRC Count―包含 CSRC標(biāo)識符(在固定頭后)的編號。

M―標(biāo)記。標(biāo)記的解釋由 Profile文件定義。允許重要事件如幀邊界在數(shù)據(jù)包流中進行標(biāo)記。

Payload Type―識別 RTP有效載荷的格式,并通過應(yīng)用程序決定其解釋。Profile文件規(guī)定了從 Payload編碼到 Payload格式的缺省靜態(tài)映射。另外的 Payload Type編碼可能通過非 RTP方法實現(xiàn)動態(tài)定義。

Sequence Number―每發(fā)送一個 RTP數(shù)據(jù)包,序列號增加1。接收方可以依次檢測數(shù)據(jù)包的丟失并恢復(fù)數(shù)據(jù)包序列。

Timestamp―反映 RTP數(shù)據(jù)包中的第一個八位組的采樣時間。采樣時間必須通過時鐘及時提供線性無變化增量獲取,以支持同步和抖動計算。

SSRC―同步源。該標(biāo)識符隨機選擇,旨在確保在同一個 RTP會話中不存在兩個同步源具有相同的 SSRC標(biāo)識符。

CSRC―貢獻源標(biāo)識符。識別該數(shù)據(jù)包中的有效載荷的貢獻源。

2. RTP控制協(xié)議(RTCP)

RTP控制協(xié)議RTCP(Real Time Control Protocol)采用與數(shù)據(jù)包相同的分發(fā)機制,將控制包周期性傳輸?shù)剿袝拝⑴c者中。底層協(xié)議必須提供數(shù)據(jù)和控制包的多路發(fā)送,例如使用不同的 UDP端口號。RTCP主要完成四個功能服務(wù)。

(1)RTCP提供數(shù)據(jù)分發(fā)質(zhì)量反饋信息。這是 RTP作為傳輸協(xié)議的部分功能并且它涉及到了其它傳輸協(xié)議的流控制和擁塞控制。

(2)RTCP為 RTP源攜帶一個持久性傳輸層標(biāo)識符,稱為規(guī)范名或 CNAME。由于一旦發(fā)現(xiàn)沖突或程序重啟時,SSRC標(biāo)識符會隨之改變,所以接收方需要 CNAME來跟蹤每一個參與者。同時接收方還要求 CNAME能夠與一組相關(guān) RTP會話中來自于給定參與者的多重數(shù)據(jù)流相關(guān)聯(lián),例如同步視頻和音頻。

(3)上述前兩個功能要求所有的參與者都要發(fā)送 RTCP包,因此必須控制速率以便 RTP按比例增加大量的參與者。通過每一個參與者發(fā)送各自的控制包給其它所有參與者,每一個參與者能夠獨立觀察到參與者數(shù)量,該數(shù)量可用來計算控制包的發(fā)送速率。

(4)OPTIONAL功能用于傳送最少會話控制信息,例如在用戶界面顯示參與者標(biāo)識。這對于“松散受控”會話(在沒有成員控制或闡述協(xié)商的情況下,參與者可以加入或退出該會話)是非常有用的。

上述功能 1～3適用于所有環(huán)境,尤其是 IP組播環(huán)境。RTP應(yīng)用程序設(shè)計者應(yīng)該避免設(shè)計只能工作于單播模式并且不能增加到大量數(shù)量的機制。在某些情況下如單向鏈接中,不可能有來自接收方的反饋,所以 RTCP的傳輸就可能由發(fā)送方和接收方分別獨立控制。

Version―識別 RTP版本。 RTP數(shù)據(jù)包中的該值與 RTCP數(shù)據(jù)包中的一樣。當(dāng)前規(guī)范定義的版本值為 2。

P―間隙(Padding)。設(shè)置時,RTCP數(shù)據(jù)包包含一些其它 padding八位位組,它們不屬于控制信息。Padding的最后八位是用于計算應(yīng)該忽略多少間隙八位位組。一些加密算法中需要計算固定塊大小時也可能需要使用 Padding字段。在一個復(fù)合 RTCP數(shù)據(jù)包中,只有最后的個別數(shù)據(jù)包中才需要使用 padding,這是因為復(fù)合數(shù)據(jù)包是作為一個整體來加密的。

RC―接收方報告計數(shù)。包含在該數(shù)據(jù)包中的接收方報告塊的數(shù)量,有效值為 0。

Packet type―包括常量 200,識別這是一個 RTCP SR數(shù)據(jù)包。

Length― RTCP數(shù)據(jù)包的大小(32位字減去 1),包含頭和任意間隙(偏移量的引入使得 0成為有效值,并避免了掃描復(fù)合 RTCP數(shù)據(jù)包過程中的無限循環(huán)現(xiàn)象,而采用 32位字計數(shù)方法則避免了對 4的倍數(shù)的有效性校驗)。

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

實時流協(xié)議(RTSP)建立并控制一個或幾個時間同步的連續(xù)流媒體,如音頻和視頻。盡管連續(xù)媒體流與控制流交叉是可能的,RTSP本身并不發(fā)送連續(xù)流。換言之,RTSP充當(dāng)多媒體服務(wù)器的網(wǎng)絡(luò)遠程控制。RTSP提供了一個可擴展框架,實現(xiàn)實時數(shù)據(jù)(如音頻與視頻)的受控、按需傳送。數(shù)據(jù)源包括實況數(shù)據(jù)與存儲的剪輯。RTSP用于控制多個數(shù)據(jù)發(fā)送會話,提供了選擇發(fā)送通道(如 UDP、組播 UDP與 TCP等)的方式,并提供了選擇基于 RTP的發(fā)送機制的方法。

目前還沒有 RTSP連接的概念;服務(wù)器維護由識別符標(biāo)識的會話。RTSP會話不會綁定到傳輸層連接,如 TCP。在 RTSP會話期間,RTSP客戶端可打開或關(guān)閉多個對服務(wù)器的可靠傳輸連接以發(fā)出 RTSP請求。它也可選擇使用無連接傳輸協(xié)議,如 UDP。

RTSP控制的流可能用到 RTP,但 RTSP操作并不依賴用于傳輸連續(xù)媒體的傳輸機制。RTSP在語法和操作上與 HTTP/1.1類似,因此 HTTP的擴展機制在多數(shù)情況下可加入 RTSP。然而,在很多重要方面 RTSP仍不同于 HTTP。

(1)RTSP引入了大量新方法并具有一個不同的協(xié)議標(biāo)識符。

在大多數(shù)情況下,RTSP服務(wù)器需要保持缺省狀態(tài),與 HTTP的無狀態(tài)相對。

(2)RTSP中客戶端和服務(wù)器都可以發(fā)出請求。

(3)在多數(shù)情況下,數(shù)據(jù)由不同的協(xié)議傳輸。

(4)RTSP使用 ISO-10646(UTF-8)而并非 ISO 8859-1,與當(dāng)前的國際標(biāo)準(zhǔn) HTML相一致。

(5)URI請求總是包含絕對 URI。為了與過去的錯誤相互兼容,HTTP/1.1只在請求過程中傳送絕對路徑并將主機名置于另外的頭字段。

該協(xié)議支持如下操作:

(1)從媒體服務(wù)器上檢索媒體。用戶可通過 HTTP或其它方法提交一個演示描述請求。

(2)媒體服務(wù)器邀請進入會議。媒體服務(wù)器可被邀請參加正進行的會議,或回放媒體,或記錄部分或全部演示。

(3)將新媒體加到現(xiàn)有演示中。如服務(wù)器能告訴客戶端接下來可用的媒體內(nèi)容,對現(xiàn)場直播顯得尤其有用。

4.流媒體傳輸協(xié)議在C/S結(jié)構(gòu)中的應(yīng)用模式

流媒體的傳統(tǒng)應(yīng)用模式是在客戶端/服務(wù)器C/S(或B/S)下工作。其工作方式如圖3所示?？蛻舳讼认騑EB服務(wù)器請求媒體的描述信息(Media MetaInfo)。再跟據(jù)此信息連接特定的流媒體服務(wù)器,通過RTSP協(xié)議進行指令操作,RTP協(xié)議進行流媒體數(shù)據(jù)傳輸,RTCP協(xié)議進行流量控制及擁塞反饋。

二、P2P流媒體點播系統(tǒng)的應(yīng)用模式

與C/S架構(gòu)下的流媒體點播模式不同在P2P環(huán)境下,流媒體數(shù)據(jù)的傳輸有以下這幾個特點。

1.流媒體數(shù)據(jù)不是來自流媒體服務(wù)器,而是來自于不同的對等節(jié)點。

2.用戶收到的流媒體數(shù)據(jù)不只是供用戶自己使用,可能還需要保存下來為其它用戶提供服務(wù)。

3.直接采用RTP/UDP的流媒體傳輸方式,可能會在傳輸過程中丟包(當(dāng)然,可在應(yīng)用層實現(xiàn)數(shù)據(jù)包的重傳),少量的丟包也許是用戶可以忍受的,但其它節(jié)點再向其請求數(shù)據(jù)時,丟包的損失進一步被放大。

因此,如圖4所示,在我們系統(tǒng)的應(yīng)用模式中,數(shù)據(jù)在網(wǎng)絡(luò)傳輸過程中沒有流化(沒有對數(shù)據(jù)進行RTP封包),只是將一般的流媒體文件數(shù)據(jù)分片發(fā)送到點播節(jié)點,點播節(jié)點通過數(shù)據(jù)分片重組模塊對來自不同節(jié)點的數(shù)據(jù)進行排序重組,并輸出到一個數(shù)據(jù)分片隊列。數(shù)據(jù)流化模塊實際上實現(xiàn)了一個小型的本地流媒體服務(wù)器。此模塊從數(shù)據(jù)分片隊列中提取數(shù)據(jù),對數(shù)據(jù)進行流化處理,并在本地回環(huán)地址loopback address上開啟一個提供RTSP服務(wù)的端口,接收響應(yīng)用戶的RTSP請求。當(dāng)用戶用播放器連接回環(huán)地址上的服務(wù)端口時,數(shù)據(jù)流化模塊將流化后的數(shù)據(jù)通過RTP協(xié)議發(fā)送給播放器,用戶即可看到點播的流媒體內(nèi)容,并可通過RTSP進行VCR操作。

參考文獻:

[1] Network Working Group.RFC1889.RTP: A Transport Protocol for Real-Time Applications.Lawrence Berkeley National Laboratory, 1996.

[2] Network Working Group.RFC3550.RTP: A Transport Protocol for Real-Time Applications.Columbia University, 2003..

[3] Network Working Group.RFC2326.Real Time Streaming Protocol (RTSP). Columbia University,1998.

[4]李煒,曾珂,戴瓊海.基于RTSP協(xié)議流媒體服務(wù)器的實現(xiàn).