隨著移動互聯(lián)網的快速發(fā)展以及智能終端性能的逐步提高，智能終端間進行實時音視頻通訊成為移動互聯(lián)網發(fā)展的一個重要方向。那么如何保證智能終端之間實時音視頻數(shù)據(jù)通訊成為一個很現(xiàn)實的問題。 實際上，實時音視頻通訊 = 音視頻處理 + 網絡傳輸。包括采集、編碼、網絡傳輸、解碼、播放等環(huán)節(jié)。其中采集、編解碼和播放屬于“音視頻處理”是不受網絡條件影響的，只受限于編解碼算法，播放策略等因素。而網絡傳輸?shù)膩G包、抖動和亂序對實時音視頻應用的體驗影響最為重大，如何解決好這些問題，是個很大的研究課題，好在目前已經存在多種非常成熟的實時音視頻數(shù)據(jù)傳輸協(xié)議，它們已經一定程度解決好了這些問題，而我們要做的就是盡可能多地了解它們，并選擇合適的協(xié)議用于我們的應用即可。本文將簡要介紹這些主流的實時音視頻數(shù)據(jù)傳輸協(xié)議。

RTP 協(xié)議

RTP（Real-time Transport Protocol）是用于Internet上針對多媒體數(shù)據(jù)流的一種傳輸層協(xié)議。RTP協(xié)議詳細說明了在互聯(lián)網上傳遞音頻和視頻的標準數(shù)據(jù)包格式。RTP協(xié)議常用于流媒體系統(tǒng)（配合RTCP協(xié)議），視頻會議和一鍵通（Push to Talk）系統(tǒng)（配合H.323或SIP），使它成為IP電話產業(yè)的技術基礎。RTP協(xié)議和RTP控制協(xié)議RTCP一起使用，而且它是建立在UDP協(xié)議上的。

RTP 本身并沒有提供按時發(fā)送機制或其它服務質量（QoS）保證，它依賴于低層服務去實現(xiàn)這一過程。 RTP 并不保證傳送或防止無序傳送，也不確定底層網絡的可靠性。 RTP 實行有序傳送， RTP 中的序列號允許接收方重組發(fā)送方的包序列，同時序列號也能用于決定適當?shù)陌恢?，例如：在視頻解碼中，就不需要順序解碼。

RTP 由兩個緊密鏈接部分組成： RTP——傳送具有實時屬性的數(shù)據(jù)；RTP 控制協(xié)議（RTCP）——監(jiān)控服務質量并傳送正在進行的會話參與者的相關信息。具體協(xié)議內容請查IETF的標準文檔RFC3550/RFC3551。

RTCP 協(xié)議

實時傳輸控制協(xié)議RTCP（Real-time Transport Control Protocol或RTP Control Protocol）是實時傳輸協(xié)議（RTP）的一個姐妹協(xié)議。RTCP為RTP媒體流提供信道外（out-of-band）控制。RTCP本身并不傳輸數(shù)據(jù)，但和RTP一起協(xié)作將多媒體數(shù)據(jù)打包和發(fā)送。RTCP定期在流多媒體會話參加者之間傳輸控制數(shù)據(jù)。RTCP的主要功能是為RTP所提供的服務質量（Quality of Service）提供反饋。

RTCP收集相關媒體連接的統(tǒng)計信息，例如：傳輸字節(jié)數(shù)，傳輸分組數(shù)，丟失分組數(shù)，jitter，單向和雙向網絡延遲等等。網絡應用程序可以利用RTCP所提供的信息試圖提高服務質量，比如限制信息流量或改用壓縮比較小的編解碼器。RTCP本身不提供數(shù)據(jù)加密或身份認證。SRTCP可以用于此類用途。

RTP和RTCP的關系可以通過一個實時視頻傳輸流程圖來理解，請看下圖：

SRTP、SRTCP 協(xié)議

安全實時傳輸協(xié)議（Secure Real-time Transport Protocol或SRTP）是在實時傳輸協(xié)議（Real-time Transport Protocol或RTP）基礎上所定義的一個協(xié)議，旨在為單播和多播應用程序中的實時傳輸協(xié)議的數(shù)據(jù)提供加密、消息認證、完整性保證和重放保護。它是由David Oran（思科）和Rolf Blom（愛立信）開發(fā)的，并最早由IETF于2004年3月作為RFC3711發(fā)布。

由于實時傳輸協(xié)議和可以被用來控制實時傳輸協(xié)議的會話的實時傳輸控制協(xié)議（RTP Control Protocol或RTCP）有著緊密的聯(lián)系，安全實時傳輸協(xié)議同樣也有一個伴生協(xié)議，它被稱為安全實時傳輸控制協(xié)議（Secure RTCP或SRTCP）；安全實時傳輸控制協(xié)議為實時傳輸控制協(xié)議提供類似的與安全有關的特性，就像安全實時傳輸協(xié)議為實時傳輸協(xié)議提供的那些一樣。

在使用實時傳輸協(xié)議或實時傳輸控制協(xié)議時，使不使用安全實時傳輸協(xié)議或安全實時傳輸控制協(xié)議是可選的；但即使使用了安全實時傳輸協(xié)議或安全實時傳輸控制協(xié)議，所有它們提供的特性（如加密和認證）也都是可選的，這些特性可以被獨立地使用或禁用。唯一的例外是在使用安全實時傳輸控制協(xié)議時，必須要用到其消息認證特性。

具體協(xié)議內容請查IETF的標準文檔RFC3711。

RTSP 協(xié)議

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

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

具體協(xié)議內容請查IETF的標準文檔RFC2326。

RTSP 和 RTP 的關系

