可以用WebRTC来做视频直播吗？

经常看到WebRTC的点对点的视频，能不能做一个平台，让别人通过WebRTC播放视频直播，让粉丝都可以看见？有什么方案讲讲？

有关回应 · 2021-5-14 20:30:35

淘宝直播是基于 WebRTC 实现的一秒内的低延迟直播，低延时这一块儿我们在业内做得比较好，关于我们的方案可以分享给大家~（欢迎关注我们，后续分享更多有关淘宝直播的技术方案）
本篇回答内容来自于阿里巴巴淘系技术部技术专家常高伟，主要面向直播行业从业者，以及对低延迟直播技术、 WebRTC 技术感兴趣的技术人员，介绍淘宝直播在低延迟直播技术上的探索，如何基于 WebRTC 实现一秒内的低延迟直播，以及低延迟直播对电商直播的业务价值。
——————————————————————————————————————————
[h2]低延迟技术选型[/h2]

[h2] 当前直播技术延迟[/h2]

传统的直播技术延迟非常大，从观众评论到看到主播给出反馈一般要在十秒以上。通过多媒体技术降低直播延迟、提高主播和粉丝的互动效率是我们研究低延迟直播技术的初衷。
我们对当前主流直播技术做了分析，在低延迟直播技术出现前主要有 HLS 和 RTMP/HTTP-FLV 两个协议。
HLS：延迟主要来自编码解码时产生延迟、网络延迟、CDN 分发延迟。由于它是切片协议，延迟分两大块，一个是服务端有切片缓冲延迟，另一个是在播放端防抖缓冲会有延迟。切片的大小和数量都会 HLS 影响延迟大小，一般在十秒以上。
RTMP/HTTP-FLV: 目前国内大部分厂家在用的 RTMP，它相对于 HLS 在服务端做了优化。RTMP 服务端不再进行切片，而是分别转发每一帧，CDN 分发延迟非常小。RTMP 延迟主要来自播放端防抖缓冲：为提升弱网环境下抖动时直播的流畅度，缓冲延迟一般有五到十秒。
这两类协议都是基于 TCP，国内厂商基本上已经将 RTMP over TCP 的延迟做到的极致，如果一个协议仍然基于 TCP 优化延迟，效果上很难优于目前的 RTMP 。
TCP 由于其自身的一些特性，并不适用于低延迟直播场景，主要原因如下：

重传慢：TCP 的 ACK 确认机制，丢包后发送侧超时重传，超时时间一般200ms，会造成接收侧帧抖动。
拥塞判断不准确：基于丢包的拥塞控制算法无法准确判断拥塞，丢包并不等于拥塞；也会造成发送链路 bufferbloat，链路 RTT 增大，延迟增加。
灵活性差：这是最主要原因，TCP 拥塞控制算法在操作系统内核层实现，优化成本较高，移动端只有利用系统已有的优化。

所以我们选择基于 UDP 的方案实现。

[h2] 低延迟直播技术选型[/h2]

上图是我们基于 UDP 的两种方案对比，第一种是可靠UDP方向，比如 Quic ，另一种是 RTC 方案，比如 WebRTC 。
我们从五个维度对两种方案做了对比：

传输方式：Quic 是可靠传输；而 RTC 是半可靠传输，特定情境下可对音视频有损传输，可有效降低延迟。
复杂度：Quic 的复杂度非常低，相当于将 TCP 接口换位 Quic 接口即可，RTC方案的复杂很高，涉及一整套的协议设计和QOS保障机制。
音视频友好性：Quic 不关心传输内容，对音视频数据透明传输。RTC 对音视频更友好，可针对音视频做定制化优化。
方案完备性：从方案完备性方面来讲，Quic 是针对传输层优化，而 WebRTC 可提供端对端优化方案。
理论延迟：经我们实验室测试以及线上数据分析，WebRTC 方案的延迟可以达到 1 秒以内。

综上，Quic 方案的最大优点是复杂度低，不过这个方案要想达到更低的延迟，也需要引入更多的复杂度。从方案的先进性上看，我们选择 WebRTC 技术作为我们的低延迟方案。同时，我们也相信，RTC 技术和直播技术的融合，是未来音视频传输技术的一个趋势。
阿里云 RTS

RTS 是由阿里云和淘宝直播共建的低延迟直播系统，此系统分两大块：

