流媒體協議掃盲（rtp/rtcp/rtsp/rtmp/mms/hls）

RTP

          參考文檔  RFC3550/RFC3551

         Real-time Transport Protocol)是用於Internet上針對多媒體數據流的一種傳輸層協議。RTP協議詳細說明了在互聯網上傳遞音頻和視頻的標準數據包格式。RTP協議經常使用於流媒體系統（配合RTCP協議），視頻會議和一鍵通（Push to Talk）系統（配合H.323或SIP），使它成爲IP電話產業的技術基礎。RTP協議和RTP控制協議RTCP一塊兒使用，並且它是創建在UDP協議上的。 

         RTP 自己並無提供按時發送機制或其它服務質量（QoS）保證，它依賴於低層服務去實現這一過程。 RTP 並不保證傳送或防止無序傳送，也不肯定底層網絡的可靠性。 RTP 實行有序傳送， RTP 中的序列號容許接收方重組發送方的包序列，同時序列號也能用於決定適當的包位置，例如：在視頻解碼中，就不須要順序解碼。

      RTP 由兩個緊密連接部分組成： RTP ― 傳送具備實時屬性的數據；RTP 控制協議（RTCP） ― 監控服務質量並傳送正在進行的會話參與者的相關信息。

RTCP

        實時傳輸控制協議（Real-time Transport Control Protocol或RTP Control Protocol或簡寫RTCP）是實時傳輸協議（RTP）的一個姐妹協議。RTCP爲RTP媒體流提供信道外（out-of-band）控制。RTCP自己並不傳輸數據，但和RTP一塊兒協做將多媒體數據打包和發送。RTCP按期在流多媒體會話參加者之間傳輸控制數據。RTCP的主要功能是爲RTP所提供的服務質量（Quality of Service）提供反饋。
        RTCP收集相關媒體鏈接的統計信息，例如：傳輸字節數，傳輸分組數，丟失分組數，jitter，單向和雙向網絡延遲等等。網絡應用程序能夠利用RTCP所提供的信息試圖提升服務質量，好比限制信息流量或改用壓縮比較小的編解碼器。RTCP自己不提供數據加密或身份認證。SRTCP能夠用於此類用途。

SRTP & SRTCP

        參考文檔  RFC3711

        安全實時傳輸協議（Secure Real-time Transport Protocol或SRTP）是在實時傳輸協議（Real-time Transport Protocol或RTP）基礎上所定義的一個協議，旨在爲單播和多播應用程序中的實時傳輸協議的數據提供加密、消息認證、完整性保證和重放保護。它是由David Oran（思科）和Rolf Blom（愛立信）開發的，並最先由IETF於2004年3月做爲RFC3711發佈。
        因爲實時傳輸協議和能夠被用來控制實時傳輸協議的會話的實時傳輸控制協議（RTP Control Protocol或RTCP）有着緊密的聯繫，安全實時傳輸協議一樣也有一個伴生協議，它被稱爲安全實時傳輸控制協議（Secure RTCP或SRTCP）；安全實時傳輸控制協議爲實時傳輸控制協議提供相似的與安全有關的特性，就像安全實時傳輸協議爲實時傳輸協議提供的那些同樣。
        在使用實時傳輸協議或實時傳輸控制協議時，使不使用安全實時傳輸協議或安全實時傳輸控制協議是可選的；但即便使用了安全實時傳輸協議或安全實時傳輸控制協議，全部它們提供的特性（如加密和認證）也都是可選的，這些特性能夠被獨立地使用或禁用。惟一的例外是在使用安全實時傳輸控制協議時，必需要用到其消息認證特性。

RTSP

       參考文檔 RFC2326

        是由Real Networks和Netscape共同提出的。該協議定義了一對多應用程序如何有效地經過IP網絡傳送多媒體數據。RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻的受控、點播成爲可能。數據源包括現場數據與存儲在剪輯中的數據。該協議目的在於控制多個數據發送鏈接，爲選擇發送通道，如UDP、多播UDP與TCP提供途徑，併爲選擇基於RTP上發送機制提供方法。

        RTSP（Real Time Streaming Protocol）是用來控制聲音或影像的多媒體串流協議，並容許同時多個串流需求控制，傳輸時所用的網絡通信協定並不在其定義的範圍內，服務器端能夠自行選擇使用TCP或UDP來傳送串流內容，它的語法和運做跟HTTP 1.1相似，但並不特別強調時間同步，因此比較能容忍網絡延遲。而前面提到的容許同時多個串流需求控制（Multicast），除了能夠下降服務器端的網絡用量，更進而支持多方視訊會議（Video Conference）。 由於與HTTP1.1的運做方式類似，因此代理服務器《Proxy》的快取功能《Cache》也一樣適用於RTSP，並因RTSP具備從新導向功能，可視實際負載狀況來轉換提供服務的服務器，以免過大的負載集中於同一服務器而形成延遲。

