專訪劉岐：直播技術看似門檻低，裡頭的門道卻不少

2017年我國直播市場營收達到304.5億元，相比2016年的218.5億元，同比增長39%。在眾多玩家爭搶賽道的時候，你是否思考過到底是什麼在推動其前行？手機的普及、流量資費的下降、網路環境不斷改善……除了這些客觀因素之外，直播技術的發展沉澱也是很重要的原因。

發展至今，直播平臺中普遍存在著哪些問題？如何從技術層面來解決這些問題？想要入坑直播技術領域的初學者應該做好哪些技術儲備……帶著疑問，我們採訪了SACC 2018影片直播平臺的架構設計實踐專場出品人、OnVideo聯合創始人劉岐。

劉歧，OnVideo聯合創始人、ChinaUnix資深版主、FFmpeg Maintainer。2007年開始做圖形影像處理，之後接觸了雲端儲存開發、雲轉碼系統設計與開發，並從此轉戰音影片技術領域。先後任職於藍汛，高升，金山雲等公司，目前是創業公司OnVideo的聯合創始人，主要負責新技術的調研以及FFmpeg原始碼的維護。

直播最怕卡頓？解決卡頓死結要從這12個方面入手

看直播最怕的是什麼呀？當然是卡頓了，卡一秒，你就只能無奈得對著滿螢幕的“666”和“233333”，完全不知道發生了什麼事。為什麼直播會發生卡頓呢？難道僅僅是因為網不好嗎？對此，劉岐表示導致卡頓的因素有很多，比較典型的是以下12種：

• 影像採集耗時超過預期

• 編碼耗時超過預期

• 封裝也就是mux耗時超過預期

• 傳輸傳送耗時超過預期

• 網路質量低於預期

• 傳輸接收耗時超過預期

• 解封裝也就是demux耗時超過預期

• 解碼耗時超過預期

• 影像render超過預期

• 時間戳異常

• 播放端接收，解封裝，解碼buffer過小

• 封裝不標準

既然已經找到了直播卡頓的因素，接下來就是解決卡頓問題了。“解決直播系統卡頓問題最關鍵的不是經驗，也不是既有技術，而是處理問題的邏輯。” 劉岐這樣認為，“首先要排除程式異常，判斷時間戳是否異常，接著判斷是否網路丟包或者擁塞導致卡頓，然後對採集、編碼、封裝、傳送逐級排查，如果傳送端沒有問題，接下來就是從接收端的接收、解封裝、解碼、render逐級排查。”

秒開、延遲、破圖……直播技術的門道可不少

對於使用者來說，可能覺得直播平臺最直觀的痛點就是卡頓，但是站在開發者的角度，想要建立一個好的直播系統，遇到的難題可遠不止卡頓，例如秒開問題、累積延遲問題、破圖問題，如果是雙向實時直播的話，還會涉及到回聲問題、嘯叫問題、空音問題等。

秒開已經成為了直播界的標配，我們以秒開為例來一窺直播技術中的門道。想要做到秒開，端到端的每個節點都不能疏忽，推流端的編碼引數設定，例如控制幀率、關鍵幀間隔、幀排列情況等；伺服器端對音影片包的控制，時間戳的控制，buffer的控制，GOP的控制，預快取GOP；播放器顯示首畫的因素，例如根據buffer閥值顯示，根據幀數閥值，關鍵幀閥值，音影片資料包對齊等。

除了考慮流媒體方面的因素，秒開還要考慮其它方面的因素，如果使用了域名服務，要考慮域名解析耗時（預解析域名，重新整理域名熱度）；如果有排程系統，要考慮排程系統耗時(儘量避免多次排程）；同時還要考慮播放器訪問到的伺服器節點的網路質量。

目前直播平臺還沒有一個比較通用的技術架構，但受GitHub的影響以及ffmpeg、gstreamer、JavaCV、 OpenGL等技術的發展成熟，只要有一家公司推出了新功能，其它家就能立馬跟上，所以從整個行業發展來看，想要獲得競爭優勢，就必須要有業務創新，而且不能只是快速的“微創新”，“微差異化”，而是要持續創新。

寫給初學者，直播技術真的只是看起來門檻低

直播產業三百多億的市場規模不僅讓創業者心動，也深深的吸引著技術人，他們認為直播技術沒啥難的，做直播server就是在做直播技術了，但事實真是如此嗎？

“直播技術真的只是看起來門檻低，一旦你實際去做了，就會發現其中有各種各樣的坑。”劉岐表示，直播要求技術全面，排程系統、日誌系統、網路、安全、儲存、編解碼等相關技術都要信手拈來，尤其是有些系統無法使用SRS/NginxRTMP/BIND9/ELK輕易搭出來，還需要自己去開發的。

坑這麼多，如何去填呢？別急，2018年10月17日~19日，由IT168旗下ITPUB企業社群平臺主辦的第十屆中國系統架構師大會（SACC2018）將推出“影片直播平臺的架構設計實踐”專場。作為該專場的出品人，劉岐也透露：“這次專場涵蓋了從整體的架構設計、業務設計到具體的細節最佳化和某個問題解決，相信每個參會者都能從中有所收穫。”

影片直播平臺的架構設計實踐專場日程如下，快速報名！

搶票入口：  http://sacc.it168.com/goupiao.html

大會官網：  http://sacc.it168.com