上行接入：可接入三种输入方式，第一种是 H5 终端，使用标准 WebRTC 推流到RTS系统中；第二种是 OBS 等传统 RTMP 推流软件，使用 RTMP 协议推流到 RTS 系统中；第三种是低延迟推流端，可以使用我们基于 RTP/RTCP 扩展的私有协议推流到RTS系统中。
下行分发：它提供两种低延迟分发，第一种是标准WebRTC 分发，另一种是我们在 WebRTC 基础上的私有协议扩展，淘宝直播目前使用最多的就是基于私有协议的分发。

[h2] 低延迟直播技术[/h2]

下面我将重点从流程协议，终端方案介绍低延迟直播技术，主要回答几个问题：

标准 WebRTC 终端如何接入
Native 终端接入如何获得更好体验
如何基于 WebRTC 设计低延迟直播端方案
播放器如何修改支持低延迟直播

[h2]
[/h2][h2] 标准 WebRTC 接入流程[/h2]

播放流程描述：

播放端端发送接入请求：通过 HTTP 发送 AccessRequest ，携带播放 URL 和 offer SDP；
RTS 收到播放的接入请求后，记录 offerSDP 和 URL ，然后创建 answerSDP，生成一次会话 token 并设置到 SDP 的 ufrag 字段，通过 http 响应发送给客户端。
客户端设置 answerSDP，发送 Binding Request 请求，请求中 USERNAME 字段携带 answerSDP 中的 ufrag（即 RTS 下发的 token ）。
RTS 收到 Binding Request，根据 USERNAME 中的 token，找到之前 HTTP 请求相关信息，记录用户 IP 和端口。借助 Binding Request 的 USERNAME 传递 token 是由于 RTS 是单端口方案，需要根据 UDP 请求中的 token 信息确定是哪个用户的请求。传统的 WebRTC 是根据端口区分用户，RTS 为每个用户设置端口会带来巨大的运维成本。

标准 WebRTC 接入过程会有各种限制：

它不支持直播中常用音频 AAC 编码和 44.1k 采样率。
其它不支持视频 B 帧、H265等编码特性，多 slice 编码在弱网下也会花屏。
WebRTC 建联过程耗时过长，会影响秒开体验。

基于以上的这些问题，我们设计了更为高效、兼容性更好的私有协议接入。

[h2] 私有协议接入流程[/h2]

播放流程描述（四次握手建联）：

发送播放请求：通过 UDP 发送 PlayRequest ，携带播放 URL ；
RTS 收到播放请求后，立即返回临时响应，并且开始回源；
RTS 回源成功后，发送最终响应，携带相关媒体描述（编解码等）；
客户端发送最终响应 ACK，通知服务端最终响应接收成功；
RTS 发送媒体数据：RTP/RTCP，连接建立成功；

对流程的几点说明：

PlayRequest 的作用是将 URL 告诉 CDN，同时兼具 UDP 打洞功能；
协议中信令和媒体在一个 UDP 通道传输；
四次握手流程设计，保证建联速度的同时，确保重要信息可靠到达；
整个建联过程只有一个 RTT，建联速度快；

[h2] 私有协议状态机设计[/h2]

上图是私有协议的流程状态机：

初始状态下发送播放请求，然后会进入等待临时相应状态；
在临时响应状态会启动毫秒级快速重发定时器，超时未收到临时响应则快速重传播放请求，保证建联速度；
收到临时响应后进入等待最终响应状态，这时会开始更长的秒级定时器；
收到最终响应建联成功；

过程中临时响应可能丢失或乱序，可能出现提前收到最终响应的情况，会直接从等待临时相应状态直接进入最终状态。

[h2] 私有协议信令设计[/h2]

私有信令我们选择使用 RTCP 协议。原因是 RFC3550 定义了 RTCP 的四个功能，其中第四项可选功能描述为：RTCP 可以用在“松散控制”系统中，传递最小会话控制信息。比如，标准定义了 BYE 消息，用于通知源已经不再处于激活状态。我们在此基础上扩展了建联的信令消息，包括请求、临时响应、最终响应以及最终响应 ACK 。
同时，我们选择 RTCP 消息中的 APP 消息承载我们的私有信令。APP消息是RTCP 提供的一种为新应用、新功能使用的一种扩展协议，即它是 RTCP 提供的一种官方扩展方式，应用层可以自己定义消息类型以及内容。此外，选择此协议也基于以下考虑：

