轉載
原文地址：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延時！