如何搭建一個完整的視頻直播系統？

01-05

朋友打算打造一個全新模式的視頻直播平台，主要功能有些類似現在很多的美女直播平台。假設前期同時在線觀看人數為2W人，清晰度不低於720P，擁有美顏、混音等附加功能，還有最重要的不能卡頓。如果以上假設成立，需要做哪些準備工作，技術門檻有多高，資金支出要多少？

視頻直播，可以分為採集，前處理，編碼，傳輸，解碼，渲染這幾個環節，下面分別說下：

採集，iOS是比較簡單的，Android則要做些機型適配工作，PC最麻煩各種奇葩攝像頭驅動，出了問題特別不好處理，建議放棄PC只支持手機主播，目前幾個新進的直播平台都是這樣的。

前處理，現在直播美顏已經是標配了，80%的主播沒有美顏根本沒法看。美顏演算法需要用到GPU編程，需要懂圖像處理演算法的人，沒有好的開源實現，要自己參考論文去研究。難點不在於美顏效果，而在於GPU佔用和美顏效果之間找平衡。GPU雖然性能好，但是也是有功耗的，GPU佔用太高會導致手機發燙，而手機發燙會導致攝像頭採集掉幀，可能原因是過熱會導致CPU降低主頻。

編碼，肯定要採用硬編碼，軟編碼720p完全沒希望，勉強能編碼也會導致CPU過熱燙到攝像頭。硬編碼兼容性又是一個大坑，android上要有人去填。編碼要在解析度，幀率，碼率，GOP等參數設計上找到最佳平衡點。

傳輸，自己做不現實，交給CDN服務商吧，也就是貴了點，相信有志於做直播平台改變世界的你不差錢。假設2W PCU大約每月帶寬費用100萬左右，因為清晰流暢的720p要1.5mbps左右。CDN只提供了帶寬和伺服器間傳輸，發送和接收端的網路連接抖動緩衝還是要自己寫的。不想要卡頓，必然要加大緩衝，會導致延遲高，延遲高影響互動性，要做權衡。

解碼，也肯定要硬解碼，目前手機普遍支持硬解了，只是android上還是有兼容性大坑要填。

渲染，這個難點不在於繪製，而在於音畫同步，目前幾個直播做得都不好。

此外音頻還有幾個坑要填，比如降噪，音頻編碼器的選擇，各種藍牙耳機，各種播放模式的適配等，如果你想做主播和觀眾連線聊天，還有個回聲消除問題。

以上是媒體模塊，還有信令控制，登錄、鑒權、許可權管理、狀態管理等等，各種應用服務，消息推送，聊天，禮物系統，支付系統，運營支持系統，統計系統等。

後台還有資料庫，緩存，分散式文件存儲，消息隊列，運維繫統等。

這些顯然不是一個程序員能解決的，如果真的有這樣的高手，請聯繫我，無論你現在薪水多少，我都出兩倍。

第一期至少要融資2000萬RMB，組建至少10人的技術團隊，10人的產品運營團隊，爭取3個月產品上線，半年達到5W在線（2w 根本不夠）然後融資1個億，或許還有希望一搏。

也許有人對帶寬問題存疑，請參考歡聚時代15年四季度財報，帶寬成本為人民幣1.611億元，摺合每月5000+萬，當然不能用這個數去推算在線人數，因為YY採購量很大所以帶寬平均成本低，而且YY不只是高清直播，還有很大比例的500kbps左右碼率的直播，還有相當一部分帶寬是靠P2P解決的。總之帶寬非常貴。

祝你朋友好運。

技術點大家都回答的很詳細了，我就我覺得視頻直播系統中的一些難點再和大家分享下。

兩年前我在做媒體雲的時候，當時都是點播的業務。做到後面，我覺得點播業務其實並不像想像的那麼難，你想你有一個穩定的存儲，找一家靠譜的 CDN，然後找一個大概能用的播放器就做出來了，這有什麼難的呢？你可以找雲服務公司，也可以找外包，或者你自己招一個人都能做。但是現在發現到了移動，尤其是 3月份移動直播火起來之後，這個門檻突然變高了。因為內容產生方變成了移動端。從幾個點來分析下為什麼：

1 、首先內容產生方就是推流端，現在主流的 IOS、安卓，IOS比較簡單，就是那個幾個機型，基本大家適配都很好。但是安卓的碎片化是非常嚴重的，大量的精力都需要做對安卓的適配，而且軟編耗電量普遍非常高，手機用了一會就會發燙，都擔心會不會爆炸。用戶體驗就是在不同的網路情況下，上傳的視頻有可能會卡，有可能不連貫，報各種各樣的錯誤，這個是作為一個開發者他自己不可能去適配的。說白了從用戶那邊提的需求就是推流端不能卡，畫質要好，不能太燙，這是我們接觸到的客戶真正提的問題，是我們從有點偏技術的角度抽取出來的，它背後對應的是哪些事情。

2 、然後是分發網路。分發網路其實躲在一個很後面的地方，用戶其實看不見的。真正對分發網路提需求用戶也提不出來，所以基本這部分需求都會提給播放端，提的需求也是不能卡，不能花屏，首屏一定要快，一點就要看到，還不能把延時弄的太大。其實這些很多都是和源站分發網路有關係的，只是用戶看不到這個需求會跟後面的播放器接在一起。

像首屏時間，就是用戶點開就要看，以前那些開源架構就是 rtmp server，它是做不到一點開就能看的，現在一些開源的國內資源寫得也比較好了，可以看到。我們是自己開發的，所以也花了一些工作，能保存之前的關鍵幀的信息，用戶一點開就能看，這個就是很細節的東西了。如果這個做不好的話，會黑屏、綠屏，或者是半天看不著圖像。

3、在播放器這邊也是我們在接業務的時候，遇到用戶投訴最多的，因為所有的問題都是在觀看的時候體現的，所有的雷都得是播放器的同學去扛。這個需求也是不能卡，不能延遲太高。如果延遲高了，要追回來，追的時候聲音不能變，最好是追的策略也能自己控制，這是用戶真正提出來的需求。

要滿足這些需求，我們需要做好多解析度的適配，保證好流暢性，保證好我們追趕的策略不會出現任何異常。所以這三個端很多是相互耦合的，像推流和分發在一起，要保障好用戶的流暢性和畫質，分發和播放器在一起要保證好低延時和播放的流暢。所有的這些需求里共同的一點就是不能卡頓。

這個是我們的系統架構圖。最下層是依託金山的雲服務，因為我們已經有了很好的平台，提供了我們計算資源，提供了存儲，提供了很多自建的節點，當然還不夠多，我們還是個融合 CDN，然後提供了數據分析的能力。我們依託它做了橙色的這一層，就是我們自己的核心，流媒體直播，然後圍繞這個核心我們在做的回看點播、在線轉碼、鑒權、內容審核。

1.回看點播：因為這不是一個短視頻錄播的項目，而是一個直播，直播就決定它的並發不會很高，內容不會很多，熱點比較少。如果你不回看的話，用戶很難維持它的日活，很難維護用戶黏度，所以用戶一定會要求做回看的。

2.在線轉碼：推流端其實做了很多把更好的畫質想盡辦法傳上來的工作，投了很多人力來做。傳上來之後，觀看也在移動端，它不一定看得了。如果他看不了怎麼辦？我們就需要在線轉，在線轉碼其實承擔的更多更重要的事情。

3.鑒權：用戶都不想被盜鏈，尤其是推流的時候，如果我不鑒權，誰都可以來推。所以這是必須要有的

4.內容審核：現在我們沒有辦法幫他做到自動審核，技術還不夠。現在做到的是截圖，按用戶指定的時間定期截圖，這樣的話，用戶就可以請一些外包來看是不是有敏感內容，是不是要下線，這個對於現在這種三四秒延遲的直播來說非常重要。你做不到的話，沒準政策因素你就做不下去了。

5.數據分析：一部分是依託金山已有的，一部分是我們自己做的，因為我們延遲性，時效性要求更高。客戶會經常大半夜突然提出一個主播看起來特別卡，問你為什麼，要是像以前那種方式，一個小時生成報表，然後出體驗圖，告訴他為什麼卡了，客戶可沒有這個耐心。我們現在基本能做到5秒間隔就出之前的各種問題定位，這個定位包括從源站收集的數據畫的曲線。還有從端上，如果端上用戶允許的話，推流和拉流端我們都會有上報數據，幾個曲線一擬合，我們就知道問題出在哪裡。

利息相關：金山雲架構師。

謝邀。剛剛接手全民TV 的研發團隊不久，短期內還在瘋狂填坑，在我看來，視頻直播項目的研發算是涉及絕大多數主流互聯網技術，整體做下來修為可以提升不少，大概把眼前的問題想了一下：

PC、Android、iOS三大平台（一般互聯網創業項目標配）
每個平台要做2種端：面向客戶的直播端，和面向主播的推流端（標配x2）
視頻編碼涉及非常多的技術參數和細節（領域特殊技術）
完整的禮物系統、支付系統、運營系統、任務系統（不亞於一般頁游項目）
即時聊天IM服務（彈幕，既要保證實時性，又要抗住高並發）
視頻推流拉流鏈路依賴第三方CDN（超越一般創業項目的運維成本）
因為涉及錢的問題，經常與各種黑暗勢力鬥爭（色情、廣告、刷小號、刷充值、告侵權、DDoS等等）

@姚冬大神回答了很多視頻直播相關的技術難點，這算是視頻直播中最核心的技術之一了，但對於創業團隊來說，還有更多技術攻堅之外的技術壓力：

即使聊天IM技術難度也很大啊，尼瑪一個大主播的直播間有十幾萬人同時在線，一個人發消息要十幾萬人都收到啊，大主播還經常帶節奏，十幾萬人一起發消息要十幾萬人一起收啊，想像這個瞬間的高峰是個什麼鬼！
視頻直播的鏈路很長，CDN經常坑爹啊，主播推流客戶端各種亂配，運營商各種劫持，出了問題都不知道甩鍋給誰啊！
支付系統一定要仔細搞啊，每個環節都要仔細想清楚各種異常情況啊，所有消費都要有流水記錄，警惕蘋果黑卡啊
研發團隊不好招人啊，我每周篩選6、70份簡歷，安排面試1、20人，也才能敲定3、4個offer，以這樣的強度估計還要再堅持幾個月啊
各種合作方的接入，各種賽事活動的接入，市場、運營、產品、客服各方都給你提需求啊，一個人要掰成好幾個人用
即便如此，作為研發，看到不順心的代碼還是想重構啊，要在高速公路上冒著煙極速飛奔的汽車上，一邊開車一邊換輪胎啊！
團隊快速擴張，彼此要磨合，管理能力還要能跟上啊，新人大量加入，還要安排好工作啊。

總之過去的一個月我是感覺自己無論在技術能力還是管理能力上的進步好像都超過了此前5年在大公司積累的總和，做視頻直播項目真的很虐心，也真的非常磨練人，現在整個視頻直播領域狼煙四起，頗有當年百團大戰的意味，作為研發，我想要是能與現在的團隊一起奮鬥成長，並在這個領域爭得一塊立足之地，也算是一項非常了不起的成就了。

如果你僅僅為了一個構想的新模式而嘗試涉足我覺得現在這個時間點已經沒有必要了，各方面資源的投入成本都會非常非常高，做個demo玩玩還行，深入做下去真是山高路遠坑深。

順便打個廣告，為我的團隊招人，可以發簡歷到 zhangyunlong@qmtv.com

