直播在2016年是一個非常火熱的領域，我也有幸在今年參與了新浪微網誌直播用戶端的開發，在此分享一下關于直播開發的一些經驗。
1.視訊直播的基本原理
視訊直播的過程大概由這麼幾個部分構成：
- 推流端
- 源伺服器
- CDN邊緣節點
- 播放端
直播架構.jpg
整個直播流轉的過程是：推流端将視訊流推向源伺服器，源伺服器對視訊流進行編碼或者轉存，CDN負責負載均衡與緩存，CDN節點從源伺服器擷取視訊流，播放端再從CDN上把視訊流拉下來。
2.不同的直播協定
-
HLS
HLS全稱是Http live stream，是蘋果公司主導的一種直播協定，完全符合http協定标準，Html對其原生進行支援，是以這種協定的優勢就在于無論是在web端，還是iOS端都可以友善快捷的播放HLS的視訊流。HLS協定不僅支援直播還支援點播，廣泛的應用于H5産品當中。
HLS本身請求的是一個m3u8格式的檔案：
#EXTM3U m3u檔案頭，必須放在第一行 #EXT-X-MEDIA-SEQUENCE 第一個TS分片的序列号 #EXT-X-TARGETDURATION 每個分片TS的最大的時長 #EXT-X-ALLOW-CACHE 是否允許cache #EXT-X-ENDLIST m3u8檔案結束符 #EXTINF extra info，分片TS的資訊，如時長，帶寬等裡面儲存了一個一個.ts格式的視訊分片檔案路徑
m3u8.jpg
直播流會首先下載下傳目前生成好的m3u8檔案，再去一個一個下載下傳裡面的分片視訊，是以對于源伺服器來講，生成好了一個m3u8檔案之後，用戶端才可能會拉到這個視訊流，這也造成了HLS協定高延遲的問題。倘若一個m3u8檔案裡面所有的分片長度為10s，那麼用戶端拉到這個視訊流的延遲至少為10s。
-
rtmp
rtmp全稱Real Time Messaging Protocol，是一種基于TCP的資料通信協定，廣泛的被應用于流媒體的傳輸中來，此協定是實時傳輸資料流，是以延遲比HLS要低，由于具備TCP協定的擁塞控制，對資料的完整性有一定保證。與此同時，Adoube對rtmp協定的支援也做的很好，Flash可以完美的支援rtmp協定的視訊流播放，大多數推流端都使用rtmp協定進行推流。
-
http-flv
http-flv是通過http協定傳輸flv的視訊流，HTTP協定中有個content-length字段，規定了請求http的body部分的長度，如果請求的時候不加content-length字段，那麼用戶端會一直受到資料。基于傳輸包的http-flv協定可以将資料包做的比rtmp做的更小，在流量上有比較大的優勢，而延遲幾乎和rtmp相同。
-
UDP
在過去傳統的視訊通話廣泛的基于UDP協定，由于不像以上幾種協定都基于TCP這種帶擁塞控制的協定，UDP可以做到1s以内的超低延遲，在直播中UDP沒有廣泛采用的原因是需要對服務端的架構進行改造，是以對于之前做過視訊通話的廠商來講，他們擁有着得天獨厚的優勢，目前很多網際網路教育廠商由于對超低延遲的需求，基本都采用了UDP協定
3.直播延遲問題
随着視訊直播領域變得越來越火，直播的延遲問題也日趨收到開發者的關注，根據不同也業務需求，廠商對延遲的要求也有所不同，美女秀場直播2~5s之間可以忍受，對于線上教育來講1s左右才能保證正常的教學需求。總體來看，目前影響直播延遲基本有這麼幾種原因：
-
網絡速度
在整個視訊直播流轉的過程中，無論是推流端到源伺服器之間的網速，還是播放端從CDN拉流的速度都影響着整個視訊直播過程的體驗。是以網速往往是直播延遲最至關重要的原因。
-
傳輸協定
在上一節中講到了不同的傳輸協定對延遲的影響，這裡不再贅述。
-
編解碼速度
對于視訊直播來講編解碼的速度，好的編解碼政策也對直播卡頓延遲問題有的很大的影響，下一節我們來從了解H.264編碼的原理上思考如何做一個好的編解碼政策。
4.H.264編碼
H264logo.jpg
我們知道視訊本身是由一張一張的圖檔構成，快速播放起來欺騙我們的眼睛，讓我們覺得圖檔裡面的場景是動态的。但是如果一個1080p的視訊，以60幀的幀率來播放，在視訊完全不壓縮的情況下，将是一個龐然大物，單單其中的一幀圖檔就要好幾M。是以大家發明了很多視訊編碼的來将視訊進行壓縮。壓縮的基本思路就是将視訊中一張一張完整的圖檔，有變化的部分存下來，一樣的部分就隻存一張就好了，去除了備援的部分視訊就會小得多。
我們讓一部分幀儲存了完整的圖檔，對于這種幀我們叫做I幀，如果I幀可以seek，我們将它叫做關鍵幀。兩個I幀之間叫做一個GOP。
隻儲存了變化部分的幀，我們叫做參考幀，其中又分為前向參考幀（P幀）和雙向參考幀（B幀）。參考幀的意思就是根據I幀或者P幀進行參考，決定自己保留圖檔中的哪部分内容。參考幀越多，尤其是B幀越多，這個視訊就越小，因為圖檔保留的部分就越少。
H.264幀排布.jpg
可以看到，B幀需要前後都要參考，雖然更多的B幀可以更好的壓縮視訊的體積，但是對于編解碼也變得更加的困難，因為當我收到一個B幀之後，我必須等到後面有一個P幀或者I幀出現我才能進行解碼，這對于直播的流暢性來講是有影響的。
5.對于直播首幀的優化
-
GOP緩存
對于播放端的解碼器而言，隻有當遇到一個I幀的時候，視訊才可以播放，假設播放端拉流的時候，剛好需要等2s才會遇到下一個I幀，這個播放器就可能會黑2s。是以為了能夠秒開，快速的播放到第一幀視訊，廠商往往會将最近的一個GOP緩存在CDN中，當播放端去拉流的時候，直接把上一個I幀傳下來，保證播放器拉到流直接就可以播放。
-
CDN最近政策
由于CDN負載均衡的政策，CDN會根據目前各個邊緣節點的負載情況來指定用戶端從哪個邊緣節點來拉流，但這樣有可能會導緻播放端走了一個比較遠的路由，進而增加延遲。有的廠商會在播放端密集的地區增加CDN的負載容納量，并且指派就近原則，選取最近而不是根據負載來判斷拉流的路徑。
-
UDP政策
将基于TCP的視訊流協定換成無擁塞控制的UDP。
-
local DNS
由于拉流時的請求位址往往是帶域名的，請求過程中走DNS伺服器有時會耗費一定的時間，可以選用local DNS，在用戶端本地拿到緩存的ip位址直接請求伺服器。