(轉)視訊播放相關協議介紹
阿新 • • 發佈：2018-12-02
作者：楊華
連結：https://www.zhihu.com/question/20621558/answer/15661190
來源：知乎
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。
作為自己的專業知識領域，我決定更新本答案。
版權保留，不得商用，轉載必須在開始位置註明作者、出處。
憑藉印象完成，錯漏地方，還請大家指正。
------------------------------------------------------------
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就夠了,非常之簡單,非常之快捷.
但是如果你真的想學習這個方面,必然不能僅僅注重於視訊的網路協議,還有其他的很多點.比如網路基礎的細節點,音視訊的編碼格式基礎知識等等.這裡面的每個點,都充滿了趣味.你可以深入挖掘.但這是一個長期的技術學習的投入,基本論年計.產出我就不瞭解了,因為我到現在還沒有真正意義的產出.