最近直播很火，很多大公司和中小創業者都想抓住這個機會做一番事業。「如何搭建一個完整的視頻直播系統？」這是一個很大的問題，不是一兩個答案能夠解釋清楚的，但我還是盡量技術和創業的角度提供給題主儘可能多的信息。

正如 @姚冬所說，一個完整的直播系統大致包含這幾個環節：採集、前處理、編碼、傳輸、解碼和渲染。在兩端傳輸的過程中再加上一個服務端處理。大致的模型如下：

在主播推流端涉及到的環節有採集、前處理和編碼，在觀眾端涉及到的環節就是解碼和渲染，在這兩個端之間建立起傳輸通道的則是服務端，它負責接收主播端的推流，將其處理之後分發給觀眾播放端：

1. 採集

採集是播放環節中的第一環，iOS 系統因為軟硬體種類不多，硬體適配性較好，所以比較簡單。Android 則不同，市面上硬體機型非常多，難以做到一個庫適配所有硬體。PC 端的採集也跟各種攝像頭驅動有關，推薦使用目前市面上最好用的 PC 端開源免費軟體 OBS: Open Broadcaster Software

參考教程：鬥魚遊戲直播教程-OBS直播軟體篇[推薦]

2. 前處理

正如 @姚冬所說，「80% 的主播沒有美顏根本沒法看。」不光是美顏，很多其它的視頻處理如模糊效果、水印等也都是在這個環節做。目前 iOS 端比較知名的是 GPUImage 這個庫，提供了豐富端預處理效果，還可以基於這個庫自己寫演算法實現更豐富端效果：GitHub - BradLarson/GPUImage: An open source iOS framework for GPU-based image and video processing

Android 也有 GPUImage 這個庫的移植：GitHub - CyberAgent/android-gpuimage: Android filters based on OpenGL (idea from GPUImage for iOS)

同時，Google 官方開源了一個偉大的庫，覆蓋了 Android 上面很多多媒體和圖形圖像相關的處理：https://github.com/google/grafika

3. 編碼

編碼主要難點有兩個：1. 處理硬體兼容性問題。2. 在高 fps、低 bitrate 和音質畫質之間找到平衡。

iOS 端硬體兼容性較好，可以直接採用硬編。而 Android 的硬編的支持則難得多，需要支持各種硬體機型，推薦使用軟編。

4. 傳輸

傳輸涉及到很多端：

從主播端到服務端
從收流服務端到邊緣節點
再從邊緣節點到觀眾端

推流端和分發端理論上需要支持的並發用戶數應該都是億級的，不過畢竟產生內容的推流端在少數，和消費內容端播放端不是一個量級，但是他們對推流穩定性和速度的要求比播放端高很多，這涉及到所有播放端能否看到直播，以及直播端質量如何。

很多人吐槽現在的 CDN 不靠譜，我也承認傳統的 CDN 在新時代顯得心有餘力不足。你能夠藉助 CDN 快速實現大規模的流分發，但是穩定高速的推流上傳可能還需要自己做很多工作。這也是為什麼我們七牛在這方面做這麼多工作的原因之一。

如果要自己動手做，服務端方面最好的參考資料可能是這個了：v3_CN_Home · ossrs/srs Wiki · GitHub

國民首席、熊貓 TV 首席架構師楊武明在「Gopher 北京聚會」上做過一個「Golang在視頻直播平台的高性能實踐」的分享，值得參考：https://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==mid=404230356idx=1sn=6b73f971c4cf1170adaf4d249480ed9ascene=1srcid=0301qrbBZPrLxORTiD5D5IO1key=b28b03434249256be5dfe068862f4c51d10c5e16b3659de35ce26bd4868f3a186366844bc7a8d3eaf48192b75536009bascene=0uin=MTUwMTI2NjQ2MA%3D%3Ddevicetype=iMac+MacBookPro11%2C2+OSX+OSX+10.11.4+build(15E65)version=11020201pass_ticket=TplbLKZJE2ZwCTACdAM6vZw%2FaJtVhaRrbn0An3uI6OAbctOQaAXHM9DZBdalM5Fi

PPT 地址：ppt/GolangPerformancePractice.pdf at master · yangwm/ppt · GitHub

5. 服務端處理

為了讓主播推上來的流適配各個平台端各種不同協議，需要在服務端做一些流處理工作，比如轉碼成不同格式支持不同協議如 RTMP、HLS 和 FLV，一路轉多路流適配各種不同的網路狀況和不同解析度的終端設備。

6. 解碼和渲染

解碼和渲染，也即音視頻的播放，目前 iOS 端的播放兼容性較好，在延遲可接受的情況下使用 HLS 協議是最好的選擇。Android 的硬體解碼和編碼一樣也存在兼容性問題，目前比較好的開源播放器是基於 ffplay 的 ijkplayer：GitHub - Bilibili/ijkplayer: Android/iOS video player based on FFmpeg n3.0, with MediaCodec, VideoToolbox support.

目前，我們七牛在客戶端採集、編碼解碼以及推流拉流加速方面做了很多工作，以上乾貨也是基於這個過程中踩過的坑整理出來的：Pili Streaming Cloud · GitHub

既然是創業，肯定要考慮到前期投入和未來的商業化，這方面我建議先看看熊貓 TV 庄明浩的長文分析：http://zhuanlan.zhihu.com/p/20717041

他在投入熊貓 TV 創業之前以投資人的視角從投資的角度深入觀察、分析了視頻和直播行業 2 年。

最近正好在做這方面的項目。

雖然是採購方，天天跟工程獅混在一起，對架構也略有了解。

寫了大致的結構圖，基本已經很清楚了。

懶的看文章的，直接點擊放大，看原圖就可以了。

新興的直播行業現在正處於一個爆髮式增長的狀態，先從以秀場為主的直播方式，再到遊戲直播，再到以UGC（user-generated Content）為主的內容生產方式的移動直播，將各行各業的內容以直播的方式分享。

不同模式的直播產品正在湧入市場，目前國內直播App就有200多個，其中100左右個項目獲得了融資，形成激烈的競爭。

而背後的視頻直播系統也需要一個龐大的技術鏈支持，下面簡單介紹一下視頻直播系統的技術鏈。

1.直播類型

視頻直播根據不同的服務對象，大致可以分為2B和2C兩種類型。

兩種類型在技術本質上沒有太多區別，但在產品形式上有很大區別。

2B指的是為企業提供直播服務。

例如微吼、易直播、趣直播、視秀等平台，幫助企業做直播解決方案。

企業召開發布會，就可以使用這些公司的服務。企業搭建專屬直播室，企業級直播服務公司可以提供標準化的產品，也可提供個性化的定製服務，將其API嵌入自家App中。

2C指的是為普通用戶提供直播服務。

市場上大部分直播平台都是這類型。又可分為一對一和一對多。

一對一是指視頻源從一個客戶端傳輸到另一客戶端。如Facetime，Skype，微信，QQ的視頻通話功能。

一對多是指視頻源從一個客戶端傳輸到多個客戶端。這種形式即「網路視頻直播」。

根據直播內容及形式又可分為以下幾個種類：

秀場直播。

主要是主播展示才藝的形式，大部分為女性主播，是中國最早的直播形式。

目前秀場直播主要有愛奇藝奇秀、騰訊QT星主播，優酷的來瘋等等。

電競直播。

以遊戲賽事，遊戲教程等為主要內容。最先是在美國興起的http://Justin.TV，之後改為Twitch，被亞馬遜收購。國內主要有鬥魚，戰旗，熊貓，虎牙等遊戲直播平台。

移動直播。

是以移動設備為視頻源的直播方式。這種形式最早在2015上半年，起源於美國的創業公司Meerkat，Periscope。之後Periscope被Twitter收購，Facebook也涉及這一領域，在Twitter，Facebook的競爭壓力下，Meerkat放棄了直播視頻社交網路業務。

在2015年下半年，中國拷貝了這種形式。以視頻化社交為方向，代表產品有映客和花椒，陌陌美拍等的直播功能。

活動直播。

主要為各種現場活動提供直播服務。這種服務通常由toB直播服務公司提供。需要相對好的人脈資源，直播要求高，行業壁壘高，大部分創業者無法涉及。對各種講座，峰會以及商業活動進行直播，主要有微吼直播等。對各種演唱會的直播，主要有優酷，樂視等大型視頻網站。

而在內容劃分上，各中直播模式依賴不同的內容生產方式。如下圖所示：

註：

UGC，User-generated Content也稱為UCC，User-created Content

PGC，Professionally-generated Content也稱為PPC，Professionally-produced Content

OGC，Occupationally-generated Content

2.視頻直播系統

一個直播系統大概可以分為一下幾個模塊，媒體模塊，服務模塊，管理模塊。

媒體模塊是直播系統的技術核心，服務模塊是關乎用戶體驗，管理模塊對數據，系統進行管理控制。

2．1媒體模塊

2.1.1採集

採集是直播系統中的第一環節，獲取視頻源。

因為iOS是軟硬體種類不多，官方也提供了穩定可靠的介面，比較簡單。

Android因為機型種類繁多，需要適配機型，會是很大一部分工作。

而PC也面臨各種攝像頭驅動，難點在於機型適配。

2.1.2前處理

前處理，主要用於圖像美化，風格化，圖像處理方面。

當前直播的美顏功能已不可或缺，除了秀場需求以外，在UGC內容生產方式下，大量的內容對美顏都有較高的要求。

美顏簡單的可以通過美顏鏡頭，但局限性大，限於PC端的主播，更好的辦法是通過軟體實現，需要圖像處理方面的人員，美顏演算法需要需要用到GPU編程，要自己參考論文去研究。

難點在於美顏效果是否自然，GPU佔用與效果的平衡。GPU用於高性能計算，但功耗也相對高，需要考慮到手機溫度對數據採集的影響。溫度過高，攝像頭容易掉幀。圖像處理不僅僅是美顏，在交互中可能會涉及到濾鏡，人臉識別，人物風格化等，使得客戶擁有更好的互動體驗。

目前iOS上比較好的圖像處理庫是GPUImage，提供了豐富的預處理效果，也可利用該庫自定義設計。

Android上也提供了功能強大的圖像處理庫grafika。

2.1.3編碼

在編碼方面，有兩種編碼方式，硬編碼（硬體）與軟編碼（軟體）。

目前大部分硬體都支持硬編碼，但在Android上存在兼容性問題，源於不同廠商的晶元差異巨大，難以構建統一的庫來兼容全平台。

編碼的工作主要是對視頻，音頻的原始數據進行編碼處理，得到可用的視頻，音頻數據。

編碼涉及一系列的技術，常用的編碼方式有CBR、VBR；對於視頻，常用的編碼標準是H.265、H.264、MPEG-4等，可封裝為MKV、AVI、MP4等；對於音頻的常用編碼標準有G.711μ、AAC、Opus等，封裝有MP3、OGG、AAC等。

編碼通過壓縮音視頻數據來減少數據體積，方便音視頻數據的推流，拉流和存儲。大大提高存儲傳輸效率。

H.265是當前性能最高的編碼技術，在相同視頻質量下，相比於H.264，H.265僅需一半的帶寬，使得低於1.5Mbps的網路能夠傳輸1080p的高清視頻。

在編碼方面的核心是平衡解析度、碼率、幀率、GOP（Group of Pictures）使得體積與畫質達到最優，參數組合為技術核心，也是個家的商業機密。

2.1.4傳輸

傳輸涉及系統的多個部分，連接主播端，服務端，客服端等多個部分。

傳輸效率高與否決定直播系統的性能好不好，傳輸是直播系統非常重要的技術核心。

下面是傳輸的簡單示意圖：

