《網(wǎng)絡(luò)多媒體技術(shù)》課件第8章

第8章流媒體技術(shù)8.1流媒體概述8.2流媒體傳輸協(xié)議8.3流媒體的關(guān)鍵技術(shù)及開發(fā)平臺8.4P2P流媒體8.5流媒體的應用8.6本章小結(jié)思考練習題流媒體技術(shù)是多媒體和網(wǎng)絡(luò)領(lǐng)域的交叉學科。多媒體技術(shù)使PC機能夠?qū)⒙曇?、視頻、文字等多種信息整合成多媒體信息，并實現(xiàn)方便的交互，從而給人們的工作和娛樂帶來豐富多采的變化，只是這些多媒體信息的數(shù)據(jù)量比傳統(tǒng)的文本文件要大得多。當人們不再滿足只在單機上看到豐富的聲、文、圖等多媒體信息，而是希望能從網(wǎng)絡(luò)中獲得多媒體信息的時候，網(wǎng)絡(luò)的數(shù)據(jù)傳輸壓力大大增加，因為即使下載一個很短時間的視/音頻文件也需要用戶等待很長的時間。形成這種等待的主要原因是多媒體文件需要從服務(wù)器上全部下載到客戶端后才能播放。為了解決這個問題，流媒體技術(shù)應運而生。本章對流媒體技術(shù)從概述、傳輸協(xié)議、關(guān)鍵技術(shù)、開發(fā)平臺以及P2P流媒體技術(shù)幾個方面進行全面介紹。

8.1.1流媒體的定義

目前尚沒有一個關(guān)于流媒體的公認定義。一般來說，流媒體(StreamingMedia)是指在Internet/Intranet中使用流式技術(shù)進行傳輸?shù)倪B續(xù)時基媒體，如音/視頻等多媒體內(nèi)容。其中流式(Streaming)技術(shù)是指在媒體傳輸過程中，服務(wù)器將多媒體文件壓縮解析成多個壓縮包后放在IP網(wǎng)上按順序傳輸，客戶端(通常是指PC機，也稱用戶端)則開辟一塊一定大小的緩沖區(qū)(計算機內(nèi)存中用于臨時存放數(shù)據(jù)的存儲塊)來接收壓縮包，8.1流媒體概述緩沖區(qū)被充滿只需幾秒鐘或數(shù)十秒鐘的時間，之后客戶端就可以解壓縮緩沖區(qū)中的數(shù)據(jù)并開始播放其中的內(nèi)容?？蛻舳嗽谙牡艟彌_區(qū)內(nèi)數(shù)據(jù)的同時，又下載后續(xù)的壓縮包到空出的緩沖區(qū)空間中，從而實現(xiàn)了邊下載邊播放的流式傳輸。可見流式傳輸是流媒體實現(xiàn)的關(guān)鍵技術(shù)。與傳統(tǒng)的多媒體技術(shù)相比，流媒體具有如下特點：

流媒體是實時的，當客戶下載媒體文件時，不需要像傳統(tǒng)的播放技術(shù)那樣將整個文件都下載下來之后再播放，而是邊下載邊播放，它不僅節(jié)省了客戶端的緩沖區(qū)容量，還大大減少了用戶的等待時間。

流媒體數(shù)據(jù)在播放后即被丟棄，不會存儲在用戶的計算機上，便于流媒體文件的版權(quán)保護。

流媒體的服務(wù)器支持客戶端對流媒體進行VCR(錄像機)操作控制，即用戶可以像使用家用錄像機一樣對流媒體進行播放、暫停、快進、快退、停止等操作。8.1.2流媒體的通信原理

由于目前的網(wǎng)絡(luò)帶寬還不能完全滿足巨大的AV、3D等多媒體數(shù)據(jù)流量的要求，因此在流媒體通信技術(shù)中，應首先對AV、3D等多媒體文件數(shù)據(jù)進行預處理，然后才能進行流式傳輸。它主要包括降低質(zhì)量和采用先進、高效的壓縮算法兩個方面。與下載方式相比，盡管流式傳輸大大降低了對系統(tǒng)緩存容量的要求，但它的實現(xiàn)仍需要緩存，這是因為Internet是以包傳輸為基礎(chǔ)進行斷續(xù)異步傳輸?shù)?。?shù)據(jù)在傳輸中要被分解為許多包，而網(wǎng)絡(luò)又是動態(tài)變化的，各個包選擇的路由可能不盡相同，故到達用戶計算機的時間延時也就不同。所以，必須使用緩存系統(tǒng)來彌補延時和抖動的影響，并保證數(shù)據(jù)包傳輸順序的正確，使媒體數(shù)據(jù)能連續(xù)輸出，不會因網(wǎng)絡(luò)的暫時擁堵而出現(xiàn)播放停頓。在整個傳輸和控制過程中，必須采用一定的網(wǎng)絡(luò)協(xié)議來實現(xiàn)流式傳輸，為客戶提供可靠的服務(wù)質(zhì)量保證。流媒體的傳輸過程如圖8-1所示?？蛻?Web瀏覽器)通過HTTP/TCP與Web服務(wù)器(WebServer)交換信息，獲取流媒體服務(wù)清單，根據(jù)獲得的流媒體服務(wù)清單向媒體服務(wù)器(AVServer)請求相關(guān)服務(wù)；然后客戶機的Web瀏覽器啟動相應的媒體播放器(AVPlayer)，通過RTP/UDP從媒體服務(wù)器中獲取流媒體數(shù)據(jù)，實時播放。在播放過程中，客戶機的媒體播放器需要實時通過RTSP/TCP(UDP)與媒體服務(wù)器交換控制信息，媒體服務(wù)器根據(jù)客戶機反饋的流媒體接收情況，智能化地調(diào)整向客戶機傳送的媒體數(shù)據(jù)流，從而在客戶端達到最優(yōu)的接收效果。圖8-1流式傳輸?shù)幕驹韺崿F(xiàn)流式傳輸有兩種方法：實時流式(RealtimeStreaming)傳輸和順序流式(ProgressiveStreaming)傳輸。一般來說，如果視頻為實時廣播，或使用流式傳輸媒體服務(wù)器，或應用如RTSP的實時協(xié)議，則流式傳輸為實時流式傳輸。如果使用HTTP服務(wù)器，文件即通過順序流發(fā)送，這種傳輸方式就稱為順序流式傳輸。流式文件在播放前可完全下載到硬盤上。

1. 順序流式傳輸

順序流式傳輸是順序下載的，在下載文件的同時客戶可觀看在線媒體，在給定時刻，客戶只能觀看已下載的那部分，而不能跳到還未下載的后續(xù)部分。順序流式傳輸不像實時流式傳輸那樣，可在傳輸期間根據(jù)客戶連接的速度作調(diào)整。由于標準的HTTP服務(wù)器可發(fā)送這種形式的文件，因而不需要其他特殊協(xié)議，它經(jīng)常被稱做HTTP流式傳輸。順序流式傳輸比較適合高質(zhì)量的短片段，如片頭、片尾和廣告，由于這種文件是無損下載的，因此它可以保證電影播放的最終質(zhì)量。這意味著客戶在觀看前必須經(jīng)歷延時，對較慢的連接尤其如此。當通過調(diào)制解調(diào)器發(fā)布短片段時，順序流式傳輸顯得很實用，它允許用比調(diào)制解調(diào)器更高的數(shù)據(jù)速率創(chuàng)建視頻片段。盡管有延時，但畢竟可以發(fā)布較高質(zhì)量的視頻片段。

順序流式文件是放在標準HTTP或FTP服務(wù)器上的，這種文件易于管理，基本上與防火墻無關(guān)。順序流式傳輸不適合長片段和有隨機訪問要求的視頻，如講座、演說與演示。它也不支持現(xiàn)場廣播，嚴格說來，它是一種點播技術(shù)。

2. 實時流式傳輸

實時流式傳輸保證媒體信號帶寬與網(wǎng)絡(luò)連接匹配，使媒體可被實時觀看到。實時流式傳輸與HTTP流式傳輸不同，它需要專用的流媒體服務(wù)器與傳輸協(xié)議。實時流式傳輸總是實時傳送，特別適合現(xiàn)場事件，也支持隨機訪問，客戶可快進或后退以觀看前面或后面的內(nèi)容。理論上講，實時流一經(jīng)播放就不可停止，但實際上可能發(fā)生周期性暫停現(xiàn)象。實時流式傳輸必須匹配連接帶寬，這意味著在以調(diào)制解調(diào)器的速度連接時圖像質(zhì)量較差，而且，由于出錯而丟失的信息被忽略掉，因此當網(wǎng)絡(luò)擁擠或出現(xiàn)問題時視頻質(zhì)量很差。如欲保證視頻質(zhì)量，采用順序流式傳輸也許更好。實時流式傳輸需要特定服務(wù)器，如QuickTimeStreamingServer、RealServer與WindowsMediaServer。這些服務(wù)器允許對媒體發(fā)送進行更多級別的控制，因而系統(tǒng)設(shè)置和管理比標準HTTP服務(wù)器更復雜。實時流式傳輸還需要特殊網(wǎng)絡(luò)協(xié)議，如RTSP(RealTimeStreamingProtocol)或MMS(MicrosoftMediaServer)。這些協(xié)議在有防火墻時有可能會出現(xiàn)問題，導致用戶不能看到一些地點的實時內(nèi)容。8.1.3流媒體的播放方式

