可以用WebRTC來做視頻直播嗎？
經常看到WebRTC的點對點的視頻， 能不能做一個平台，讓別人通過WebRTC播放視頻直播，讓粉絲都可以看見？ 有什麼方案講講？
別迷信 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 的直播服務，比如網宿（鬥魚的直播服務提供商）。
這是正道，別走彎路了。---
我所在的項目用這個技術兩年多了，先說結論：完全可以！
但是，凡事總有但是，也沒那麼簡單。你以為調用幾個Chrome的API就能直播了？too simple
樓上 米小嘉 回答中的猜想是不正確的，WebRTC用的不是插件，是Chrome自帶的功能，是原生js的API，也沒有什麼瀏覽器自帶的插件。
樓上 煎餅果子社長 的方法也不對，WebRTC的API不僅僅是給你獲取本地信源的，所謂RTC是real time communication的縮寫，自然這套API是帶傳輸功能的。所以獲取圖像信源之後不應該用websocket發送圖像數據，而是直接用WebRTC的通信相關API發送圖像和聲音（這套API是同時支持圖像和聲音的）數據。
所以，正確的方法是什麼呢？
1、你得有一個實現了WebRTC相關協議的客戶端。比如Chrome瀏覽器。
2、架設一個類似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%左右，內存使用率是多少我記不清了，但是印象中不高，而且比較穩定。能不能支持更多的客戶端我們沒有嘗試，因為當時已經滿足我們的需求了。
可以的，還可以結合nodejs，redis和mongodb，不過性能和穩定性是個問題
天翼rtc就提供這種能力，可以音頻聊天，視頻會議，對講，和微直播。
謝 @郭小燦 邀…最近是有參與相關的事，然而也只是初接觸。
Talk is cheap, show you some codes:
- meetecho/janus-gateway · GitHub
- WebRTC-Experiment/webrtc-broadcasting at master · muaz-khan/WebRTC-Experiment · GitHub, with demo: WebRTC Broadcasting - Muaz Khan
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搭建的，在微信和手機瀏覽器中都能收看。
可以用Chrome瀏覽器訪問 http://plaza.maodou.io 體驗一下，主播端需要手機驗證碼登錄。
答案1：webrtc整體的技術並不適合做直播。webrtc設計的初衷只是為了在兩個瀏覽器/native app之間解決直接連接發送media streaming/data數據的，也就是所謂的peer to peer的通信，大多數的情況下不需要依賴於伺服器的中轉，因此一般在通信的邏輯上是一對一。而我們現在的直播服務大部分的情況下是一對多的通信，一個主播可能會有成千上萬個接收端，這種方式用傳統的P2P來實現是不可能的，所以目前直播的方案基本上都是會有直播伺服器來做中央管理，主播的數據首先發送給直播伺服器，直播伺服器為了能夠支持非常多用戶的同事觀看，還要通過邊緣節點CDN的方式來做地域加速，所有的接收端都不會直接連接主播，而是從伺服器上接收數據。
答案2：webrtc內部包含的技術模塊是非常適合解決直播過程中存在的各種問題的，而且應該在大多數直播技術框架中都已經得到了部分應用，例如音視頻數據的收發、音頻處理迴音消除降噪等。
所以綜上，可以使用webrtc內部的技術模塊來解決直播過程中存在的技術問題，但是不適合直接用webrtc來實現直播的整體框架。
這要看你用的客戶端是什麼。如果你是想用瀏覽器，那webrtc不是好方案。但如果你是用app，可以肯定回答：可以，而且強烈建議你基於webrtc。
為什麼說對App是完全可行呢？瀏覽器在用的Webrtc其實分兩層，底層是個用C++寫的庫（Native Code），然後上層寫個Javascript封裝，以便供HTML5調用。既然是寫app，那完全不用管上層Js封裝，而且Google在開發Webrtc時已考慮用在app，底層C++庫的API已做得很完善了。
對直播使用場景，很多人是用移動設備，移動設備基本都是用app。而webrtc中的Native Code部分跨平台特性很好，基本不用改，就能寫出完全跨iOS、Android、Windows平台的代碼，所以有了iOS/Android app，基本不耗成本Windows上的app就出來了。——當然，如果有人在Windows還是堅持要用瀏覽器，那隻能說在Windoes不得不留有瑕疵。
為什麼有人一想到webrtc，直觀就認為只有p2p？我猜是和默認的信令伺服器是p2p有關。關於這默認的信令伺服器是怎麼個交互流程，我有畫過圖。http://www.libsdl.cn/bbs/forum.php?mod=viewthreadamp;amp;amp;amp;tid=83amp;amp;amp;amp;extra=page%3D2
根據這個圖，你可以模糊中發現，只要換了信令伺服器，就有可能變成直播。而事實也的確是這樣。就像有人說直播時圖像單向就夠了（主播傳向觀眾），而Webrtc是雙向，——只要改信令伺服器，立刻就單向了。
為什麼強烈建議你基於webrtc？對直播系統，難的不是伺服器，而是客戶端。客戶端難的地方則主要體現在兩個方面，一是網路傳輸有關，像偵聽事件，同步主線程和讀線程，穿透；二是流數據有關，像編碼、解碼、回聲消除。而這些正是webrtc幫你解決了。也正因為如此，現在很多直播系統最早的客戶端其實是以webrtc為根的，只是後面自個不斷優化，慢慢地變成自個系統而已。——誠然，官方webrtc是有地方不盡如意，但它們不斷更新，就像最近一段時間優化了回聲消除。
可以用WebRTC來做視頻直播嗎？
經常看到WebRTC的點對點的視頻， 能不能做一個平台，讓別人通過WebRTC播放視頻直播，讓粉絲都可以看見？ 有什麼方案講講？
雖然我這邊不提供WebRTC的視頻直播技術方案，但是作為一個技術控的客觀立場來回答：這是可以的。 然而，你需要回答一個問題：你的用戶群是使用什麼瀏覽器？如果你的用戶是使用Google Chrome或者Opera，那恭喜你，你完完全全可以用WebRTC來做視頻直播，而且聽說效果還挺好。
我在即構科技做後台，當初也考慮過使用WebRTC來做視頻直播，但是後來經過調研後放棄轉而使用RTMP來做視頻直播。原因是在國內有60%的瀏覽器不支持WebRTC，而且主推WebRTC的google Chrome在國內的效果也大打折扣。RTMP其實也不是最優的選擇，但是我們最終還是選擇了RTMP，為什麼呢？因為RTMP是標準協議，能被眾多CDN網路支持，能兼容客戶的老系統。儘管RTMP比較難做到比較低的延遲，但是經過我們不斷的死磕，還是創造了奇蹟，在主播端做到400毫秒延遲，觀眾端1秒左右的延遲。其實最適合做視頻直播的是UDP協議，容易做到比較低的延遲，可惜基於UDP的私有協議在兼容性上面有先天不足，因此我們最後捨棄，而是使用它作為互補的方案，在網路比較差的時候才使用基於UDP的私有協議來推流，平時還是使用RTMP。在即構科技給花椒直播，一直播和么么直播這些直播大廠服務的過程中，我們更是慶幸當初選擇協議的時候做了正確的決定。如果我們採用WebRTC，這些大廠不管我們效果有多好，都不會選擇我們的。
因此，如果你要求覆蓋比較廣的用戶面，確保你的直播平台有普適性，實在不建議用WebRTC。請多做一點測試比較，就能驗證我上面描述的情況。邏輯上完全可以：
webrtc基本應用邏輯使用，P2P的傳輸，也就是說除了除了Session建立過程，整個過程無需伺服器，完全可以用p2p 的udp來傳輸所有視頻內容。
下面我們一個個場景來看可行的方法:
1.1-&>5以下(直接點對點)
1對10以下完全可用基本的傳輸邏輯進行，直播方直接將視頻內容duplicate給不同的客戶端。普遍電信網路均有2Mbps的上傳帶寬，每個客戶端大概最多能得到400Kbps的直播帶寬。由於存在部分不能直連的情況，需要tunnel來幫助不能直連情況的轉發。
2.1-&>5以上
基本的傳輸邏輯由於主播方的帶寬在超過5個客戶端的情況下已經用盡帶寬。所以不能直接完全通過直連的方式進行視頻傳輸。因此在Session控制上可以引入類似BitTorrent的機制。把客戶端同時作為視頻服務端轉發數據。從原理上說這是靠譜的，快播當年就用了類似技術。
優點:
1.去平台化，內容服務不依賴伺服器
2.工具化，可作為工具直接使用，可免除內容監管的麻煩。
破迷信：
1.直播是允許延遲的內容發放方式，實時性要求比網路會議低很多，天然規避掉難度最大的環節。(有個3-5秒的延遲您在乎么？)
2.直播是單向信息傳遞，混音/畫面混疊/網路回聲混疊這些在webrtc中最麻煩的問題天然被規避掉了。
補充一點，直播應該是流媒體處理及利用上早就有的概念。WebRTC只是提供了一種可以替換現有的直播系統中的流媒體傳輸及處理的框架。
同時，其它答案也提到了，做直播或者視頻內的服務，很多都會牽涉到對流媒體的Mix處理及轉發。在這裡我需要提醒大家，Video相關的mix在webrtc的底層框架中是沒有的，這裡有很大的坑，不是那麼簡單就能填起來的，請大家在做產品預言的時候深入考慮下哦：），Audio相關的Mix倒是在webrtc的底層音頻相關的框架中已經有了，很容易就可以被大家拿來使用（雖然chrome啥的，都是只用來做p2p）。
用WebRTC來實現一個支持直播的服務是完全可行的，但是，要做到直播的交互性，以及大規模的並發（比如一個主播，數以千計的觀眾）這是做直播最需要考慮的問題。WebRTC在這裡點上只是提供了一個流媒體的傳輸途徑包括音頻、視頻編解碼的接入等，這些都是可以借鑒或者使用它來作為實現直播的一個部分。但是，只用webrtc，你也只能做一個簡單的玩具，做產品的話，請更多考慮產品的應用場景，用戶量，帶寬需求，伺服器搭設及運維。不適用純粹的webrtc做直播。
webrtc中有大量的rtcp控制和反饋，防止網路丟包，抗延時，保證視頻質量。所以沒辦法直接支持大量用戶的～
在直播中，webrtc一個比較典型的用法是連麥。
在media server混流後，用rtmp推流到客戶端吧。
而且直播用戶多了後，還是要靠cdn來撐的。
完全可以的，現在已經有很多成熟的範例了，包括行業內的一些SDK也有用到WebRTC中的模塊
從實際使用中，難以解決的是迴音消除問題。原生代碼裡面這個函數還沒實現。
大大的博客寫得很詳細，完成可以實現。
藉助webrtc完全可以實現，詳見：Android IOS WebRTC 音視頻開發總結（二八）-- 多人視頻方案介紹
另一種實現方式就是rtmp，也就是韋易笑說的，詳見：Android IOS WebRTC 音視頻開發總結（五八）-- 圖文解說視頻直播原理
webrtc跨平台支持得比較好，延遲比較低，但入門難度比rtmp高，具體優缺點比較可參考：Android IOS WebRTC 音視頻開發總結（六六）-- 三個角度分析美女視頻直播這個行業呵呵。我來回答這個問題吧
1：視頻主播、直播多採用本地軟體採集視頻和語音(試試OBS)，然後RTMP傳到服務端，服務端搭個RTMP伺服器+web網站就可以實現直播了，再加個聊天室，就是典型的遊戲、美女直播系統了。然後再把rtmp流傳到CDN去，好！你可以支持到上千人了。但是注意：只能跟直播人文字聊。
2：webrtc是語音與視頻的互動，可以互相語音和視頻。但是讓他做直播？顯然不是一個系列的東西了。當然6-8人的視頻直播啥的還是可以玩玩的。
1對N的直播, 一般都是伺服器轉發的吧.
webrtc當然可以用作視頻直播了，而且527輕會議已經做出來了，瀏覽器直播，不需要下載任何客戶端，而且支持大方數。還能和手機端和機頂盒端互聯互通，支持VP8/H264雙編解碼。不需要硬體mcu伺服器這些，都是雲端mcu部署，自己可以去了解了解。
騰訊課堂(http://ke.qq.com )已經上線了webrtc的1對多直播方案
答案是：可以做，但是改造成本相對傳統直播方案較大。但是帶來的收益也是比較明顯的，在延遲，首幀，弱網卡頓等方面都有比較大的提升。可以實現毫秒級時延。
完全可以，直播我理解是點對多的方式，需要伺服器中轉分發。
獲取信源就用webrtc獲取你的桌面或者某應用的圖像，可以選擇，webrtc的API中可以設置。然後用WebSocket發送到你的伺服器(不是唯一的辦法，只是這種方法試過可行)，然後轉發。
客戶端也是一樣的原理，websocket接收，直接用html5自帶的就能播放信源。
推薦閱讀：