網路直播在近兩年異常火熱，比如我們所熟知的秀場直播平臺（9158、6間房、YY）；遊戲直播平臺（虎牙直播、龍珠直播、熊貓TV）；移動直播平臺（映客）；線上直播購物平臺（菠蘿蜜）；線上教育平臺（百度傳課、淘寶同學）。

由於朋友公司的老總拿到了一大筆投資，準備搭建自己的旅遊直播平臺，本人作為流媒體技術方面的碼農被應招入伍並被委以重任，帶領團隊打造一套自己的網路直播平臺。

經過幾個月的戰鬥最近終於完成了一套完整的直播平臺建設，經歷了太多苦逼的加班和熬夜，但是也得到了不小的收穫，下面就把我這段經歷記錄下來與大家一起分享。

接到領導下達的任務後，幾天內心裡一直忐忑不安。雖然被賦予了大權，但是因為我之前在華為工作時主要負責

 無奈，已經箭在弦上，不得不發了。因此接下來開始做各種構思、技術資訊收集和開發準備工作。

 首先，我還是按照端到端的業務流程來逐個尋找解決方案。

遊戲直播業務流程圖

根據上面的業務流程圖，我們團隊開始按部就班地開始行動。

第一步，PC端視音訊採集

目前最火併且流量最大的遊戲還是端遊，比如英雄聯盟、劍靈、坦克世界、DOTA2、跑跑卡丁車、夢三國、怪物獵人、完美世界、穿越火線、魔獸世界、夢幻西遊、爐石傳說等大型遊戲，需要完美採集PC端的遊戲畫面和音訊，

PC端的影象目前主流的是1080P高清解析度，並且主要是運動畫面，資料量非常大，如何高效地採集到這些資料並且還要實時地進行編碼壓縮，同時要有更高的壓縮效率從而節省平臺端的資料頻寬成本，都是需要詳細考慮的問題。

為了完成這一步，我們詳細比較了多種不同的實現方案，主要有如下幾種：

1）採用目前市面上現成的硬體視訊編碼裝置；

我們測試了多個廠商的裝置，這種裝置通過內建的DSP專用晶片做視音訊處理，實時性很好，但是測試後發現其對運動影象的處理效果不好，編碼後的影象會有比較大的失真，並且壓縮效率低，產生的資料量大。此外，廣播級的硬體編碼裝置單臺價格都在2萬元左右，不適合我們面向個人玩家推廣。

2）通過硬體+軟體的方式來實現；

按照通常視訊會議的應用模式來實現，配置專業的高清視訊採集卡和PC端視訊採集編碼軟體。市場調查後發現，採集卡倒是有很多品牌，單價在1000~3000元不等，並且測試後發現採集的影象效果很不錯。但是難題出現在了PC端軟體上。可以實現這種功能的專業PC端採集編碼軟體屈指可數，深入研究後知道了原因，主要因為這方面涉及的技術層面太專業，這種軟體通常都需要使用C語言來編寫（程式設計難度大），而且要求程式設計師精通當前最主流的視音訊編碼演算法（H.264/H.265/AAC等），同時要精通socket網路程式設計和流媒體協議棧（UDP、RTMP、RTSP、HTTP、HLS），在國內要招聘到這樣的高手真是太難，因為這方面的技術標準制定都是國外主導的，即使可以請到，這種人的月薪估計也在10W左右，並且這種程式的開發週期至少在1年到2年的時間，因此我們研究後決定放棄PC端軟體的自主開發計劃。放棄自主開發不等於說是放棄這種實現方式，因為從整體上來衡量，採用軟體方式實現雖然前期投入大，但是大規模運營時單位終端上的攤銷成本就很低，因為軟體可以無限複製。

軟體的選型是一個費事費力的過程。PC端專業的視訊採集軟體主要有Adobe 的Flash Media Live Encoder，FFMPEG，直播大師，VLC等少數幾款。