1.單播

客戶端與媒體服務(wù)器之間是點到點連接的，媒體服務(wù)器為每一提出請求的客戶端單獨發(fā)送一條媒體流，這種播放方式稱為單播?？梢姡挥挟斂蛻舳耸紫劝l(fā)出請求后，服務(wù)器才會發(fā)送單播流，并且請求的客戶數(shù)越多，單播流就越多，這會給服務(wù)器和網(wǎng)絡(luò)帶寬帶來沉重負擔。

2.組播

媒體服務(wù)器只需發(fā)送一條媒體流，之后通過組播轉(zhuǎn)發(fā)樹再復制并轉(zhuǎn)發(fā)該媒體流，使網(wǎng)絡(luò)中的所有客戶端共享同一條流，這種播放方式稱為組播?？梢姡M播的好處是減少了網(wǎng)絡(luò)上傳輸?shù)拿襟w流的數(shù)量，從而節(jié)省了網(wǎng)絡(luò)帶寬。

3.點播和廣播

點播是指客戶端主動與服務(wù)器取得聯(lián)系，要求服務(wù)器傳送它指定的媒體流。點播連接時，用戶可以對流進行開始、暫停、后退等VCR操作，實現(xiàn)了對流的最大控制。由于點播最終傳送的是單播流，因此，當點播的用戶數(shù)不斷增加時，網(wǎng)絡(luò)帶寬會迅速消耗殆盡。

廣播是指服務(wù)器將一條媒體流向網(wǎng)絡(luò)中的所有客戶發(fā)布，而客戶只能被動接收，并且不能通過VCR操作來控制流。這種廣播連接同樣會浪費網(wǎng)絡(luò)帶寬。8.1.4流媒體系統(tǒng)的基本結(jié)構(gòu)

流媒體系統(tǒng)包括音/視頻源的編碼/壓縮、存儲、流媒體服務(wù)器、媒體流傳輸網(wǎng)絡(luò)、用戶端播放器5個部分，如圖8-2所示。原始音/視頻流經(jīng)過編碼和壓縮后，形成流媒體文件并存儲，媒體服務(wù)器根據(jù)用戶的請求把流媒體文件傳遞到用戶端的媒體播放器。這5個部分有些是網(wǎng)站需要的，有些是客戶端需要的，而且不同的流媒體標準和不同公司的解決方案會在某些方面有所不同。

一個流媒體系統(tǒng)應至少包括以下三個組件。圖8-2流媒體系統(tǒng)基本結(jié)構(gòu)

1.編碼器(Encoder)

它用于將原始音/視頻轉(zhuǎn)換成流媒體格式的軟件或硬件。要傳送的多媒體數(shù)據(jù)應先進行預處理，將多媒體文件經(jīng)過壓縮編碼，處理成流媒體文件格式。這種格式的文件尺寸較小，并且加入了流式信息，適合在網(wǎng)絡(luò)上邊下載邊播放。常用的流媒體文件格式有*.wma、*.wmv、*.avi、*.rm、*.mp3、*.mov等。前面章節(jié)曾介紹過，有多種不同的壓縮編碼方法可以將原始音/視頻壓縮成能夠在Internet上傳播的流格式文件。

2.媒體服務(wù)器(MediaServer)

它是用于向客戶發(fā)布流媒體的軟件。轉(zhuǎn)換成流媒體格式的文件被存放在媒體服務(wù)器上，作為向客戶發(fā)布流媒體的服務(wù)器，它要處理來自客戶端的請求，例如客戶端要求播放、暫停或者快進一個流文件，這就要求服務(wù)器在流媒體傳輸期間要始終與客戶端的播放器保持通信。

3.播放器(Player)

它是客戶端用來收看(聽)流媒體的軟件。位于客戶端的播放器實際上就是一個解碼器，它能夠解碼收到的流媒體文件。除此之外，播放器還通過與媒體服務(wù)器的相互通信來提供對流的交互式操作。不僅如此，要實現(xiàn)流媒體的傳輸，客戶端需要緩沖系統(tǒng)來緩存流數(shù)據(jù)。流媒體文件通過IP網(wǎng)絡(luò)傳輸?shù)臅r候，最終是以一個個IP分組的形式傳送的。IP分組在傳輸時是各自獨立的，因此會根據(jù)路由選擇協(xié)議動態(tài)地選擇不同的路由到達客戶端，導致客戶端接收到的分組延時不同，次序被打亂。因此需要緩沖系統(tǒng)將IP分組按正確的順序進行整理，保證媒體數(shù)據(jù)的順序輸出。不僅如此，當網(wǎng)絡(luò)出現(xiàn)暫時擁塞使得數(shù)據(jù)分組延誤到達時，由于緩沖區(qū)事先緩存了一定數(shù)量的數(shù)據(jù)，因此節(jié)目不會中斷，從而保證了播放的連續(xù)性。緩沖區(qū)采用環(huán)形鏈表結(jié)構(gòu)存儲數(shù)據(jù)，該結(jié)構(gòu)能使已經(jīng)播放完的數(shù)據(jù)隨即被丟棄，空出的緩沖區(qū)空間再重新被利用來緩存后續(xù)的媒體內(nèi)容。

除了以上這三個組件之外，通常為了用戶操作的簡單和直觀，流媒體系統(tǒng)還采用Web服務(wù)器向用戶提供流媒體節(jié)目的目錄信息，用戶可以通過自己的Web瀏覽器獲得這個目錄信息，從而定位節(jié)目所在的媒體服務(wù)器的位置，之后與媒體服務(wù)器建立聯(lián)系。

流媒體采用流式傳輸方式在網(wǎng)絡(luò)服務(wù)器與客戶端之間傳輸數(shù)據(jù)。流式傳輸?shù)膶崿F(xiàn)需要合適的傳輸協(xié)議。IETF(InternetEngineeringTaskForce，因特網(wǎng)工程任務(wù)組)制定的很多協(xié)議可用于實現(xiàn)流媒體技術(shù)。8.2流媒體傳輸協(xié)議8.2.1實時傳輸協(xié)議

實時傳輸協(xié)議(Real-timeTransportProtocol，RTP)是由IETF設(shè)計的用于互聯(lián)網(wǎng)上多媒體數(shù)據(jù)流的一種傳輸協(xié)議，主要用來為實時數(shù)據(jù)的應用提供點到點或點到多點的傳輸服務(wù)。它已成為IP網(wǎng)多媒體系統(tǒng)廣泛采用的實時媒體傳輸層協(xié)議。

RTP由兩個緊密相關(guān)的部分組成：實時傳輸協(xié)議(RTP)和實時傳輸控制協(xié)議(RealtimeTransportControlProtocol，RTCP)。為了可靠、高效地傳送實時數(shù)據(jù)，RTP和RTCP必須配合使用。RTP主要用于承載多媒體數(shù)據(jù)，并通過包頭時間參數(shù)的配置來使其具有實時的特征。RTCP主要用于周期性地傳送RTCP包，監(jiān)視RTP傳輸?shù)姆?wù)質(zhì)量。在RTCP包中，含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料。因此，服務(wù)器可以利用這些信息動態(tài)地改變傳輸速率，實現(xiàn)流量控制和擁塞控制服務(wù)。

1.相關(guān)概念

(1)RTP會話。兩個或多個用戶之間通過RTP建立的連接稱為RTP會話，“用戶”為會話的參加者。對于一個參加者而言，會話由一對傳輸層地址標識。這對傳送層地址包括一個網(wǎng)絡(luò)地址(IP地址)和一對端口號。一個端口為RTP報文的發(fā)送/接收所使用，另一個端口為RTCP報文的發(fā)送/接收所使用。如果會話是由組播建立起來的RTP會話，那么該RTP會話的標識對于會話的每個參加者來說都是相同的，即每個參加者使用同一個IP地址和同一對端口號標識該RTP會話以進行通信。如果會話是由單播建立起來的，那么會話雙方使用各自的IP地址，但卻用相同的一對端口號來標識該RTP會話。在一個RTP會話上通常只傳送一種媒體類型的數(shù)據(jù)，多個媒體對應多個RTP會話，每個RTP會話具有自己的RTCP報文，用以控制會話的質(zhì)量。RTP會話之間通過不同的端口對號來區(qū)分。

(2)RTP協(xié)議的相關(guān)文件。為了實現(xiàn)根據(jù)應用進行分幀的原則，RTP定義了兩類文件：

格式文件(FormatDocuments)，規(guī)定了將某種媒體流劃分成應用數(shù)據(jù)單元(ADU)的原則以及ADU的格式。RTP協(xié)議已經(jīng)為H.26X視頻流、MPEG視頻流以及各種編碼格式的音頻流等制定了格式文件。用戶也可以根據(jù)自己的需要定義新的格式文件。

輪廓文件(ProfileDocument)，規(guī)定了某一特定應用對RTP協(xié)議的具體使用方法。一般一種應用對應一個輪廓文件。

