轉載
原文位址：https://blog.csdn.net/mymottoissh/article/details/83661182
目前幾種視訊流的簡單對比：
| 協定 | httpflv | rtmp | hls | dash |
| 傳輸方式 | http流 | tcp流 | http | http |
| 視訊封裝格式 | flv | flv tag | Ts檔案 | Mp4 3gp webm |
| 延時 | 低 | 低 | 高 | 高 |
| 資料分段 | 連續流 | 連續流 | 切片檔案 | 切片檔案 |
| Html5播放 | 可通過html5解封包播放(flv.js) | 不支援 | 可通過html5解封包播放(hls.js) | 如果dash檔案清單是mp4webm檔案，可直接播放 |
題外話：
HTTP漸進下載下傳流媒體播放: 基于TCP。
yy、樂視、愛奇藝、優酷洋芋、搜狐視訊、花椒直播，主要還是通過rtmp&hls來實作的，
但他們也意識到rtmp的天生缺陷，是以不管是技術預研也好，還是測試版也好，都已經或多或少在弄WebRTC了。
流媒體概述：
所謂流媒體是指采用流式傳輸的方式在 Internet 播放的媒體格式。
流媒體又叫流式媒體，它是指商家用一個視訊傳送伺服器把節目當成資料包發出，傳送到網絡上。
使用者通過解壓裝置對這些資料進行解壓後，節目就會像發送前那樣顯示出來。
流媒體以流的方式在網絡中傳輸音頻、視訊和多媒體檔案的形式。
流媒體檔案格式是支援采用流式傳輸及播放的媒體格式。
流式傳輸方式是将視訊和音頻等多媒體檔案經過特殊的壓縮方式分成一個個壓縮包，
由伺服器向使用者計算機連續、實時傳送。在采用流式傳輸方式的系統中，使用者不必像非流式播放那樣等到整個檔案
全部下載下傳完畢後才能看到當中的内容，而是隻需要經過幾秒鐘或幾十秒的啟動延時即可在使用者計算機上利用
相應的播放器對壓縮的視訊或音頻等流式媒體檔案進行播放，剩餘的部分将繼續進行下載下傳，直至播放完畢。
RTP :(Real-time Transport Protocol)
是用于Internet上針對多媒體資料流的一種傳輸層協定.RTP 協定和 RTP 控制協定 RTCP 一起使用，
而且它是建立在 UDP 協定上的.
RTP 不像http和ftp可完整的下載下傳整個影視檔案，它是以固定的資料率在網絡上發送資料，用戶端也是按照這種速度觀看影視檔案，當
影視畫面播放過後，就不可以再重複播放，除非重新向伺服器端要求資料。
RTCP:Real-time Transport Control Protocol 或 RTP Control Protocol或簡寫 RTCP)
實時傳輸控制協定,是實時傳輸協定(RTP)的一個姐妹協定.
注:--:RTP 協定和 RTP控制協定(RTCP) 一起使用，而且它是建立在UDP協定上的（一般用于視訊會議）
RTSP:(Real Time Streaming Protocol)
實時流媒體會話協定,SDP(會話描述協定)，RTP(實時傳輸協定)。
是用來控制聲音或影像的多媒體串流協定,RTSP 提供了一個可擴充架構，使實時資料，如音頻與視訊的受控、點播成為可能。
媒體資料使用rtp,rtcp協定。
一般使用udp 作為傳輸層。适合IPTV場景。
資料源包括現場資料與存儲在剪輯中的資料。該協定目的在于控制多個資料發送連接配接，為選擇發送通道，如UDP、多點傳播UDP與TCP提供途
徑，并為選擇基于RTP上發送機制提供方法
傳輸時所用的網絡通訊協定并不在其定義的範圍内，伺服器端可以自行選擇使用TCP或UDP來傳送串流内容，比較能容忍網絡延遲.
--->:RTSP 與 RTP 最大的差別在于：RTSP 是一種雙向實時資料傳輸協定，它允許用戶端向伺服器端發送請求，如回放、快進、倒退等操作。當
然，RTSP 可基于 RTP 來傳送資料，還可以選擇 TCP、UDP、多點傳播 UDP 等通道來發送資料，具有很好的擴充性。它時一種類似與http協定
的網絡應用層協定.
WebRTC:
web端實作流媒體的協定。google剛推出WebRTC的時候巨頭們要麼冷眼旁觀，要麼抵觸情緒很大。使用RTP協定傳輸。
RTMP(Real Time Messaging Protocol)
Macromedia 開發的一套視訊直播協定，現在屬于 Adobe。和 HLS 一樣都可以應用于視訊直播，基于TCP不會丢失。
// 差別是 RTMP 基于 flash 無法在 iOS 的浏覽器裡播放，但是實時性比 HLS 要好。
實時消息傳送協定是 Adobe Systems 公司為 Flash 播放器和伺服器之間音頻、視訊和資料傳輸開發的開放協定.
// iOS 代碼裡面一般常用的是使用 RTMP 推流，可以使用第三方庫 librtmp-iOS 進行推流，librtmp 封裝了一些核心的 API 供使用者調用
RTMP 協定也要用戶端和伺服器通過"握手"來建立 RTMP Connection，然後在Connection上傳輸控制資訊。RTMP 協定傳輸時會對資料格式化，而實際傳輸的時候為了更好地實作多路複用、分包和資訊的公平性，發送端會把Message劃分為帶有 Message ID的Chunk，每個Chunk可能是一個單獨的Message，
也可能是Message的一部分，在接受端會根據Chunk中包含的data的長度，message id和message的長度把chunk還原成完整的Message，進而實作資訊的收發。
HLS:HTTP Live Streaming(HLS)
是蘋果公司(Apple Inc.)實作的基于HTTP的流媒體傳輸協定，
可實作流媒體的直播和點播 ,主要應用在iOS系
統，為iOS裝置(如iPhone、iPad)提供音視訊直播和點播方案。
HLS 點播，基本上就是常見的分段HTTP點播，不同在于，它的分段非常小。
相對于常見的流媒體直播協定，例如RTMP協定、RTSP 協定、MMS 協定等，HLS 直播最大的不同在于，直播用戶端擷取到的，并不是一個完
整的資料流。
HLS 協定在伺服器端将直播資料流存儲為連續的、很短時長的媒體檔案(MPEG-TS格式)，而用戶端則不斷的下載下傳并播放這些小檔案，
因為伺服器端總是會将最新的直播資料生成新的小檔案，這樣用戶端隻要不停的按順序播放從伺服器擷取到的檔案，就實作了直播。
由此可見，基本上可以認為，HLS 是以>>點播的技術方式來實作直播<<。由于資料通過 HTTP 協定傳輸，是以完全不用考慮防火牆或者代理的問
題,而且分段檔案的時長很短，用戶端可以很快的選擇和切換碼率，以适應不同帶寬條件下的播放。不過HLS的這種技術特點，決定了它的
延遲一般總是會高于普通的流媒體直播協定。
// iOS和 Android 都天然支援這種協定，配置簡單，直接使用 video 标簽即可
***VLS ：是一種流伺服器，專門用來解決流的各種問題，它也具有一些 VLC 的特征。 videolan 作為伺服器可以輸出http，rtp，rtsp的流。
原則上，RTSP，RTMP，HTTP 都可以做直播和點播，但一般做直播用 RTSP和RTMP，做點播用 HTTP。我們選用的是RTMP協定。
各種協定延時及其原因
rtmp和httpflv：這兩種協定大緻資料一緻，是以延時原因都是差不多的。按理說tcp流式傳輸直播因該都是延時極低的，為什麼rtmp和httpflv還有延時呢？原因在h264上，rtmp和httpflv都是傳輸的flv tag，視訊tag的資料平常就是h264資料，h264解碼有個IBP，I是關鍵幀，是一幀完整的圖像，必須要先有個I才能解碼後面的BP，BP幀可以随便少，但是I幀不能少，是以I幀必須是在flv tag傳輸中第二個傳輸的（第一個是h264spspps），但是I幀在h264流裡不是常有的，是隔一段才有個I幀，這個一段的間隔，俗稱GOP，當編碼時候GOP設定很短，當用戶端連接配接上來，伺服器會以最快速度找到流中最近I幀，從I幀開始發送直播資料，然而當GOP很長，I幀間隔很長，或者等待下一個I幀開始向新連接配接發送資料，或者在緩存裡找最近的上一個I幀開始發送，這裡就是rtmp和hls協定延時的關鍵了，在各大cdn平台，叫"rtmp秒開技術"，原理就是将推流資料二次解編碼，設定很小的gop。總的來說，gop設定1s，在不考慮網絡傳輸鍊路延時情況，資料延時最大就為1s，運氣好剛好就是I幀就是0延時！