視頻播放相關的網路協議有哪些？

01-07

不懂rtp與之的區別，或者國內採用的是http協議？

作為自己的專業知識領域，我決定更新本答案。

版權保留，不得商用，轉載必須在開始位置註明作者、出處。

憑藉印象完成，錯漏地方，還請大家指正。

----

視頻相關的協議有很多，不同的公司，甚至有自己的協議標準。本文盡量涵蓋目前常見的視頻相關的協議。

1，RTSP/RTP/RTCP協議族

本協議族是最早的視頻傳輸協議。其中RTSP協議用於視頻點播的會話控制，例如發起點播請求的SETUP請求，進行具體播放操作的PLAY、PAUSE請求，視頻的跳轉也是通過PLAY請求的參數支持的。而RTP協議用於具體的視頻數據流的傳輸。RTCP協議中的C是控制的意思，用於在視頻流數據之外，丟包或者碼率之類的控制。

該協議族RTSP是建立在TCP之上的，RTP、RTCP建立在UDP之上。不過也可以通過interleave的方式，將RTP和RTSP一起在同一個TCP連接上傳輸。

RTSP協議族，是最早被提出來的，因此很多考慮的地方，都還帶有早期的特徵。比如使用UDP，是考慮到傳輸的效率，以及視頻協議本身對丟包就有一定的容忍度。但是UDP協議，顯然不能用於更大規模的網路，而且複雜網路下路由器的穿透也是問題。

從視頻角度而言，RTSP協議族的優勢，在於可以控制到視頻幀，因此可以承載實時性很高的應用。這個優點是相對於HTTP方式的最大優點。H.323視頻會議協議，底層一般採用RTSP協議。RTSP協議族的複雜度主要集中在伺服器端，因為伺服器端需要parse視頻文件，seek到具體的視頻幀，而且可能還需要進行倍速播放（就是老舊的DVD帶的那種2倍速，4倍速播放的功能），倍速播放功能是RTSP協議獨有的，其他視頻協議都無法支持。

缺點，就是伺服器端的複雜度也比較高，實現起來也比較複雜。

2，HTTP協議

HTTP的視頻協議，主要是在互聯網普及之後。在互聯網上看視頻的需求下形成的。

2.1

最初的HTTP視頻協議，沒有任何特別之處，就是通用的HTTP文件漸進式下載。本質就是下載視頻文件，而利用視頻文件本身的特點，就是存在頭部信息，和部分視頻幀數據，就完全可以解碼播放了。顯然這種方式需要將視頻文件的頭部信息放在文件的前面。有些例如faststart工具，就是專門做這個功能的。

但是最為原始的狀態下，視頻無法進行快進或者跳轉播放到文件尚未被下載到的部分。這個時候對HTTP協議提出了range-request的要求。這個目前幾乎所有HTTP的伺服器都支持了。range-request，是請求文件的部分數據，指定偏移位元組數。在視頻客戶端解析出視頻文件的頭部後，就可以判斷後續視頻相應的幀的位置了。或者根據碼率等信息，計算相應的為位置。

2.2

支持HTTP range-request的伺服器，目前就可以支持我們一般網路看視頻的要求了。但是，這種方式，無法支持實時視頻流，或者准實時視頻流。因為視頻流，是不存在一個視頻文件的概念的。HTTP協議播放視頻的好處，就是簡單。採取通用的HTTP伺服器，就可以提供服務，不需要專門類型的伺服器，也不需要特別的網路埠，穿過路由器防火牆一點都沒有問題。而且還可以利用通用的CDN來簡化視頻的部署分發的工作，減少帶寬的使用。

這個是目前用於PC端或者網頁端，視頻點播業務，最常見的解決方案。客戶端的實現，一般採用flash完成，flash本是的videoplayer或者videodisplay控制項就可以完成。資源一般採用flv格式，也可以使用mp4格式。

在此基礎上，多家公司推出了自己的解決方法。

2.3 HLS HDS MSS DASH

蘋果推出的HTTP Live Streaming，就是隨著蘋果設備的普及得以廣泛應用的一種。從名詞就可以判斷出來，HLS支持Live直播式的視頻傳輸。HTTP採用m3u8作為索引文件，視頻為MPEG2-TS格式的片段文件。如果為直播視頻流，則採取更新m3u8文件，從而更新視頻索引列表，達到視頻直播的目的。但是這種方法，因為最終視頻是片段文件，所以必然存在片段視頻長度的延遲。因此只可以用於對實時性要求沒有那麼高的准實時視頻流。但是HLS方式，因為採用了較早的MPEG2-TS格式，這種格式的overhead，也就是頭部信息佔據總文件的比例比較大，也就是效率不夠高。之所以沒有使用其他格式，主要是商業競爭和版權的問題。