(3)同步源和提供源。在一個采用RTP支持的多媒體會議會話中，需多個用戶同時參加，而且每個用戶發(fā)出多種類型的媒體，例如麥克風的聲音或攝像機的視頻，那么發(fā)出某一類媒體的源，如麥克風和攝像機被稱為同步源(SynchronizationSource，SSRC)。同步源之間通過同步源標識符來區(qū)分。要注意的是，如果某一類型的媒體來自多個源，例如同時有多個攝像機提供視頻，那么每一個源也都要用不同的同步源(SSRC)標識符來區(qū)分。會話過程中，多個用戶發(fā)出的多個同步源都匯集到一個叫做Mixer(混合器)的中間系統(tǒng)中，經(jīng)混合器重新組合形成一個新的組合流再發(fā)送出去，用戶接收的是混和器輸出的組合流。這樣，用戶終端就能夠獲得所有參加會議的其他用戶的信息?；旌掀鞯淖饔檬墙邮账性吹腞TP報文，以某種方式將它們組合起來，其中還對部分報文進行數(shù)據(jù)格式轉(zhuǎn)換，使之形成新的RTP報文，并將其發(fā)送出去。由于這些輸入的同步源彼此之間不同步，因此需利用混合器對它們進行調(diào)整，生成組合流。這樣，該組合流就是一個同步流，它同樣也需要用一個同步源標識符來標識。此時該同步源標識符代替了輸入混合器的所有同步源的同步源標識符，這樣便將具有唯一一個同步源標識符的組合流送給各個接收端。在混和器中形成組合流的所有同步源叫做該組合流的提供源(ContributingSource，CSRC)。

2.RTP

RTP報文由固定長度的報頭、可選的CSRC及載荷組成，格式如圖8-3所示。

RTP報頭為固定長度，共12個字節(jié)。RTP報文包含的主要字段有：

V：RTP協(xié)議的版本號，占2位。當前的協(xié)議版本號為2。

P：填充標志，占1位，指明載荷區(qū)最后是否有填充數(shù)據(jù)。如果有填充數(shù)據(jù)，則載荷區(qū)的最后一字節(jié)中裝載填充數(shù)據(jù)的長度。圖8-3RTP報文格式

X：擴展標志，占1位，如果X＝1，則在RTP報頭后跟有一個擴展報頭。

CC：CSRC計數(shù)器，占4位，指示CSRC標識符的個數(shù)。

M：標記，占1位，標識連續(xù)碼流中的某些特殊事件，標記的具體解釋則在輪廓文件中定義。

PT：有效載荷類型，占7位，用于說明RTP報文中有效載荷的類型，接收端可以據(jù)此解釋并播放RTP數(shù)據(jù)。

序列號：占16位，用于標識發(fā)送者所發(fā)送的RTP報文的序列號，每發(fā)送一個報文，序列號增1。接收者通過序列號來檢測報文的丟失情況，重新排序報文，恢復數(shù)據(jù)。

時戳(Timestamp)：占32位，反映了該RTP報文的第一個字節(jié)的采樣時刻。接收者使用時戳來計算延時和延時抖動，并進行同步控制。

同步源標識符：占32位，用于標識同步源。該標識符是隨機選擇的，參加同一視頻會議的兩個同步源不能有相同的SSRC。

提供源標識符列表(CSRC)：每個CSRC標識符占32位，可以有0～15個，具體數(shù)目則由上面的CC字段給出。每個CSRC標識了包含在該RTP報文有效載荷中的所有提供源。

3.RTCP

RTCP是一個控制協(xié)議，它的報文不攜帶用戶數(shù)據(jù)，只攜帶與會話有關(guān)的控制信息。它通過周期性地向所有參加者發(fā)送RTCP報文來傳輸有關(guān)服務(wù)質(zhì)量的反饋信息和參加會話的成員信息。

為了實施不同的控制功能，RTCP定義了發(fā)送者報告報文(SenderReport，SR)、接收者報告報文(ReceiverReport，RR)、信源描述報文(SourceDescriptionItems，SDES)、結(jié)束報文和應用相關(guān)功能報文(ApplicationSpecificFunctions)等五種類型的報文，其中最重要的是SR和RR。

SR報文在會話中由當前發(fā)送者產(chǎn)生，格式如圖8-4所示。

SR報文包含三部分內(nèi)容：

(1)SR報頭部分。報頭部分包含了一個RTCP報文的公共信息，包括以下字段：V，版本號，占2位，標識RTP版本，與RTP報頭中的版本號相同；P，填充標志，占1位；RC，接收報告計數(shù)，占5位，指出接收報告塊的個數(shù)；PT，報文類型，占8位，SR報文類型標識符為200；報文長度，占16位；SSRC標識符，占32位，為發(fā)送該SR報文的同步源標識符。圖8-4SR報文格式

(2)發(fā)送者信息部分。發(fā)送者信息部分記錄了有關(guān)本機發(fā)送RTP報文情況的信息，包括以下字段：NTP時戳，占64位，指出該SR報文發(fā)送時的全局網(wǎng)絡(luò)時間；RTP時戳，占32位，和NTP時戳相一致的時間，用于媒體內(nèi)部和媒體間的同步；發(fā)送者的報文計數(shù)，占32位，指出該發(fā)送者從開始傳送RTP報文到該SR報文產(chǎn)生的時間間隔內(nèi)共發(fā)送的RTP報文總數(shù)；發(fā)送者的有效載荷計數(shù)，占32位，指出該發(fā)送者從開始傳送RTP報文到該SR報文產(chǎn)生的時間間隔內(nèi)共發(fā)送的有效載荷總數(shù)，以字節(jié)為單位，不包括報頭和填充。

(3)接收報告塊部分。接收報告塊的個數(shù)取決于本機自上次發(fā)送接收報告到現(xiàn)在的時間間隔內(nèi)收到的所有RTP報文中所含的同步源個數(shù)。本機將通過接收報告塊向這些同步源反饋本機的接收情況。一個接收報告塊對應于一個同步源。

接收報告塊包括以下各部分：同步源標識符(SSRC-n)，占32位，標識在最近傳輸間隔內(nèi)曾向本機發(fā)送過RTP報文的同步源，本機通過該接收報告塊向這個SSRC-n反饋接收信息；丟失率，占8位，在最近傳輸間隔內(nèi)，標識從SSRC-n接收的RTP報文的丟失率；報文丟失累計，占24位，標識從開始接收到現(xiàn)在為止，從SSRC-n接收的RTP報文的累計丟失數(shù)；接收到的最高序列號，占32位，標識從SSRC-n接收到的RTP報文的最高序列號；平均延時抖動，占32位，每當從同步源SSRC-n收到第i個RTP報文時，則按相應公式計算平均延遲抖動；最近發(fā)送SR的時間(LSR)，占32位，標識從SSRC-n接收到的最近一個SR報文中所記錄的發(fā)送該SR的時間；LSR的時間差(DLSR)，占32位，標識從SSRC-n接收到的最近一個SR的時刻到發(fā)送該接收報告之間的時間差。

RR報文由在會話中那些不是當前發(fā)送者的參加會議者產(chǎn)生，其內(nèi)容與SR報文中包含的接收報告塊內(nèi)容相同。用分組類型201來標識RR報文。信源描述報文用來描述與同步源/提供源有關(guān)的信息。結(jié)束報文用來標識參與的結(jié)束，它應該是信息源發(fā)出的最后一種報文。

RTCP協(xié)議可實現(xiàn)以下功能：

①Q(mào)oS監(jiān)控和擁塞控制。RTCP控制報文是多點傳送的，其中包括監(jiān)控QoS所必需的信息。因此，所有的對話成員都能夠大致了解其他參與者的進展情況。

②媒體同步。RTCP控制報文中包含了序列號和時間戳，這兩個值允許不同媒體同步。

③標識。信源描述報文為每個對話成員提供了一個全局唯一的標識符。

④對話大小的估計和規(guī)劃。由于每個對話成員定期發(fā)送RTCP控制報文，當對話包含數(shù)百個與會者時，必須限制控制流量只占對話帶寬的一小部分(通常為5％)。8.2.2實時流協(xié)議

實時流協(xié)議(RealTimeStreamingProtocol，RTSP)是由RealNetworks和Netscape以及哥倫比亞大學共同提出的。它是一個應用層協(xié)議，定義了媒體服務(wù)器和多用戶之間如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。

它是一個請求/響應的協(xié)議，當客戶端發(fā)出請求時，媒體服務(wù)器作出響應；同樣，當媒體服務(wù)器發(fā)出請求時，客戶端也能作出響應。利用RTSP可以在服務(wù)器和客戶端之間建立并控制連續(xù)的音頻媒體流和視頻媒體流，進行服務(wù)器和客戶端之間的“網(wǎng)絡(luò)遠程控制”，提供遠程控制功能(如暫停、快進、倒帶和直接選擇位置等功能)。

RTSP協(xié)議建立并控制一個或多個時間同步的連續(xù)媒體流，例如音頻或視頻。但是其本身并不傳送連續(xù)媒體流，而是提供一種方法來選擇傳送通道，例如UDP、TCP，或提供一種方法來選擇基于RTP的傳送機制，可見它扮演的是“網(wǎng)絡(luò)遠程控制”的角色。RTSP控制的流可以通過一個獨立的協(xié)議來傳送，該協(xié)議與RTSP的控制通道無關(guān)。例如，RTSP的控制通道可基于TCP連接，而它控制的流則基于UDP連接。那么，需要在媒體服務(wù)器保持所謂的“會話狀態(tài)”，以便將RTSP請求與對應的流聯(lián)系起來。在RTSP的媒體服務(wù)器和客戶端中，主要存在四種狀態(tài)：Init、Ready、Playing和Recording。狀態(tài)之間的轉(zhuǎn)變可以通過某種方法傳遞消息來觸發(fā)。有如下幾種重要的方法：

