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