相應的，adobe公司，推出相似的HTTP dynamic streaming。這種方式本質和HLS的策略是類似的，就是通過索引文件+視頻片段的方式。但是顯然採用的索引格式和視頻片段格式都不一樣的。HDS採用的是視頻格式是flv或者f4v，索引格式記不清楚了。

類似的，微軟也推出了Microsoft Smooth Streaming，也即是mss的視頻播出方式，採用的視頻格式是分段mp4格式。

MPEG標準組則推出了Dynamic Adaptive Streaming over HTTP,DASH.採用的視頻格式為3GPP吧。

顯然，這個目前是百花齊放的狀態，雖然最常用的的是HLS，誰叫蘋果這麼霸氣呢。而安卓和蘋果上面對於flash都有限制，而HDS是adobe推出在adobe平台上面的。mss，只有在少數幾個地方見到過。dash，目前僅僅是論文裡面的產物。

以上的協議，主要是解決一個問題，就是自適應碼率切換，上面的dynamic，adaptive都是類似的意思。主要是利用索引文件中同時給出不同碼率的視頻文件的地址，這樣播放器端，可以根據帶寬情況，自適應選擇不同碼率的視頻文件。

同時在視頻直播方面，在安卓和iOS平台以外，還有很多視頻伺服器提供廠商，自己開發協議，一般採用方式為固定時間片段的flv文件的方式（採用flv，是因為flash上方便播放）

2.4 HTML5

同時HTML制定廠商也不寂寞，推出HTML5這種方式，這種方式本質上，和前面的HTTP視頻協議沒有任何區別。但是播放器端，不再依賴於特定的插件如flash，或者其他播放軟體，而是可以支持瀏覽器的直接視頻播放。採用的是html中嵌入video標籤，同時直接指明視頻的url。不過，不同的瀏覽器，對於音視頻的格式支持不完全相同。比較通用的是視頻H。264格式，音頻AAC格式，封裝格式MP4。

2.5其他

在HTTP協議的基礎上，各家公司，針對自己的業務特性，也可能開發自己的專有的數據格式，或者協議。但是都是在上述的基本上做出一些細微的修改而已。畢竟國內的技術體系，還完全無法提出一個新的技術的程度。（google，就提出新的編碼格式替換H.264,SPDY協議，這個國內做不到的）。

一般只會做到例如HTTP特殊欄位或者特殊參數，傳遞到flash中做出一定的解釋。或者在原有的視頻文件格式基礎上添加一些特殊意義的頭部等等。

3，RTMP

這個是adobe公司自己推出的視頻播放協議。需要專用的伺服器，如FMS，開源的有red5.這種協議也是flash默認支持的。

----

總體來看，視頻相關的協議發展，是從專用的協議、伺服器，逐漸向HTTP過渡的過程。而且逐漸適應網路的發展和需求，複雜多變的網路環境，才催生了http的視頻協議。

----

應邀更新.

上面已經對不同協議的應用場景分別解釋了.

單純的協議,http非常簡單,rtsp族比較複雜,rtmp沒有深入了解過.

如果你只是要做個應用,或者使用它,那麼http就夠了,非常之簡單,非常之快捷.

但是如果你真的想學習這個方面,必然不能僅僅注重於視頻的網路協議,還有其他的很多點.比如網路基礎的細節點,音視頻的編碼格式基礎知識等等.這裡面的每個點,都充滿了趣味.你可以深入挖掘.但這是一個長期的技術學習的投入,基本論年計.產出我就不了解了,因為我到現在還沒有真正意義的產出.

近年來，OTT業務在國內外均處於一個蓬勃發展的時期，而OTT業務中的主要視音頻傳輸協議包括：HTTP Live Streaming(HLS)、 HTTP Dynamic Streaming（HDS）等視頻傳輸協議，以及未來有可能作為下一代國際標準的Dynamic Adaptive Streaming over HTTP (DASH)協議。

HLS是蘋果公司提出的流媒體網路傳輸協議，工作原理是把整個流分成一個個小的基於HTTP的文件來下載，每次只下載一些。當媒體流正在播放時，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會話適應不同的數據速率。在開始一個流媒體會話時，客戶端會下載一個包含元數據的extended M3U (m3u8)文件，即切片索引文件，用於尋找可用的媒體切片。