SETUP，引發(fā)服務(wù)器給一個流分配資源，并啟動一個RTSP會話；

PLAY、RECORD，啟動該流的數(shù)據(jù)傳輸；

PAUSE，暫時中斷流，但不釋放服務(wù)器資源；

TEARDOWN，服務(wù)器釋放與該流有關(guān)的資源，RTSP會話結(jié)束。

當這些方法攜帶的消息被傳遞給服務(wù)器或客戶端時，服務(wù)器或客戶端的狀態(tài)就會相應地發(fā)生改變。8.2.3資源預留協(xié)議

RSVP(ResourceReserveProtocol)是用于Internet上資源預留的協(xié)議，位于IP層之上，屬于OSI參考模型中的傳輸層，但它不是網(wǎng)絡(luò)傳送協(xié)議，因為它不傳送應用數(shù)據(jù)，它是一種網(wǎng)絡(luò)控制協(xié)議，用于建立網(wǎng)絡(luò)資源預留。它允許客戶端向網(wǎng)絡(luò)提出一個特定的請求，為其數(shù)據(jù)流提供所需的端到端的服務(wù)質(zhì)量。使用RSVP協(xié)議，能在數(shù)據(jù)流經(jīng)路徑上的所有節(jié)點處保留必要的資源，以保證實際傳輸時所需要的帶寬。在RFC2205中給出了RSVP協(xié)議的定義，最近的更新在RFC2750中給出。

1.RSVP協(xié)議的基本概念

(1)流(Flow)。流是以單播或多播方式在源宿間傳輸?shù)臄?shù)據(jù)碼流，它為不同服務(wù)提供類似連接的邏輯通道。流在RSVP協(xié)議中占有重要的位置，協(xié)議中所有的操作幾乎都是圍繞流而進行的。

(2)路徑消息(PathMessage)。路徑消息由源端定時發(fā)出，并沿流的方向傳輸，其主要目的是保證沿正確的路徑預留資源。RSVP規(guī)定，發(fā)送者在發(fā)送數(shù)據(jù)前首先要發(fā)送Path報文與接收者建立一個傳輸路徑，并協(xié)商QoS級。一個路徑消息包含如下信息：

①Phop：后續(xù)節(jié)點地址，指出轉(zhuǎn)發(fā)該Path消息的下一個支持RSVP的節(jié)點(路由器或接收端)的IP地址。該路徑上每個支持RSVP的路由器都要更新這個地址。

②SenderTemplate：發(fā)送者模板，包括發(fā)送者的IP地址和可選擇的發(fā)送者端口。

③SenderTspec：發(fā)送者傳輸說明，其傳輸說明是用一種漏桶流量模型描述的，其中有數(shù)據(jù)流峰值速率p、桶深b、標記桶速率r、最小管理單元m以及最大數(shù)據(jù)報長度M等參數(shù)。④Adspec：通告說明，可選項，含有OPWA(OnePassWithAdvertising)信息，使得接收者能計算出應保留的資源級，以獲得指定的端到端QoS。該路徑上每個支持RSVP的路由器都要更新這些信息。

(3)預留消息(ReservationMessage)。預留消息由接收端定時發(fā)出，并沿路徑消息建立的路由反向傳輸，其主要目的是為保障通信服務(wù)質(zhì)量而請求各級節(jié)點預留資源。接收者接收到路徑消息后，從SenderTspec和Adspec字段中提取傳輸特性參數(shù)和QoS參數(shù)，利用這些參數(shù)建立起接收者保留說明Rspec，利用Rspec創(chuàng)建預留消息。一個預留消息包含如下信息：

①保留模式指示。

②過濾器說明(Filterspec)：用來標識期望接收的發(fā)送者集合，采用與一個Path報文中的SenderTemplate完全相同的格式。

③數(shù)據(jù)流說明(Flowspec)：用來說明一個期望的服務(wù)質(zhì)量(QoS)，由保留說明Rspec和流量說明TRspec組合而成。通常，將TRspec設(shè)置成與SenderTspec相等。④保留確認對象(ResvConf)：是可選項，含有接收者的IP地址，用于指示接收該保留請求的節(jié)點。ResvConf報文在分布樹上向上傳播，最終達到該消息接收者，表明端到端保留成功。

2.RSVP協(xié)議的工作過程

RSVP協(xié)議的工作過程如圖8-5所示。

發(fā)送端主機發(fā)出Path消息，路由器根據(jù)路由選擇協(xié)議選擇路由轉(zhuǎn)發(fā)此消息。沿途每一個接收到該Path消息的節(jié)點，都會建立一個“Path狀態(tài)”，保存在每一個節(jié)點中。在“Path狀態(tài)”信息中至少包括前一跳節(jié)點的單播IP地址，Resv消息就是根據(jù)這個前一跳地址來確定反向路由方向的。圖8-5RSVP協(xié)議的工作過程接收端主機負責向發(fā)送端發(fā)出Resv消息，Resv消息依據(jù)先前記錄在網(wǎng)絡(luò)節(jié)點中的“Path狀態(tài)”信息，沿著與Path消息相反的路徑傳向發(fā)送端。在沿途的每一個節(jié)點處依照Resv消息所包含的資源預留的描述Flowspec和Filterspec，生成“Resv狀態(tài)”，各個節(jié)點根據(jù)這個“Resv狀態(tài)”信息，預留出所要求的資源。

發(fā)送端的數(shù)據(jù)沿著已經(jīng)建立資源預留的路徑傳向接收端。

3.RSVP協(xié)議基本框架

RSVP協(xié)議包含決策控制(PolicyControl)、接納控制(AdmissionControl)、分類控制(ClassifiedControl)、分組調(diào)度(Scheduling)和RSVP處理模塊等幾個主要部分，如圖8-6所示。決策控制主要用來判斷用戶是否擁有資源預留的許可權(quán)。接納控制用來判斷可用資源是否滿足應用的需求，主要用來減少網(wǎng)絡(luò)負荷。分類控制用來決定數(shù)據(jù)分組的通信服務(wù)等級，主要用來實現(xiàn)由Filterspec指定的分組過濾方式。分組調(diào)度則根據(jù)服務(wù)等級進行優(yōu)先級排序，主要用來實現(xiàn)由Flowspec指定的資源配置。在預留建立期間，RSVP處理模塊將接收端發(fā)來的一個RSVPQoS請求——Resv消息傳遞給接納控制模塊和決策控制模塊。如果其中任何一個控制模塊測試失敗，預留請求都被拒絕，此時RSVP處理模塊將一個錯誤的消息返回給接收端。只有兩個控制模塊都測試成功，節(jié)點才會進一步處理，分別依據(jù)Rsvp消息中的Flowspec和Filterspec設(shè)置分類控制模塊和分組調(diào)度模塊中的參數(shù)，以滿足所需的QoS請求。圖8-6RSVP協(xié)議框架預留資源后便可進行數(shù)據(jù)傳輸。當數(shù)據(jù)傳輸?shù)皆摴?jié)點后，分類控制模塊確定每一個數(shù)據(jù)分組的QoS等級，將具有不同QoS等級的數(shù)據(jù)分組進行分類，然后把它們送到分組調(diào)度模塊中，按照不同的QoS等級進行排隊，再通過接口發(fā)送出去。

8.3.1流媒體的關(guān)鍵技術(shù)

1.視頻、音頻壓縮/解壓縮編碼

從流媒體技術(shù)的角度來講，希望壓縮編碼具有伸縮性或?qū)哟涡?，即信息源?jīng)一次壓縮編碼后，編碼數(shù)據(jù)在傳輸時應該能方便地根據(jù)網(wǎng)絡(luò)帶寬的變化進行一定的調(diào)整處理，使客戶端獲取最好質(zhì)量的同時能維持最好的連續(xù)性。目前，已有多種形式的編碼方式，如H.263、MPEG-1、MPEG-2、MPEG-4，或多或少都具有一定的可伸縮特性。8.3流媒體的關(guān)鍵技術(shù)及開發(fā)平臺結(jié)合多種視/音頻編碼技術(shù)來適應網(wǎng)絡(luò)上的QoS波動是今后可伸縮性視頻編碼的發(fā)展方向。比如，可伸縮性視頻編碼可以適應網(wǎng)絡(luò)帶寬的變化，錯誤彈性編碼(ErrorResilientEncoding，ERE)可以適應一定程度的丟包，DCVC(DelayCognizantVideoCoding)可以適應網(wǎng)絡(luò)時延變化狀況。這些技術(shù)的綜合運用可以更好地提供應對網(wǎng)絡(luò)QoS波動的解決方案。

2.緩存技術(shù)

與下載方式相比，盡管流式傳輸對于系統(tǒng)存儲容量的要求大大降低了，但要保持連續(xù)的視頻播放仍需要較大的緩存，這是因為Internet是分組傳輸?shù)模仨氂镁彺鏅C制來克服延時和延時抖動的影響，使媒體數(shù)據(jù)能連續(xù)播放，不會因網(wǎng)絡(luò)暫時的擁塞而出現(xiàn)停頓。高速緩存使用環(huán)形鏈表結(jié)構(gòu)來存儲數(shù)據(jù)，通過丟棄已經(jīng)播放的內(nèi)容，重新利用緩存空間來存儲后續(xù)的媒體內(nèi)容。如果源端和終端之間用無連接方式(如UDP/IP)通信，還必須保證數(shù)據(jù)包順序的正確。