使用 RTCP-APP 可以解决私有协议和标准 RTP/RTCP 区分问题。如之前所讲，媒体和信令在同一个通道，服务端收到后如何区分私有协议、RTCP 包以及原生 RTCP 包，RFC3550 有清晰的描述，帮助我们解决了这个问题。
使用此协议可以直接使用现有包分析工具解析抓包。
我们可复用 RTCP 相关定义，例如 payload type、subtype、ssrc 等。

[h2]  RTCP-APP 消息介绍[/h2]

介绍下 RTCP-APP 消息的细节，上图是 RTCP-APP 消息头，主要字段如下：
1、subtype消息子类型，可用于定义私有应用扩展消息，我们私有信令的请求、临时响应、最终响应都是根据 subtype 区分的。subtype 的取值范围是 0 到 31，其中 31 预留将来做扩展的消息类型。
2、payload typeAPP 固定 payload type 是 204。可用于区分其它 RTP 和 RTCP 消息。
3、SSRCSSRC 是 RTCP sender 的标识。
4、Namename是应用名称，用于区分其它应用APP消息。RFC3550 中描述消息类型用两个字段区分，name 确定应用类型，subtype 用于区分消息类型，同一个 name 下可有多个 subtype 类型。
5、application-dependent data应用层扩展消息内容，我们使用 TLV 格式，即 type、length、value，是一种灵活的、扩展性高的二进制数据格式，它占用空间低。
[h2]  私有协议媒体部分设计[/h2]
媒体部分协议主体遵循标准 RTP/RTCP 规范以及 WebRTC 的相关规范，其中 H264 采用 rfc6184 规范，H265 采用 rfc7798 规范。
对 RTP 的扩展部分使用标准的RTP扩展，为了和 WebRTC 兼容，标准 RTP 扩展头部定义使用了 rfc5285 标准。
  两种接入方式对比

标准 WebRTC 接入的优点：

标准 WebRTC 接入除了 HTTP 建联请求外，全部符合 WebRTC 规范。
标准终端方便接入。
可快速实现原型。

标准 WebRTC 接入的缺点：

建联过程耗时长，使用HTTP情况下达到5RTT，选用HTTPS会更长。
媒体必须加密传输。
音视频有相关限制，使用时需要在服务端转码。

私有协议接入优点：

基于标准扩展信令和媒体协议，与标准协议差异很小。
建联速度快，秒开体验非常好。
支持直播技术栈，增加了媒体兼容性，减少了服务端转码成本。

私有协议接入缺点：

虽基于标准扩展，但仍然带来了部分私有化实现。
使用私有协议后，复杂度有所提升。

淘宝直播落地方案中，为了能够获得更好的体验，Native 端我们使用私有协议接入，目前已在线上大规模运行。

[h2] 流程协议设计原则[/h2]

流程协议设计原则有三个：

尽量使用标准，包括 WebRTC 相关规范。这个原则意味着我们和标准 WebRTC 互通，会非常方便。
当标准和体验发生冲突时，优先保障体验。
当需要扩展时，基于标准协议扩展，并且使用标准扩展方式。

我们并没有将 RTP/RTCP 协议全部推翻，使用完全的私有协议，有两个原因：首先是工作量问题，重新设计的工作量会比使用标准协议多很多。其次， RTP/RTCP 协议设计非常精简，久经考验，自己设计不一定能考虑到所有问题。所以我们选择基于标准扩展而非重新设计。

[h1]终端接入方案[/h1][h2] 基于 WebRTC 全模块的接入方案[/h2]

基于webrtc全模块的接入方案，使用webrtc的所有模块，通过对部分模块的修改，实现低延迟直播功能。
这个方案的优缺点并存：
优点：

经过多年发展，它非常成熟，很稳定，同时提供了完整的解决方案，包括 NACK、jitterbuffer、NetEQ 等可直接用于低延迟直播。

缺点：

它的缺点也很很明显。如上图中是WebRTC整体架构，它是一个从采集、渲染、编解码到网络传输的完备的端对端方案，对现有推流端和播放端侵入性极大，复杂度极高。
RTC技术栈和直播技术栈存在差异，他不支持B帧、265等特性。在QOS策略方面，WebRTC的原生应用场景是通话，它的基本策略是延迟优于画质，这个策略在直播中不一定成立。
包大小：所有webrtc模块全部加入到APP中，包大小至少增加3M。