RTP不象http和ftp可完整的下載整個影視文件，它是以固定的數(shù)據(jù)率在網絡上發(fā)送數(shù)據(jù)，客戶端也是按照這種速度觀看影視文件，當影視畫面播放過后，就不可以再重復播放，除非重新向服務器端要求數(shù)據(jù)。

RTSP與RTP最大的區(qū)別在于：RTSP是一種雙向實時數(shù)據(jù)傳輸協(xié)議，它允許客戶端向服務器端發(fā)送請求，如回放、快進、倒退等操作。當然，RTSP可基于RTP來傳送數(shù)據(jù)，還可以選擇TCP、UDP、組播UDP等通道來發(fā)送數(shù)據(jù)，具有很好的擴展性。它時一種類似與http協(xié)議的網絡應用層協(xié)議。

我們來看看下圖所示的例子：服務器端實時采集、編碼并發(fā)送兩路視頻，客戶端接收并顯示兩路視頻。由于客戶端不必對視頻數(shù)據(jù)做任何回放、倒退等操作，可直接采用UDP+RTP+組播實現(xiàn)。

RTMP/RTMPS 協(xié)議

RTMP(Real Time Messaging Protocol)實時消息傳送協(xié)議是Adobe Systems公司為Flash播放器和服務器之間音頻、視頻和數(shù)據(jù)傳輸 開發(fā)的開放協(xié)議。

它有三種變種：

• 工作在TCP之上的明文協(xié)議，使用端口1935；

• RTMPT封裝在HTTP請求之中，可穿越防火墻；

• RTMPS類似RTMPT，但使用的是HTTPS連接。

RTMP協(xié)議(Real Time Messaging Protocol)是被Flash用于對象、視頻、音頻的傳輸。這個協(xié)議建立在TCP協(xié)議或者輪詢HTTP協(xié)議之上。RTMP協(xié)議就像一個用來裝數(shù)據(jù)包的容器,這些數(shù)據(jù)既可以是AMF格式的數(shù)據(jù),也可以是FLV中的視/音頻數(shù)據(jù)。一個單一的連接可以通過不同的通道傳輸多路網絡流.這些通道中的包都是按照固定大小的包傳輸?shù)摹?/p>

MMS 協(xié)議

MMS (Microsoft Media Server Protocol)，中文“微軟媒體服務器協(xié)議”，用來訪問并流式接收 Windows Media 服務器中 .asf 文件的一種協(xié)議。MMS 協(xié)議用于訪問 Windows Media 發(fā)布點上的單播內容。MMS 是連接 Windows Media 單播服務的默認方法。若觀眾在 Windows Media Player 中鍵入一個 URL 以連接內容，而不是通過超級鏈接訪問內容，則他們必須使用MMS 協(xié)議引用該流。MMS的端口是1755。

當使用 MMS 協(xié)議連接到發(fā)布點時，使用協(xié)議翻轉以獲得最佳連接?！皡f(xié)議翻轉”始于試圖通過 MMSU 連接客戶端。 MMSU 是 MMS 協(xié)議結合 UDP 數(shù)據(jù)傳送。如果 MMSU 連接不成功，則服務器試圖使用 MMST。MMST 是 MMS 協(xié)議結合 TCP 數(shù)據(jù)傳送。

如果連接到編入索引的 .asf 文件，想要快進、后退、暫停、開始和停止流，則必須使用 MMS。不能用 UNC 路徑快進或后退。若您從獨立的 Windows Media Player 連接到發(fā)布點，則必須指定單播內容的 URL。若內容在主發(fā)布點點播發(fā)布，則 URL 由服務器名和 .asf 文件名組成。例如：mms://windows_media_server/sample.asf。其中 windows_media_server 是 Windows Media 服務器名，sample.asf 是您想要使之轉化為流的 .asf 文件名。

若您有實時內容要通過廣播單播發(fā)布，則該 URL 由服務器名和發(fā)布點別名組成。例如：mms://windows_media_server/LiveEvents。這里 windows_media_server 是 Windows Media 服務器名，而 LiveEvents 是發(fā)布點名。

HLS 協(xié)議

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

相對于常見的流媒體直播協(xié)議，例如RTMP協(xié)議、RTSP協(xié)議、MMS協(xié)議等，HLS直播最大的不同在于，直播客戶端獲取到的，并不是一個完整的數(shù)據(jù)流。HLS協(xié)議在服務器端將直播數(shù)據(jù)流存儲為連續(xù)的、很短時長的媒體文件（MPEG-TS格式），而客戶端則不斷的下載并播放這些小文件，因為服務器端總是會將最新的直播數(shù)據(jù)生成新的小文件，這樣客戶端只要不停的按順序播放從服務器獲取到的文件，就實現(xiàn)了直播。由此可見，基本上可以認為，HLS是以點播的技術方式來實現(xiàn)直播。由于數(shù)據(jù)通過HTTP協(xié)議傳輸，所以完全不用考慮防火墻或者代理的問題，而且分段文件的時長很短，客戶端可以很快的選擇和切換碼率，以適應不同帶寬條件下的播放。不過HLS的這種技術特點，決定了它的延遲一般總是會高于普通的流媒體直播協(xié)議?！?/p>

根據(jù)以上的了解要實現(xiàn)HTTP Live Streaming直播，需要研究并實現(xiàn)以下技術關鍵點：

技術交流加 q q 群：?384170753

• 采集視頻源和音頻源的數(shù)據(jù)

• 對原始數(shù)據(jù)進行H264編碼和AAC編碼

• 視頻和音頻數(shù)據(jù)封裝為MPEG-TS包

• HLS分段生成策略及m3u8索引文件

• HTTP傳輸協(xié)議?