在網(wǎng)絡(luò)質(zhì)量有一定保證的前提下，緩存機制是實現(xiàn)流媒體技術(shù)的重要技術(shù)。

3.應用層QoS控制技術(shù)

由于目前的Internet只提供盡力的服務(wù)，因此需要通過應用層的機制來實現(xiàn)QoS的控制。QoS控制技術(shù)集中在適應網(wǎng)絡(luò)帶寬變化和處理分組丟失的技術(shù)上，可以分為擁塞控制技術(shù)和差錯控制技術(shù)。擁塞控制的目的是應對和避免網(wǎng)絡(luò)阻塞，降低延時和丟包率。常用的擁塞控制機制有速率控制和速率整形。對于視頻流，擁塞控制的主要方法是速率控制。速率控制機制試圖使視頻連接的需求與整個鏈路的可用帶寬相匹配，同時使網(wǎng)絡(luò)擁塞和丟包率達到最小。速率控制機制主要包括基于源端的控制機制、基于終端的控制機制以及混合速率控制。基于源端的控制機制是一種反饋機制，它根據(jù)接收端發(fā)送的反饋信息來調(diào)整編碼器的某些參數(shù)，從而控制流速率。這種方法在互聯(lián)網(wǎng)中被率先采用，但是在異構(gòu)網(wǎng)絡(luò)中的運行情況并不是很好?；诮K端的控制機制則主要根據(jù)所接收的視頻流的狀況向上層反映相應的統(tǒng)計信息，實時調(diào)整緩沖及播放內(nèi)容，并力圖使節(jié)奏均勻，這種機制使用較少。混合速率控制的方法兼有前兩者的特點，目前已得到廣泛采用。擁塞控制能降低網(wǎng)絡(luò)擁塞、延時和丟包率，但是網(wǎng)絡(luò)中不可避免地會存在數(shù)據(jù)包丟失，而且到達延時過大的分組也會被丟棄，從而降低了傳輸質(zhì)量。要改善傳輸質(zhì)量就需要一定的差錯控制機制。差錯控制機制包括以下四個方面：

(1)前向糾錯(FEC)。FEC在傳輸?shù)拇a流中加入用于糾錯的冗余信息，在遇到包丟失的情況時，利用冗余信息恢復丟失的信息。其不足之處是增加了編碼延時和附加開銷。

(2)延時約束的重傳。由于終端緩存有限，而且通常流的播放有時間限制，因此重傳的時間必須與緩存及流播放時間匹配。時間過長的重傳是沒有意義的。

(3)錯誤彈性編碼(ERE)。在編碼中通過適當?shù)目刂?，使得發(fā)生數(shù)據(jù)丟失情況后能夠最大限度地減少對質(zhì)量的影響。在Internet環(huán)境下，典型的方法是使用多描述編碼(MDC)。MDC把原始數(shù)據(jù)序列壓縮成多個流，每個流對應一種描述，可以提供不同的質(zhì)量，多個描述結(jié)合起來提供更好的質(zhì)量。該方法的優(yōu)點是實現(xiàn)了對數(shù)據(jù)丟失的魯棒性。其缺點是，與單描述編碼(SDC)相比，MDC在壓縮效率上受到影響。而且由于在多描述之間必須加入一定的相關(guān)性信息，因而進一步降低了壓縮效率。

(4)差錯隱蔽。差錯隱蔽是指接收端通過采取一些措施，部分恢復由于傳輸錯誤而被破壞的數(shù)據(jù)。主要有時間隱蔽方法、空間隱蔽方法和運動補償隱蔽方法等。時間隱蔽將丟失或者被破壞的數(shù)據(jù)塊用前一幀對應位置上的數(shù)據(jù)塊來代替，該方法對于相對靜止部分的差錯隱蔽效果較好，而對快速運動的物體和場景切換的情況則不好?？臻g隱蔽利用周圍無差錯的數(shù)據(jù)塊進行插值來恢復丟失或被破壞的數(shù)據(jù)塊，雖然很難恢復出圖像的細節(jié)，但底色和粗略輪廓的恢復會在很大程度上降低差錯的能見度。運動補償隱蔽方法是在進行幀間編碼的宏塊產(chǎn)生錯誤或丟失時，根據(jù)它的運動補償量找到該宏塊的參考數(shù)據(jù)塊，用參考數(shù)據(jù)塊來代替該宏塊。

4.連續(xù)媒體分發(fā)服務(wù)

連續(xù)媒體分發(fā)服務(wù)的目的是在Internet盡力服務(wù)的基礎(chǔ)上提供QoS和高效的多媒體信息傳輸，包括網(wǎng)絡(luò)過濾、應用層多播和內(nèi)容復制等。

(1)網(wǎng)絡(luò)過濾。網(wǎng)絡(luò)過濾是擁塞控制的一種，它不僅可以提高傳輸質(zhì)量，還可以提高帶寬利用率。網(wǎng)絡(luò)過濾是在流媒體服務(wù)器和客戶端之間的傳輸路徑上通過虛擬信道連入過濾器的，該過濾器根據(jù)網(wǎng)絡(luò)的擁塞狀態(tài)實現(xiàn)速率的整形。網(wǎng)絡(luò)過濾通常采用的是丟幀過濾器，基本方法是根據(jù)網(wǎng)絡(luò)丟包率向過濾器發(fā)送請求來增減幀速率，以調(diào)節(jié)媒體流所需的帶寬。

(2)應用層多播。應用層多播打破了IP多播的一些障礙，其目的在于構(gòu)建網(wǎng)絡(luò)上的多播服務(wù)，可以以更靈活的方式實現(xiàn)多播控制。

(3)內(nèi)容復制。內(nèi)容或媒體復制是提高媒體傳輸系統(tǒng)可伸縮性的一項重要技術(shù)。它主要有兩種形式：鏡像和緩存。鏡像是把原始媒體內(nèi)容復制到分布在網(wǎng)絡(luò)上的備份服務(wù)器中，用戶可以從最近的備份服務(wù)器上獲得媒體數(shù)據(jù)。緩存則是從原服務(wù)器中獲得媒體文件，然后傳輸給客戶端，同時在本地作備份。如果緩存中已經(jīng)存在客戶端需要的數(shù)據(jù)，緩存就會把本地復制的媒體內(nèi)容傳給用戶，而不再向服務(wù)器請求媒體數(shù)據(jù)。內(nèi)容復制的優(yōu)點在于降低網(wǎng)絡(luò)連接帶寬的使用，減輕流服務(wù)器負荷，縮短客戶端延時，提高有效性。

5.流媒體服務(wù)器

流媒體服務(wù)器在流媒體服務(wù)中起著非常重要的作用。流媒體服務(wù)器在響應客戶的請求后，從存儲系統(tǒng)讀入一部分數(shù)據(jù)到特定緩存中，再把緩存的內(nèi)容通過網(wǎng)絡(luò)接口發(fā)送給相應的客戶，保證視頻流的連續(xù)輸出。目前存在以下三種類型的流媒體服務(wù)器結(jié)構(gòu)：

(1)通用主機方法。通用主機的方法采用計算機主機作為流媒體服務(wù)器，它的主要功能是存儲、選擇、傳送數(shù)據(jù)。缺點是系統(tǒng)成本高，不能完全發(fā)揮主機的功能。

(2)緊耦合多處理機。把由一些可以大量完成某指令或者專門功能的硬件單元組合成的專用系統(tǒng)級聯(lián)起來，就構(gòu)成了緊耦合多處理機實現(xiàn)的視頻服務(wù)器。這種服務(wù)器費用低、性能高、功能強，但是可擴展性較差。

(3)調(diào)諧流媒體服務(wù)器。它通過在主板中插入更多的服務(wù)通路，可以方便地進行擴展。其缺點是成本較高。

對于流媒體服務(wù)，如何更有效地支持交互控制功能，如何設(shè)計磁盤陣列上多媒體對象高效可靠的存儲和檢索，如何設(shè)計更好的可伸縮性流媒體服務(wù)器，如何設(shè)計兼有奇偶和鏡像特性的容錯存儲系統(tǒng)是目前研究的重點。

流媒體具有很好的發(fā)展前景，一些相關(guān)技術(shù)，包括圖像編碼技術(shù)、解決網(wǎng)絡(luò)傳輸服務(wù)質(zhì)量問題等，已經(jīng)有了一定的進展，業(yè)務(wù)的應用范圍也在不斷擴大。但流媒體服務(wù)器的處理能力以及并發(fā)流數(shù)量等問題還有待解決。8.3.2流媒體開發(fā)平臺簡介

目前市場上主流的流媒體技術(shù)有三種：RealNetworks公司的RealMedia、Microsoft公司的WindowsMedia和Apple公司的QuickTime。這三家都有各自的流媒體格式、編/解碼算法和傳輸控制協(xié)議等。

1.RealMedia流媒體

