我所在的项目用这个技术两年多了，先说结论：完全可以！但是，凡事总有但是，也没那么简单。

你以为调用几个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%左右，内存使用率是多少我记不清了，但是印象中不高，而且比较稳定。

能不能支持更多的客户端我们没有尝试，因为当时已经满足我们的需求了。