Ｐ２Ｐ流媒體點播系統的應用

任從容

[摘要]本文在分析了通用流媒體協議RTP/RTCP/RTSP的工作原理,以及傳統C/S結構的流媒體系統的應用模式的基礎上,結合P2P下流傳輸的特點提出P2P流媒體點播系統的應用模式。

[關鍵詞]點播系統 流媒體傳輸協議 應用模式

點播系統的應用模式是指點播系統與用戶的直接交互方式,在傳統C/S結構的流媒體系統的應用模式是:用戶通過通用播放器與流媒體服務器進行交互,二者之間的通信由一系列標準流媒體傳輸協議提供保證。在P2P環境下我們仍然希望能通過通用播放器將流媒體內容展現給用戶。為此,我們跟據P2P的特點,對傳統的應用模式進行了一些改動。以下我們先介紹流媒體協議族以及傳統C/S模式下的應用模式。最后,討論怎樣在P2P下利用流媒體協議與用戶交互。

一、流媒體傳輸協議

1.實時傳輸協議(RTP)

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

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

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

(2)RTP控制協議 (RTCP)。監控服務質量并傳送正在進行的會話參與者的相關信息。

RTP協議頭的結構如圖1所示。

V―版本。識別 RTP版本。

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

X―擴展位。設置時,在固定頭后面,根據指定格式設置一個擴展頭。

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

M―標記。標記的解釋由 Profile文件定義。允許重要事件如幀邊界在數據包流中進行標記。

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

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

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

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

CSRC―貢獻源標識符。識別該數據包中的有效載荷的貢獻源。

2. RTP控制協議(RTCP)

RTP控制協議RTCP(Real Time Control Protocol)采用與數據包相同的分發機制,將控制包周期性傳輸到所有會話參與者中。底層協議必須提供數據和控制包的多路發送,例如使用不同的 UDP端口號。RTCP主要完成四個功能服務。

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

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

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

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

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

Version―識別 RTP版本。 RTP數據包中的該值與 RTCP數據包中的一樣。當前規范定義的版本值為 2。

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

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

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

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

3.實時流協議(RTSP)

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

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

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

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

在大多數情況下,RTSP服務器需要保持缺省狀態,與 HTTP的無狀態相對。

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

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

(4)RTSP使用 ISO-10646(UTF-8)而并非 ISO 8859-1,與當前的國際標準 HTML相一致。

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

該協議支持如下操作:

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

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

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

4.流媒體傳輸協議在C/S結構中的應用模式

流媒體的傳統應用模式是在客戶端/服務器C/S(或B/S)下工作。其工作方式如圖3所示。客戶端先向WEB服務器請求媒體的描述信息(Media MetaInfo)。再跟據此信息連接特定的流媒體服務器,通過RTSP協議進行指令操作,RTP協議進行流媒體數據傳輸,RTCP協議進行流量控制及擁塞反饋。

二、P2P流媒體點播系統的應用模式

與C/S架構下的流媒體點播模式不同在P2P環境下,流媒體數據的傳輸有以下這幾個特點。

1.流媒體數據不是來自流媒體服務器,而是來自于不同的對等節點。

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

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

因此,如圖4所示,在我們系統的應用模式中,數據在網絡傳輸過程中沒有流化(沒有對數據進行RTP封包),只是將一般的流媒體文件數據分片發送到點播節點,點播節點通過數據分片重組模塊對來自不同節點的數據進行排序重組,并輸出到一個數據分片隊列。數據流化模塊實際上實現了一個小型的本地流媒體服務器。此模塊從數據分片隊列中提取數據,對數據進行流化處理,并在本地回環地址loopback address上開啟一個提供RTSP服務的端口,接收響應用戶的RTSP請求。當用戶用播放器連接回環地址上的服務端口時,數據流化模塊將流化后的數據通過RTP協議發送給播放器,用戶即可看到點播的流媒體內容,并可通過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協議流媒體服務器的實現.