[h2] 基于 WebRTC 传输层的接入方案[/h2]

我们目前终端的整体接入方案如上图，也是基于 WebRTC，但是我们只使用了 WebRTC 几个核心传输相关模块，包括 RTP/RTCP、FEC、NACK、Jitterbuffer、音视频同步、拥塞控制等。
我们在这些基础模块上进行了封装，将他们封装成 FFmpeg 插件注入到 FFmpeg 中。之后播放器可直接调用 FFmpeg 相关方法打开 URL 即可接入我们的私有低延迟直播协议。这样可极大减少播放器和推流端的修改，降低对低延迟直播技术对原有系统的侵入。同时，使用基础模块也极大减少了包大小的占用。
[h2] 播放器针对低延迟直播的修改[/h2]

上图是普通播放器的架构。播放器使用 FFmpeg 打开网络连接，读取音视频帧后会放入播放器缓冲，之后会依次对它进行解码、音视频同步及渲染。
接入低延迟直播系统后，整体架构如图下面部分：FFmpeg 增加低延迟直播插件支持我们的私有协议；将播放器的缓冲设置为0秒，FFmpeg 输出的音视频帧直接送入解码器进行解码，然后同步，渲染。我们将播放器原先的缓冲区移动到了我们的传输层SDK中，使用jitterbuffer可以根据网络质量好坏动态的调整缓冲区大大小。
整个方案对播放器的修改很小，基本不影响原有播放器的逻辑。

[h1]低延迟直播业务价值[/h1]

低延迟直播技术目前已在淘宝直播中大规模应用，它的上线降低了淘宝直播的延迟，提升了用户的互动体验，这是最直接的价值。
所有的技术优化都是为了创造业务价值，所有体验的提升应该对业务提升有帮助。我们经过线上验证发现，低延迟直播对电商直播的成交有明显的促进作用，其中 UV 转化率提升4%，GMV 提升5%。
同时，低延迟直播技术也可支持更多业务形态，例如拍卖直播，客服直播等。

[h1]未来展望[/h1]

我们对低延迟直播技术的未来展望有三点：

现在的 WebRTC 开源软件还不能很好支持直播，希望未来的标准 WebRTC 能很好直播，这样我们可以很方便的在浏览器上做低延迟直播。
5G 到来后，网络环境会越来越好，低延迟直播技术会成为直播行业未来的一个技术方向。
现在各厂商的低延迟直播协议大都存在私有协议，对用户来说，从一个厂商切换到另一个厂商时成本会很高。低延迟直播协议的统一、标准化对直播行业非常重要。一个基本判断是，随着低延迟直播技术的方案和普及，低延迟直播协议在未来一定会走向统一化和标准化。也希望我们国家的技术厂商能够在推动低延迟直播标准化的过程中发出自己的声音，贡献自己的力量。

（欢迎关注我们，后续分享更多有关淘宝直播的技术方案）

————————————————————————————————————————
本账号主体为阿里巴巴淘系技术，淘系技术部隶属于阿里巴巴新零售技术事业群，旗下包含淘宝技术、天猫技术、农村淘宝技术、闲鱼、躺平等团队和业务，是一支是具有商业和技术双重基因的螺旋体。
刚刚入驻社区，将会给大家带来超多干货分享，立体化输出我们对于技术和商业的思考与见解。
详情介绍可以看这里阿里巴巴淘系技术介绍
欢迎收藏点赞关注我们！共同进步~ ：）

有关回应 · 2021-5-14 20:30:36

别迷信 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 的直播服务，比如网宿（斗鱼的直播服务提供商）。

这是正道，别走弯路了。
---

有关回应 · 2021-5-14 20:30:37

我所在的项目用这个技术两年多了，先说结论：完全可以！

但是，凡事总有但是，也没那么简单。你以为调用几个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%左右，内存使用率是多少我记不清了，但是印象中不高，而且比较稳定。能不能支持更多的客户端我们没有尝试，因为当时已经满足我们的需求了。

有关回应 · 2021-5-14 20:30:38