RTSP 和RTP的關係

 

       RTP不象http和ftp可完整的下載整個影視文件，它是以固定的數據率在網絡上發送數據，客戶端也是按照這種速度觀看影視文件，當影視畫面播放事後，就不能夠再重複播放，除非從新向服務器端要求數據。

      RTSP與RTP最大的區別在於：RTSP是一種雙向實時數據傳輸協議，它容許客戶端向服務器端發送請求，如回放、快進、倒退等操做。固然，RTSP可基於RTP來傳送數據，還能夠選擇TCP、UDP、組播UDP等通道來發送數據，具備很好的擴展性。它時一種相似與http協議的網絡應用層協議。目前碰到的一個應用：服務器端實時採集、編碼併發送兩路視頻，客戶端接收並顯示兩路視頻。因爲客戶端沒必要對視頻數據作任何回放、倒退等操做，可直接採用UDP+RTP+組播實現。

RTP：實時傳輸協議（Real-time Transport Protocol） 
RTP/RTCP是實際傳輸數據的協議 
RTP傳輸音頻/視頻數據，若是是PLAY，Server發送到Client端，若是是RECORD，能夠由Client發送到Server 
整個RTP協議由兩個密切相關的部分組成：RTP數據協議和RTP控制協議（即RTCP） 
RTSP：實時流協議（Real Time Streaming Protocol，RTSP） 
RTSP的請求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顧名思義能夠知道起對話和控制做用 
RTSP的對話過程當中SETUP能夠肯定RTP/RTCP使用的端口，PLAY/PAUSE/TEARDOWN能夠開始或者中止RTP的發送，等等 
RTCP： 
RTP/RTCP是實際傳輸數據的協議 
RTCP包括Sender Report和Receiver Report，用來進行音頻/視頻的同步以及其餘用途，是一種控制協議

SDP

        會話描述協議（SDP）爲會話通知、會話邀請和其它形式的多媒體會話初始化等目的提供了多媒體會話描述。
       會話目錄用於協助多媒體會議的通告，併爲會話參與者傳送相關設置信息。SDP 即用於將這種信息傳輸到接收端。SDP 徹底是一種會話描述格式 ― 它不屬於傳輸協議 ― 它只使用不一樣的適當的傳輸協議，包括會話通知協議（SAP）、會話初始協議（SIP）、實時流協議（RTSP）、MIME 擴展協議的電子郵件以及超文本傳輸協議（HTTP）。

        SDP 的設計宗旨是通用性，它能夠應用於大範圍的網絡環境和應用程序，而不只僅侷限於組播會話目錄，但 SDP 不支持會話內容或媒體編碼的協商。
        在因特網組播骨幹網（Mbone）中，會話目錄工具被用於通告多媒體會議，併爲參與者傳送會議地址和參與者所需的會議特定工具信息，這由 SDP 完成。SDP 鏈接好會話後，傳送足夠的信息給會話參與者。SDP 信息發送利用了會話通知協議（SAP），它週期性地組播通知數據包到已知組播地址和端口處。這些信息是 UDP 數據包，其中包含 SAP 協議頭和文本有效載荷（text payload）。這裏文本有效載荷指的是 SDP 會話描述。此外信息也能夠經過電子郵件或 WWW （World Wide Web） 進行發送。

SDP 文本信息包括：

1. 會話名稱和意圖；
2. 會話持續時間；
3. 構成會話的媒體；
4. 有關接收媒體的信息（地址等）。
5. 協議結構

SDP 信息是文本信息，採用 UTF-8 編 碼中的 ISO 10646 字符集。SDP 會話描述以下：（標註 * 符號的表示可選字段）：
v = （協議版本）
o = （全部者/建立者和會話標識符）
s = （會話名稱）
i = * （會話信息）
u = * （URI 描述）
e = * （Email 地址）
p = * （電話號碼）
c = * （鏈接信息 ― 若是包含在全部媒體中，則不須要該字段）
b = * （帶寬信息）

一個或更多時間描述（以下所示）：
z = * （時間區域調整）
k = * （加密密鑰）
a = * （0 個或多個會話屬性行）
0個或多個媒體描述（以下所示）

時間描述
t = （會話活動時間）
r = * （0或屢次重複次數）

