<img height="1" width="1" border="0" src="http://image.360doc.com/DownloadImg/2178/54251_13" />
RTSP，實時流協(xié)議，是一個C/S多媒體節(jié)目協(xié)議，它可以控制流媒體數(shù)據(jù)在IP網(wǎng)絡(luò)上的發(fā)送，同時提供用于音頻和視頻流的“VCR模式”遠(yuǎn)程控制功能，如停止、快進(jìn)、快退和定位。同時RTSP又是一個應(yīng)用層協(xié)議
，用來與諸如RTP、RSVP等更低層的協(xié)議一起，提供基于Internet的整套流化服務(wù)?；赗TSP協(xié)議流媒體服務(wù)器的實現(xiàn)方案可以讓流媒體在IP上自由翱翔。
RTSP協(xié)議
1．協(xié)議特點
RTSP協(xié)議具有如下的特點：
● 可擴(kuò)展性：新方法和參數(shù)很容易加入RTSP。
● 易解析：RTSP可由標(biāo)準(zhǔn) HTTP或MIME解析器解析。
● 安全：RTSP使用網(wǎng)頁安全機(jī)制。
● 獨(dú)立于傳輸：RTSP傳輸通道，可使用不可靠數(shù)據(jù)包協(xié)議（UDP）或可靠數(shù)據(jù)包協(xié)議（RDP），如要實現(xiàn)應(yīng)用級可靠，可使用諸如TCP的可靠流協(xié)議。
● 記錄設(shè)備控制：協(xié)議可控制記錄和回放設(shè)備。
● 適合專業(yè)應(yīng)用：通過SMPTE 時標(biāo)，RTSP支持幀級精度，允許遠(yuǎn)程數(shù)字編輯。
● 演示描述中立：協(xié)議未強(qiáng)加特殊演示或元文件，可傳送所用格式類型；然而，演示描述至少需包含一個RTSP URI。
● 代理與防火墻友好：協(xié)議可由應(yīng)用和傳輸層防火墻處理。防火墻需要理解SETUP方法，為UDP媒體流打開一個“缺口”。
● 適當(dāng)?shù)姆?wù)器控制：如用戶啟動一個流，則也可以停止一個流。
● 傳輸協(xié)調(diào)：實際處理連續(xù)媒體流前，用戶可協(xié)調(diào)傳輸方法。
● 性能協(xié)調(diào)：如基本特征無效，則必須有一些清理機(jī)制讓用戶決定那種方法不生效。這允許用戶提出適合自己的界面。
2．同其他協(xié)議的關(guān)系
RTSP在功能上與HTTP有重疊，最明顯的交叉是在流媒體內(nèi)容的發(fā)布上——大多是通過網(wǎng)頁進(jìn)行的。目前的協(xié)議規(guī)范同時允許網(wǎng)頁服務(wù)器和流媒體服務(wù)器支持RTSP實現(xiàn)。例如，演示描述可通過HTTP或RTSP獲取，這樣減少了基于瀏覽器情況下的往返傳遞時間，同時也支持獨(dú)立的RTSP 服務(wù)器與不依賴HTTP的客戶端通信。
但是，RTSP與HTTP 的本質(zhì)差別在于以下五個方面
● RTSP和HTTP是兩個不同的協(xié)議，它們采用不同的方法和協(xié)議標(biāo)志符。
● RTSP協(xié)議的數(shù)據(jù)發(fā)送不占用協(xié)議帶寬，并且以不同的協(xié)議發(fā)送。
● HTTP是一個不對稱協(xié)議，客戶端發(fā)出請求，服務(wù)器應(yīng)答。在RTSP中，客戶端和服務(wù)器都可發(fā)出請求，且請求是有狀態(tài)的。
● HTTP是一個無狀態(tài)協(xié)議，而RTSP在任何情況下，必須保持一定狀態(tài)，以便在請求確認(rèn)后的很長時間內(nèi)，仍可設(shè)置參數(shù)，控制媒體流。
● RTSP使用ISO 10646（UTF-8）定義，而不使用ISO 8859-1定義，保持與當(dāng)前的HTML一致。
雖然大多數(shù)實時媒體采用RTP作為傳輸協(xié)議，但RTSP并不綁定RTP。
重用HTTP的功能至少在兩個方面有好處:安全和代理。由于要求非常接近，因此在緩存、代理和授權(quán)上采用HTTP功能是有價值的。
RTSP的實現(xiàn)
RTSP在流媒體傳輸過程中，僅僅為雙方建立連接，并不具備任何智能，也就不能很好地應(yīng)付難以預(yù)料的網(wǎng)絡(luò)狀態(tài)。因此，必須在它原有功能的基礎(chǔ)上，進(jìn)行改進(jìn)。
1、初始化
在建立連接之前，客戶端應(yīng)向服務(wù)器提出測試請求，即要求服務(wù)器向客戶端發(fā)送相應(yīng)的測試數(shù)據(jù)包。初始化的目的，是為了獲取客戶端和服務(wù)器之間的一些網(wǎng)絡(luò)參數(shù)，估測基本網(wǎng)絡(luò)狀況，并以此選擇相應(yīng)的網(wǎng)絡(luò)傳輸協(xié)議，使客戶端獲得最佳觀看效果。
接到這個請求之后，服務(wù)器將根據(jù)自身情況進(jìn)行如下測試：
● 利用同客戶端建立的RTSP通道，采用TCP協(xié)議，下發(fā)測試數(shù)據(jù)包。
● 采用UDP協(xié)議，向客戶端下發(fā)測試數(shù)據(jù)包。
測試數(shù)據(jù)包僅做測試用，上面帶有相應(yīng)的時間和順序信息，其內(nèi)部數(shù)據(jù)并無任何意義。
需要向RTSP增加一個新的方法TEST，以支持這種傳輸前的測試工作。
2、TCP傳輸
如果在TCP測試中，客戶端反饋良好，即丟包率在可承受范圍之內(nèi)，并且在規(guī)定時間內(nèi)到達(dá)，那么就認(rèn)為客戶端同服務(wù)器之間的網(wǎng)絡(luò)狀況良好， 可以采用RTP over TCP的方式發(fā)送數(shù)據(jù)。由于TCP沒有丟包（其自身具有重傳機(jī)制），網(wǎng)絡(luò)狀況又屬于良好，因此客戶端將有較高的視聽享受。
當(dāng)子網(wǎng)內(nèi)存在防火墻時，就需要采用RTSP附加數(shù)據(jù)傳輸方式。即把音視頻數(shù)據(jù)直接打包，在RTSP通信信道內(nèi)傳輸。這種傳輸方式也存在一定的問題：
● 傳輸過程中，只是把音視頻文件當(dāng)成一個普通文件來處理，而沒有考慮到它的音視頻特性，不利于以后的擴(kuò)展。
● 音頻與視頻文件沒有分離，不利于某些特殊需求的場合。例如，客戶端需要對音、視頻做不同的處理。
● 客戶端的反饋和RTSP的控制信息也是通過同一條RTSP信道傳送，因此控制效率不高。
因此，一般情況下，都默認(rèn)使用RTP over TCP的方式發(fā)送數(shù)據(jù)。
3、UDP傳輸
如果在TCP測試中，客戶端的反饋存在比較大的問題，即網(wǎng)絡(luò)情況不理想，就應(yīng)該考慮進(jìn)行UDP測試。
目前初步采取的措施，在服務(wù)器端準(zhǔn)備了兩種碼率的視頻文件——高碼率和低碼率。
收到客戶端的TEST方法后，將采用UDP協(xié)議下發(fā)測試包。采取的策略是每間隔2秒，下發(fā)一個1500字節(jié)的UDP數(shù)據(jù)包。當(dāng)丟包率處于一定范圍（75％～85％）之內(nèi)，就認(rèn)為客戶端的網(wǎng)絡(luò)狀況基本良好，可以下發(fā)高碼率的電影文件;否則，認(rèn)為測試不成功，由于網(wǎng)絡(luò)狀況的限制，僅對客戶端下發(fā)低碼率的電影文件。
在基于UDP的播放過程中，可能會出現(xiàn)輕微的馬賽克，這是完全可以接受的。這些馬賽克出現(xiàn)的主要原因是：
● 不可靠連接造成的網(wǎng)絡(luò)丟包，為客戶端被動丟包。
● 高質(zhì)量文件（DVD－>MP4）的高數(shù)據(jù)量，使得客戶端解碼線程和顯示線程出現(xiàn)擁塞，從而出現(xiàn)客戶端主動丟包。
但從整體而言，UDP傳輸消耗的帶寬，要比TCP小許多。在一般的視頻點播要求下，使用基于UDP的傳輸線路，是完全可以滿足要求的。
4、傳輸反饋
在傳輸過程中，主要采取的方式是RTP over TCP或RTP over UDP，因此，在RTP端口之外，還存在一個回傳端口RTCP。
在服務(wù)器收到客戶端的RTCP回傳信息后，需要對其進(jìn)行判斷。如果客戶端的丟包率、解碼率等指標(biāo)在一定限度之下，就認(rèn)為目前傳送的視頻文件可令客戶端獲得最大程度的音視頻享受;否則，考慮改為傳輸更低碼率的視頻文件或放棄這次RTSP會話，以避免更大范圍的擁塞。
5、實際效果
采取如上方法設(shè)計的系統(tǒng)，可以滿足視頻點播的基本要求，避免了服務(wù)器視頻文件下發(fā)的盲目性，同時使客戶端應(yīng)用效果最好。
引入智能流技術(shù)
隨著針對流媒體技術(shù)研究的不斷深入，簡單的流媒體實現(xiàn)已經(jīng)不能滿足人們?nèi)找嬖鲩L的網(wǎng)絡(luò)文化需求。即使在寬帶條件下，當(dāng)網(wǎng)絡(luò)用戶達(dá)到一定限額時，簡單的流媒體技術(shù)將面臨著網(wǎng)絡(luò)擁塞、丟包等常見的網(wǎng)絡(luò)問題。因此，如何在網(wǎng)絡(luò)出現(xiàn)異常的情況下，依然保證客戶端音視頻享受的最大化，就成為現(xiàn)在研究的熱點。
一種解決方法是服務(wù)器減少發(fā)送給客戶端的數(shù)據(jù)而阻止再緩沖，在RealSystem 5.0中，這種方法稱為“視頻流瘦化”。這種方法的限制是RealVideo文件必須是一種數(shù)據(jù)速率設(shè)計，結(jié)果可通過抽取內(nèi)部幀擴(kuò)展到更低速率，導(dǎo)致質(zhì)量較低，離原始數(shù)據(jù)速率越遠(yuǎn)，質(zhì)量越差。
另一種解決方法是根據(jù)不同連接速率創(chuàng)建多個文件，根據(jù)用戶連接，服務(wù)器發(fā)送相應(yīng)文件，這種方法帶來制作和管理上的困難，而且，用戶連接是動態(tài)變化的，服務(wù)器也無法實時協(xié)調(diào)。
智能流技術(shù)通過兩種途徑克服帶寬協(xié)調(diào)和流瘦化:首先，確立一個編碼框架，允許不同速率的多個流同時編碼，合并到同一個文件中；第二，采用一種復(fù)雜客戶/服務(wù)器機(jī)制探測帶寬變化。
針對軟件、設(shè)備和數(shù)據(jù)傳輸速度上的差別，用戶以不同帶寬瀏覽音視頻內(nèi)容。為滿足客戶要求，Real Networks公司編碼、記錄不同速率下媒體數(shù)據(jù)，并保存在單一文件中，此文件被稱為智能流文件，即創(chuàng)建可擴(kuò)展流式文件。當(dāng)客戶端發(fā)出請求時，它將其帶寬容量傳給服務(wù)器，媒體服務(wù)器根據(jù)客戶帶寬將智能流文件相應(yīng)部分傳送給用戶。以此方式，用戶可使用最優(yōu)質(zhì)的傳輸，制作人員只需要壓縮一次，管理員也只需要維護(hù)單一文件，而媒體服務(wù)器根據(jù)所得帶寬自動切換。智能流通過描述Internet上變化的帶寬特點來發(fā)送高質(zhì)量媒體并保證其可靠性，并對混合連接環(huán)境的內(nèi)容授權(quán)提供了解決方法。這樣流媒體實現(xiàn)方式如下：對所有連接速率環(huán)境創(chuàng)建一個文件。在混合環(huán)境下以不同速率傳送媒體。根據(jù)網(wǎng)絡(luò)的變化情況，無縫切換到其他速率。關(guān)鍵幀優(yōu)先，音頻比部分視頻幀數(shù)據(jù)更重要，向后兼容老版本RealPlayer。