從推流端到服務端。數據經過推流端採集和預處理，編碼之後推流到服務端，流傳輸就涉及到相應的傳輸協議，最常用的協議是RTMP(Real Time Messaging Protocol，實時消息傳送協議)，RTMP是Adobe Systems公司為Flash播放器和伺服器之間音頻、視頻和數據傳輸開發的開放協議。還有RTSP,HLS等。

RTMP的傳輸延遲通常在1-3秒，符合手機直播對性能的要求，因此RTMP是手機直播中最常見的傳輸協議。之後通過QoS（Quality of Service指一個網路能夠利用各種基礎技術，為指定的網路通信提供更好的服務能力, 是網路的一種安全機制，是用來解決網路延遲和阻塞等問題的一種技術。）將流數據推送到網路端，通過CDN分發。

在直播場景中，網路不穩定很常見，需要通過QoS來保證直播體驗。服務端還需要對數據流一定的處理，轉碼，使得數據流支持HLS，HTTP-FLV，RTMP等格式的拉流，支持一轉多，適配不同網路、解析度的終端。

推流作為視頻源的傳輸，在穩定性速度上都比拉流高得多。實現推拉流的技術線沒有雄厚的人才與資金是不現實的，通常需要依賴第三方的CDN提供商。

在實際中，大多數直播平台會接入多個視頻雲服務提供商，做拉流線路互備，視頻集群也是可優化部分來提高直播流暢性與穩定性。

2.1.5解碼，渲染

拉流獲取音視頻數據後，需要通過解碼器解碼，渲染才能在播放器上播放。

H.264和H.265是有所壓縮的，在解碼恢復之後是缺損的原數據。

之前提到的體積最小畫質最優的編碼參數，就是在這裡恢復畫質的，該參數組合是非常重要的技術。現在的播放器普遍都需要高清支持，解碼也應選擇硬解碼。iOS能夠較好的支持，但Android還需要很多工作去彌補Android在平台差異的缺陷。

而在播放端，保證音畫同步的同時，保證穩定流暢的直播流量，需要服務端與播放端做調度優化。

2．2服務模塊

服務模塊涉及用戶體驗，從用戶方的收益一部分也來自於服務模塊。

系統需要完整的禮物，支付，運營，任務等系統，複雜度不亞於頁游系統。

國內直播平台的營利模式決定：平台從打賞中抽成。禮物系統就成為平台的盈利方式。禮物系統是多數視頻直播平台的標配。

在中國部分人有禮品消費的習慣。平台為用戶主播設計多個等級、爵位等頭銜。利用財富榜，家族榜，等級榜類拉動消費。

IM技術。IM即時通訊服務。包括聊天室、彈幕等。彈幕交互方式是很好的體驗，偏年輕化，大量用戶願意通過彈幕互動。高峰時，彈幕消息量特別大，一是需要考慮到高峰時彈幕的實時性和高並發量，二是要在產品策略上作一些體驗上的優化。

支付系統需要仔細處理各種異常，消費流水記錄。

系統還需要在政策上作相應的考慮，例如國家規定所有直播必須打水印並存留15天以上。在內容審核方面，淫穢、暴力、犯罪、敏感問題的審核。在數據分析方面也需要相應的統計系統。

2．3管理模塊

管理模塊包括客戶端的設計與維護、後台資料庫、後台控制系統。

該部分根據直播平台的特性、定位設計相應的管理策略。具體技術上還包括緩存、分散式文件存儲、消息隊列，運維繫統等等。

2．4 OBS直播軟體

Open Broadcaster Software（OBS）是一款很好用的PC端直播開源軟體。該軟體提供了對H264 (x264) 、AAC編碼的支持。支持多場景多數據源，到Twitch, YouTube等平台的LRS支持。支持輸出視頻，基於GPU的遊戲捕捉提供高性能的視頻流等等眾多支持。能夠很好地完成採集、編碼。

以上簡單地介紹了視頻直播系統的技術構架，構架本身容易，但構建性能優良的構架就很有難度，需要在傳輸速度與效率、推流端兼容性、客戶端體驗上作深入的工作。

但說實話，如果僅從問題描述來看，我覺得這樣的格局，對未來的生存表示擔憂。

現在鋪天蓋地的直播，從遊戲直播、到秀場、到移動端。

看似是塊很大的蛋糕，但能留到最後的，一定是巨頭中的其中一家。

很多初創團隊，都覺得直播的市場很大，機會很多，但這個時間點入場，給初創者的時間並不多。

王思聰的熊貓TV，騰訊投資鬥魚和龍珠，最近瘋狂燒錢的騰訊直播和企鵝直播，360投的花椒直播，陌陌的哈你直播、微博的一直播，金沙江投資映客，這些豪華陣容在直播的戰場上廝殺的火熱。

這類2C直播平台最重要的就是利用直播內容和主播人氣吸引巨大的流量。

有流量就有錢進來。

這樣的遊戲規則下，各大2C平台就瘋狂的買內容，簽主播。廣告狂轟亂炸，爭奪江湖地位。

瘋狂燒錢的同時，也只有一輪又一輪不斷的融資才能生存下來。

有資本進入的地方就有對賭。

不管是2C的映客、鬥魚、熊貓，還是2B的微吼直播。

相比2C端頻繁的資本大戰，在2B端發展還是相對穩健。

還是以微吼直播為例，被爆已完成B輪對賭，對賭金額達7000萬元人民幣，有望在年內成為業內首家盈利的直播平台。

現在企業直播服務、城市直播服務的市場還是被嚴重低估。

儘管現在很多工作上的事情在微信里溝通、討論。但是我們知道，選擇微信，只是因為大家都在用它！只是大家都在用它！

封閉的社交環境使其在商業協作中難登大雅之堂的主因。

單從溝通介質所能承載的信息量來看：文字 &< 語言 &< 視頻 &< 面對面交流。

網路直播這種面對面的交流能夠承載最豐富最真實的信息，這也讓微吼直播這樣的2B直播行業迎來了千載難逢的機會。

回到題主的問題，我覺得自己搭建直播平台，還不如在別人已經創造好的平台上發現新的機會。

（個人觀點，人還是要有夢想的嘛。）

很多回答，已經給題主提了不少的建議。知乎上網路服務公司，響應也真是夠快的，在問題的評論里，有幾家也跟題主對接上了。

粗略看了下，2C和2B的都有，直播服務的大趨勢就是這樣。

（圖片我下午拍的，2B直播調試現場）

最後，補充一句：搭建視頻直播系統一定要符合中國特色。

為什麼捏？

一個服務商告訴我的：

我們架的這套視頻雲協作系統，核心技術是思科的。

老牛逼了，海外版本預設的是，不同的人發言的時候，系統會自動判斷麥克風聲音方向，高清攝像頭就會自動轉向發言的人，並且自動優化構圖。然後，系統會把發言的人放大，突出顯示在現場的大屏幕上。

但引進到國內後，這套系統就被改成了：

領導的畫面永遠最大，並且永遠在最中間…

謝邀，最近回答了關於直播的問題，今天就有人邀請我回答技術貼了。以下都以秀場直播為基礎進行介紹——簡單說，一個直播平台的技術搭建，按照各端的順序，大概是下邊這樣的：

先從採集端說起，也就是通過攝像頭拍攝到直播者的圖像以及錄製聲音。單就這個地方來說，其實是沒什麼問題的。但是樓上幾個答案提到的安卓機型碎片化很嚴重的問題也是客觀存在的。所以，自己做架構的時候，一定要注意多終端適配，另外就是離線採集技術、手動對焦等等也會影響用戶體驗。

接下來一個重要的環節就是前處理，其實最主要的部分就是GPU渲染的實時美顏。一方面，實時美顏的演算法本身，就相當考驗APP廠商的技術實力；而另一方面，如何能夠利用有限的GPU資源進行美顏處理，也是一個很關鍵的點。這裡就不能不提到兼容性的問題。雖然現在國內手機晶元市場佔據領先地位的只有高通和聯發科，GPU也是除了高通就是PowerVR，但是如果再考慮到各種因素，想在前處理方面做好技術的適配確實需要相當的成本。這段時間國內很多直播產品迭代都比較快，所以直接後果就是技術適配做得差，很多常見的機型都會閃退和驟停。

另外，除了美顏之外，前處理還有一個點是水印、時間戳等等。因為現在很多小平台之間，都會互相盜鏈，惡性競爭，這樣算是防患於未然。

再之後就是編碼。我們都知道把視頻上傳到優酷上會有一個編碼的過程，直播也如此。只不過，前者依靠的是雲計算，後者則是通過手機自身CPU的性能進行編碼——考慮到國內很多網紅主播用流量直播的現狀，以及國內大多數地區的網速，先上傳後編碼完全不現實。而在這種情況下，最常見的一個問題就是手機發燙，原因是CPU和GPU同時在沒有良好優化的情況下進行長時間的滿負荷工作。這又會帶來兩重問題，其一是用戶體驗差，其二是電量消耗快。最嚴重的一次，我一個朋友拿手機直播時我隨手拿起來看了一下，有種「燙手」的感覺。

編碼本身的演算法也有講究，一方面要減小CPU的使用率，另一方面又要控制碼率更低。所以基本上，如果你自己或者服務商的編碼標準不是H.264或者H.265，基本上就可以一票否決了。

接下來到了傳輸部分，這裡邊的重點在於推流。因為如果只是傳輸路徑上某一個點有故障，只是一部分人看不了，但如果推流出了問題，所有的人都看不了了。更何況，移動直播平台的競爭非常激烈，如果技術上不過關，一旦宕機影響用戶體驗，後果會很嚴重。前一陣子花椒直播找張繼科直播，30萬人的量就出現了宕機，很明顯就是傳輸方面沒到位。

傳輸這一塊是技術活。所以基本上國內大多數成熟的直播平台，都選擇把這一塊交給專業的CDN廠商去做。畢竟，創業公司一般都會把精力專註於自己的業務，而自建CDN這種很垂直的事情，連很多非運維的技術人員都不懂，再加上伺服器、帶寬之類的成本，自己做很困難。

這就涉及到CDN的選擇問題。先科普一下，CDN最核心的資源比拼就是內容分發節點，但是如果涉及到直播的話，流傳輸的技術架構也同樣重要。

從架構上來看，國內大概是三類：

第一類是傳統的CDN老牌，代表是網宿、藍汛。他們的優勢是骨幹帶寬強，缺點是架構上明顯沒有跟上步伐，而且價格比較高。

第二類是雲CDN，優勢相對會大一些。這個問題下關於CDN的推薦基本上都是關於雲CDN的，比如Ucloud，七牛雲、又拍雲等都推出了自己的雲CDN，樓上的答案也已經提到了他們各自的優勢，題主也可以進行參考。

除了以上兩類，最近還有一家CDN採用和前兩者有所不同的模式，是迅雷旗下一家名叫網心科技的公司推出的星域CDN。他們的模式比較獨特，除了正常的大型骨幹節點之外，還通過名叫「賺錢寶」的智能硬體連接家庭路由器，從而利用閑置帶寬布局了幾十萬個家庭內容分發節點。這種模式的優勢是：在內容傳輸時可以做到更快地建立起傳輸路徑，對於直播這種對實時傳輸要求比較高的技術來說，還是有一些好處的。

國內三大主流CDN直播支持技術對比圖，以各自領域最優數據進行對比

數據來源：國內三大主流CDN橫向全對比_DoNews-互聯網

國內三大主流CDN橫向全對比_DoNews-互聯網

目測題主的朋友是創業公司，在預算方面還是比較緊的，就不要考慮傳統CDN從後兩種之間選擇好了。建議是去這幾家公司的官網對比一下價格。我這裡截了幾張圖，從上到下分別是七牛雲，Upyun和星域。