RealNetworks公司于20世紀90年代中期最早推出了流媒體技術(shù)——RealMedia，在Internet上被公認為流媒體傳輸技術(shù)的先驅(qū)者。隨著Internet的飛速發(fā)展，RealNetworks公司擁有目前最多的用戶，其用戶數(shù)量已經(jīng)超過20億。由RealMedia技術(shù)構(gòu)成的系統(tǒng)RealSystem的結(jié)構(gòu)如圖8-7所示。該系統(tǒng)由三部分組成：媒體內(nèi)容制作工具——RealProducer、媒體服務(wù)器——RealServer和客戶端播放器——RealPlayer。

RealProducer實際上是一個編碼器，它的作用是將其他格式的音/視頻等多媒體文件或?qū)崟r的現(xiàn)場信號轉(zhuǎn)換成RealSystem使用的Real格式文件(*.rm等)并傳送給RealServer，RealServer將RealProducer制作好的流媒體內(nèi)容通過IP網(wǎng)傳送給用戶，用戶端則通過安裝好的RealPlayer播放器提出請求，并對傳送來的媒體節(jié)目進行播放。Real格式文件有多種，表8-1示出其中的幾種。圖8-7RealSystem系統(tǒng)的結(jié)構(gòu)表8-1Real格式文件類型

RealSystem的編/解碼采用自己開發(fā)的編碼器，其中包含很多先進的設(shè)計，如SVT(ScalableVideoTechnology，可擴展視頻技術(shù))、Two-passEncoding(兩次編碼技術(shù))。SVT技術(shù)是RealSystem主要的視頻編/解碼技術(shù)，采用了基于小波變換的Real專用算法。當用戶的連接速率低于編碼的速率時，服務(wù)器端通過丟棄不重要的增強信息來自動調(diào)整媒體的播放質(zhì)量。Two-passEncoding技術(shù)類似于可變比特率編碼(VBR)，它可以通過預先掃描整個媒體內(nèi)容，再根據(jù)掃描結(jié)果選擇最優(yōu)化的壓縮編碼來提高編碼質(zhì)量。RealSystem的音頻部分采用了RealAudio編碼技術(shù)，在低帶寬環(huán)境中傳輸時具有非常突出的優(yōu)良性能。為了提高流傳輸?shù)馁|(zhì)量，RealNetworks采用了SureStream自適應流技術(shù)，該技術(shù)是RealNetworks公司最具有代表性的技術(shù)。首先，確立一個編碼框架，編碼器可以對同一多媒體數(shù)據(jù)按多種壓縮比率進行編碼，對應生成多種傳輸速率的數(shù)據(jù)流以適應不同網(wǎng)絡(luò)帶寬的需求，這多個數(shù)據(jù)流集成在一個多媒體節(jié)目中。當播放器連接到一個能提供這種節(jié)目的媒體服務(wù)器時，服務(wù)器根據(jù)該播放器的連接速度，提供與之匹配的數(shù)據(jù)流。當播放器的網(wǎng)絡(luò)帶寬下降導致丟包時，服務(wù)器就會轉(zhuǎn)向發(fā)送更低速率的數(shù)據(jù)流；而當播放器的連接速度上升后，服務(wù)器又會自動轉(zhuǎn)向提供更高速率的數(shù)據(jù)流。這中間的轉(zhuǎn)變過程是瞬時完成的，用戶不會感覺到中斷或有間隔。

RealMedia發(fā)展到現(xiàn)在，各個產(chǎn)品的版本不斷升級，產(chǎn)品的功能也在不斷擴展。例如，播放器已升級為RealOneplus，并且播放器已不再是單純的播放器，而是將播放器、曲庫管理、瀏覽器功能集于一身；RealProducer已升級到RealProducer10plus；服務(wù)器則升級到功能更強大的HelixServer。因此RealMedia能夠以更低的成本向更多的用戶傳送高質(zhì)量的流媒體數(shù)據(jù)。

2. WindowsMedia流媒體

Microsoft公司是較晚涉足流媒體技術(shù)這個市場的，但它利用其Windows操作系統(tǒng)的便利性，將它的流媒體產(chǎn)品——WindowsMedia捆綁在Windows操作系統(tǒng)這個平臺上，免費提供流媒體服務(wù)以及相應的播放器，從而很快占據(jù)了相當?shù)氖袌龇蓊~。

WindowsMedia的系統(tǒng)結(jié)構(gòu)類似于RealSystem，也是由三部分組成，包括WindowsMediaEncoder、WindowsMediaServer和WindowsMediaPlayer。Encoder用于將源音/視頻數(shù)據(jù)轉(zhuǎn)換成WindowsMedia使用的格式文件(*.asf、*.wma、*.wmv等)并傳送給MediaServer；MediaServer用于網(wǎng)絡(luò)流媒體發(fā)布；MediaPlayer位于客戶端,用于音/視頻數(shù)據(jù)的解碼。

WindowsMedia的核心是高級流格式(AdvancedStreamingFormat,ASF)，它既是一個獨立于編碼方式的、支持在IP網(wǎng)上實時傳播多媒體數(shù)據(jù)的公開技術(shù)標準，也是一種數(shù)據(jù)格式，即微軟定義為同步媒體的統(tǒng)一容器文件格式。ASF可以使用任何一種底層傳輸協(xié)議，支持任意的壓縮/解壓縮編碼方式，其在網(wǎng)絡(luò)上傳輸?shù)膬?nèi)容被稱為ASF流。音/視頻、控制命令腳本等多媒體數(shù)據(jù)通過ASF技術(shù)編碼成ASF格式，經(jīng)網(wǎng)絡(luò)傳輸，實現(xiàn)流式多媒體內(nèi)容的發(fā)布。圖8-8說明了通過WindowsMedia系統(tǒng)向用戶提供流媒體內(nèi)容的過程。圖8-8WindowsMedia系統(tǒng)結(jié)構(gòu)圖中：

①WindowsMedia工具將其他格式的文件轉(zhuǎn)換為.asf格式文件存入ASF文件倉庫；

②Encoder直接創(chuàng)建.asf文件放入ASF文件倉庫(數(shù)據(jù)庫)中存儲起來；

③Encoder將實時媒體內(nèi)容(例如一個攝像頭實時捕捉到的信息)通過一個端口傳送給MediaServer；

④MediaServer可以使用ASF文件倉庫中的非實時文件；

⑤MediaServer將其發(fā)布的媒體內(nèi)容單播到客戶端；⑥MediaServer將其發(fā)布的媒體內(nèi)容組播到客戶端。

.asf文件內(nèi)容包括音/視頻數(shù)據(jù)，后來微軟公司將僅限于音頻的.asf文件改為.wma擴展名，將僅限于視頻的.asf文件改為.wmv擴展名。

WindowsMedia采用了微軟公司特有的智能流(IntelligentStream)媒體技術(shù)，它與RealNetworks采用的SureStream自適應流技術(shù)一樣，也是一種高級流技術(shù)，同樣使服務(wù)器與播放器之間可以根據(jù)網(wǎng)絡(luò)帶寬進行播放，并可進行質(zhì)量的動態(tài)溝通和調(diào)整，其原理與SureStream自適應流技術(shù)相同。

3.QuickTime流媒體

Apple公司的QuickTime是數(shù)字媒體領(lǐng)域事實上的工業(yè)標準，它實際上是一個媒體集成技術(shù)，包含了各種流式和非流式的媒體技術(shù)，是一個開放式的結(jié)構(gòu)體系。它支持真正的流媒體是從1999年發(fā)布的QuickTime4.0版本開始的。QuickTime同樣依托于其操作系統(tǒng)MacOS的便利，擁有不少的用戶。

QuickTime系統(tǒng)將QuickTimeBroadcaster(編碼器)、QuickTimeStreamingServer(流媒體服務(wù)器)和QuickTimePlayer(播放器)結(jié)合起來提供了基于MPEG-4的Internet廣播系統(tǒng)。

QuickTime的優(yōu)點在于其極大的包容性和靈活的交互性，基于QuickTime平臺可以使用多種媒體技術(shù)共同制作媒體內(nèi)容，其中包括各種互動的界面和動畫。

向大規(guī)模的用戶群提供高質(zhì)量、可交互的流媒體服務(wù)一直都被認為是當今Internet的應用難點之一。傳統(tǒng)的Client/Serve架構(gòu)的流媒體服務(wù)遠遠不能滿足大量并發(fā)用戶對高質(zhì)量流媒體服務(wù)的需求，而P2P流媒體卻有效解決了傳統(tǒng)網(wǎng)絡(luò)電視對用戶帶寬、服務(wù)器負載的高要求，也使得網(wǎng)絡(luò)視頻給用戶帶來了全新視覺感受。8.4P2P流媒體

P2P流媒體通過在流媒體服務(wù)系統(tǒng)中引入P2P技術(shù)，在不增加成本的同時有效提升了服務(wù)能力，并有效避免了P2P應用的諸多弊端，是當前網(wǎng)絡(luò)條件下一種較理想的多媒體分發(fā)技術(shù)?；赑2P的流媒體技術(shù)有兩方面的優(yōu)點：不需要互聯(lián)網(wǎng)路由器和網(wǎng)絡(luò)基礎(chǔ)設(shè)施的支持，因此性價比高且易于部署；流媒體用戶不只可下載媒體流，而且還可把媒體流上傳給其他用戶，因此，這種方法可以擴大用戶組的規(guī)模，且由更多的需求帶來更多的資源。8.4.1P2P與傳統(tǒng)流媒體技術(shù)的比較