[h2]这篇文章是花椒服务端的调研。主要是针对直播连麦功能的。希望能对你的问题有所帮忙[/h2][h2]引言[/h2]webrtc是一种免费开源的实时通信技术，集成了音视频采集、编解码、流媒体传输、渲染等功能，并在Native代码基础上，封装了简单的JavaScript api，仅通过几行代码即可实现点对点通信，且具有良好的跨平台特性，目前主流的浏览器都已支持。
[h2]基本概念[/h2]SDP： 即会话描述协议，主要保存当前会话的媒体和传输信息，其中媒体信息包括媒体类型、传输协议、媒体格式等，传输信息包括媒体的远程地址信息、带宽等；它由多行kv格式的文本信息组成，具体可参考这里。（https://tools.ietf.org/pdf/draft-nandakumar-rtcweb-sdp-08.pdf）
Offer： 通信的发起方对自己的sdp描述
Answer： 通信的接收方对自己的sdp描述
信令： 协调发起方、接收方通信的数据信息，其中包括sdp描述信息、会话控制信息（节点加入、退出及各类的业务控制信息等）、网络信息、错误信息等。
[h2]webrtc通信[/h2]基于webrtc的点对点音视频通信示意图如下图所示：

其具体的流程如下：

客户端A初始化本地音视频设备，创建一个用于offer的SDP对象，其中SDP对象中保存当前音视频的相关信息；
客户端A通过信令服务器将SDP信息发送给客户端B；
客户端B在接收到客户端A发送的SDP信息并保存后，初始化本地音视频设备并创建用于answer的SDP对象；
客户端B通过信令服务器将SDP信息发送给客户端A；
客户端A、B通过交换SDP等信息，建立P2P通道进行音视频传输；

[h2]Webrtc ICE（交互式连接建立）[/h2]在现实世界中，客户端A、B大部分位于NAT之后，只具有一个内网访问的私有ip，不足以提供足够的信息来建立一条端对端的连接。为了克服由NAT产生的网络问题，一般情况下，webrtc采用ICE框架，通过ICE来找到一条对等连接的最佳道路。
举个栗子，小A和小B是好朋友，某天他们都换了手机号，而且都绑定了一个手机短号（短号不在一个集团网中），然而都忘记新的号码是多少。为了两个人通话联系，小A尝试用短号拨号不通后，小A拨打114询问自己的电话号码，114看到来电显示后将手机号告诉小A；小B以同样的方式获得了自己的手机号；这样两人就可以相互通话了。
类似于上边的例子，客户端A和客户端B处在不同的内网环境中，首先ICE尝试采用从操作系统和网卡获得的主机地址建立连接，如果连接建立失败，ICE会发送binding request给STUN服务器，服务器探测到客户端A的公网地址后将信息加在binding request中，并返回给客户端A，这样客户端A获取到了自己的公网地址。以同样的方式客户端B获取到自己的公网地址。这样，客户端A、B就可以将SDP中的地址信息替换为公网地址进行通信了。

然而，有些情况并不是那么顺利，比如114显示小A、小B电话未知来电或者小A、小B通话线路故障等原因，导致小A、小B不能通话。这个时候114说，要不这样吧，我给你们各发一个临时号，如果你们要通信，我直接按照你们的临时号给中转一下通话信息。同理，webrtc中，如果STUN建连失败，可以采用TURN服务器的方式。TRUN可以担任中间人的角色，将客户端A、B的数据进行中继转发，实现不同内网的客户端通信。
Stun/turn服务器可以采用coturn（https://github.com/coturn/coturn），服务器验证方式可以参考这里（https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/）。
[h2]Webrtc与直播：[/h2]以下根据自己的理解，简要的说明几种直播方案的优缺点。
[h2]1、rtmp方式[/h2]众所周知，目前主流的直播方案一般采用rtmp方式，首先客户端采集音视频流，并通过rtmp协议推流到流媒体服务器，流媒体服务器做一些编码处理等将流分发给各个客户端，进而拉流播放。出于成本、安全等考虑，可能会将不同流按照一定的配比推送到不同的流媒体服务商，在特殊情况下可采用调度方式进行切流处理。

优点：

CDN 支持良好，主流的 CDN 厂商都支持
技术比较成熟，集成方便，例如声网、即构等，集成对应平台的sdk即可进行推流。
相较于端对端的webrtc方式，并发度高，适合多人直播场景；