七牛雲

Upyun

星域CDN直播

不同的CDN廠商，根據不同流量區間價格不一樣，按流量計費和按帶寬計費也是不一樣的。

直播平台的帶寬成本比較高，這時價格之間的差異對選擇天平的傾斜影響還是相當大的。或者，也可以找一些免費送流量的公司體驗一下，這樣可以無需充值就能感受到服務的效果。比如說：七牛0-10GB就是完全免費的，星域註冊也會送100G。另外，如果數據量夠大的話，星域的單價比起其他家明顯會低很多。

另外，可以通過觀察CDN企業服務的直播平台來認識他們的實力。畢竟，大公司在採購時會有很嚴格的要求，基本上能通過的也都是經過九九八十一難，「剩者為王」。自己列了一張表，不一定全，僅供參考。

從CDN說回直播本身，在拉流之後就是視頻的解碼、渲染等等，這一塊對於硬體的要求比編碼會低一些，技術上難度也會小一點。這裡邊也有一些細節，比如軟硬碼自動切換，連麥互動，H.265解碼，動態追幀，播錄一體化這些。每一個細節，都有可能帶來用戶體驗上的差距。

當然，以上說的只是直播平台技術里視頻的一部分，樓上 @姚冬老師說的很好，音頻、禮物、資料庫甚至支付都是不得不考慮的事情。至於技術準備和資金門檻，只能說：以一個創業公司的資金和資源從零做起的話，很多問題其實確實是不太容易解決的。一個好的直播平台，光是技術的解決方案上百萬就是杯水車薪，而且要找到靠譜的人才能畫好這筆錢。尤其是趕上這輪資本寒冬，直播平台裡邊老大老二基本分出來了，如果現在想融到兩千萬然後拿出上千萬搞技術——未必可行。

好在國內市場足夠大，允許各種各樣的競爭者同時出現，所以最近有一些做雲計算和CDN的廠商，乾脆把直播的技術解決方案整合成了SDK，賣給創業公司。

這類SDK能做的事情，還是比較多的，網上找來了張圖，題主和大家也可以參考一下。而且，這一類解決方案因為相對標準化，所以成本相當低，價格也不高。當然，做這種事情的門檻不低，基本上都是比較大的CDN廠商在做。

比如文章上邊提到的星域，就是直接把視頻推拉流、採集、轉碼之類的技術打包在了一起，同時優化各個環節。畢竟，CDN行業的競爭很激烈，價格也是逐年下跌，所以服務商們為了找自己的差異化競爭點，還是很賣力氣的。

總結起來，一是直播平台在技術方面的要求很高，尤其是CDN一塊專業性很強，想完全用自己的技術解決不現實；二是，要麼捨得砸錢招BAT技術團隊，要麼就用標準化的技術解決方案——畢竟直播平台技術只不過決定著及格線，真正的核心競爭力在於產品和運營。如果真的有那麼多錢，還不如把技術上省下來的錢花在網紅的簽約和入駐上，對吧！

直播技術要求這塊上面已經講的很詳細了，我就不再贅述了。作為又拍直播雲的研發，這邊就說說接入又拍直播雲（直播雲 - 一站式視頻直播加速）的流程，非常的簡單方便。新用戶通過官網註冊賬號，並進行個人/公司認證，審核通過後可以正常使用控制台。詳細步驟如下所述：

創建服務：

Step1，創建服務。進入又拍雲官網——控制台——點擊【創建服務】。參考如下：

Step2. 配置服務.源站選擇及配置：

又拍雲源，用戶通過推流器或編碼器主動將直播流推送至又拍，經過又拍的流媒體加速中心加速後，通過相應的拉流 URL 進行訪問。適用場景為秀場主播、遊戲直播和在線教育等；

自主源站，客戶提供直播源伺服器，又拍向客戶源請求源數據。適用場景為電視台，體育比賽等。

又拍雲源配置：

推流域名：用於推送直播流的域名，長度小於60個字元，支持泛域名綁定，比如：*.yourdomain. com

播放域名：用於播放直播流的域名，默認支持 RTMP，HLS 和 HTTP-FLV；推流域名、播放域名共計最多可綁定個域名，支持泛域名，所綁定的域名需要備案；

接入點：支持1-60位英文字元和數字，如：rtmp://http://push.example.com/{接入點}/{流名}，該項可不填，為空時表示，可以使用任意的接入點。

示例：接入點：live；推流域名：http://push.example.com；播放域名：http://pull.example.com

則

推流地址：rtmp:// http://push.example.com /live/streamid

rtmp 播放地址：rtmp://http://pull.example.com/live/ streamid

hls 播放地址：http:// http://pull.example.com/live/ streamid.m3u8

flv 播放地址：http:// http://pull.example.com/live/ streamid.flv

自主源站，請填寫自己的源站地址

源站：支持 RTMP/HTTP 兩種協議回源，源站支持輸入域名/IP，請填寫正確的源站地址，直播流將推流到源站拉取直播流進行分發

播放域名：用於播放直播流的域名，默認支持 RTMP，HLS 和 HTTP-FLV，推流域名、播放域名共計最多可綁定 10 個域名，支持泛域名，所綁定的域名需要備案；

接入點：支持1-60位英文字元和數字，如：rtmp://http://push.example.com/{接入點}/{流名}，該項可不填，為空時表示，可以使用任意的接入點。

示例：接入點：live；協議為：RTMP；源站：11.11.11.11 ；埠為：1935

則

回源地址為：rtmp:// 11.11.11.11:1935/live/streamid

播放域名：http://pull.example.com

hls 播放地址：http:// http://pull.example.com/live/ streamid.m3u8

flv 播放地址：http:// http://pull.example.com/live/ streamid.flv

註：流名默認支持任意字元串

Step3. 配置成功

配置完成後，系統會自動為您生成該推流域名需要 CNAME 地址，您可以前往域名的 DNS 服務商為自主域名添加 CNAME 地址。

——————————分割線——————————

三步完成配置，就是這麼輕鬆簡單。

附上又拍直播雲文檔：http://docs.upyun.com/live/

提問者如果打算自建視頻直播平台，成本確實很高，技術門檻也比較高。我就從調用相關雲服務的角度來說好了。相對來說，效率要高得多。

搭建一個完整的視頻直播系統，首先要了解一般直播產品的架構。架構圖如下：

其次要選擇一個功能完善，性能良好，運行穩定的視頻雲平台。目前市場上主流的有百度雲，騰訊雲，樂視雲，歡聚雲，暴風雲，網易視頻雲，目睹直播這些。還有其他的就不一一列舉了，重點分析一下列舉的這幾個的特點。

騰訊雲。定位：Paas層。推流SDK支持Windows、Web、Android、iOS。播放器SDK支持Web（Flash、H5）、Android、iOS。CDN全球400+。優勢是互動直播方案比較成熟，但是穩定性不佳。收費方式是按核心機房和邊緣節點的帶寬進行計費。技術支持：開發文檔和工單。

網易視頻雲。定位：Paas層。推流SDK支持Windows、Web、Android、iOS。播放器SDK支持Windows、Web、Android、iOS。CDN數600+。優勢是推流碼流可以自適應，自帶美顏、混音等擴展功能。直播功能價格，同樣按流量和帶寬計費，但是使用推出的套餐會相對別家便宜很多。技術支持：文檔和工具交流，提供1V1的專家技術支持。

百度雲指的是百度開放雲。定位是Paas層。現在發布到2.0版本，還比較成熟。推流SDK 支持PC、Android、iOS,移動端支持閃光燈、濾鏡等功能，暫不支持動態碼流自適應。播放器SDK支持Web（Flash、H5）、Android、iOS。CDN主要覆蓋了一二線城市。優勢是功能較完善，但是使用複雜度很高。價格有兩種計費方式分別是按直播下行流量和帶寬峰值。技術支持主要通過開發文檔和QQ群。

歡聚雲也就是我們知道的YY。定位：Paas層。目前雲服務還沒開放，需要邀請碼才能試用。推流SDK支持PC、Android、iOS和Web。播放器SDK支持Web端（Flash、H5），移動端支持HLSFLV。優勢是支持音視頻連麥。價格不詳，技術支持只有一些文檔。

暴風雲。定位：Paas層。推流SDK有Windows直播助手和移動端直播助手。播放器SDK支持Web(Flash、H5)、Android、iOS。CDN數不詳，但是默認直播並發不能超過2000人。優勢是在視頻雲是做的最早的公司。計費也有兩種，按流量和按帶寬。技術支持：開發文檔和QQ交流。

目睹直播。定位：Saas。推流SDK支持Windows、Web、Android、iOS、導播台。播放器SDK支持PC、Android、iOS。CDN數不詳。優勢是擴展功能較豐富。計費：0.04~0.06元/分鐘/人。技術支持不詳。

總的來說，這些產品各有優劣。個人覺得，有兩方面需要注意。一個是視頻雲服務的穩定性。如果本身雲服務系統就有一大堆問題，那接入的時候肯定問題更多。所以可以先考慮行業大公司的雲服務。網易視頻雲和百度雲的穩定性都做的不錯。第二個是技術支持的力度，換句話說出了問題之後的響應和解決速度能有多快。網易視頻雲在技術服務有1V1的專家支持，這在業界尚屬領先。總的來說，網易視頻雲的性價比在雲服務商里算是最高的。

選擇完視頻雲服務公司，就可以根據相應的情況進行搭建，接入直播功能。具體操作的時候，肯定還是會有各種各樣的問題，那就不是一個知乎問答能解決的了。

姚冬、@何李石和張雲龍的答案都很好很全面。

看到這個問題好幾次了，不少人都提到了美顏這個點，忍不住來發篇回（硬）答（廣）。

關於美顏，以下幾點應該是標配：

美顏處理流暢快速
濾鏡效果自然
適配機型足夠多
耗電量低

我所在的 TuSDK 團隊目前正專註於移動端圖像服務，我們積累了十年以上圖像領域相關經驗，從圖片處理和相機 SDK 做起，目前針對直播市場也推出了專門的解決方案 http://tusdk.com/video 。

目前我們取得的效果：

iOS 每幀處理時間小於 1ms，Android 在 3ms 左右
通過 GPU 識別技術適配市面上絕大部分機型
可根據需要調整濾鏡和美顏效果

正在做的事情：

動態貼紙
與已有的人臉識別技術結合，實現更多需求

提供兩種服務：

獨立的客戶端處理引擎，適用於已經成形的移動視頻產品，用以完善功能、提升體驗。
一站式解決方案，包含了前後端的所有功能，更全面、更專業的視頻直播方案。

一、直播的技術架構：

直播視頻採集SDK（PC/IOS/Anddroid）——直播CDN

（直播流分發加速）——直播視頻播放器SDK（PC/IOS/Android）

二、音視頻處理的一般流程：

數據採集→數據編碼→數據傳輸(流媒體伺服器) →解碼數據→播放顯示

1、數據採集：

攝像機及拾音器收集視頻及音頻數據，此時得到的為原始數據

涉及技術或協議：

攝像機：CCD、CMOS

拾音器：聲電轉換裝置（咪頭）、音頻放大電路

2、數據編碼：

使用相關硬體或軟體對音視頻原始數據進行編碼處理（數字化）及加工（如音視頻混合、打包封裝等），得到可用的音視頻數據

涉及技術或協議：

編碼方式：CBR、VBR

編碼格式

視頻：H.265、H.264、MPEG-4等，封裝容器有TS、MKV、AVI、MP4等

音頻：G.711μ、AAC、Opus等，封裝有MP3、OGG、AAC等