A.Adobe的Flash Media Live Encoder測試

首先測試的是Adobe 的Flash Media Live Encoder，這是一款成熟的直播軟體，配合Adobe 釋出的Flash Media Server使用的，軟體穩定性不錯，但是這款軟體的弊端也很明顯：1）它不支援AAC音訊編碼，因為AAC音訊編碼是要向第三方機構購買Licence授權費用的，Adobe出於節省成本的考慮沒有加入這個特性（因為Flash Media Live Encoder是免費的）；2）它的H.264視訊編碼採用CPU來運算，由於H.264編碼演算法很複雜，所以做高清編碼時佔用的CPU資源太高，i5/i7系列CPU做編碼時資源都佔到了50%，這時運動大型遊戲時主機很吃力，經常出現執行不暢和卡頓的現象。解決的方式也很簡單，配置一臺獨立的主機做採集編碼工作，這時增加了5000元的額外開支；3）在直播的同時不能實時存檔錄製MP4檔案格式，只能存檔成FLV格式再用轉碼工具做格式轉換，費時費力而且二次轉碼會降低影象的清晰度；4）不能在直播的同時疊加字幕和臺標；5）Adobe太大牌，人家不願意給我們做定製開發，並且不提供原始碼和開發介面，這點是最要命的。畢竟是做運營，我們希望將伺服器資訊和一些直播預設值寫死到程式中去，同時自行開發它目前沒有的功能，但是人家看不上我們，後來領匯出面去溝通對方將就同意了提供定製化的二次開發，但是要價幾百萬美元，老闆最終決定放棄這款方案。

B.FFMPEG測試

其次我們開始測試FFMPEG的直播客戶端方案，由於FFMPEG這款軟體是開源軟體，如果該方案可用肯定是最優的方案，畢竟可以按自己的意願隨意改造。測試工作進行了半個多月時間，毋庸置疑，這款軟體的功能非常全面，基本上在音視訊處理方面你能想到的功能點它都想到了，國內外做視音訊方面開發的有很大一部分都是基於FFMPEG做二次開發。但是測試後發現，這款軟體的最大弊端是1）穩定性差，動不動就會崩潰或者死掉，無法長時間工作；2）命令列方式操作，沒有直觀的圖形使用者介面，非專業人士不會操作；3）硬體相容性差，無法與第三方硬體裝置的驅動程式進行良好的互動（比如各廠商採集卡驅動）；4）沒有專業的二次開發技術支援，只能自行研究和改進。由於我們的運營專案對上線時間有要求，改造FFMPEG至少需要1年的時間，因此只能將ffmpeg作為一款備選方案。

C.直播大師測試

直播大師是北京順景科技有限公司開發的一款專業直播採集編碼軟體，該軟體拿到手進行測試，給人的第一感覺就是操作簡單，具有圖形化的操作介面，採用所見即所得的設計風格，非常適合非專業人士使用。

接下來我們進行了更詳細的效能測試，測試結果表明，這款軟體是我們在市面上見到的最高效的一款直播採集編碼軟體，它能夠以H.264編碼格式同時編碼6路1080P的視訊，此時的CPU佔用率也只有5% 【CPU型號：i7-4770k】，同時可以將多個輸出碼流推送到多臺伺服器上做冗餘備份。此外，這款軟體支援在本地多種格式的錄製功能【MP4、TS、FLV、MOV、3GP這些常用格式】，支援當今最新的H.265編碼技術【個人認為H.265在不久將會取代H.264成為主流標準】，還支援多種協議的輸出【RTMP、RTSP、UDP、HTTP】。除此之外，該軟體還支援電視臺中常用的實時字幕疊加、臺標疊加、時間戳疊加等實用的功能，以上這些已經完全滿足了我們做遊戲直播這種應用場景的需要。如果產品的穩定性有保障的話，這應該是一款非常好的方案。

