能夠用WebRTC來作視頻直播嗎？

https://www.zhihu.com/question/25497090

 

做者：韋易笑
連接：https://www.zhihu.com/question/25497090/answer/72397450
來源：知乎
著做權歸做者全部，轉載請聯繫做者得到受權。

//--------------------------------------------------------------------------------------------

做者：劉津瑋
連接：https://www.zhihu.com/question/25497090/answer/43395462
來源：知乎
著做權歸做者全部，轉載請聯繫做者得到受權。

我所在的項目用這個技術兩年多了，先說結論： 徹底能夠！

可是，凡事總有可是， 也沒那麼簡單。你覺得調用幾個Chrome的API就能直播了？too simple

樓上 米小嘉 回答中的猜測是不正確的，WebRTC用的不是插件，是Chrome自帶的功能，是原生js的API，也沒有什麼瀏覽器自帶的插件。
樓上 煎餅果子社長 的方法也不對，WebRTC的API不只僅是給你獲取本地信源的，所謂RTC是real time communication的縮寫，天然這套API是帶傳輸功能的。因此獲取圖像信源以後不該該用websocket發送圖像數據，而是直接用WebRTC的通訊相關API發送圖像和聲音（這套API是同時支持圖像和聲音的）數據。

因此，正確的方法是什麼呢？
一、你得有一個實現了WebRTC相關協議的客戶端。好比Chrome瀏覽器。
二、架設一個相似MCU系統的服務器。（不知道MCU是什麼？看這： MCU（視頻會議系統中心控制設備））

第一步，用你的客戶端，好比Chrome瀏覽器，經過WebRTC相關的媒體API獲取圖像及聲音信源，再用WebRTC中的通訊API將圖像和聲音數據發送到MCU服務器。
第二步，MCU服務器根據你的需求對圖像和聲音數據進行必要的處理，好比壓縮、混音等。
第三步，須要看直播的用戶，經過他們的Chrome瀏覽器，連接上你的MCU服務器，並收取服務器轉發來的圖像和聲音流。

先說步驟一，若是你只是作着玩玩，徹底能夠直接用Chrome瀏覽器作你的直播客戶端。把攝像頭麥克風連上電腦以後，Chrome能夠用相關的js的API獲取到攝像頭和麥克風的數據。缺點就是若是長時間直播，Chrome的穩定性堪憂，我不是嚇唬你。咱們項目的經驗是，chrome這樣運行24小時以上內存佔用很厲害，並且容易崩潰。

第二步，你可能要問，WebRTC能夠直接在瀏覽器之間P2P地傳輸流，爲何還要有中轉的MCU服務器？由於Chrome的功能很弱，視頻的分辨率控制、多路語音的混音都作不了，因此須要MCU參與。最重要的是，Chrome同時給6個客戶端發視頻流就很消耗資源了，因此你若是有超過10個用戶收看的話，Chrome很容易崩潰。

第三步就比較簡單了，沒什麼好說的。

最後最後，仍是老話題，兼容性。你能夠查一下如今支持的瀏覽器有款，IE聽說支持，可是咱們研究了一下好像他用的協議和Chrome不同，不能互通。firefox和opera狀況也不是很理想。

-------------------------2015年11月17日 更新--------------------------
韋易笑 的答案中說「10人之內使用，超過10人就掛了」。從我我的的經驗來看，我認爲WebRTC並無那麼不堪。我不知道他是用什麼樣的方案，可是我原來的那個項目，13年作的結果是 1人廣播，39人收看，在一臺i3 + 4G + Centos6.4 mini的機器上跑MCU，連續運行48小時沒有出現問題。CPU的使用率大概在60%左右，內存使用率是多少我記不清了，可是印象中不高，並且比較穩定。能不能支持更多的客戶端咱們沒有嘗試，由於當時已經知足咱們的需求了。

//--------------------------------------------------------------------------------------------

別迷信 WebRtc，WebRtc只適合小範圍（8人之內）音視頻會議，不適合作直播：

1. 視頻部分：vpx的編碼器太弱，專利緣由不能用264，作的好的都要本身改264/265代碼才行。
2. 音頻部分：音頻只適合人聲編碼，對音樂和其餘非人聲的效果很糟糕。
3. 網絡部分：對國內各類奇葩網絡適應性過低，網絡糟糕點或者人多點就卡。
4. 信號處理：同時用過 GIPS和 WebRTC 進行對比，能夠確定目前開源的代碼是GIPS閹割過的。
5. 使用規模：10人之內使用，超過10人就掛了，WebEx方案支持的人數都比 RTC 強。