3、數據傳輸：

將編碼完成後的音視頻數據進行傳輸，早期的音視頻通過同軸電纜之類的線纜進行傳輸，IP網路發展後，使用IP網路優傳輸

涉及技術或協議：

傳輸協議：RTP與RTCP、RTSP、RTMP、HTTP、HLS（HTTP Live Streaming）等

控制信令：SIP和SDP、SNMP等

4、解碼數據：

使用相關硬體或軟體對接收到的編碼後的音視頻數據進行解碼，得到可以直接顯示的圖像/聲音

涉及技術或協議：

一般對應的編碼器都會帶有相應的解碼器，也有一些第三方解碼插件等

5、播放顯示：

在顯示器（電視、監視屏等）或揚聲器（耳機、喇叭等）里，顯示相應的圖像畫面或聲音

涉及技術或協議：

顯示器、揚聲器、3D眼鏡等

三、常見的視頻直播相關協議：

1、RTMP(Real Time Messaging Protocol，實時消息傳送協議)

RTMP是Adobe Systems公司為Flash播放器和伺服器之間音頻、視頻和數據傳輸開發的開放協議。它有三種變種：

1）、工作在TCP之上的明文協議，使用埠1935；

2）、RTMPT封裝在HTTP請求之中，可穿越防火牆；

3）、RTMPS類似RTMPT，但使用的是HTTPS連接；

RTMP協議是被Flash用於對象、視頻、音頻的傳輸。這個協議建立在TCP協議或者輪詢HTTP協議之上。RTMP協議就像一個用來裝數據包的容器，這些數據既可以是AMF格式的數據，也可以是FLV中的視音頻數據。一個單一的連接可以通過不同的通道傳輸多路網路流，這些通道中的包都是按照固定大小的包傳輸的。

2、RTSP(Real Time Streaming Protocol，實時流傳輸協議)

RTSP定義了一對多應用程序如何有效地通過IP網路傳送多媒體數據。RTSP提供了一個可擴展框架，數據源可以包括實時數據與已有的存儲的數據。該協議目的在於控制多個數據發送連接，為選擇發送通道如UDP、組播UDP與TCP提供途徑，並為選擇基於RTP上發送機制提供方法。

RTSP語法和運作跟HTTP/1.1類似，但並不特彆強調時間同步，所以比較能容忍網路延遲。代理伺服器的緩存功能也同樣適用於RTSP，並且因為RTSP具有重新導向功能，可根據實際負載情況來切換提供服務的伺服器，以避免過大的負載集中於同一伺服器而造成延遲。

3、RTP(Real-time Transport Protocol，實時傳輸協議)

RTP是針對多媒體數據流的一種傳輸層協議，詳細說明了在互聯網上傳遞音頻和視頻的標準數據包格式。RTP協議常用於流媒體系統（配合RTCP協議），視頻會議和一鍵通系統（配合H.323或SIP），使它成為IP電話產業的技術基礎。

RTP是建立在UDP協議上的，常與RTCP一起使用，其本身並沒有提供按時發送機制或其它服務質量（QoS）保證，它依賴於低層服務去實現這一過程。

RTP 並不保證傳送或防止無序傳送，也不確定底層網路的可靠性，只管發送，不管傳輸是否丟包，也不管接收方是否有收到包。RTP 實行有序傳送，RTP中的序列號允許接收方重組發送方的包序列，同時序列號也能用於決定適當的包位置，如在視頻解碼中，就不需要順序解碼。

4、RTCP(Real-time Transport Control Protocol，實時傳輸控制協議）

RTCP是RTP的配套協議，為RTP媒體流提供信道外的控制。RTCP和RTP一起協作將多媒體數據打包和發送，定期在多媒體流會話參與者之間傳輸控制數據。

RTCP的主要功能是為RTP所提供的服務質量（QoS）提供反饋，收集相關媒體連接的統計信息，例如傳輸位元組數，傳輸分組數，丟失分組數，單向和雙向網路延遲等等。網路應用程序可以利用RTCP所提供的信息來提高服務質量，比如限制流量或改用壓縮比小的編解碼器。

四、直播下的聊天室功能

1、直播的場景下，除了視頻直播還有一塊就是聊天功能，觀眾打開一個直播房間時，也就自動進入了一個聊天室，觀眾可以發文字發表情進行互動，道具打賞也是基於聊天室的介面做上去的。

2、聊天室和群聊的功能類似，兩者的區別是：聊天室的場景下，用戶進入後才能看到聊天信息，群成員信息，退出後再進來就看不到之前的歷史消息了。

3、聊天室其實是im即時通訊中的一個功能，im主要能實現一對一聊天、群聊、聊天室3種場景。

五、利益相關

我們團隊是做直播、IM即時通訊技術的，底層架構都是做好的，開放給開發者sdk和api介面、demo源碼。我的qq3103607948。歡迎交流，相互學習。知乎專欄這篇文章彙集了我對這個行業的理解，歡迎大家指點

直播產品首先要確認是PGC還是UGC，即要區分是固定網紅或簽約主播進行直播，還是隨便一個路人都可以進行直播，兩種場景的差異很大。目測這裡應該更偏向於PGC的直播。

成熟在運營的產品其實已經有不少，720P更多是針對的PC用戶，移動端的沒有這個必要。首先要確認是屬於以下哪種場景：

#1 PC推流+PC觀看

#2 PC推流+PC、移動觀看

#3 移動推流+移動觀看

涉及的技術有視頻編解碼、客戶端開發、大規模直播流分發、產品前端開發等。

#1的最低成本的投入方案：OBS+任選flashplayer(之前筆誤把ijkplayer歸成了flashplayer，這裡誠摯道歉，再給做個宣傳：ijkplayer: ijkplayer非常不錯)+雲直播， OBS是開源免費的PC端推流工具，鬥魚直播的主播們對這個軟體應該非常熟悉了，穩定、流格式標準、佔用資源少還有豐富插件，如混音。一般免費的flashplayer都可以直接播放RTMP的視頻直播。雲直播即CDN的方案。可以到雲服務或CDN公司申請，推薦UCloud直播雲，花10來分鐘即可自助完成配置。這個方案，客戶還需要搞定除視頻外的其他功能，比如聊天室，打賞燈。缺點是OBS目前沒有太好的美顏插件，好在專業主播都有配美顏攝像頭，300~500 不等。

#2 相對於#1 來說多了移動端播放的入口，研發成本肯定大大增加，可以先考慮是iOS還是Android，APP 和視頻直播都自研投入人力不菲，我沒見過有創業公司這麼乾的。一般的做法是：APP框架自己搭建，找開源或第三方的視頻直播SDK 集成視頻直播能力，相關的SDK 有很多；還有一種實時性沒那麼高的做法是內嵌瀏覽器直接用HTML5播放直播流，但是需要CDN提供商支持HLS協議，一般延遲在5~7秒。

#3 這麼玩需要移動端有較強的研發實力，起碼需要1位或以上音視頻編解碼的資深攻城獅。具體的方案：開源SDK（如kickflip，坑多慎入）或第三方推流SDK+播放SDK（UCloud、親加等）+直播加速CDN。目前業內已有的APP把這塊體驗的門檻做得很高，如秒開，低延遲，美顏等特性已成標配，需要第三方的SDK能支持這些功能。提供SDK的公司很多，逃離不開穩定性，兼容性兩個話題。 iOS的機型少一些好處理，Android太多了。如某米的低端機型，市場佔有率高，使用晶元較雜，硬編的兼容性是非常差的，軟編性能又不夠高，美顏、混音的處理是開不起來的，不然會非常卡，層面要考慮這些是否是目標主播。從付費比例來看，iOS和Android高端機的機主可以作為首發目標，低端機型的覆蓋再慢慢搞。另外就是IM的功能，提供SDK的公司也很多，比較出名的如環信、融雲，功能上其實都差不多。

另外的一些建議：

如果是PC 端推流的PGC內容(通常說的美女秀場)，為了節約成本，可以把幀率調到15或16，可以節省35%左右帶寬。對於2W在線來說，720P 按每路至少1000kps碼率，就得20G帶寬，省個35%就是7G，每個月省10好幾萬。

實時直播流轉碼的功能（比如適配多終端或多屏幕大小）。看似高大上，實際投入產出比極低，一般4核的設備可以實時轉碼個位數的直播流，2w在線，按1:5主播觀看算，就有4000路流，這個設備投入是天文數字，所以別花心思自己搞設備區轉了。當然對於足夠針對熱度的流做優化是有價值的。

搭車放個招人廣告，有視頻終端或後台系統開發的同學，可以發簡歷至ken.zeng@ucloud.cn

什麼分析，什麼架構上面 @張雲龍@姚冬兩位大哥已經分析得比較清楚了。我就給大家提供一個方便；

下面是我在開發直播APP中整理的一些技術，歡迎GitHub持續更新-歡迎Star

直播關鍵字

採集、前處理、編碼、傳輸、解碼、渲染, 推流, 拉流、連麥、直播、互動、RTMP

原理科普

為何一直推薦WebRTC？
RTMP vs RTMFP
大話直播
android音視頻點/直播模塊開發一些基本概念
【如何快速的開發一個完整的iOS直播app】(原理篇)
姚東（YY），金山18667號碼農，張雲龍（全民TV), 何李石（七牛）分享如何搭建直播平台淺談
視頻參數（流媒體系統，封裝格式，視頻編碼，音頻編碼，播放器）對比
流媒體中用到的幾個協議簡介
【總結】視音頻編解碼技術零基礎學習方法
【移動開發】關於視頻直播技術，你想要知道的都在這裡了（三）編碼和封裝
【HTML 5】視頻直播一站式掃盲
【React Native】在直播應用中的實踐 | 架構師實踐日
TCP 的那些事兒（上）

WebRTC

Getting Started with WebRTC
【WebRTC】使用WebRTC搭建前端視頻聊天室——入門篇
【WebRTC】用WebRTC搭建前端視頻聊天室——信令篇
用WebRTC搭建前端視頻聊天室——點對點通信篇
WebRTC的RTCDataChannel
7 Creative Uses of WebRTC』s Data Channel
Android之WebRTC介紹

流媒體-伺服器-CDN

奧點雲
七牛
網宿
UCloud
【Nginx】優秀的免費Web伺服器，通過擴展的nginx-rtmp模塊，可以支持流媒體播放和管理。
【EasyDarwin】高性能開源流媒體伺服器，支持RTSP、HLS、HTTP直播

禮物系統，聊天系統，彈幕系統多半依賴IM，可根據自定義的消息來定義不同消息類型；

環信
極光IM
Teameeting-MsgServer 免費開源

連麥互動

視頻直播中用戶連麥技術模型與特點分析（轉載）
全球首創4人連麥-RTMP + RTC
親加通訊雲郝飛：探討直播低延遲低流量的粉絲連麥技術

性能優化

移動直播技術秒開優化經驗（含PPT）
QQ空間直播秒開優化實踐
Facebook 直播如何撐起瞬間 80 萬人的流量？
淺析低延遲直播協議設計：RTP/RTCP
如何實現1080P延遲低於500ms的實時超清直播傳輸技術

優秀開源項目

【Android】DyncRTMPLiveClient-Android-推流-拉流-連麥-彈幕
【IOS】MPCHybirdEngine-IOS-推流-拉流-連麥-美顏-彈幕
ijkplayer-播放器
基於ijkplayer的視頻直播軟體
【IOS】現了作為一個直播App的基本功能，比如本地視頻流採集、播放、美顏、禮物、點贊出心
【IOS】PLCameraStreamingKit
【IOS】一個高仿項目

