可以用WebRTC来做视频直播吗？
24 个回答
别迷信 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%左右，内存使用率是多少我记不清了，但是印象中不高，而且比较稳定。能不能支持更多的客户端我们没有尝试，因为当时已经满足我们的需求了。
Talk is cheap, show you some codes:
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 十分强大，我想剥出来自己使用（其实不是我想）。
答案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=viewthread&tid=83&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来撑的。
大大的博客写得很详细，完成可以实现。
借助webrtc完全可以实现，详见：Android IOS WebRTC 音视频开发总结（二八）-- 多人视频方案介绍
另一种实现方式就是rtmp，也就是韦易笑说的，详见：Android IOS WebRTC 音视频开发总结（五八）-- 图文解说视频直播原理
webrtc跨平台支持得比较好，延迟比较低，但入门难度比rtmp高，具体优缺点比较可参考： Android IOS WebRTC 音视频开发总结（六六）-- 三个角度分析美女视频直播这个行业
1：视频主播、直播多采用本地软件采集视频和语音(试试OBS)，然后RTMP传到服务端，服务端搭个RTMP服务器+web网站就可以实现直播了，再加个聊天室，就是典型的游戏、美女直播系统了。然后再把rtmp流传到CDN去，好！你可以支持到上千人了。但是注意：只能跟直播人文字聊。
2：webrtc是语音与视频的互动，可以互相语音和视频。但是让他做直播？显然不是一个系列的东西了。当然6-8人的视频直播啥的还是可以玩玩的。
webrtc当然可以用作视频直播了，而且527轻会议已经做出来了，浏览器直播，不需要下载任何客户端，而且支持大方数。还能和手机端和机顶盒端互联互通，支持VP8/H264双编解码。不需要硬件mcu服务器这些，都是云端mcu部署，自己可以去了解了解。
腾讯课堂(http://ke.qq.com )已经上线了webrtc的1对多直播方案
答案是：可以做，但是改造成本相对传统直播方案较大。但是带来的收益也是比较明显的，在延迟，首帧，弱网卡顿等方面都有比较大的提升。可以实现毫秒级时延。
完全可以，直播我理解是点对多的方式，需要服务器中转分发。
获取信源就用webrtc获取你的桌面或者某应用的图像，可以选择，webrtc的API中可以设置。然后用WebSocket发送到你的服务器(不是唯一的办法，只是这种方法试过可行)，然后转发。
客户端也是一样的原理，websocket接收，直接用html5自带的就能播放信源。
可以的. webrtc就是浏览器直接有实时视频功能, 不需要额外的插件, 但有可能是浏览器的默认插件
----
楼上有人说
" 视频部分：vpx的编码器太弱，专利原因不能用264，做的好的都要自己改264/265代码才行。"
请参见Firefox默认携带的Cisco提供的H264插件, 专利方面是没啥问题的. 这个插件是一个开源项目, 想要改进其性能可以自己去github上面提改进.
侵权举报 网上有害信息举报专区
违法和不良信息举报：010-82716601
儿童色情信息举报专区
联系我们 © 2018 知乎
338
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