缺点：

协议基于tcp，相对于webrtc方式延时较大，对于某些低延时场景体验较差；
不支持浏览器推流等；

[h2]2、基于端对端的webrtc[/h2]基于端对端的webrtc方式，严格来说不属于常规的直播场景，其主要适用于人数较少的视频会议等场景，各个节点分别建立p2p连接进行音视频的传输，主要工作流程如上边webrtc所示。
优点：

在web端，对于开发者和使用者来说，音视频通信的开发和使用简单化；对于开发者来说，门槛低，不必熟悉流媒体，仅调用js api即可实现；对于使用者来说，打开浏览器等浏览器即可。
点对点通信，节省服务器带宽费用。
相对于基于tcp的rtmp推拉流方式，支持udp的webrtc方式延时低。

缺点：

客户端浏览器的性能有局限。如果是1v1方式的直播连麦，尚好；如果多人同时进行直播连麦，浏览器需要同时给多人进行视频传输，性能欠佳。
音视频处理相对来说比较困难。webrtc开放的api接口较少，集成第三方音视频处理方案较难，比如秀场直播的美颜等。
音视频的传输质量难以保障，尤其在跨地区、跨运营商的情况下，仅能做一下端对端质量控制算法，无法保障。
兼容性问题。在pc端，目前的主流浏览器都支持webrtc，但是在移动端，只有部分浏览器支持（目前国内的主流手机浏览器均不支持）。
关于直播内容的后续工作不好展开，内容质量难以把控。比如rtmp推拉流方式生成的回放、内容审核等很难处理了。

[h2]3、基于媒体服务器的webtrc直播：[/h2]基于端对端的webrtc受限于客户端性能、连接人数等限制，很难适用于直播场景。为了解决这些问题，可以引入媒体服务器，客户端仅传输一路音视频流到媒体服务器，其余客户端通过与媒体服务器建立连接进行音视频显示。

目前开源的主流webrtc媒体服务器如下：

Kurento（https://github.com/Kurento/kurento-media-server）
licode（https://github.com/lynckia/licode）
janus（https://github.com/meetecho/janus-gateway）

优点：

相对于端对端的webrtc方式，避免了客户端性能低、音视频处理、内容审核等问题，支持更为复杂的应用场景；
支持多人进行同时观看直播，并发度高；
在web端集成相对简单容易，采用浏览器即可接入，且延时较低；

缺点：

该种方式相对于端对端的webrtc方式，开发成本较高，需要实现自己的媒体服务器，而目前没有比较成熟的方案。
相对于成熟的rtmp配套解决方案，周边设施相对较少。

综上所述，基于端对端的webrtc直播的方式不适合直播场景；基于媒体服务器的webtrc直播，目前还没有成熟的解决方案，需要自己实现媒体服务器，门槛较高，具体可根据开发成本与收益进行定夺。
我们是花椒技术，如果想了解更多内容请关注我们的公众号：花椒技术
http://weixin.qq.com/r/bRM7I8bEx5u4rYJA90Z-123 (二维码自动识别)

有关回应 · 2021-5-14 20:30:39

答案1：webrtc整体的技术并不适合做直播。webrtc设计的初衷只是为了在两个浏览器/native app之间解决直接连接发送media streaming/data数据的，也就是所谓的peer to peer的通信，大多数的情况下不需要依赖于服务器的中转，因此一般在通信的逻辑上是一对一。而我们现在的直播服务大部分的情况下是一对多的通信，一个主播可能会有成千上万个接收端，这种方式用传统的P2P来实现是不可能的，所以目前直播的方案基本上都是会有直播服务器来做中央管理，主播的数据首先发送给直播服务器，直播服务器为了能够支持非常多用户的同事观看，还要通过边缘节点CDN的方式来做地域加速，所有的接收端都不会直接连接主播，而是从服务器上接收数据。
答案2：webrtc内部包含的技术模块是非常适合解决直播过程中存在的各种问题的，而且应该在大多数直播技术框架中都已经得到了部分应用，例如音视频数据的收发、音频处理回音消除降噪等。
所以综上，可以使用webrtc内部的技术模块来解决直播过程中存在的技术问题，但是不适合直接用webrtc来实现直播的整体框架。

可以用WebRTC来做视频直播吗？

5 个回复