App技術點

【IOS】仿在直播、映客、Periscope、花椒等直播APP點贊動畫
【IOS】上彈幕源碼實現
【IOS】基於IOS的圖像處理美顏
開源的H.264編碼器
【IOS】直播開源項目喵播-APP
【Android】開源彈幕
【Android】仿花椒直播聊天的時候消息向上彈出，一定時間後自動消失的效果
QQ 空間直播頁面禮物冒泡效果

服務提供商

AnyRTC-全球首創RTMP + RTC;
網易雲信 - 在線教育;
騰訊雲 - 老牌公司;
聲網
阿里雲

專欄博客

WebRTC開發總結
鉑淵信息技術
雷霄驊(leixiaohua1020)的專欄一個廣院工科生的視音頻技術筆記

競品分析-產品方向

全民娛樂直播：映客、花椒直播競品分析
花椒和映客直播App競品分析
視頻直播的發展歷程、產品分類及現況
站在風口，移動直播+營銷將何去何從？
「映客直播」產品體驗報告
移動直播異軍突起：ME直播產品體驗報告

業界新聞

AnyRTC：國內獨家擁有四連麥技術的直播平台
直播逐漸滲透各行各業，在未來有哪些新的趨勢？
給你一幅中國 VR 產業的全景圖（內附PDF版）
在直播大戰中殺出重圍的一種套路—搞CP
PPT+長文推薦：『直播』大時代
以直播類產品為例，產品總監如何制定公司2016年的KPI？
【直播風口】--資訊整合
遊戲直播產品的 10 個 Growth Hacking 營銷案例盤點

歡迎加入我們一起研究直播技術：

GitHub持續更新-歡迎Star

QQ群：580477436
Email: zhulang@dync.cc

看完大神們的總結，醍醐灌頂，水太深了...

視頻直播，確實不是你想做，想做就能做。這是一個強！技術強！運營的工作，非常消耗資源，需要巨額的帶寬成本和頂尖的技術人才。所以第一你得有錢，其次有錢也不能解決問題，得有人才

作為一個想速成的公司來說，能買的服務就盡量買吧（不要問我怎麼知道的），省時省力。視頻雲，買！（個人比較喜歡網宿的服務），還有你說的美顏功能，買！客服系統，買！

前期要準備好至少600萬，不一定夠花3個月，好，接下來我告訴你怎麼花錢

一、帶寬成本=30萬/月

以2w人同時在線來看，手機碼率如果在600Kb，電腦的碼率在1M，基本可以算是高清了，那麼每月的帶寬費用就至少在30萬

二、人力成本=50萬/月

10個技術 = 2萬*10人 = 20萬（服務端4個，IOS3個，安卓3個）

10個運營 = 1萬*10人 = 10萬（主播管理6個，活動策劃2個，主播財務管理2個）

2個產品經理 = 5萬「謝三藏提醒」

5個審核和推薦（假設有500個同時直播）= 3萬

3個客服 = 2萬

1個數據 = 2萬

5個市場和渠道 = 2萬*5 = 10萬

其他人員，如財務、Hr等 = 3萬

三、渠道支出 = 100萬/月

你得投廣告吧，你得買新用戶吧，一個比較理想的用戶單價，假設他為10元/個，那麼你想保持2萬的同時在線，一天至少得要20萬的DAU，粗暴的假設，每天的量中10萬是新增用戶（對於一款新產品這個新增用戶佔比太友好了），其中5萬是自然新增（我特么說的是不是太理想了），那麼你每日，是日！哦，的花費就在50萬，一個月得1500萬。我知道說到這裡你肯定不服，考慮到你要從0做起，一個月做到20萬DAU（然而並不太可能），假設這是一個線性增長，且新增用戶的一半是自然新增不算費用，那麼一個月的費用依然在100萬左右

四、其他成本 = 20萬/月

好了，算到這裡，每個月大概需要200萬的支出，我還是比較節儉的，目前市面上的直播公司，尤其是最近比較火的手機直播軟體公司，沒有一個是草根出身的，都是抱大腿有乾爹的，他們有錢、有技術、有推廣資源，但他們一年後還能不能存在，誰也不能肯定。所以，如果有其他更好的更容易的創業方向，還是選擇其他吧

補充：不知道為什麼，你沒有提到經濟系統，做了用戶付費之後，你可能每個月能有100萬的流水，30萬的收入。美好么？不美好。就算你每天都是20萬的DAU，付費率5%，每月流水1000萬，收入300萬，考慮到其他成本，半年內也一直在燒錢。

102個回答。。。我覺得再洋洋洒洒多少字，恐怕都難以解決你的問題。

這樣，咱先不要急於去尋求答案，先和你朋友坐下來好好聊聊，你朋友做這件事情的目的何在？

先說個題外話——

上周末我在家看了一部電影《楚門的世界》，看完後細思極恐！暗地裡直播主角半輩子的無恥鏡頭不就是我們一天到晚離不開的手機嗎？說遠了。。。國內風靡一時的全民直播不正是這個處處牽動劇中「銀屏外觀眾」的真人秀直播的衍化嗎？

在國內，直播的「星星之火」應該是由李學凌開創的YY直播的崛起，然後以9185和6間房為代表的秀場直播也興起了。一直到成「燎原之勢」的2016直播元年，直播平台像雨後春筍般湧現出來，去年上半年網路直播企業就達到200來家，且90%以上的市場被YY、虎牙、花椒、鬥魚、映客、龍珠、熊貓、戰旗等主流平台瓜分。另外根據Trustdata發布的《2016年移動直播行業分析報告》顯示，花椒直播、映客、一直播等三大直播平台總使用時長佔比超八成，頭部態勢明顯。

以下這張圖你應該在很多地方看過。

一夜之間湧現出這麼多平台，直播平台的競爭就像千軍萬馬過獨木橋一樣。一些一線直播平台光每個月寬頻、運營成本就得上千萬，還要搶資源挖熱門主播！比如虎牙直播今年以1億人民幣簽下知名遊戲女主播Miss……重金聘請當紅主播、動輒千萬甚至過億的挖人，對新入局者來說恐怕難以吃得消。

這種像共享單車一樣陷入白熱化競爭、市場有些飽和且只能靠燒錢大戰攻佔地盤的格局，我不知道還能怎麼突進重圍打入市場分一杯羹？

說到燒錢大戰，好多直播平台後台都硬著呢！像熊貓TV背後有王思聰，章魚TV有樂視，虎牙有歡聚時代，鬥魚和龍珠有騰訊，花椒有奇虎360，火貓TV有阿里巴巴……

現在直播平台大都沒進入盈利模式，這個市場最終也勢必像滴滴收購Uber一樣由獲勝的巨頭收拾戰場，千播大戰，拉鋸戰慘烈，在這樣的勢頭上還想打造一個自己的全新直播平台，我覺得有些BOOK思議。

以上是你朋友想搭建一個全新模式、美女直播平台式的直播平台的市場背景。現在咱來說說直播發展趨勢。

今年6月份，文化部關停了12家網路表演平台，YY直播、龍珠直播、虎牙、秒拍等30家內容違規的網路表演平台被依法查處，映客賣身宣亞、YY旗下ME直播停運……另外《2016年移動直播行業分析報告》指出，隨著直播用戶新鮮感的衰減，直播應用每日打開時長呈逐步萎縮態勢。

直播是載體，是船，而內容是水，有內容船才能動，持續的內容生產才能讓船平穩前行。一些跟色情打擦邊球的直播肯定會翻船。而秀場直播不但引流成本高，而且流量是無法保證的，這是其天花板。

由此我們得出一個結論：秀場直播難以沉澱內容，不能實現持續的自我造血，內容決定直播高度。

因此在這個「內容為王」的時代，可以大膽預測，未來一定是「直播+」的時代，在「直播+」做得好的如在在教育領域獨佔鰲頭的保利威視，支持100萬人同時在線觀看（沒有實測過但人家是這兩年春晚直播指定的平台，並發數應該是能保證的）。我們在上邊做的VR直播測試，視頻參數可達到解析度4096*2048、碼率5M，據說解析度最高能支持4K，而碼率只要保證網路上行沒有限制。甚至還有SVIP直播服務，承諾有任何卡頓全額退款。這些都直接秒殺你朋友做全新直播系統的需求了！

鑒於「直播+」受眾穩定，有持續的流量變現，直播與教育、醫療、金融、電商等實體行業的結合是趨勢，也是未來。利用直播平台去做內容倒不失為一個好機遇。

打了這麼多「驢頭不對馬嘴」的字，不是打擊你朋友啊，而是要先認清局勢——如果了解了直播發展階段和趨勢，你朋友還想立志做這樣一個視頻直播系統，那麼我……無話可說。滑鼠請滾動到贊數最高的答主的回答。

祝你朋友好運。

一開始看到「美顏」二字，第一個想到就是手機，因為手機的美顏功能還是很強大的，操作也較為方便，但是手機受到的局現性也比較大，如果真要做直播，採用電腦或者攝像機，整體效果還是會好一些。

去年開始，直播已經成為一種潮流，因此也有很多直播平台也一涌而出，但是是自己搭建方便省錢還是找第三方平台好呢？下面我們簡單來分析一下：

視頻直播，主要是由採集、編碼、傳輸、分發、播放、互動和回看這幾個環節組成的。其實看到這幾個環節，估計大家都能預估到搭建一個完整的視頻直播系統的難度以及成本了吧，哈哈。但在用戶看來，只要能發起直播，觀眾能觀看，而且覺得聲音畫質效果不錯就行，至於中間的視頻編碼、數據傳輸等環節，只要有技術團隊就OK了。但其實不是這樣的，舉個例子，編碼，至少也要有單獨的伺服器吧，數據的分發、傳輸，如果要穩定，肯定還是要依託CDN的，但是CDN的價格也不便宜，而且後期的技術維護，人力成本等也要考慮進去吧。但是如果找一個成熟的第三方平台服務商，有提供CDN、帶寬等，還有技術支持，雖然前期付出的成本可能會比較高，但是後期一旦運營起來，成本、效果等都是明顯可以得到對比的。下面我也分享一下自己的經歷。

前段時間，因為要做一場直播，一開始想著自己搭建平台，應該也能省掉不少成本，但事實卻不是這樣。在開發的過程中，碰到很多坑，也想方設法去解決，但最終還是沒成功。因為前期耗費了太多時間，後面項目趕著上線，我就直接找了幾家直播平台做比較，下面我挑了幾個來說一下，題主可以參考一下。

騰訊雲，2015年創立的，屬於PAAS層服務商，直播功能也是比較簡單基礎的，國內的節點也不多，如果真像上面題主提到的，要支持2W人在線觀看，還需要再實戰測試一下。在體驗騰訊雲產品的時候，感受最深還是在於客服對接這方面，回復很慢，而且對接的人有好幾個，都分不清那個是主要負責人，工單的響應也較慢，體驗不是很好。價格方面，騰訊雲是按照流量來計費的，價格還是比較便宜。如果題主前期預算比較有限的話，騰訊雲也可以作為一個考慮對象。

微贊，一站式微信社群與內容變現的SAAS雲，其立足的基礎就是微信，核心部分主要還是在於營銷方面而不是技術。不過微贊的推流端是有美顏功能的，也支持多種直播形態。價格也是相對來說比較便宜，一年只需要3000元或者6000元。但也是由於微贊沒有技術功底，很多客戶在使用過程中經常出現問題，但是卻沒有專門的負責人來對接，基本上客戶有問題都是需要通過他們的400電話或者論壇自助解答，響應速度很慢，口碑在業界相對較低。