傳統(tǒng)流媒體服務(wù)都是C/S模式，即用戶從流媒體服務(wù)器點擊觀看節(jié)目，然后流媒體服務(wù)器以單播方式把媒體流推送給用戶。這種C/S架構(gòu)的流媒體服務(wù)遠遠不能滿足大量并發(fā)用戶對高質(zhì)量流媒體服務(wù)的需求。20世紀80年代，以微軟的TigerShark流媒體集群文件系統(tǒng)和美國南加州大學的Yima集群視頻服務(wù)系統(tǒng)為代表的技術(shù)希望通過集群技術(shù)來提高流媒體服務(wù)系統(tǒng)中服務(wù)器端的服務(wù)能力。然而，流媒體服務(wù)中高帶寬、高實時性的需求，使得這類系統(tǒng)在服務(wù)能力上仍然只能停留在同時服務(wù)并發(fā)上千人的規(guī)模上。與此同時，另外兩種思想在學術(shù)研究界得到了廣泛的認同。其一就是通過IP層的多播技術(shù)和客戶端流合并技術(shù)來提高系統(tǒng)的并發(fā)服務(wù)量。然而，由于IP層多播在可靠性、安全性等方面存在缺陷，現(xiàn)有的Internet缺乏對IP層多播技術(shù)的支持，因此這種技術(shù)在產(chǎn)業(yè)界沒有得到有效的實現(xiàn)。其二是通過高性能的中心服務(wù)器和靠近用戶的邊緣代理服務(wù)器來組建多媒體CDN(ContentDistributionNetwork)的方式為大規(guī)模的用戶提供高質(zhì)量的流媒體服務(wù)。

CDN仍然是一種基于C/S結(jié)構(gòu)的分布式媒體服務(wù)技術(shù)平臺，也是目前采用比較普遍、技術(shù)成熱度比較高的一種平臺，它在現(xiàn)有的Internet中增加一層新的網(wǎng)絡(luò)架構(gòu)，并采用智能化策略將用戶需要訪問的內(nèi)容分發(fā)到距離用戶最近、服務(wù)質(zhì)量最好的節(jié)點，同時通過后臺服務(wù)自動地將用戶調(diào)度到相應的節(jié)點，為用戶提供最好的服務(wù)。這種方案有效地緩解了Internet網(wǎng)絡(luò)的擁塞狀況，提高了用戶訪問網(wǎng)站的響應速度，比較好地解決了由于網(wǎng)絡(luò)帶寬小、用戶訪問量大、網(wǎng)點分布不均等原因造成的用戶訪問響應速度慢的問題。

但是，CDN技術(shù)雖然可以在一定程度上加速流媒體，實現(xiàn)下載、直播和點播，但其核心仍然是基于集中服務(wù)器的架構(gòu)，而且跟地域化管制緊密相連，因此很難降低其擴展的成本，而且CDN技術(shù)在高峰時期對突發(fā)流量的適應性、容錯性等方面仍然存在一定缺陷。流媒體業(yè)務(wù)在到達一定規(guī)模后，就需要大規(guī)模擴充帶寬、服務(wù)器和內(nèi)容分發(fā)系統(tǒng)以滿足需求，這些舉措無疑都會大大增加開銷。同時這種用戶多了就擴容、擴容完了再大力發(fā)展用戶的做法只能是一種權(quán)宜之計，它無法從根木上解決流媒體業(yè)務(wù)發(fā)展所遭遇到的瓶頸問題。

C/S模式已經(jīng)成為制約流媒體技術(shù)發(fā)展的“瓶頸”，將體系結(jié)構(gòu)向?qū)Φ冗B接(P2P)模式演化不失為一個有效的解決方法。

P2P技術(shù)也稱為對等網(wǎng)絡(luò)(Peer-to-Peer)技術(shù)，簡單地說，就是一種用戶不經(jīng)過中繼設(shè)備直接交換數(shù)據(jù)或服務(wù)的技術(shù)。它將目前互聯(lián)網(wǎng)的“內(nèi)容位于中心”模式改變?yōu)椤皟?nèi)容位于邊緣”模式，將權(quán)利交還給用戶。在這種架構(gòu)中，每個節(jié)點的地位都相同，具備客戶端和服務(wù)器的雙重特性，可以同時作為服務(wù)使用者和服務(wù)提供者。采用P2P技術(shù)后，每個流媒體點播用戶都是一個節(jié)點，用戶可以根據(jù)他們的網(wǎng)絡(luò)狀態(tài)和設(shè)備能力與一個或幾個用戶建立連接來分享數(shù)據(jù)。有的流媒體點播用戶播放的流媒體內(nèi)容完全來自于其他流媒體點播用戶的設(shè)備之中，而跟流媒體服務(wù)器毫無關(guān)聯(lián)；還有的流媒體點播用戶播放的流媒體內(nèi)容既來自于其他流媒體點播用戶的設(shè)備又來自于流媒體服務(wù)器。

P2P和流媒體技術(shù)各自有什么特點呢？下面我們對傳統(tǒng)流媒體技術(shù)和P2P技術(shù)作一個簡單的優(yōu)劣勢分析，如表8-2所示。表8-2P2P和傳統(tǒng)流媒體技術(shù)的比較通過分析我們可以看到，在可擴展性、內(nèi)容版權(quán)、用戶管理有效性、QoS服務(wù)、流量有序性方面，傳統(tǒng)流媒體技術(shù)和P2P技術(shù)各有所長，基本上完全互補。如果能將兩種技術(shù)有效地結(jié)合起來，將是一種更加完美的組合。P2P流媒體這項嶄新的技術(shù)由此應運而生。8.4.2P2P流媒體技術(shù)

1.P2P流媒體技術(shù)的優(yōu)勢

P2P流媒體與傳統(tǒng)流媒體技術(shù)相比較而言，具有下列優(yōu)勢：

(1)流服務(wù)能力的提高。P2P流媒體傳輸?shù)膬?nèi)容與原CDN的內(nèi)容有所不同。P2P流媒體在核心節(jié)點根據(jù)P2P協(xié)議對內(nèi)容(包括文件和流)作切片處理，P2P用戶將根據(jù)這些規(guī)則來完成P2P共享。

P2P在邊緣層的引入大大降低了邊緣服務(wù)器的壓力，提高了文件傳輸和流媒體傳輸?shù)男?。P2P流媒體技術(shù)充分利用了用戶的閑置上行帶寬，這樣運營商可以通過更少的邊緣服務(wù)器，提供更多的業(yè)務(wù)量為更多的用戶服務(wù)，即以較低成本代價應對迅猛增長的客戶規(guī)模帶來的挑戰(zhàn)。試驗證明，P2P流媒體在千人規(guī)模的情況下播放500k碼流左右的節(jié)目，服務(wù)端CPU消耗小，帶寬消耗小，而且用戶服務(wù)質(zhì)量高。

(2)可管理的P2P流媒體網(wǎng)絡(luò)。為了避免骨干網(wǎng)上的流量對沖，通過集中的分布式架構(gòu)將P2P的流量嚴格限制在同一邊緣節(jié)點的區(qū)域內(nèi)，這樣就繼承了P2P和CDN的優(yōu)點，同時又摒棄了雙方的缺點，避免電信骨干網(wǎng)上的流量無序性和風暴，增強了網(wǎng)絡(luò)的可管理性和服務(wù)的高可靠性。通過客戶端，可以實現(xiàn)對用戶的監(jiān)控和流量的監(jiān)管。

(3)客戶體驗的改善。一方面，P2P和流媒體結(jié)合的方式使得有限的服務(wù)能力可以為更多的用戶提供流媒體服務(wù)。另一方面，P2P技術(shù)的應用也能夠更有效地防止網(wǎng)絡(luò)的抖動對服務(wù)質(zhì)量的影響。

(4)增值業(yè)務(wù)的擴展。由于需要建立緩沖來進行P2P交換，會帶來大約1分鐘左右的延時，另外，在節(jié)目開始播放之前也需要幾十秒的下載緩沖時間，在這段時間內(nèi)，系統(tǒng)可以播放廣告。此外，在電影、電視劇的播放過程中，系統(tǒng)也可以插播廣告。通過與廣告代理進行商務(wù)上的合作，P2P流媒體會增加增值業(yè)務(wù)的收入。

(5)幫助互連互通。中國的網(wǎng)絡(luò)由多個運營商割據(jù)，網(wǎng)絡(luò)之間的連通性很差。例如電信的用戶訪問網(wǎng)通的服務(wù)器會有一定的延時。而通過P2P流媒體系統(tǒng)，當P2P的用戶數(shù)達到一定的數(shù)量(例如100人以上)時，網(wǎng)絡(luò)之間的差異可以被基本抹平。這是由于處于中間地帶的用戶起到了橋梁作用。

2.體系結(jié)構(gòu)

將基于CDN的流媒體技術(shù)和P2P技術(shù)有效地結(jié)合起來，是一種完美的組合，于是產(chǎn)生了P2P流媒體這項嶄新的技術(shù)，其體系如圖8-9所示。