媒體描述
m = （媒體名稱和傳輸地址）
i = * （媒體標題）
c = * （鏈接信息 — 若是包含在會話層則該字段可選）
b = * （帶寬信息）
k = * （加密密鑰）

a = * （0 個或多個會話屬性行）

RTMP/RTMPS

RTMP(Real Time Messaging Protocol)實時消息傳送協議是Adobe Systems公司爲Flash播放器和服務器之間音頻、視頻和數據傳輸 開發的開放協議。
它有三種變種：

1)工做在TCP之上的明文協議，使用端口1935；

2)RTMPT封裝在HTTP請求之中，可穿越防火牆；

3)RTMPS相似RTMPT，但使用的是HTTPS鏈接；

      RTMP協議(Real Time Messaging Protocol)是被Flash用於對象,視頻,音頻的傳輸.這個協議創建在TCP協議或者輪詢HTTP協議之上.

      RTMP協議就像一個用來裝數據包的容器,這些數據既能夠是AMF格式的數據,也能夠是FLV中的視/音頻數據.一個單一的鏈接能夠經過不一樣的通道傳輸多路網絡流.這些通道中的包都是按照固定大小的包傳輸的.

mms

        MMS (Microsoft Media Server Protocol)，中文「微軟媒體服務器協議」，用來訪問並流式接收 Windows Media 服務器中 .asf 文件的一種協議。MMS 協議用於訪問 Windows Media 發佈點上的單播內容。MMS 是鏈接 Windows Media 單播服務的默認方法。若觀衆在 Windows Media Player 中鍵入一個 URL 以鏈接內容，而不是經過超級連接訪問內容，則他們必須使用MMS 協議引用該流。MMS的預設埠（端口）是1755

        當使用 MMS 協議鏈接到發佈點時，使用協議翻轉以得到最佳鏈接。「協議翻轉」始於試圖經過 MMSU 鏈接客戶端。 MMSU 是 MMS 協議結合 UDP 數據傳送。若是 MMSU 鏈接不成功，則服務器試圖使用 MMST。MMST 是 MMS 協議結合 TCP 數據傳送。
若是鏈接到編入索引的 .asf 文件，想要快進、後退、暫停、開始和中止流，則必須使用 MMS。不能用 UNC 路徑快進或後退。若您從獨立的 Windows Media Player 鏈接到發佈點，則必須指定單播內容的 URL。若內容在主發佈點點播發布，則 URL 由服務器名和 .asf 文件名組成。例如：mms://windows_media_server/sample.asf。其中 windows_media_server 是 Windows Media 服務器名，sample.asf 是您想要使之轉化爲流的 .asf 文件名。
若您有實時內容要經過廣播單播發布，則該 URL 由服務器名和發佈點別名組成。例如：mms://windows_media_server/LiveEvents。這裏 windows_media_server 是 Windows Media 服務器名，而 LiveEvents 是發佈點名

HLS

      HTTP Live Streaming（HLS）是蘋果公司(Apple Inc.)實現的基於HTTP的流媒體傳輸協議，可實現流媒體的直播和點播，主要應用在iOS系統，爲iOS設備（如iPhone、iPad）提供音視頻直播和點播方案。HLS點播，基本上就是常見的分段HTTP點播，不一樣在於，它的分段很是小。

       相對於常見的流媒體直播協議，例如RTMP協議、RTSP協議、MMS協議等，HLS直播最大的不一樣在於，直播客戶端獲取到的，並非一個完整的數據流。HLS協議在服務器端將直播數據流存儲爲連續的、很短時長的媒體文件（MPEG-TS格式），而客戶端則不斷的下載並播放這些小文件，由於服務器端老是會將最新的直播數據生成新的小文件，這樣客戶端只要不停的按順序播放從服務器獲取到的文件，就實現了直播。因而可知，基本上能夠認爲，HLS是以點播的技術方式來實現直播。因爲數據經過HTTP協議傳輸，因此徹底不用考慮防火牆或者代理的問題，並且分段文件的時長很短，客戶端能夠很快的選擇和切換碼率，以適應不一樣帶寬條件下的播放。不過HLS的這種技術特色，決定了它的延遲通常老是會高於普通的流媒體直播協議。　

     根據以上的瞭解要實現HTTP Live Streaming直播，須要研究並實現如下技術關鍵點

1. 採集視頻源和音頻源的數據
2. 對原始數據進行H264編碼和AAC編碼
3. 視頻和音頻數據封裝爲MPEG-TS包
4. HLS分段生成策略及m3u8索引文件
5. HTTP傳輸協議