正確的方法是啥呢？
------------------------- 分割線 -------------------------
讓粉絲們來看直播，若是同時粉絲數>10人，那麼不關 WebRtc 鳥事，服務器請使用 nginx rtmp-module架設，架設好了用 ffmpeg 命令行來測試播攝像頭。主播客戶端請使用rtmp進行推流給rtmp-module，粉絲請使用 rtmp / flv + http stream 進行觀看，PC-web端的粉絲請使用 Flash NetStream來觀看，移動 web端的粉絲請使用 hls / m3u8 來觀看。

若是你試驗成功要上線了，出現壓力了，那麼把nginx分層（接入層+交換層），稍微改兩行代碼，若是資金不足以全國部署服務器，那麼把 nginx-rtmp-module 換爲 cdn 的標準直播服務，也能夠直接調過 nginx，一開始就用 cdn 的直播服務，好比網宿（鬥魚的直播服務提供商）。

這是正道，別走彎路了

 

//--------------------------------------------------------------------------------------

做者：沈園舊友
連接：https://www.zhihu.com/question/25497090/answer/72527818
來源：知乎
著做權歸做者全部，轉載請聯繫做者得到受權。

WebRTC 的初衷和優點是 Browser-to-Browser 的，它是 Web 端音視頻實時通訊。考慮到須要實現 live broadcast，因此 WebRTC 幾乎不靠譜，頂多在 broadcaster 和 server 上實現協議棧。server 實現各類 management，好比 room server；若是不在 server 端轉發，而是以 broadcaster 爲中心進行多個 p2p 鏈接，那要實現 signaling server, ice server，供 browser 之間鏈接，並且一個 broadcaster client 能力有限因此支持不了太多鏈接（基本上是個位數）；若是要在 server 端轉發（幾乎是必需），那要實現 stream server，接收 broadcaster 的 WebRTC 的 rtp 包，流媒體處理（考慮下 gstreamer ?），錄製成文件或 rtmp 發送到各個 participants。大系統能夠考慮用多臺 stream server，cdn + p2p 結合，因而要再實現個 server 蒐集和維護各個 peer 的網絡信息進行分發調度……其餘的 client 端問題無非是網絡傳輸協議和音視頻編解碼問題，注意統一和兼容。Chrome 的 WebRTC 實現已經很完整，有人提到回聲消除，這在 VoiceEngine 裏有實現，是用的 NetEQ 算法，源自 GIPS，還有降噪、靜音檢測等功能。VoiceEngine 十分強大，我想剝出來本身使用（其實不是我想）。

 

//--------------------------------------------------------------------------------------

補充一點，直播應該是流媒體處理及利用上早就有的概念。WebRTC只是提供了一種能夠替換現有的直播系統中的流媒體傳輸及處理的框架。

同時，其它答案也提到了，作直播或者視頻內的服務，不少都會牽涉到對流媒體的Mix處理及轉發。在這裏我須要提醒你們，Video相關的mix在webrtc的底層框架中是沒有的， 這裏有很大的坑，不是那麼簡單就能填起來的，請你們在作產品預言的時候深刻考慮下哦：），Audio相關的Mix卻是在webrtc的底層音頻相關的框架中已經有了，很容易就能夠被你們拿來使用（雖然chrome啥的，都是隻用來作p2p）。 用WebRTC來實現一個支持直播的服務是徹底可行的，可是，要作到直播的交互性，以及大規模的併發（好比一個主播，數以千計的觀衆）這是作直播最須要考慮的問題。WebRTC在這裏點上只是提供了一個流媒體的傳輸途徑包括音頻、視頻編解碼的接入等，這些都是能夠借鑑或者使用它來做爲實現直播的一個部分。可是，只用webrtc，你也只能作一個簡單的玩具，作產品的話，請更多考慮產品的應用場景，用戶量，帶寬需求，服務器搭設及運維。

做者：魯強 連接：https://www.zhihu.com/question/25497090/answer/44968159 來源：知乎 著做權歸做者全部，轉載請聯繫做者得到受權。