接下來我們進行了產品的穩定性測試，按照對方給出的測試環境【i7 CPU/8GB記憶體/1TB SATA/千兆網路/4路高清採集卡】，我們使用該主機在辦公室常溫環境下同時採集編碼4路高清視訊進行測試，不關機運行了2周時間，機器執行一切正常，中間沒有發生過宕機和記憶體增長的情況，執行極其穩定。

再接下來，就是領導和對方在商務上和服務支援方面的溝通。我們本想要對方開放原始碼或者提供介面給我們，然後我們自己增加一些應用功能進去，但是看到對方的產品原始碼後才發現，對方的產品軟體結構很複雜，沒有詳細的軟體開發文件，讓我們很難快速掌握其整體結構脈絡。最終，經過上層領導的溝通協調，對方答應為我們開發個性化的應用功能，開發週期在1.5個月內完成，增加的主要功能包括：1）與我們自身流媒體釋出平臺的繫結，2）使用者登入驗證資訊的繫結，3）通過軟體方式實現遊戲視音訊訊號的採集。第3）個功能對我們的運營平臺意義重大，這樣可以節省下每個終端高清採集卡的硬體成本，對於我們這種大規模運營平臺來說節省的成本非常大。

D.VLC測試

VLC是一款開源的客戶端軟體，具有解碼、編碼和串流等應用功能。本質上，VLC是基於FFMPEG開發的更高階的應用，但是VLC開發團隊自己設計了圖形使用者介面。這款軟體已經持續開發了10多年時間，使用者範圍遍佈全球。因此，我們對其進行了如下幾個方面的測試：

1、功能測試。

由於VLC本身就是基於FFMPEG做的開發，所以功能上還是很強大的，基本上滿足我們的需要。

2、效能測試。

我們用它做H.264的編碼測試，發現它用的是x264這個開源的編碼演算法，通過CPU進行計算，編碼1路1080P的高清視訊CPU資源佔用率達到了50%。

3、易用性測試。

用VLC做播放器使用其使用者體驗效果還是很不錯的，並且提供多種使用者介面可以選擇。作為採集編碼軟體來使用的時候，它的使用者體驗效果很差，操作很不方面，而且也不直觀，如果自己做二次開發改造的話需要花費很大的人力和時間。

4、穩定性測試。

我們使用它進行採集和編碼測試，首先發現其對服務端的協議適配性不是很好，經常有無法推送節目的現象發生。此外，在網路抖動或者短時間中斷的情況下，程式會自動退出，導致直播服務中斷。這些問題我們無法找到原因，官方也沒有專職人員可以提供技術支援，因為整個專案是由一群分佈在世界各地的志願者來維護的。這種花費了10多年時間做的軟體專案，短時間內我們還無法掌握其核心架構和模組功能實現方式。原始碼也非常晦澀難懂。

通過以上測試，我們發現A、B、D這三種方案可行性都很差，因為當前我們在這方面沒有足夠強的開發實力以及充足的開發時間。因此只有C 這款方案最適合我們現實的應用場景。最終領導決定下來採用“直播大師”這款軟體，並在此基礎上做二次開發。

第二步，移動端視音訊採集

除了做PC端遊戲的直播，我們還要做手機端遊戲和戶外場景的直播，因此開發手機端的直播工具軟體勢在必行。

眾所周知，當前主流的兩大手機作業系統就是google的android和Apple的iOS。兩大作業系統的開發語言和開發框架差異很大，android系統採用java語言來做應用層開發，而Apple的iOS系統採用Objective-C語言做開發。兩個平臺具有各自不同的開發介面和特性，兩個平臺上的應用程式沒有任何相容性，因此我們必須組建兩個APP開發小組來完成這件事情。

目標確定了，下面就是技術路線選型工作。

