參考原文鏈接:
http://blog.csdn.net/maopig/article/details/6665250
http://www.cnblogs.com/qingquan/archive/2011/07/14/2106834.html
RTSP實時流協(xié)議
多媒體播放控制協(xié)議严就，TCP/IP協(xié)議體系中的一個應(yīng)用層協(xié)議炊汹，用來使用戶在播放從因特網(wǎng)下載的實時數(shù)據(jù)時能夠進(jìn)行控制蔗蹋。（暫停澎胡，播放偷遗，后退哈误，前進(jìn)）
RTSP特性
- 流控分離：從控制邏輯上來說RTSP和FTP相似逃延，控制流和數(shù)據(jù)流是分開的卓囚。
- 可擴(kuò)展性：因為RTSP協(xié)議是基于文本的協(xié)議所以其具有較強(qiáng)的可擴(kuò)展性套鹅。
- 安全：RTSP 使用網(wǎng)頁安全機(jī)制站蝠。
RTSP協(xié)議條件
實現(xiàn)控制功能 除協(xié)議外還需
- 1 媒體播放器(media player)
- 2 媒體服務(wù)器(media server)
RTSP 報文結(jié)構(gòu)
RTSP有 兩類報文：請求報文和響應(yīng)報文。請求報文是指從客戶向服務(wù)器發(fā)送請求報文卓鹿，響應(yīng)報文是指從服務(wù)器到客戶的回答菱魔。
由于RTSP 是面向正文的(text-oriented)，因此在報文中的每一個字段都是一些 ASCII 碼串吟孙，因而每個字段的長度都是不確定的澜倦。
請求報文
響應(yīng)報文
協(xié)議特點
- 可擴(kuò)展性：新方法和參數(shù)很容易加入RTSP。
- 易解析：RTSP可由標(biāo)準(zhǔn) HTTP或MIME解析器解析杰妓。
- 安全：RTSP使用網(wǎng)頁安全機(jī)制藻治。
- 獨立于傳輸：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ī)制讓用戶決定那種方法不生效衫生。這允許用戶提出適合自己的界面裳瘪。
與HTTP協(xié)議流控制協(xié)議的區(qū)別
- 都使用純文本來發(fā)送信息，語法類似
- RTSP協(xié)議是有狀態(tài)的協(xié)議罪针，HTTP是無狀態(tài)的協(xié)議
協(xié)議的狀態(tài)是指下一次傳輸數(shù)據(jù)的時候能考慮到這次傳輸信息的狀態(tài)彭羹。也有是說有狀態(tài)協(xié)議以前的請求導(dǎo)致協(xié)議所處的狀態(tài)會影響后續(xù)的狀態(tài)，協(xié)議會根據(jù)上一個狀態(tài)創(chuàng)建上下文泪酱。
- http協(xié)議里就是無狀態(tài)協(xié)議不用考慮上下文派殷；每個請求都是與服務(wù)器的獨立連接，即下一次請求到來的時候協(xié)議不用維護(hù)這次請求中客戶機(jī)-服務(wù)器間交互的信息墓阀。
- RTSP通過維護(hù)一個session來維護(hù)其狀態(tài)的轉(zhuǎn)換
協(xié)議實現(xià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)用效果最好
