?

如何快速搭建運營級的網絡直播平臺

?

網絡直播在近兩年異常火熱，比如我們所熟知的秀場直播平臺（9158、6間房、YY、花椒）；移動直播平臺（映客）；在線直播購物平臺（菠蘿蜜）；在線教育平臺（百度傳課、淘寶同學）。

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

?

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

?

接到領導下達的任務后，幾天內心里一直忐忑不安。雖然被賦予了大權，但是因為我之前在華為工作時主要負責IPTV流媒體平臺部分，現在將整個端到端的解決方案都要我來掌控和負責，真切感受到了什么叫“肚子里的墨水還是太少”。因為這個平臺的確比IPTV還要復雜，不僅包括流媒體內容分發平臺，還包括多種前端設備的采集編碼（PC終端、Android和iOS移動終端），多節目源的導播切換、臺標和字幕的疊加，視頻彈幕，多分辨率視頻的實時轉碼，多播放終端的節目流適配，多終端的硬件解碼，移動APP的開發，互動功能的開發等等一系列工作。所有這些，都需要自己親自去實現。而在之前的IPTV應用中，前端編碼有現成的編碼硬件實現，終端解碼也有N多種現成的機頂盒支持。?

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

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

游戲直播業務流程圖

?

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

第一步，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的FlashMedia Live Encoder測試

首先測試的是Adobe的FlashMedia Live Encoder，這是一款成熟的直播軟件，配合Adobe發布的FlashMedia Server使用的，軟件穩定性不錯，但是這款軟件的弊端也很明顯：1）它不支持AAC音頻編碼，因為AAC音頻編碼是要向第三方機構購買Licence授權費用的，Adobe出于節省成本的考慮沒有加入這個特性（因為FlashMedia 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內存/1TBSATA/千兆網絡/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平臺架構

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

第六步，終端播放器開發

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

PC端：

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

Android端：

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

iOS端：

iOS端的播放器也是基于同樣的考慮，我們選擇了蘋果提供的VideoToolbox開發接口，通過它可以直接調用蘋果處理器自帶的硬件解碼功能，這樣可以大大降低設備的功耗，延長電池的續航時間。

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

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

?

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

總結

以上是生活随笔為你收集整理的如何搭建运营级的网络直播平台的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。