首先，對於手機端的視音訊採集編碼技術，我們有過類似的經驗。考慮到手機的處理能力，我們的技術路線是利用手機自身核心處理器的視訊編碼能力來完成。在Android端呼叫Mediacodec開發介面來實現，iOS端呼叫蘋果提供的Core Video框架來實現，編碼格式上我們採用H.264視訊編碼和AAC音訊編碼，通過硬體編碼方式極大地降低了移動終端的CPU負荷與功耗，。在協議的選擇上，我們採用當前主流的RTMP協議由客戶端向伺服器端推送資料。RTMP是Adobe公司制定的一款流傳輸一些，結構比較簡單，自己研究就能搞定，而且這款協議在行業內應用非常廣泛，便於不同產品的整合。

其次，字幕和臺標的疊加

在PC端，順景科技的直播大師已經具備了專業級的字幕臺標疊加功能，下面考慮的主要是移動端的實現。還好，順景科技在這方面也給我們提供了技術支援，通過渲染技術實現了字幕和臺標的疊加功能。不僅如此，在他們的幫助下我們的移動端軟體還加入了影象美顏功能，支援120多種常見濾鏡效果。

第三步，內容的釋出和轉碼

前端裝置將直播的視音訊內容採集處理後，首先推送給平臺的源站伺服器，我們將源伺服器部署在了北京本地的運營商骨幹節點機房（近距離便於維護）。源伺服器採用多機叢集熱備份機制，防止一臺源站伺服器宕機後影響整個平臺的穩定執行。

源站伺服器連線有專業的磁碟陣列儲存裝置，當源站伺服器接收到資料後，首先複製N份轉發給下面的N個二級CDN節點，同時複製一份給轉碼伺服器。轉碼伺服器將接收到的每一個流進行實時的轉碼，主要是將高清碼流轉換一份標清碼流給小屏移動終端，移動終端接收標清小碼流不僅符合自身的小屏解析度需要，同時可以降低對移動端的解碼能力要求，還能有效節省頻寬成本。

同時，轉碼伺服器將實時的直播碼流錄製儲存到磁碟陣列中，供以後點播回放使用。

在這個實時轉碼環節，我們突然發現之前考慮的欠周到，因為根據我之前在華為做IPTV的經驗，內容的轉碼可以交給高效能的伺服器來完成，之前我們用配置四顆Intel E5系統八核心的處理器來做視訊轉碼，轉碼1080P視訊可以達到8倍速以上。但是當我將之前的技術用於這個專案中測試時發現，我們之前的轉碼技術還是遠遠不能滿足要求。因為我們當前的應用是大併發的直播運營，在同一時間平臺可能要對數百個甚至上千個直播流進行實時轉碼，這樣就需要很多臺高配置的伺服器，這樣很難控制運營成本；此外，直播流的轉碼必須是實時性的，要求轉碼延遲在1秒以內，這和我們之前的2~3秒延遲還是有很大差距的。如果對原有的技術進行改造，這部分的開發週期預計要1年以上，而且還沒有絕對的把我可以達到最好的效果。最後在多方面的嘗試後，我們採用了直播大師廠商順景科技提供的他們自行開發的先鋒雲轉碼方案，因為他們的方案在轉碼效能上不僅有更大的提升（單臺伺服器可以達到1080P 30倍速的轉碼效率），而且他們的轉碼實時性也更強，轉碼延遲可以控制在500ms以內。

第四步，流媒體釋出

流媒體釋出這個環節對於整個平臺來說也是至關重要，因為最終面向終端使用者提供服務的是分佈在全網的流媒體伺服器，流媒體伺服器的穩定性以及效能優劣決定著終端使用者的體驗效果和平臺的運營成本。根據之前做IPTV的經驗，我們在這個專案中選擇的技術路線還是自行開發，當然還是基於之前做IPTV流媒體伺服器的基礎來做，核心技術點又有如下的改進：

1.流媒體伺服器還是採用C語言實現，保障執行效率最高；

