102 個回答
視頻直播，可以分爲 採集，前處理，編碼，傳輸，解碼，渲染 這幾個環節，下面分別說下：
採集，iOS是比較簡單的，Android則要做些機型適配工作，PC最麻煩各種奇葩攝像頭驅動，出了問題特別不好處理，建議放棄PC只支持手機主播，目前幾個新進的直播平臺都是這樣的。
前處理，現在直播美顏已經是標配了，80%的主播沒有美顏根本沒法看。美顏算法需要用到GPU編程，需要懂圖像處理算法的人，沒有好的開源實現，要自己參考論文去研究。難點不在於美顏效果，而在於GPU佔用和美顏效果之間找平衡。GPU雖然性能好，但是也是有功耗的，GPU佔用太高會導致手機發燙，而手機發燙會導致攝像頭採集掉幀，iPhone6尤其明顯，因爲iPhone6的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秒間隔就出之前的各種問題定位，這個定位包括從源站收集的數據畫的曲線。還有從端上，如果端上用戶允許的話，推流和拉流端我們都會有上報數據，幾個曲線一擬合，我們就知道問題出在哪裏。
利息相關：金山雲架構師。
- PC、Android、iOS三大平臺（一般互聯網創業項目標配）
- 每個平臺要做2種端：面向客戶的直播端，和麪向主播的推流端（標配x2）
- 視頻編碼涉及非常多的技術參數和細節（領域特殊技術）
- 完整的禮物系統、支付系統、運營系統、任務系統（不亞於一般頁遊項目）
- 即時聊天IM服務（彈幕，既要保證實時性，又要抗住高併發）
- 視頻推流拉流鏈路依賴第三方CDN（超越一般創業項目的運維成本）
- 因爲涉及錢的問題，經常與各種黑暗勢力鬥爭（色情、廣告、刷小號、刷充值、告侵權、DDoS等等）
- 即使聊天IM技術難度也很大啊，尼瑪一個大主播的直播間有十幾萬人同時在線，一個人發消息要十幾萬人都收到啊，大主播還經常帶節奏，十幾萬人一起發消息要十幾萬人一起收啊，想象這個瞬間的高峯是個什麼鬼！
- 視頻直播的鏈路很長，CDN經常坑爹啊，主播推流客戶端各種亂配，運營商各種劫持，出了問題都不知道甩鍋給誰啊！
- 支付系統一定要仔細搞啊，每個環節都要仔細想清楚各種異常情況啊，所有消費都要有流水記錄，警惕蘋果黑卡啊
- 研發團隊不好招人啊，我每週篩選6、70份簡歷，安排面試1、20人，也才能敲定3、4個offer，以這樣的強度估計還要再堅持幾個月啊
- 各種合作方的接入，各種賽事活動的接入，市場、運營、產品、客服各方都給你提需求啊，一個人要掰成好幾個人用
- 即便如此，作爲研發，看到不順心的代碼還是想重構啊，要在高速公路上冒着煙極速飛奔的汽車上，一邊開車一邊換輪胎啊！
- 團隊快速擴張，彼此要磨合，管理能力還要能跟上啊，新人大量加入，還要安排好工作啊。
總之過去的一個月我是感覺自己無論在技術能力還是管理能力上的進步好像都超過了此前5年在大公司積累的總和，做視頻直播項目真的很虐心，也真的非常磨練人，現在整個視頻直播領域狼煙四起，頗有當年百團大戰的意味，作爲研發，我想要是能與現在的團隊一起奮鬥成長，並在這個領域爭得一塊立足之地，也算是一項非常了不起的成就了。
如果你僅僅爲了一個構想的新模式而嘗試涉足我覺得現在這個時間點已經沒有必要了，各方面資源的投入成本都會非常非常高，做個demo玩玩還行，深入做下去真是山高路遠坑深。
順便打個廣告，爲我的團隊招人，可以發簡歷到 [email protected]
最近直播很火，很多大公司和中小創業者都想抓住這個機會做一番事業。「如何搭建一個完整的視頻直播系統？」這是一個很大的問題，不是一兩個答案能夠解釋清楚的，但我還是儘量技術和創業的角度提供給題主儘可能多的信息。
正如 @姚冬 所說，一個完整的直播系統大致包含這幾個環節：採集、前處理、編碼、傳輸、解碼和渲染。在兩端傳輸的過程中再加上一個服務端處理。大致的模型如下：
在主播推流端涉及到的環節有采集、前處理和編碼，在觀衆端涉及到的環節就是解碼和渲染，在這兩個端之間建立起傳輸通道的則是服務端，它負責接收主播端的推流，將其處理之後分發給觀衆播放端：
1. 採集
採集是播放環節中的第一環，iOS 系統因爲軟硬件種類不多，硬件適配性較好，所以比較簡單。Android 則不同，市面上硬件機型非常多，難以做到一個庫適配所有硬件。PC 端的採集也跟各種攝像頭驅動有關，推薦使用目前市面上最好用的 PC 端開源免費軟件 OBS: Open Broadcaster Software
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=404230356&idx=1&sn=6b73f971c4cf1170adaf4d249480ed9a&scene=1&srcid=0301qrbBZPrLxORTiD5D5IO1&key=b28b03434249256be5dfe068862f4c51d10c5e16b3659de35ce26bd4868f3a186366844bc7a8d3eaf48192b75536009b&ascene=0&uin=MTUwMTI2NjQ2MA%3D%3D&devicetype=iMac+MacBookPro11%2C2+OSX+OSX+10.11.4+build(15E65)&version=11020201&pass_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從後兩種之間選擇好了。建議是去這幾家公司的官網對比一下價格。我這裏截了幾張圖，從上到下分別是七牛雲，Upyun和星域。
七牛雲
Upyun
星域CDN直播
不同的CDN廠商，根據不同流量區間價格不一樣，按流量計費和按帶寬計費也是不一樣的。
直播平臺的帶寬成本比較高，這時價格之間的差異對選擇天平的傾斜影響還是相當大的。或者，也可以找一些免費送流量的公司體驗一下，這樣可以無需充值就能感受到服務的效果。比如說：七牛0-10GB就是完全免費的，星域註冊也會送100G。另外，如果數據量夠大的話，星域的單價比起其他家明顯會低很多。
另外，可以通過觀察CDN企業服務的直播平臺來認識他們的實力。畢竟，大公司在採購時會有很嚴格的要求，基本上能通過的也都是經過九九八十一難，“剩者爲王”。自己列了一張表，不一定全，僅供參考。
從CDN說回直播本身，在拉流之後就是視頻的解碼、渲染等等，這一塊對於硬件的要求比編碼會低一些，技術上難度也會小一點。這裏邊也有一些細節，比如軟硬碼自動切換，連麥互動，H.265解碼，動態追幀，播錄一體化這些。每一個細節，都有可能帶來用戶體驗上的差距。
當然，以上說的只是直播平臺技術裏視頻的一部分，樓上
老師說的很好，音頻、禮物、數據庫甚至支付都是不得不考慮的事情。至於技術準備和資金門檻，只能說：以一個創業公司的資金和資源從零做起的話，很多問題其實確實是不太容易解決的。一個好的直播平臺，光是技術的解決方案上百萬就是杯水車薪，而且要找到靠譜的人才能畫好這筆錢。尤其是趕上這輪資本寒冬，直播平臺裏邊老大老二基本分出來了，如果現在想融到兩千萬然後拿出上千萬搞技術——未必可行。好在國內市場足夠大，允許各種各樣的競爭者同時出現，所以最近有一些做雲計算和CDN的廠商，乾脆把直播的技術解決方案整合成了SDK，賣給創業公司。
這類SDK能做的事情，還是比較多的，網上找來了張圖，題主和大家也可以參考一下。而且，這一類解決方案因爲相對標準化，所以成本相當低，價格也不高。當然，做這種事情的門檻不低，基本上都是比較大的CDN廠商在做。
比如文章上邊提到的星域，就是直接把視頻推拉流、採集、轉碼之類的技術打包在了一起，同時優化各個環節。畢竟，CDN行業的競爭很激烈，價格也是逐年下跌，所以服務商們爲了找自己的差異化競爭點，還是很賣力氣的。
總結起來，一是直播平臺在技術方面的要求很高，尤其是CDN一塊專業性很強，想完全用自己的技術解決不現實；二是，要麼捨得砸錢招BAT技術團隊，要麼就用標準化的技術解決方案——畢竟直播平臺技術只不過決定着及格線，真正的核心競爭力在於產品和運營。如果真的有那麼多錢，還不如把技術上省下來的錢花在網紅的簽約和入駐上，對吧！
直播產品首先要確認是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路流，這個設備投入是天文數字，所以別花心思自己搞設備區轉了。 當然對於足夠針對熱度的流做優化是有價值的。
搭車放個招人廣告，有視頻終端或後臺系統開發的同學，可以發簡歷至[email protected]
提問者如果打算自建視頻直播平臺，成本確實很高，技術門檻也比較高。我就從調用相關雲服務的角度來說好了。相對來說，效率要高得多。
搭建一個完整的視頻直播系統，首先要了解一般直播產品的架構。架構圖如下：
其次要選擇一個功能完善，性能良好，運行穩定的視頻雲平臺。目前市場上主流的有百度雲，騰訊雲，樂視雲，歡聚雲，暴風雲，網易視頻雲，目睹直播這些。還有其他的就不一一列舉了，重點分析一下列舉的這幾個的特點。
騰訊雲。定位：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源碼。感興趣的朋友可私聊。歡迎交流，相互學習。知乎專欄 這篇文章彙集了我對這個行業的理解，歡迎大家指點
直播技術要求這塊上面已經講的很詳細了，我就不再贅述了。作爲又拍直播雲的研發，這邊就說說接入又拍直播雲（直播雲 - 一站式視頻直播加速）的流程，非常的簡單方便。新用戶通過官網註冊賬號，並進行個人/公司認證，審覈通過後可以正常使用控制檯。詳細步驟如下所述：
創建服務：
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/
下面是我在開發直播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，可根據自定義的消息來定義不同消息類型；
連麥互動
性能優化
- 移動直播技術秒開優化經驗（含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：國內獨家擁有四連麥技術的直播平臺
- 直播逐漸滲透各行各業，在未來有哪些新的趨勢？
- 給你一幅中國 VR 產業的全景圖（內附PDF版）
- 在直播大戰中殺出重圍的一種套路—搞CP
- PPT+長文推薦：『直播』大時代
- 以直播類產品爲例，產品總監如何制定公司2016年的KPI？
- 【直播風口】--資訊整合
- 遊戲直播產品的 10 個 Growth Hacking 營銷案例盤點
歡迎加入我們一起研究直播技術：
QQ羣：580477436
Email: [email protected]
視頻直播，確實不是你想做，想做就能做。這是一個強！技術&強！運營的工作，非常消耗資源，需要鉅額的帶寬成本和頂尖的技術人才。所以第一你得有錢，其次有錢也不能解決問題，得有人才
作爲一個想速成的公司來說，能買的服務就儘量買吧（不要問我怎麼知道的），省時省力。視頻雲，買！（個人比較喜歡網宿的服務），還有你說的美顏功能，買！客服系統，買！
前期要準備好至少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萬，考慮到其他成本，半年內也一直在燒錢。
在這個直播如火如荼的時代，各大雲服務提供商也站到了時代的風口上，因此，如何選擇產品和服務快速搭建直播系統，我想應該是衆多創業者最關心的問題了，趣拍直播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進行分發。
採集手機直播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緩存服務器的廠商，性能還是非常有保障的。通常，大多數直播平臺都會同時接入多個視頻雲服務提供商，這樣可以做拉流線路互備，對推流後視頻集羣再進行優化也可提高直播的流暢性和穩定性。
我的這個回答更偏向於移動端直播的構建，期間走了不少歪路，在這裏總結下經驗提供給大家，有錯誤的地方歡迎指正。
推薦閱讀（都是自己寫的文章）：
直播雲功能基礎篇：推流和拉流、多協議輸出、多訪問方式、回源端口自定義
正文：
視頻直播，主要涉及到採集、預處理、編碼、傳輸、服務器轉碼、解碼這樣一個流程。如圖所示
一、採集：採集主要包含圖像採集和音頻採集；
圖像採集設置前置攝像頭、後置攝像頭，並配置採集的參數、圖像數據的長寬、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 框架。
這裏都講的都比較簡單，沒有深入到技術點。如果對直播技術興趣的小夥伴，可以閱讀推薦閱讀，歡迎技術探討交流。
=================
這種問題其實純粹浪費大家時間，對IT一竅不通的土豪根本不知道後面成本是多麼驚人。
他們都在嚇唬你 ！！！
需要哪些準備工作，技術門檻有多高，資金支出要多少？
只需要找個外包團隊，技術門檻在當前雲環境下極低（聊天有聊天雲 視頻有cdn視頻雲） 100萬！ 你不需要僱傭任何技術人員就能幫你搞定，剩下就是帶寬費用了 2萬人花不了多少錢
看到90多個認真的回答，雖然信息量很大，但是竊以爲樓主無法按照這些思路是解決問題。
我在即構科技做技術，有一些實操的經驗。讓我儘量根據實操經驗去回答，希望有價值。
如何搭建一個完整的視頻直播系統？
朋友打算打造一個全新模式的視頻直播平臺，主要功能有些類似現在很多的美女直播平臺。假設前期同時在線觀看人數爲2W人，清晰度不低於720P，擁有美顏、混音等附加功能，還有最重要的不能卡頓。如果以上假設成立，需要做哪些準備工作，技術門檻有多高，資金支出要多少？
本來想長篇累牘的給你提供信息，但是最後長嘆一口氣，覺得必須要對你誠實。你要搭建的完整的視頻直播系統技術門檻很高。不是一個創業團隊短期內能夠做到的。高在哪裏？
1）技術積累：語音視頻技術是硬骨頭，不是簡單搞幾個頁面，不是搞一個業務支撐系統，這是需要經過多年技術積累的。比如說YY，他們做很多年才積累到今天的水平。比如說騰訊，他們也是摸爬打滾了好多年纔有幾天的輝煌。
2）人力成本：語音視頻工程師的價格是相當貴的，如果不是最貴的IT工程師，也是最貴之一。語音處理的模塊包括噪音抑制，回聲消除，自動增益，前向糾錯，丟幀補償，抖動緩衝等幾個模塊至少每人負責一個，然後要實現跨平臺和全終端兼容，每個平臺必須又要有一個人做。這麼算起來，整個語音視頻團隊就至少十個人了。假定一個平均工資，十個人算下來一年也是不少錢的。
3）開發週期：開發週期至少要大半年，那還是一流的開發團隊才能做到的。開發完成以後，效果好不好還是未知數。曾經有團隊找到我，說他們很厲害，一年就開發出來了，但是就是回聲消除和噪聲抑制效果不好。我心裏想，word哥阿，那是核心問題，核心問題你沒解決，能算做好了嗎？
上面說的是門檻，如果這個門檻沒有嚇住你，請繼續看下面我的知識分享：
不卡頓是一個核心的特徵，低延遲又是另外一個核心特徵。但是這兩個特徵是一堆矛盾兄弟：如果要做到互動效果好，就要低延遲，如果要低延遲，就要把緩衝隊列做的儘量短；如果緩衝隊列短，就避免不了卡頓。因此，最折中的方案必須是要找到不卡頓和低延遲的平衡點，讓語音視頻不卡頓的情況下，達到最低的延遲。即構科技給花椒直播提供的視頻直播方案中，充分的展現了這兩個特徵的平衡。我也是在給花椒直播提供服務的過程中，真心體會到，簡簡單單一句說“不卡頓就好了”，是多麼的不容易，是多少個碼農熬夜通宵的蹉跎青春。
“假設前期同時在線觀看人數爲2W人”
這個觀看人數不算多的，對於一個能支持高併發的方案來說，2W多人觀看是小case。還是拿我熟悉的即構科技說事情吧（因爲別的公司我也不懂），單個房間支持百萬在線整體支持千萬級高併發的。團隊是早期騰訊QQ出來的，多年的高併發經驗積累也不是蓋的。
清晰度不低於720P，
這需要保證比較高的碼率，帶寬要達到800kbps以上，也就是說終端的上行帶寬要達到1M以上才比較合適。
擁有美顏、混音等附加功能
美顏可以做成插件的方式，如果自己能做出來，就用自己的，做的效果不好，就用別家的。
混音的功能可以在本地提供回調接口，把額外的語音流和本地採集進來的語音流混合在一起，產生背景音樂的效果。即構科技這邊的做法是在SDK中提供了接口，開發這可以通過調用接口把數據扔個下層SDK進行混音。
直播，突然成爲了中國互聯網的一個最流行的詞彙。在《2016-2020年中國網絡直播行業深度調研及投資前景預測報告》中的數據表示，2015年，全國在線直播平臺數量接近200家，其中網絡直播的市場規模約爲90億，網絡直播平臺用戶數量已經達到2億，大型直播平臺每日高峯時段同時在線人數接近400萬，同時直播的房間數量超過3000個，更可怕的是，這一數據還在以極快的速度向上攀升。
高票答案非常詳細的說了開發相關的前期工作。這邊重要講一下網絡直播平臺開銷中的另一個大頭：帶寬的問題。在大量用戶體量下，直播類的應用對於服務器的要求要高過一般的應用。
1、更大的數據量
視頻數據和文本數據完全是兩個量級的概念，假設一個直播房間有5000人，視頻1s的數據60K，那麼就需要5000*60=300000KB=292.97MB，基本已經達到了2-3三個手遊的大小了，而這只是一個房間產生的流量。當前某著名網絡直播APP日活躍用戶超過了800W，服務器將承受458Gbps的帶寬壓力。
2、更高的併發量
不同於普通應用和遊戲，直播類應用的使用時間段非常的集中，一般來說，社交類的直播app時間集中在晚飯後時間至睡前20點~23點，遊戲類App活躍時間集中在下班後18~20點間，秀場類App集中在13點和18(午休及下班時間)，因此在這短短幾小時之間，會涌入大量的用戶，一次大V的直播通常就會造成百萬級的用戶登錄，APP需要有詳盡的限流、分流和負載均衡策略，保證服務器不會被沖垮。
3、更真實的用戶登錄場景
直播應用與普通應用相比，交互的功能異常多，除了直播視頻流的服務器壓力之外，還要包括用戶消息推送、聊天、禮物、支付以及統計系統帶來的數據交互壓力，服務器進行需要識別不同的業務字段，才能精確判定用戶的行爲是否成功完成，從交互頻率的角度上來說，直播類的應用，與其說更像應用，不如說更像遊戲。
4、更低的延遲
直播需要一個很強的即時性，如果主播的行爲和用戶的評論無法同步的時候，會給用戶非常不好的體驗，如果一個用戶發現其他用戶在歡呼鼓掌，但是屏幕中的主播什麼動靜都沒有的時候，這個直播應用基本可以不要再用了，因此直播類應用不僅需要面對更大的數據量和更高的併發，還要保證更低的延遲。通常可以要保證服務器的處理數據速度要快，要有足夠強大的帶寬；另外則是通過P2P算法保證數據分享的合理性，保證服務器的數據和P2P的數據可以達到平衡。
直播應用一般使用的分辨率是360p，720p以及1080p三種，按照題主以720p來計算，那麼直播應用需要1024kbps的帶寬，也就是每秒傳遞的數據大小爲1024/8=128KB。簡單來說，如果在APP中打開直播，使用了720p的分辨率，一個用戶每秒鐘需要傳輸128KB的數據（當然實際情況中直播應用還有消息推送，送禮，支付等行爲，直播畫面分辨率、壓縮比等區別，實際會消耗更多的數據）。
以目前最紅火的幾大直播平臺爲例，鬥魚TV的在線人數可以超過1000 萬，戰旗 TV 在在線人數約500 萬左右，龍珠在線人數約 400 萬左右，虎牙在線人數約100萬，直播平臺的帶寬成本通常是帶寬峯值月結的形式，按照題主說的，前期2W左右的在線，理論上當月的開銷就在30W人民幣左右。 所以對於直播應用來說，服務器最難處理的環節就是視頻流量和用戶交互等高頻率高帶寬的場景，由於用戶的行爲難以預測，經常會出現突發性的暴漲，進行活動時流量可能是平時的幾十倍。
所以在直播系統的準備中，一定要對所有接口進行壓力測試，提前暴露問題並解決，確保活動的順利實施。這裏安利一款產品WeTest服務器性能可同時調用的場景接口，不斷增加可實現的併發數，提供更大的併發壓力和更真實的行爲場景，節省成本。
做直播不僅需要完整的系統，千萬別遺漏了服務器是否穩定，支撐住整個平臺的正常運營。
