參考
【騰訊Bugly乾貨分享】從0到1打造直播 App從入門到出家：流媒體協議—FLVH5直播起航全面進階 H5 直播HTML5 視頻直播（一）HLS 和 RTMPHTML5 視頻直播（二）Web Sockets+CanvasHTML5 視頻直播（三）WebRTC直播伺服器簡單實現 http_flv和hls 內網直播桌面RTMP、RTSP、HTTP視頻協議詳解（附：直播流地址、播放軟體）帶你吃透RTMP[總結]RTMP流媒體技術零基礎學習方法直播雲解決方案整理直播未來屬於RTMP還是HTTP？Paste_Image.png
一、HLS
HLS （HTTP Live Streaming）, 是由 Apple 公司實現的基於 HTTP 的媒體流傳輸協議。Apple 的全系列產品支持，由於 HLS 是蘋果提出的， 所以在 Apple 的全系列產品包括 iphone、 ipad、safari 都不需要安裝任何插件就可以原生支持播放 HLS， 現在Android 也加入了對 HLS 的支持。但PC端目前除了Microsoft Edge外，Chrome、Firefox等瀏覽器均不支持該協議的播放。可直接採用網上一些比較成熟的方案，如：sewise-player、MediaElement、videojs-contrib-hls、jwplayer。
對於支持 HLS 的瀏覽器來說，直接這樣寫就能播放了：
<videocontrolsautoplay> <sourcesrc="http://live.hkstv.hk.lxdns.com/live/hks/playlist.m3u8"type="application/vnd.apple.mpegurl"/> <pclass="warning">Your browser does not support HTML5 video.</p> </video>
以上測試地址參考
m3u8直播測試地址，或者
APPLE提供測試地址HLS 的基本原理就是當採集推流端將視頻流推送到流媒體伺服器時，伺服器將收到的流信息每緩存一段時間就封包成一個新的 ts 文件，同時伺服器會建立一個 m3u8 的索引文件來維護最新幾個 ts 片段的索引。當播放端獲取直播時，它是從 m3u8 索引文件獲取最新的 ts 視頻文件片段來播放，從而保證用戶在任何時候連接進來時都會看到較新的內容，實現近似直播的體驗。相對於常見的流媒體直播協議，例如 RTMP 協議、RTSP 協議等，HLS 最大的不同在於直播客戶端獲取到的並不是一個完整的數據流，而是連續的、短時長的媒體文件，客戶端不斷的下載並播放這些小文件。這種方式的理論最小延時為一個 ts 文件的時長，一般情況為 2-3 個 ts 文件的時長。HLS 的分段策略，基本上推薦是 10 秒一個分片，這就看出了 HLS 的缺點：
通常 HLS 直播延時會達到 20-30s，而高延時對於需要實時互動體驗的直播來說是不可接受的。
HLS 基於短連接 HTTP，HTTP 是基於 TCP 的，這就意味著 HLS 需要不斷地與伺服器建立連接，TCP 每次建立連接時的三次握手、慢啟動過程、斷開連接時的四次揮手都會產生消耗。
不過 HLS 也有它的優點：
數據通過 HTTP 協議傳輸，所以採用 HLS 時不用考慮防火牆或者代理的問題。
使用短時長的分片文件來播放，客戶端可以平滑的切換碼率，以適應不同帶寬條件下的播放。
HLS 是蘋果推出的流媒體協議，在 iOS 平臺上可以獲得天然的支持，採用系統提供的 AVPlayer 就能直接播放，不用自己開發播放器。
HLS有一個非常大的優點：HTML5可以直接打開播放；這個意味著可以把一個直播連結通過微信等轉發分享，不需要安裝任何獨立的APP，有瀏覽器即可，所以流行度很高。社交直播APP，HLS可以說是剛需
以下參考
直播協議 HTTP-FLV 詳解這裡首先要說一下，HLS其實是一個「文本協議」，而並不是一個流媒體協議。那麼，什麼樣的協議才能稱之為流媒體協議呢？
流（stream）：數據在網絡上按時間先後次序傳輸和播放的連續音/視頻數據流。之所以可以按照順序傳輸和播放連續是因為在類似 RTMP，FLV協議中， 每一個音視頻數據都被封裝成了包含時間戳信息頭的數據包。而當播放器拿到這些數據包解包的時候能夠根據時間戳信息把這些音視頻數據和之前到達的音視頻數據連續起來播放。MP4，MKV等等類似這種封裝，必須拿到完整的音視頻文件才能播放，因為裡面的單個音視頻數據塊不帶有時間戳信息，播放器不能將這些沒有時間戳信息數據塊連續起來，所以就不能實時的解碼播放。
二、MPEG DASH(Dynamic Adaptive Streaming over HTTP)
參考
MPEG-DASH 流媒體技術介紹（上）MPEG-DASH 流媒體技術介紹（中）MPEG-DASH 流媒體技術介紹（下）MPEG DASH 和 HLS1.在基於HTTP提供流媒體的方面，到目前為止已經看到了三種方案，蘋果的HLS，Adobe HTTP Dynamic Streaming (HDS)和Microsoft Smooth Streaming (MSS)，當然，各家用的協議，格式神馬的都不會一樣。於是每次做支持都要來三人份的。看到這三倍工作量，再想想老闆不給加工資，碼農們的心都寒了...MPEG的同志們體察到了這份疾苦，呼籲大家來個標準點的玩意唄，於是就有了MPEG DASH 。
這裡有一篇綜述，寫的比我好還圖文並茂的，去那看吧～
2.B站在2018.8.2發布的
我們為什麼使用DASH中提到以後點播會使用DASH方案，直播因為延遲問題仍然使用FLV(評論回覆中有提到)
文中有提到B站二壓，這個可以參考
【教程向】教你怎樣壓製出「B站直傳「的清晰視頻DASH，又叫MPEG DASH，DASH：Dynamic Adaptive Streaming over HTTP ，是一種在網際網路上傳送動態碼率的Video Streaming技術，類似於蘋果的HLS，DASH會通過media presentation description (MPD)將視頻內容切片成一個很短的文件片段，每個切片都有多個不同的碼率，DASH Client可以根據網絡的情況選擇一個碼率進行播放，支持在不同碼率之間無縫切換。YouTube採用DASH。其網頁端及移動端APP都使用了DASH。DASH的其他採用者包括：Netflix, Hulu。
DASH是由MPEG (Moving Picture Experts Group)組織制定，2010年開始啟動，2011年11月發布Draft版本，2012年4月發布第一稿Version（ISO/IEC 23009-1:2012），2014年5月發布第二稿（ISO/IEC 23009-1:2014），最新稿（ISO/IEC 23009-3:2015）。
目前3GPP Release 10已經將DASH納入其中；在HbbTV 1.5中也支持DASH；DVB-DASH也將DASH納入到DVB（ETSI TS 103 285 v.1.1.1）。目前DASH Industry Forum由發起廠家組成，致力於推進DASH產品生態，將DASH產業化和業界最佳實踐推向批量應用。
15年的B站我們使用整段的FLV和MP4，這種方案的好處是簡單且兼容性高，抖音與今日頭條就是用該方案。但缺點也很明顯，隨著視頻時長的增長，整段的MP4的頭部過於複雜，體積過於龐大，導致拉取與加載極為緩慢。
16年的B站為了規避這個問題，使用了分段的FLV來提升加載速度，這種方案的好處是視頻頭部小，加載速度高。愛奇藝和優酷也使用類似方案。這種方案簡單且兼容性高，而且與直播流統一了格式，所以一直沿用至今，中間由於flv.js的出現 ，把這種方案帶向了全平臺。
但隨著用戶的增加，用戶的網絡種類和情況也變得更加複雜，如果我們需要在各種場景下都需要給用戶較好的體驗，我們需要選擇一種能在不同網絡下都能流暢播放的方案。我們需要引入Dynamic Adaptive Streaming/ Bitrate 技術，以進一步提升用戶體驗。我們也需要對多音軌和多視頻軌
在評估了一些行業內使用的方案後，我們選中了DASH，DASH也可以更靈活的實現用戶與產品的新增需求。
image.png
image.png
對於普通看視頻的用戶，我們期待部署Dash有以下改進：
觀看視頻更為流暢，如下圖所示，我們會在網速不佳時無縫切換至較低清晰度視頻，在網速充足時無縫切換至高清晰度視頻，切換過程對於用戶無感。
可以很容易的支持音頻模式，滿足聽相聲/音樂的你
在退到後臺後，可以自動切換至只拉取音頻，更節省你的流量，播放更加流暢。(恢復回來可能黑屏，所以上傳視頻時，會做GOP對齊，並嘗試將GOP縮減到5s)
可以很容易的支持視頻新增多音軌，多視頻軌，多字幕軌的任意切換 ，原聲，中配，多版本字幕任君選擇。
3.兼容性
參考
新時代的點播與直播wikipedia DASHWhy YouTube & Netflix use MPEG-DASH in HTML5MSE(
Media Source Extensions)是目前Youtube使用的DASH的基礎。
image.png
dash.js是Dash行業論壇官方參考和生產播放器。
shaka-player是出自Google的開源dash播放器。
三、RTMP
RTMP協議是Real Time Message Protocol(實時信息傳輸協議)的縮寫，它是由Adobe公司提出的一種應用層的協議，用來解決多媒體數據傳輸流的多路復用（Multiplexing）和分包（packetizing）的問題。
使用RTMP技術的流媒體系統有一個非常明顯的特點：使用 Flash Player 作為播放器客戶端，而Flash Player 現在已經安裝在了全世界將近99%的PC上，因此一般情況下收看RTMP流媒體系統的視音頻是不需要安裝插件的。用戶只需要打開網頁，就可以直接收看流媒體，十分方便。
相對於 HLS 來說，採用 RTMP 協議時，從採集推流端到流媒體伺服器再到播放端是一條數據流，因此在伺服器不會有落地文件。這樣 RTMP 相對來說就有這些優點：
延時較小，通常為 1-3s。
基於 TCP 長連接，不需要多次建連。
因此業界大部分直播業務都會選擇用 RTMP 作為流媒體協議。通常會將數據流封裝成 FLV 通過 HTTP 提供出去。但是這樣也有一些問題需要解決：
iOS 平臺沒有提供原生支持 RTMP 或 HTTP-FLV 的播放器，這就需要開發支持相關協議的播放器。
實例
最簡單的基於Flash的流媒體示例：RTMP推送和接收（ActionScript）Paste_Image.png
public function simplest_as3_rtmp_player() { nc =newNetConnection(); nc.addEventListener(NetStatusEvent.NET_STATUS, netStatusHandler); nc.connect("rtmp://localhost/live"); } private function netStatusHandler(event:NetStatusEvent):void { trace("event.info.level: "+event.info.level +"\n", "event.info.code: "+event.info.code); switch(event.info.code) { case"NetConnection.Connect.Success": doVideo(nc); break; case"NetConnection.Connect.Failed": break; case"NetConnection.Connect.Rejected": break; case"NetStream.Play.Stop": break; case"NetStream.Play.StreamNotFound": break; } } // play a recorded stream on the server private function doVideo(nc:NetConnection):void{ ns =newNetStream(nc); ns.addEventListener(NetStatusEvent.NET_STATUS, netStatusHandler); video =newVideo(640,480); video.attachNetStream(ns); ns.play("myCamera"); addChild(video); }
四、HTTP-FLV協議：
即使用HTTP協議流式的傳輸媒體內容。相對於RTMP，HTTP更簡單和廣為人知，而且不擔心被Adobe的專利綁架。內容延遲同樣可以做到2~5秒，打開速度更快，因為HTTP本身沒有複雜的狀態交互。所以從延遲角度來看，HTTP-FLV要優於RTMP。
http_flv&rtmp這兩個協議實際上傳輸數據是一樣的，數據都是flv文件的tag。http_flv是一個無限大的http流的文件，相比rtmp就只能直播，而rtmp還可以推流和更多的操作。但是http有個好處，就是是以80http通信的，穿透性強，而且rtmp是非開放協議。這兩個協議是如今直播平臺主選的直播方式，主要原因就是延時極低。
以下參考
直播http-flv小調研HTTP協議中有個約定：content-length欄位，http的body部分的長度
伺服器回復http請求的時候如果有這個欄位，客戶端就接收這個長度的數據然後就認為數據傳輸完成了，如果伺服器回復http請求中沒有這個欄位，客戶端就一直接收數據，直到伺服器跟客戶端的socket連接斷開。
http-flv直播就是利用第二個原理，伺服器回復客戶端請求的時候不加content-length欄位，在回復了http內容之後，緊接著發送flv數據，客戶端就一直接收數據了。
五、其它
1.直播整體流程大致可分為：
視頻採集端：可以是電腦上的音視頻輸入設備、或手機端的攝像頭、或麥克風，目前以移動端手機視頻為主。
直播流視頻服務端：一臺Nginx伺服器，採集視頻錄製端傳輸的視頻流(H264/ACC編碼)，由伺服器端進行解析編碼，推送RTMP/HLS格式視頻流至視頻播放端。
視頻播放端：可以是電腦上的播放器（QuickTime Player、VLC），手機端的native播放器，還有就是 H5 的video標籤等，目前還是以手機端的native播放器為主。
2.以下參考
基於rtmp協議等的流媒體伺服器是否可以被取代flash已經死了，但是在手機平臺上還是有很多人用C++來解析rtmp協議做直播流。因為對比其他直播流協議，rtmp的實時延遲可以做到1秒以內。hls的延遲基本有10秒左右。幾年前，我做過一個菲律賓賭場的直播APP，賭場的荷官發牌，然後客戶端同時顯示開牌信息，如果不同步或者超過1秒內的延遲，會給用戶一種作弊的感覺。使用rtmp，就算在美國看這個直播，延遲也是在1秒以內。找了很多視頻直播協議，實時性最好就是rtmp，暫時找不到能代替rtmp的協議。
3.以下參考
前主流視頻網站視頻點播都是使用的哪些協議幾乎所有主流直播平臺網站幾乎都是主線路為cdn提供的httpflv，其他線路大部分都是rtmp。上面有人說httpflv的延遲比rtmp高一點，那是瞎扯，httpflv理論延時至少是與rtmp差不多的。至於HLS，我以前倒是在web上見到過，只不過現在沒見到了，幾乎都是rtmp+httpflv。至於hls相對rtmp及httpflv的優點，我想僅僅是能夠html5播放，僅此而已，hls本身有很多不好的設計，比如ts文件，ts文件是不停的在http請求，這就相當於http和長連接的區別，不僅帶來伺服器的資源消耗，還有http報文頭一堆冗餘信息。這對流媒體直播那金貴流量費來說，這不不是一個好選擇。hls還有個致命的問題，那就是延時，本身就是分文件塊傳輸的，延時自然比rtmp高出許多。如果將hls的ts文件縮小，或許稍許降低延時。但hsl真的不是面向大眾直播的第一選擇。