经常看到WebRTC的点对点的视频， 能不能做一个平台，让别人通过WebRTC播放视频直播，让粉丝都可以看见？ 有什么方案讲讲？
回复内容：
我所在的项目用这个技术两年多了，先说结论：
完全可以！
但是，凡事总有但是，
也没那么简单。你以为调用几个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%左右，内存使用率是多少我记不清了，但是印象中不高，而且比较稳定。能不能支持更多的客户端我们没有尝试，因为当时已经满足我们的需求了。 别迷信 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 的直播服务，比如网宿（斗鱼的直播服务提供商）。
这是正道，别走弯路了。
--- 我弄一个手机视频直播应用，刚刚上线，基于WebRTC技术，Mesh tree的网络架构，浏览器之间走P2P Relay, 正在产品迭代中。产品见:
http://
yacamera.com
谢 @郭小灿 邀…最近是有参与相关的事，然而也只是初接触。
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就是浏览器直接有实时视频功能, 不需要额外的插件, 但有可能是浏览器的默认插件
----
楼上有人说
" 视频部分：vpx的编码器太弱，专利原因不能用264，做的好的都要自己改264/265代码才行。"
请参见Firefox默认携带的Cisco提供的H264插件, 专利方面是没啥问题的. 这个插件是一个开源项目, 想要改进其性能可以自己去github上面提改进. 呵呵。我来回答这个问题吧
1：视频主播、直播多采用本地软件采集视频和语音(试试OBS)，然后RTMP传到服务端，服务端搭个RTMP服务器+web网站就可以实现直播了，再加个聊天室，就是典型的游戏、美女直播系统了。然后再把rtmp流传到CDN去，好！你可以支持到上千人了。但是注意：只能跟直播人文字聊。
2：webrtc是语音与视频的互动，可以互相语音和视频。但是让他做直播？显然不是一个系列的东西了。当然6-8人的视频直播啥的还是可以玩玩的。 可以实现功能，但是效果绝对让你抓瞎，不知道你的应用场景是什么，千万别进坑里去，见过公司都烧钱烧精力结果搞出一个四不像，最后苦苦挣扎资金断流...如果能详细讲一下应用场景，大家可以帮你分析一下的。
贴一个我刚刚写的答案的一部分，希望对你有帮助
--------------------------------------------------分开----------------------------------------------------------------
火热的游戏直播行业，为什么优酷土豆爱奇艺这样视频站没有抓住机会？ - 张腾的回答
一，视频直播与视频点播
很多人凭着第一印象，觉得两个名词里面都有视频，就认为两者实现的方式和技术要点是一样的，众多视频点播网站巨头（题主所说的：优酷，土豆，新浪等）都在探索视频直播的道路上吃了大亏，也是因为对两者之间区别的认识不够深刻。
视频点播对于视频本身的要求是：高质量（高码率）和流畅（低卡顿，即加载时间）
视频直播对于视频本身的要求是：清晰，流畅，低延时（无互动，不直播，把延时控制在3秒以内，甚至1秒内意义重大，这一点很多直播平台还都没有认识到）。
注意到区别了？低延时，也就是实时性，差之毫厘谬以千里。
为什么低延时在传统视频点播平台运营商那里会遇到大麻烦，需要讲一下现在所有视频服务的骨架CDN的前世今生，请仔细阅读下面的文字：
随着Internet的迅速发展，用户数量和信息量快速增长，为了从技术上全面解决网络带宽小，用户访问量大，网点分布不均匀等问题，1998年诞生了解决问题的方案，即CDN（内容分发网络）。
CDN技术采用了分布式缓存/复制、负载均衡、流量工程和客户端重定向等技术，设立若干分支节点，尽量将用户请求的内容存储到距离用户“最后一公里”的边缘节点上，在Internet上构筑一个地理上分布的内容分送网络，将信息资源向网络边缘推近，用户可以在 “最近”的位置快速访问到所需的内容，继而提高了终端用户的访问速度和服务质量。
CDN整体框架的顶层设计是为了解决文件的分发和传输问题架设的，系统起初是服务于文件而非实时的流媒体数据。在处理流媒体数据时，现有方案仍沿用了传统的分发原则与模式，无法满足互动直播高质量低延时的要求。
读到这里，你仿佛知道了他们之间的差异。但是，如果你认为CDN是现在主要的技术瓶颈，那你就错了，CDN只是个基础，更纠结的还在下面
二，流媒体传输协议
传输层协议主要讲下面三种
1.TCP
TCP为点对点的协议，虽然能保证了数据传输的可靠性，但是对服务器资源耗费较大，在数据流大的场合难以保证数据流传输的实时性。
2.UDP
UDP为不可靠传输协议，不需要维护连接状态，也不认为每个数据包都必须到达接受端，因此网络负荷比TCP小，传输速度也要比TCP快；但在网络越拥挤时，越有更多的数据包丢失。
3.RTMP
RTMP一个专门为高效传输视频，音频和数据而设计的协议。它通过建立一个二进制TCP连接或者连接HTTP隧道实现实时的视频和声音传输。
现在传统的视频直播都使用的RTMP传输协议，因为不管是UDP还是TCP协议，都不适用于流媒体的实时传输。但是使用RTMP+CDN或云的方案也存在根本性的缺陷。因为不管事RTMP还是CDN， 都源自服务于文件传输的方案，问题主要有以下几个
a:现在做的最好的用RTMP来搭建视频直播方案，其延时也最多能达到5秒左右，实际上，如果要保证视频的流畅（低卡顿）和清晰（高码率），5秒的延时都很难达到，有的方案甚至在7-8秒，直播的很大一部分意义在与互动和实时性，互动对于延时的要求，最佳时间是在2-3内，再长就会体验很差（大家可以自己试一下），而对于很多行业，直播的要求甚至要在半秒以内才有意义，这是现有方案完全无法满足的。
b:对于客户资源的最大程度利用，这一点涉及公司的方案设计，不再详述，有兴趣的可以私信。
c:CDN节点完全属于盲点，直播流浪涌入，一旦某个节点出现波动，只能被动地让用户承担极差用户体验的风险（卡顿，模糊），而对于网络状况本身却处于黑箱状态，不可管，不可控，受制约严重。我相信这一点有相关运维经验的知友都深有感触。
d.e.f....太多字了不写了
我想上面的答案应该能让题主明白，为什么优酷这种巨头做不好“一点微薄的工作“
简而言之
1.运营能力不能代表技术开发水平
2.流媒体实时传输这块领域太窄，不要说优酷，全世界真正深入研究的公司或团体，据我所知，除了我们公司还有一家美国的公司在做，不过他们和我们做的方向还是不一样，这是后话了。
3.互联网节奏太快，很多巨头的想法是，加大投入，缩短研发周期，立竿见影地把流媒体直播这个坑填平，但他们没有想到的是，一个坑后面还有无数个坑，坑里面还有坑，甚至方向可能都错了，赶时间赶进度的初衷反而被这种浮躁的心态给牺牲了。
可以的，http://www.anyrtc.io可以去了解一下，有成熟的视频直播方案，而且可以实现互动直播 天翼rtc就提供这种能力，可以音频聊天，视频会议，对讲，和微直播。 完全可以的，现在已经有很多成熟的范例了，包括行业内的一些SDK也有用到WebRTC中的模块
