隨着互聯網視頻化的發展，各類網絡直播產品層出不窮，比如秀場直播、遊戲直播、教育直播、演唱會直播和監控直播等多個直播生態圈。這些生態圈形成的背後，是視頻直播相關技術的不斷髮展，例如互聯網帶寬的日益增加，視頻壓縮標準的日漸完善，視頻雲技術的出現等。
直播涉及到的技術比較多，主要大類有：採集、前處理、音視頻編解碼、流媒體協議、系統架構、CDN、播放控制、交互技術等。
由於是簡單介紹，我也就不全部介紹，挑個平時大家談論比較多的點聊聊。
流媒體協議
直播常用到的流媒體協議有rtmp、http、hls、rtsp。
下面簡單說一下這幾種協議的優劣：
| 協議名稱 |
優勢 |
劣勢 |
| rtmp |
● 實時性高：一般能做到3秒內。 ● 支持加密：rtmpe和rtmps爲加密協議。 ● 穩定性高：在PC平臺上flash播放的最穩定方式是rtmp，如果做CDN或者大中型集羣分發，選擇穩定性高的協議一定是必要的。 ● 一般主流編碼器都支持該協議。 |
● 協議複雜：開發者寫起來累，效率也不行。 ● Cache麻煩：流協議做緩存不方便。 |
| http |
● 性能很高：http的性能好，協議簡單，高性能服務器也完善。如果分發的量特別大，譬如點播視頻網站，沒有直播的實時性要求，http協議是最好選擇。 ● 沒有碎片：http相比hls沒有碎片。 ● 穿牆：http協議是互聯網唯一肯定會開放的協議，所以不存在封端問題。 |
● 實時性差：延遲10s起步。 ● 原生支持不好：PC上flash對於http流支持還可以，但是移動端對於http的支持不是很完善 |
| hls |
● 性能好：和http一樣。 ● 穿牆：和http一樣。 ● 原生支持很好：iOS上支持完美，Android上支持差些。PC/flash上現在也有各種as插件支持HLS。 |
● 實時性差：與ts切片長度有關，大約3個切片長度時間的延遲，基本上HLS的延遲在10秒以上。 ● 文件碎片：若分發HLS，碼流低，切片較小時，會導致太多的文件碎片 |
| rtsp |
● 延遲低，一般都能夠做到500ms。 ● 帶寬好，時效率高。 ● 倍速播放，主要是回放的時候提供的功能。 ● 控制精準，任意選擇播放點。 |
● 服務端實現複雜。 ● 代理服務器弱：數量少，優化少。 ● 無路由器防火牆穿透 ● 管流分離：需要1-3個通道。 |
看了以上這些協議，想必各位都注意到了一個問題，那就是“延遲”。所有的協議裏都有延遲，延遲最低的也有500ms。那麼爲什麼會出現這樣的情況呢？接下來，簡單和大家說一說“延遲”。
簡說延遲
在這裏簡單說一下rtmp和rtsp的延遲，我們先談rtmp的延遲。圈內有人整理了一張直播延遲（rtmp的）的圖片，我直接上個真相。
看完上圖你大概就能明白了，rtmp的延遲是和gop掛鉤的。
那麼，爲什麼rtsp延遲會比rtmp低呢？因爲，它是精確控制的，可以跳出這個以gop組爲單位的控制。
rtsp延遲已經是上述四個協議裏最低的了，那麼延遲還有降低的空間嗎？
如何降低延遲時間
我們公司經過多次測試，發現udp直接發裸流,可以將延遲控制在80ms到170ms的範圍內。
既然udp直接發裸流延遲那麼低，爲啥不流行？
原因很簡單， udp是個不可靠傳輸、丟包、亂序。而且直接裸流穩定性也差，兼容性更不用談，沒有編碼器跟你對接。這就是一個鋼絲上騎自行車的活，高難度動作，能幹這行的，必須得是藝高人膽大。
直播涉及到的技術非常多，本文主要簡單介紹了直播中用得比較多的幾種協議。而對於流媒體的傳輸，現在出現了越來越多的私有協議，這些私有協議一般延遲都比較低，比如大家平時用的微信視頻，就不屬於流媒體。延遲的話，相信大家也都用過，比rtsp的500ms顯然低很多。但通常來說，這些私有協議都只支持端，不能用於web開發，因爲一般協議，都是用c/c++寫的socket通信。
總結
就直播發展而言，最近幾年的直播發展勢頭，用“迅猛”形容絕不爲過。自14年習近平主席提出“網絡強國”戰略和李克強總理提出了“互聯網+”的新思路新理念後，各大小直播平臺如雨後春筍般涌現，甚至2016年被授予了一個特殊稱號----“網絡直播元年”。2017年2月19日，央視新聞移動網正式上線，爲廣大記者打造了移動直播系統——“正直播”。這些都標誌着大數據時代、新媒體時代已經到來，媒體行業將面臨新一輪的挑戰和轉型，這將是傳媒史上一次對新聞直播技術的革新，也將成爲新聞直播樣態的一次革命性創舉。
附流媒體技術圖
（直播技術圖，來源：CSDN）
聯繫我們，掃碼關注微信公衆號