保利威視：2012年創立的，屬於SAAS層服務商。支持電腦和手機發起直播，操作也比較簡單。上面題主也提到不能卡頓，但是個人覺得卡頓的原因有很多，最主要還是在於網速。不過之前在保利威視做過幾次測試，過程還是比較順暢的。而且還可以添加自己的logo、水印、廣告等，現在他們家也是可以支持語音、視頻互動，一帶三，發紅包打賞等，功能相對來說還是蠻齊全的。另外在服務方面，保利威視給我印象最深的就是，他們的客服都很貼心。因為我在體驗過程中，很多不懂，他們客服都一步一步的指導我如何操作，很有耐心，而且問題回復也很及時。價格方面，保利威視主要是按分鐘數，價格不算便宜，但也不算很貴，處於中等階段。

每個平台都各有優劣勢，最終選擇哪個平台，還是要結合題主具體的需求和預算。不過相對於自建來說，個人覺得，前期還是可以考慮找個成熟的第三方平台，等後期運營起來之後再做考慮自建。畢竟運營時間長了，技術團隊也有了，那麼搭建起來也容易些了。另外在直播方面，延遲和穩定，也是用戶最在意的兩個點，所以如果要找第三方平台，還是找大公司的雲服務商，口碑好點，產品也是比較可靠，雖然價格可能會貴些，但是有了穩定性和對應的服務為依託，總體性價比還是較高的，也是值得託付的。

這樣的問題不如換成怎麼挖到一個視頻直播網站的主程序團隊

如何快速搭建一個完整的手機直播系統

在這個直播如火如荼的時代，各大雲服務提供商也站到了時代的風口上，因此，如何選擇產品和服務快速搭建直播系統，我想應該是眾多創業者最關心的問題了，趣拍直播SDK就很好集成，下面會跟大家一一分享。

下面，我們先看下搭建一個完整的手機直播都包含哪些必須的環節：推流端（採集、前處理、編碼、推流），服務端處理（轉碼、錄製、截圖、鑒黃），播放器（拉流、解碼、渲染）、互動系統（聊天室、禮物系統、贊）。

手機直播推流端需要做哪些工作？

直播推流端即主播端，主要通過手機攝像頭採集視頻數據和麥克風采集音頻數據，經過一系列前處理、編碼、封裝，然後推流到CDN進行分發。

採集

手機直播SDK通過手機攝像頭和麥克風直接採集視頻數據和音頻數據。其中,視頻採樣數據一般採用RGB或YUV格式、音頻採樣數據一般採用PCM格式。對於採集到的原始音視頻的體積是非常大的，因此需要經過壓縮技術來處理，降低視頻的大小來提示傳輸效率。在手機視頻採集方面，iOS系統在硬體的兼容性方面做得比較好，系統本身提供了比較完整的視頻採集的介面，使用起來也比較簡單。但是，Android系統就比較麻煩了，千奇百怪的機型都有，適配起來非常難。我們在初期做了一項調研，發現Android的適配率還不到50%。

前處理

在這個環節主要處理美顏、水印、模糊等效果。特別是美顏功能幾乎是直播的標配功能，沒有美顏的直播主播們根本提不起興趣。我們見過太多case是因為沒有美顏功能被拋棄使用的。另外國家明確提出了，所有直播都必須打有水印並回放留存15天以上。所以，在選擇直播SDK時，沒有美顏和水印功能基本就可以選擇放棄了。

美顏實際上是通過演算法去識別圖像中的皮膚部分，再對皮膚區域進行色值調整。通常情況下人的膚色與周邊環境色調存在較大差異，通過顏色對比，找到皮膚的基本輪廓，進一步進行膚色檢查還可以確定人臉範圍。找到了皮膚的區域，可以進行色值調整、添加白色圖層或調整透明度等來等來達到美白效果。美顏除了美白效果還需要磨皮功能，磨皮實際上就是用模糊濾鏡實現的。濾鏡有很多種，如高斯濾波，雙邊濾波，導向濾波，到底選擇什麼樣的模糊濾鏡各家也有自己的喜好。

在美顏處理方面，最著名的GPUImage提供了豐富的效果，同時可以支持IOS和Android，還支持自己寫演算法實現自己最理性的效果。GPUImage本事內置了120多種常見濾鏡效果，添加濾鏡只需要簡單調用幾行代碼就可以了，比如大家可以試試使用GPUImageBilateralFiter的雙邊濾波濾鏡來處理基本的磨皮效果，想要實現更理想的效果還是要通過自定義演算法去實現的，各家也都有自己一套演算法。

編碼

為了便於手機視頻的推流、拉流以及存儲，通常採用視頻編碼壓縮技術來減少視頻的體積。現在比較常用的視頻編碼是H.264，但具有更高性能的H.265編碼技術正在飛速發展，並可能很快成為主流；在音頻方面，通比較常用的是用AAC編碼格式進行壓縮，其它如MP3、WMA也是可選方案。視頻經過編碼壓縮大大提高了視頻的存儲和傳輸效率，當然，經過壓縮後的視頻在播放時必須進行解碼。通俗點講就是編碼器將多張圖像進行編碼後產生一段段GOP（Group of Pictures），播放時解碼器讀取一段段GOP進行解碼後讀取圖像並進行渲染顯示。在編碼方面的核心是在解析度、碼率、幀率等參數中找到最佳平衡點，達到體積最小畫面最優的效果，這些參數各家也都有自己的一套核心參數。

2012年8月，愛立信公司推出了首款H.265編解碼器，六個月後，國際電聯(ITU)就正式批准通過了HEVC/H.265標準，稱之為高效視頻編碼(High Efficiency Video Coding)，相較於之前的H.264標準有了相當大的改善，做到了僅需要原來一半帶寬即可播放相同質量的視頻，低於1.5Mbps的網路也能傳輸1080p的高清視頻。國內，如阿里雲、金山雲都在推自己的H.265編解碼技術，隨著直播的快速發展和對帶寬的依賴，H.265編解碼技術已有全面取代H.264的趨勢。當然，全面推開應用還需要些時間。

另外，硬體編碼已經成為手機直播的首選方案，軟編碼處理在720p以上的視頻頹勢非常明顯。在IOS平台上硬體編碼的兼容性比較好，可以直接採用，但在 Android 平台上，Android的MediaCodec 編碼器，針對不同的晶元平台表現差異還是非常大的，要完全實現全平台兼容的成本還是非常高的。

推流

要想用於推流還必須把音視頻數據使用傳輸協議進行封裝，變成流數據。常用的流傳輸協議有RTSP、RTMP、HLS等，使用RTMP傳輸的延時通常在1–3秒，對於手機直播這種實時性要求非常高的場景，RTMP也成為手機直播中最常用的流傳輸協議。最後通過一定的Qos演算法將音視頻流數據推送到網路斷，通過CDN進行分發。在直播場景中，網路不穩定是非常常見的，這時就需要Qos來保證網路不穩情況下的用戶觀看直播的體驗，通常是通過主播端和播放端設置緩存，讓碼率均勻。另外，針對實時變化的網路狀況，動態碼率和幀率也是最常用的策略。

當然，在網路傳輸方面全部自己來做基本不現實，找提供推流服務的CDN服務商提供解決方案是最好的選擇，可參考文章開頭介紹的雲視頻服務商。據了解，阿里雲是國內唯一能自研CDN緩存伺服器的廠商，性能還是非常有保障的。通常，大多數直播平台都會同時接入多個視頻雲服務提供商，這樣可以做拉流線路互備，對推流後視頻集群再進行優化也可提高直播的流暢性和穩定性。

服務端處理需要做哪些工作？

要想適配各終端和平台，服務端還需要對流進行轉碼，如支持RTMP、HLS、FLV等格式拉流，支持一路轉多路適配不同網路和解析度的終端設備。另外，像現在必備的鑒黃功能也需要服務端完成。

截圖、錄製、水印

像阿里雲、金山雲、UCloud等雲服務商都提供了實時轉碼技術將用戶推流碼率較高（比如720P）實時轉化成較低清晰度（比如360P）的流以適應播放端的需求。如果要自己搭建實時轉碼系統，這個成本是極高的。一台8核設備只能實時轉10 路流，如果一個正常的直播平台有1000路流，那至少就需要100台設備，加上後期的運維成本，一般公司就吃不消了。實時截圖功能和實時轉碼類似，只是一般單機可以處理100路流。市面上雲服務提供商基本上都提供了服務端轉碼、截圖、錄製功能，建議選擇好的雲服務提供商即可，可以節約大量成本。

鑒黃

2016年，4月14日上午10時，文化部公布了一則消息，鬥魚、虎牙、YY、熊貓TV、戰旗TV、龍珠直播、六間房、9158等網路直播平台因涉嫌提供含宣揚淫穢、暴力、教唆犯罪等內容的互聯網文化產品，被列入查處名單。文化部已部署相關執法機構查處涉案企業，將及時公布處罰結果。在前期的野蠻生長後，國家介入管制一定程度上遏制了直播的發展速度，但更有利於直播行業打造健康的生態，進入良性發展。這也意味著直播行業鑒黃成了必須環節，使用技術手段去鑒黃是手機直播平台必然採用的方案。

市面上提供鑒黃服務的方案主要有兩種，第一種是對視頻進行截圖，然後對圖片進行鑒黃，返回鑒黃結果和分值。典型的企業有阿里（綠網）、圖譜科技，他們目前都支持直接傳入視頻，經過服務端分析返回結果，鑒黃的結果分為色情、疑似色情、正常或性感，並對每種結果進行打分。通常由業務系統接入鑒黃服務，根據鑒黃結果對直播流進行控制，如切斷直播流、禁用用戶的賬號等。第二種是和CDN結合，直接對直播流進行分析，識別結果也分為色情、疑似色情、性感和正常，業務系統根據識別結果直接控制直播流。典型的企業是Viscovery，這套方案的優點是實時性保證比較好，缺點是必須部署到CDN或自己的機房，使用成本相對高一些。

趣拍微視頻雲服務作為一站式直播解決方案提供商，我們的主旨是讓用戶以最短時間、最小成本接入直播服務。因此，用戶只需在控制台對鑒黃服務進行配置就可以針對每個應用，每一路直播流進行實時審核，審核內容包括色情、暴恐、時政敏感等。在控制台中，趣拍微視頻服務實時將鑒黃結果返回，用戶可以直接查看色情直播和違規界面的截圖，同時可以對直播流進行控制，切斷問題直播流。我們提供了簡訊、郵件和站內信提供功能，避免漏洞一個非法視頻，給平台造成損失。數據統計功能讓用戶可以把握平台最新的動態信息，為進一步採取必要的措施提供可靠的依據。同時，為了滿足用戶定製化需求，我們還提供了豐富的介面，可以很方便的將鑒黃服務接入到自己的業務系統。

播放器端需要做哪些工作？

在播放器端如何做到秒開，在直播過程中保證畫面和聲音清晰度的同時，穩定、流程、無卡頓的直播流量，這些工作都需要播放器端配合服務端來做優化，做到精確調度。

拉流

拉流實際是推流的逆過程。首先通過播放端獲取碼流，標準的拉流格式有RTMP、HLS、FLV等。RTMP是Adobe的專利協議，開源軟體和開源庫都支持的比較好，如開源的librtmp庫，播放端只要支持flashPlayer的就能非常簡單的播放RTMP直播，直播延遲一般在1–3秒。HLS是蘋果提出的基於HTTP的流媒體傳輸協議，HTML5可以直接打開播放，通過微信、QQ等軟體分享出去，用戶也可以直接觀看直播，可以說手機直播app，HLS拉流協議是必須支持的，缺點是延遲通常大於10秒。FLV（HTTP-FLV）協議是使用HTTP協議傳輸流媒體內容的一個協議，也不用擔心被Adobe的專利綁架，直播延遲同樣可以做到1–3秒。

