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是同时支持图像和声音的）数据。
所以，正确的方法是什么呢？
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%左右，内存使用率是多少我记不清了，但是印象中不高，而且比较稳定。能不能支持更多的客户端我们没有尝试，因为当时已经满足我们的需求了。
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 十分强大，我想剥出来自己使用（其实不是我想）。
同时，其它答案也提到了，做直播或者视频内的服务，很多都会牵涉到对流媒体的Mix处理及转发。在这里我需要提醒大家，Video相关的mix在webrtc的底层框架中是没有的，这里有很大的坑，不是那么简单就能填起来的，请大家在做产品预言的时候深入考虑下哦：），Audio相关的Mix倒是在webrtc的底层音频相关的框架中已经有了，很容易就可以被大家拿来使用（虽然chrome啥的，都是只用来做p2p）。
用WebRTC来实现一个支持直播的服务是完全可行的，但是，要做到直播的交互性，以及大规模的并发（比如一个主播，数以千计的观众）这是做直播最需要考虑的问题。WebRTC在这里点上只是提供了一个流媒体的传输途径包括音频、视频编解码的接入等，这些都是可以借鉴或者使用它来作为实现直播的一个部分。但是，只用webrtc，你也只能做一个简单的玩具，做产品的话，请更多考虑产品的应用场景，用户量，带宽需求，服务器搭设及运维。
作者：鲁强
链接：https://www.zhihu.com/question/25497090/answer/44968159
来源：知乎
著作权归作者所有，转载请联系作者获得授权。