HDS是Adobe公司的傳統流媒體解決方案RTMP+FLV的結合，在互聯網視頻行業得到了廣泛的應用。它包含了多個部件來完成內容的準備工作，並通過HTTP將內容傳送給終端的Flash Player。內容準備模塊包括了面向VOD和面向Live直播的模塊，VOD打包模塊將媒體文件分片，並以F4F的格式存儲，Live直播打包模塊將直播流實時地寫入到F4F文件當中。同時均會產生媒體對應的F4M格式的索引文件，索引文件中包含了編碼、解析度以及碼率等參數信息。

DASH也稱為MPEG-DASH，類似於HLS、HDS等協議，DASH也將視頻內容切片為多個視頻小片段，每個片段包含一小段視頻內容。DASH是第一個基於HTTP的自適應碼率的國際標準。

綜合而言，此類協議的基本特點為：均採用了索引文件加實際視頻切片文件的二級結構。

一、RTMP(Real

Time Messaging Protocol，實時消息傳送協議)

RTMP是Adobe Systems公司為Flash播放器和伺服器之間音頻、視頻和數據傳輸開發的開放協議。它有三種變種：

1、工作在TCP之上的明文協議，使用埠1935；

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

3、RTMPS類似RTMPT，但使用的是HTTPS連接；

RTMP協議是被Flash用於對象、視頻、音頻的傳輸。這個協議建立在TCP協議或者輪詢HTTP協議之上。RTMP協議就像一個用來裝數據包的容器，這些數據既可以是AMF格式的數據，也可以是FLV中的視音頻數據。一個單一的連接可以通過不同的通道傳輸多路網路流，這些通道中的包都是按照固定大小的包傳輸的。

二、RTSP(Real

Time Streaming Protocol，實時流傳輸協議)

RTSP定義了一對多應用程序如何有效地通過IP網路傳送多媒體數據。RTSP提供了一個可擴展框架，數據源可以包括實時數據與已有的存儲的數據。該協議目的在於控制多個數據發送連接，為選擇發送通道如UDP、組播UDP與TCP提供途徑，並為選擇基於RTP上發送機制提供方法。

RTSP語法和運作跟HTTP/1.1類似，但並不特彆強調時間同步，所以比較能容忍網路延遲。代理伺服器的緩存功能也同樣適用於RTSP，並且因為RTSP具有重新導向功能，可根據實際負載情況來切換提供服務的伺服器，以避免過大的負載集中於同一伺服器而造成延遲。

三、RTP(Real-time

Transport Protocol，實時傳輸協議)

RTP是針對多媒體數據流的一種傳輸層協議，詳細說明了在互聯網上傳遞音頻和視頻的標準數據包格式。RTP協議常用於流媒體系統（配合RTCP協議），視頻會議和一鍵通系統（配合H.323或SIP），使它成為IP電話產業的技術基礎。

RTP是建立在UDP協議上的，常與RTCP一起使用，其本身並沒有提供按時發送機制或其它服務質量（QoS）保證，它依賴於低層服務去實現這一過程。

RTP 並不保證傳送或防止無序傳送，也不確定底層網路的可靠性，只管發送，不管傳輸是否丟包，也不管接收方是否有收到包。RTP 實行有序傳送，RTP中的序列號允許接收方重組發送方的包序列，同時序列號也能用於決定適當的包位置，如在視頻解碼中，就不需要順序解碼。

四、RTCP(Real-time

Transport Control Protocol，實時傳輸控制協議）

RTCP是RTP的配套協議，為RTP媒體流提供信道外的控制。RTCP和RTP一起協作將多媒體數據打包和發送，定期在多媒體流會話參與者之間傳輸控制數據。

RTCP的主要功能是為RTP所提供的服務質量（QoS）提供反饋，收集相關媒體連接的統計信息，例如傳輸位元組數，傳輸分組數，丟失分組數，單向和雙向網路延遲等等。網路應用程序可以利用RTCP所提供的信息來提高服務質量，比如限制流量或改用壓縮比小的編解碼器。

amp;https://pic1.zhimg.com/v2-4a3b0546e217be906596608c8cb2292c_b.png&" dw="865" dh="354" w="865" data-original="&https://pic1.zhimg.com/v2-4a3b0546e217be906596608c8cb2292c_r.png" data-editable="true" data-title="zhimg.com 的頁面">https://pic1.zhimg.com/v2-4a3b0546e217be906596608c8cb2292c_r.png&"amp;>

利益相關

我們團隊是做直播技術的，底層架構都是做好的，開放給開發者sdk和api介面，開發者接入後就可以實現直播的功能。歡迎相互交流學習。我的qq3103607948

就是用TCP傳輸的flv視頻流，沒有用RTP也沒有用RTSP~這個你用wireshark截個包就全瞭然了哈~

其中，118.228.16.56就是youku的視頻地址~

rtp和rtsp不是一個可以直接對比的東東吧！？