圖中，每個節(jié)點代表一個Peer節(jié)點，同一臺路由器相連接。每個節(jié)點既是一臺服務(wù)器，也是一臺客戶端機器，所有的功能都是一樣的。假設(shè)A是數(shù)據(jù)源，B、C、D這3個節(jié)點都要同時接收相同的流媒體數(shù)據(jù)包，按照圖中箭頭所示線路進行數(shù)據(jù)傳輸，則B和D通過路由器直接由A節(jié)點傳送數(shù)據(jù)，但是C節(jié)點由于距離源數(shù)據(jù)點A比較遠，就通過D節(jié)點傳送數(shù)據(jù)。因此雖然有3個節(jié)點需要流媒體數(shù)據(jù)，圖8-9P2P流媒體技術(shù)結(jié)構(gòu)但是最大帶寬并不是單個流媒體數(shù)據(jù)包的3倍，而是兩倍。降低了帶寬。而且按照這種模式傳輸，節(jié)點數(shù)量可以無限增加，但是節(jié)點的帶寬并不增加。同時由于傳輸?shù)氖橇髅襟w數(shù)據(jù)，其緩沖技術(shù)也增加了網(wǎng)絡(luò)傳輸?shù)姆€(wěn)定性，充分體現(xiàn)了流媒體技術(shù)和P2P技術(shù)的優(yōu)點。

上面的P2P模式是一種單源的P2P流媒體模式，建立在應用層組播技術(shù)的基礎(chǔ)之上，由一個發(fā)送者向多個接收者發(fā)送數(shù)據(jù)，接收者有且只有一個數(shù)據(jù)源。為了解決帶寬問題，還可以將其改為多源的P2P流媒體模式，如圖8-10所示。由多個發(fā)送者以單播的方式同時向一個接收者發(fā)送媒體數(shù)據(jù)，在這種方式下，單個發(fā)送者提供的上行帶寬不足以支持一個完性的媒體流正?；胤艜r所需帶寬R，如果將若干發(fā)送者的能力聚合在一起，使得其上行帶寬的總和大于R，就能夠提供正常的流媒體服務(wù)，這種方式適于性能較低的節(jié)點。圖8-10多源的P2P流媒體傳輸

P2P流媒體服務(wù)體系下的Peer節(jié)點一般具有以下幾個特性：

(1)與傳統(tǒng)的服務(wù)器節(jié)點相比，Peer節(jié)點作為普通的主機節(jié)點，其所能夠或愿意提供的帶寬資源有限，而流媒體數(shù)據(jù)率較高，因此通常需要多個節(jié)點才能為單個節(jié)點提供數(shù)據(jù)服務(wù)。

(2)不同Peer節(jié)點的帶寬資源具有異構(gòu)性，因而能接收和處理不同QoS等級的流數(shù)據(jù)。

(3)不同Peer節(jié)點所緩存數(shù)據(jù)的異構(gòu)性導致其對外所能提供的數(shù)據(jù)內(nèi)容也不同。

(4)同一Peer節(jié)點的上行、下行帶寬也可能具有異構(gòu)性。分層流媒體能夠適應節(jié)點的異構(gòu)性。在分層流媒體中，節(jié)點接收到的數(shù)據(jù)層次越多，服務(wù)質(zhì)量越好。

3.關(guān)鍵技術(shù)

由于P2P流媒體系統(tǒng)中的節(jié)點存在不穩(wěn)定性，P2P流媒體系統(tǒng)需要解決如下幾個關(guān)鍵技術(shù)：文件定位、節(jié)點選擇、容錯機制以及安全機制等。

1) 文件定位技術(shù)

流媒體服務(wù)實時性強，要快速準確地進行文件定位是流媒體系統(tǒng)要解決的基本問題之一。在P2P流媒體系統(tǒng)中，新加入的客戶在覆蓋網(wǎng)絡(luò)中以P2P的文件查找方式，找到可提供所需媒體內(nèi)容的節(jié)點并建立連接，接收這些節(jié)點提供的媒體內(nèi)容。

P2P方式的文件查找研究是近年來P2P計算的一個研究熱點。在P2P網(wǎng)絡(luò)結(jié)構(gòu)中，常用的文件定位方式是通過分布式哈希表(DHT)算法來實現(xiàn)的。每個文件經(jīng)哈希運算后得到唯一一個標識符，每個節(jié)點也對應一個標識符，文件存儲到與其標識符相近的節(jié)點中。查找文件時，首先將文件名經(jīng)過哈希運算得到該文件的標識符，然后通過不同的路由算法找到存放該文件的節(jié)點。雖然以DHT方式查找文件快速有效，但是也存在一些固有的問題：首先DHT是將文件均勻分布在各個節(jié)點上的，不能反映媒體文件的熱門度，導致負載的不均衡；其次DHT不能提供關(guān)鍵字的搜索，如不支持對同時包含媒體文件名、媒體類型等豐富信息的文件的查詢。

2) 節(jié)點選擇

在一個典型的P2P覆蓋網(wǎng)絡(luò)中，網(wǎng)絡(luò)中的節(jié)點來自各個不同自治域，節(jié)點可以在同一時間自由地加入或離開覆蓋網(wǎng)絡(luò)，導致覆蓋網(wǎng)絡(luò)具有很大的動態(tài)性和不可控性。因此，如何在服務(wù)會話初始時，確定一個相對穩(wěn)定的可提供一定服務(wù)質(zhì)量(QoS)保證的服務(wù)節(jié)點或節(jié)點集合，是P2P流媒體系統(tǒng)迫切需要解決的問題。

節(jié)點的選擇可以根據(jù)不同的QoS需求采取不同的選擇策略。若希望服務(wù)延時小，可以選擇鄰近的節(jié)點快速建立會話，如在局域網(wǎng)內(nèi)有提供服務(wù)的節(jié)點，就不選擇互聯(lián)網(wǎng)上的節(jié)點，這也可以避免互聯(lián)網(wǎng)上的帶寬波動和擁塞；若希望高質(zhì)量服務(wù)，則可選擇能夠提供高帶寬、CPU能力強的節(jié)點，如在寬帶接入的PC機和不對稱數(shù)字用戶線(ADSL)接入的終端之間應選擇前者；若希望得到較穩(wěn)定的服務(wù)，應選擇相對穩(wěn)定的節(jié)點，如在系統(tǒng)中停留時間較長，不會頻繁加入或退出系統(tǒng)的或正在接受服務(wù)的節(jié)點。通常選擇的策略是上述幾種需求的折中。具有代表性的節(jié)點選擇機制有：PROMISE體系中的端到端的選擇機制和感知拓撲的選擇機制、P2Cast系統(tǒng)的“最合適(BestFit，簡稱BF)”節(jié)點選擇算法等。

3) 容錯機制

由于P2P流媒體系統(tǒng)中節(jié)點具有動態(tài)性，正在提供服務(wù)的節(jié)點可能會離開系統(tǒng)，傳輸鏈路也可能因擁塞而失效。為了保證接受服務(wù)的連續(xù)性，必須采取一些容錯機制使系統(tǒng)的服務(wù)能力不受影響或盡快恢復。

對于節(jié)點失效的問題，可以采取主、備用節(jié)點的方式容錯。在選擇發(fā)送節(jié)點時，應選擇多個服務(wù)節(jié)點，將其中某個節(jié)點(集)作為活動節(jié)點(集)，其余節(jié)點作為備用節(jié)點。當活動節(jié)點失效時則由備用節(jié)點繼續(xù)提供服務(wù)。值得研究的問題是如何快速有效地檢測節(jié)點的失效，以及如何保證在主、備用節(jié)點切換的過程中流媒體服務(wù)的連續(xù)性。流媒體服務(wù)的實時性較強，因此節(jié)點的故障檢測時間應盡可能短，才能保證服務(wù)不中斷。目前有大量關(guān)于如何縮短故障檢測時間的研究，大都采用軟狀態(tài)協(xié)議詢問節(jié)點的存在，需要考慮詢問頻度與詢問消息開銷之間的折中。

數(shù)據(jù)的編碼技術(shù)也可以提供系統(tǒng)的容錯性，如前向錯誤編碼(FEC)和多描述編碼(MDC)。FEC通過給壓縮后的媒體碼流加上一定的冗余信息來有效地提高系統(tǒng)的容錯性；而(MDC)的基本思想是對同一媒體流的內(nèi)容采用多種方式進行描述，每一種描述都可以單獨解碼并獲得可以接受的解碼質(zhì)量，多個描述方式結(jié)合起來可以使解碼質(zhì)量得到增強。這兩種編碼都能適應客戶異構(gòu)性的特點，客戶可以根據(jù)自己的能力選擇收取多少數(shù)據(jù)進行解碼。此外，將FEC和MDC結(jié)合，能取得更好的容錯效果。

4) 安全機制

網(wǎng)絡(luò)安全是P2P流媒體系統(tǒng)的基本要求，必須通過安全領(lǐng)域的身份識別認證、授權(quán)、數(shù)據(jù)完整性、保密性和不可否認性等技術(shù)，對P2P信息進行安全控制。對版權(quán)的控制，現(xiàn)階段可采用DRM技術(shù)；對于基于企業(yè)級的P2P流媒體播出系統(tǒng)，可以安裝防火墻阻止非法用戶訪問；因特網(wǎng)上的P2P流媒體系統(tǒng)可以通過數(shù)據(jù)包加密方式保證安全。在P2P流媒體系統(tǒng)內(nèi)，可采用用戶分級授權(quán)的辦法阻止非法訪問。

4.研究方向