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