2.將之前的多程序模型改成非同步IO模型，提高伺服器的併發處理效能；

3.在協議層上增加對RTMP、HLS協議的支援；

4.引入hadoop這一分散式架構，便於大規模分散式部署、排程和容錯；

通過這些改進，流媒體伺服器的整體效能又會有一個質的飛躍。

這部分開發工作要持續半年多的時間。

第五步，CDN內容分發

這方面是我的業務特長所在，與我之前做IPTV平臺的技術路線相同，主要是對流媒體資料在全網範圍內的多個節點之間進行快速的分發，從而提高終端使用者的體驗效果。

在協議的選擇上，我們根據直播和點播應用的特點，支援RTMP協議、HTTP協議、UDP協議這三個型別。

節點伺服器的建設方面，我們根據國內網際網路的整體佈局，採用中心節點->各省級節點->地市級節點 三級架構模式，把主要的使用者流量首先引導到第三級節點，然後是第二級節點，之所以這樣設計，主要因為越到中小城市，頻寬價格越低，這樣可以極大地節省後期的運營成本。

為了保障平臺執行的穩定性，我們將CDN系統部署在64位Linux伺服器上，與優酷這類大的視訊門戶技術架構相同。

按照公司業務規劃，我們前期先部署一、二級節點，做到每個省會城市都有一個CDN分發節點，每個二級節點有3臺以上的伺服器組成分發叢集。

第六步，終端播放器開發

在終端的解碼回放部分，我們考慮自行開發PC、Android和iOS三個終端的播放器，由於三種終端採用不同的作業系統平臺，因此我們成立了三個開發小組來分別完成，下面講一下技術路線：

PC端：

採用行業內主流的技術路線，基於Adobe的Flash Player做應用層開發，這也是當前最成熟時的技術路線。為了縮短開發週期，我們基於Adobe的OSMF播放器框架來做，開發週期控制在2個月以內比較可行。

Android端：

Android端的播放器開發我們首先考慮到的是終端的解碼效能，因為解碼框架有多個可選，比如FFMPEG、VLC、MediaPlayer API、Exoplayer等，從我們自身的熟悉程度和專案的可控性上考慮，最終決定採用google的Exoplayer做二次開發，開發週期可以控制在2個月以內。

iOS端：

iOS端的播放器也是基於同樣的考慮，我們選擇了蘋果提供的VideoToolbox開發介面，通過它可以直接呼叫蘋果處理器自帶的硬體解碼功能，這樣可以大大降低裝置的功耗，延長電池的續航時間。

經過團隊15個人的艱苦奮戰和N多個的加班熬夜，四個月後平臺原型已經基本宣告完成，雖然在應用功能上還需要進一步完善，但是從效能測試上看，我們的技術路線是正確的，因為整體效能比優酷、樂視這些同行業兄弟站點高出了20%左右，而且資金投入上並沒有高於其他平臺，反而比他們還要低。而且，在整個平臺的架構上，我們還考慮到了向後的相容性和可升級性，比如在整個內容釋出環節我們都支援了H.265視訊編碼標準，雖然現在還未大規模應用起來，但是這個產業鏈在2~3年內應該會有很大的起色，也是未來的主流標準，因為H.265比H.264的壓縮效率提高了一倍，這就意味著採用這項技術不僅能將儲存成本降低一半，還能夠將頻寬消耗降低一半，這無疑會為將來的運營節省大筆開支。

能夠如期完成這樣一個工程，團隊的兄弟姐妹們付出了很多辛勞與汗水，我要為他們點個贊！作為整個專案的技術負責人，取得這樣的成績自己也感到很欣慰，所以要為自己點個贊，哈哈 ~-~

以上就是我做這個直播平臺的一段經歷和收穫的一點點經驗，記錄下來既是對自己的總結，同時也想與各位創業者和同行一起分享，希望對大家有所幫助。如果您有不同的見解，歡迎交流和拍磚！