趣拍微視頻雲服務的直播拉流提供了RTMP、HLS、FLV三種格式，滿足不同業務場景的需求，如對即時性要求較高或有互動需求的可以採用RTMP或FLV格式進行直播拉流播放；對於有回放或跨平台需求的，推薦使用HLS。當然，三種協議是可以同時使用的，分別用到自己的場景就可以了。

解碼和渲染

拉流獲取封裝的視頻數據後，必須通過解碼器解碼、渲染後才能在播放器上播放。它是編碼的逆過程，是指從音視頻的數據中提取原始數據。前面介紹的H.264和H.265編碼格式都是有損壓縮，所以在提取後的原始數據，並非原始採樣數據，存在一定的信息丟失。因此，在視頻體積最小的情況下通過各種編碼參數保留最好的原始畫面，成為了各視頻公司的核心機密。

考慮對高清的支持，解碼肯定還是要選擇硬解碼的。前面介紹過，IOS系統由於硬體比較單一、比較封閉，支持的比較好，Android系統由於平台差異非常大，編解碼要完全兼容各平台還需要很多工作要做。

渲染最大的難點不在與畫面繪製，而在於畫音同步，業內大部分直播平台在這塊做的都還是不夠的。我們在這方面積累了一些經驗和大家分享。

手機直播中的交互系統

手機直播中最常見的交互有聊天室（彈幕）、點贊、打賞和禮物等，有些比較有特色的手機直播平台也加入了和主播互動的遊戲功能。交互系統涉及消息的實時性和互動性，在技術實現上大多是使用IM的功能來實現的，對伺服器的壓力也是比較大。對於在線人數比較多的房間，彈幕消息量是非常大，主播與用戶其實都看不過來，為了緩解伺服器壓力，在產品策略可以做一些必要的優化，比如對於發送消息的頻率進行限制或對每條消息發送對象的上限進行限制等。

聊天室

手機直播中的彈幕交互功能已經成為直播必不可少的部分，是用戶和主播互動的主要方式。手機直播中的彈幕實際上就是IM中的聊天室功能。聊天室和群聊功能類似，但聊天室的消息是不需要分發給不在線的用戶的，對於歷史消息也不需要查看，用戶只有進入聊天室後才能查看聊天消息和群成員信息。要面對複雜多變的網路狀況，還需要根據用戶位置就近選擇近對應運營商的單線機房接入彈幕消息服務，讓彈幕更及時。當然，可以根據團隊情況選擇自己搭建還是選擇第三方的聊天服務。

趣拍直播SDK提供豐富的聊天室功能和介面，以最簡單的方式對接自己的聊天系統或第三方的聊天系統。

禮物系統

禮物系統已是絕大多數手機直播平台的標配了，它是這些平台主要的收入來源。在手機直播平台上我們常常可以見到土豪秒榜、土豪對刷的情景，據報道，明星直播一場禮物收入幾十萬也是常有的事，一年千萬收入的網紅也不少，可見國內有禮物消費習慣的土豪還不少。另一方面，送禮物的形式增強了用戶和主播之間的互動交流，也是主播依賴平台的最主要原因。

禮物的收發在技術實現上也是用聊天室介面做的，通常採用IM中的自定義消息實現，當用戶收到或發送禮物時將自定義消息對應的禮物圖形渲染出來。另外，面對大量用戶刷禮物時，禮物系統對一致性要求就比較高了，所以在實現上存一份數據建多條索引是一種很好的選擇，也可以降低對事務的依賴。

手機直播的前景

手機直播行業現在如此火熱，我們認為這個火熱會在很長一段時間內持續，並且在未來通過和各行業的整合，會成為具有無限可能性的行業。所以直播SDK的選擇也成為一些企業的轉折點，就比如趣拍直播SDK吧，擁有視頻開發行業長達10年的歷史，和阿里雲、支付寶、釘釘、芒果直播有著緊密的合作，關於趣拍直播的雲服務和技術總是能跑在行業的前面，選擇趣拍直播SDK是一種信任。

往主要原因包括如下幾點：

第一，手機直播的UGC生產模式比PC端的直播更明顯，人人都有設備，隨時隨地開播，完全順應了互聯網時代的開放性原則，全民直播時代將內容生產潛力發揮到最大。如今，「網紅經濟」如此火熱，更是刺激更多人去創造和傳播優質內容。作為網紅經濟的代表，papi醬融資1200萬，估值2億，廣告招標溝通會門票8000元/張，單條貼片廣告中標價2200萬，一個個數字都如此刺激大眾眼球。手機直播中的網紅價值也在被更多創業者重視，擁有極大的增漲空間。

第二，網路帶寬和速度在逐漸提高，網路成本在逐漸下降，4G乃至今後的5G也會像今天的有線網路那麼廉價，為手機直播提供一個極佳的發展環境。技術的發展，手機可以承載的內容也就越豐富，文字、聲音、視頻、遊戲等都會在手機直播中呈現，創造更加豐富的用戶體驗。各行業都可以將直播作為一種工具接入到自己的應用中，教育、社交、電商、金融等行業都可以通過手機直播形式開展新業務，增強與用戶之間的互動，提高用戶粘性。比如，教育領域中的課後輔導完全可以以直播的形式開展業務，電商也可藉助直播讓用戶挑選商品，促進銷售。

第三，一個與VR/AR技術相結合的手機直播為整個行業的未來提供了新的發展空間。VR/AR直播能夠讓用戶身臨其境，帶動主播與觀眾更貼切真實的互動，大大提高平台的用戶參與度。更加創新的硬體設備與直播的結合，如穿戴設備，更加豐富的感測器，更方便的採集信息，也將會大大拓展手機直播未來的應用場景。哪家公司如果在VR/AR和穿戴設備上取得突破性進展勢必會在直播行業取得領先地位。

總之，手機直播欣欣向榮的發展已是必然趨勢，儘管國家層級在加強管控、內容創作上還比較單一，紅海一片搏死拼殺，但是它的未來是一個具有無限可能的超級市場，這個領域必然將會誕生千億市值的巨頭。

播推流端即主播端，主要通過手機攝像頭採集視頻數據和麥克風采集音頻數據，經過一系列前處理、編碼、封裝，然後推流到CDN進行分發。

採集

前處理

編碼

推流

我的這個回答更偏向於移動端直播的構建，期間走了不少歪路，在這裡總結下經驗提供給大家，有錯誤的地方歡迎指正。

推薦閱讀（都是自己寫的文章）：

移動直播六大關鍵技術詳解

直播雲功能基礎篇：推流和拉流、多協議輸出、多訪問方式、回源埠自定義

直播雲功能處理篇：轉碼、錄製、視頻水印、視頻截圖

直播雲功能高級篇：防盜鏈、秒級禁播、自動鑒黃、API介面

正文：

視頻直播，主要涉及到採集、預處理、編碼、傳輸、伺服器轉碼、解碼這樣一個流程。如圖所示

一、採集：採集主要包含圖像採集和音頻採集；

圖像採集設置前置攝像頭、後置攝像頭，並配置採集的參數、圖像數據的長寬、fps、輸出的方向、橫屏豎屏等，然後從回調中取到數據。

音頻採集和編碼主要面臨的挑戰在於：雜訊消除（Denoise）、回聲消除（AEC）演算法等。

前期不需要音頻數據處理需求的時候，只需配置音頻採集的採樣頻率、採樣精度和聲道。

二、預處理：分為音頻處理和視頻處理兩個方面。

音頻處理是直播難點之一，尤其主播離手機有一段距離，直播環境會有噪音，所以直播的音頻處理是整體降噪的過程。增益降噪等處理可直接從 speex 項目中抽出來的聲音處理代碼，然後調用、處理。如有類似在直播的時候播放背景音樂的混音需求，就需要使用 Audio Unit 來實現音頻數據的混音，而還需要將混音的背景音樂轉成 PCM 數據，拷貝一份送入混音，原來的數據送入播放器。

濾鏡、美顏功能是直播標配，如果需要美白、水印、裁剪等處理效果，就必須處理拿到的 buffer, 這個時候還要考慮到拿到的數據是 YUV 還是 RGB。iOS 上是不能對 YUV 格式直接進行美顏處理，只能是 RGB 格式。可選擇使用 GPUImage 庫，調用 GPUImage 來進行採集和美白、水印、裁剪的處理，然後取出來進行編碼上傳，並顯示在預覽畫面上。

三、編碼：

軟編碼: 現在廣泛採用 FFmpeg 庫結合編碼庫來實現，FFmpeg + x264 來編碼視頻數據 YUV/RGB 輸出 H264 數據， FFmpeg+fdk_aac 來編碼音頻數據 PCM 輸出 AAC 數據。

硬編碼: iOS 8 之後開放了硬解碼和硬編碼 AP，所以基本上都是選擇 VideoToolBox 和 AudioToolBox 進行圖像和音頻的硬編碼。

四、傳輸：又拍雲播放器採用 FFMPEG 進行數據的接收，推流端默認使用 FFMPEG 進行數據的封包發送。

相對來說，封包最主要注意的一個點是時間戳。因為用的 AVPacket 封包，每個包都會有一個DST(Decode Time Stamp)、PST (Presentation Time Stamp) 參數，從字面上可以理解，就是解碼時間和顯示時間，在沒有 B 幀存在的情況下 DTS 的順序和 PTS 的順序應該是一樣的。這塊還涉及到重連和丟幀，用戶的網路情況波動斷開了,會進行重連。重連失敗之後才會發送失敗回調。丟幀是一個弱網情況的策略，根據音視頻數據的緩衝區大小來判斷是否丟幀,丟幀會優先丟非關鍵幀，保留關鍵幀，而一旦需要丟關鍵幀的時，關鍵幀後的非關鍵幀也會一起丟掉直到下一個關鍵幀，來保證畫面不會花屏。

五、服務端

現在主流的兩種推送協議是 RTMP 和 HLS，兩者的優缺點我就不在這裡做比較了。又拍直播雲採用用的是 RTMP 協議。

六、播放器

播放器主要負責拉流、解碼、播放。

1. 解析協議

播放器端根據 URL 解析所用的流媒體協議（RTMP，HLS）。

2. 解封裝

解封裝，就是 demux 的過程，從容器格式（FLV，TS）中，分離出音視頻數據。

3. 解碼

解碼，就是把獲取到的數據解壓縮，恢復成原始數據。解碼就是將 H264 變成 YUV，AAC 變成PCM。解碼可以使用軟解碼，硬解碼。

4. 渲染數據

採用 OpenGL 渲染 YUV 數據，呈現視頻畫面。將 PCM 送入設備的硬體資源播放，產生聲音。

iOS 播放流式音頻，使用 Audio Queue 的方式，即利用 AudioToolbox.Framework 框架。

這裡都講的都比較簡單，沒有深入到技術點。如果對直播技術興趣的小夥伴，可以閱讀推薦閱讀，歡迎技術探討交流。

視頻直播技術還沒有什麼成熟的框架。都是各大公司自己弄的，技術門檻不低。同時涉及的帶寬、伺服器資源驚人。自建基本沒戲。沒有上億的資金做墊底，我覺得就不用想了。可以考慮下雲服務。例如網易雲。同時在線2萬。網易的報價是70萬/月。什麼美顏混音暫時就不用想了。

=================

這種問題其實純粹浪費大家時間，對IT一竅不通的土豪根本不知道後面成本是多麼驚人。