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

淘宝直播是基于 WebRTC 实现的一秒内的低延迟直播，低延时这一块儿我们在业内做得比较好，关于我们的方案可以分享给大家~（欢迎关注我们，后续分享更多有关淘宝直播的技术方案）

本篇回答内容来自于阿里巴巴淘系技术部技术专家常高伟，主要面向直播行业从业者，以及对低延迟直播技术、 WebRTC 技术感兴趣的技术人员，介绍淘宝直播在低延迟直播技术上的探索，如何基于 WebRTC 实现一秒内的低延迟直播，以及低延迟直播对电商直播的业务价值。

——————————————————————————————————————————

低延迟技术选型

▐ 当前直播技术延迟

传统的直播技术延迟非常大，从观众评论到看到主播给出反馈一般要在十秒以上。通过多媒体技术降低直播延迟、提高主播和粉丝的互动效率是我们研究低延迟直播技术的初衷。

我们对当前主流直播技术做了分析，在低延迟直播技术出现前主要有 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 的方案实现。

▐ 低延迟直播技术选型

上图是我们基于 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 基础上的私有协议扩展，淘宝直播目前使用最多的就是基于私有协议的分发。

▐ 低延迟直播技术

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

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

▐ 标准 WebRTC 接入流程

播放流程描述：

• 播放端端发送接入请求：通过 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 建联过程耗时过长，会影响秒开体验。

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

▐ 私有协议接入流程

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

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

对流程的几点说明：

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

▐ 私有协议状态机设计

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

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

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

▐ 私有协议信令设计

私有信令我们选择使用 RTCP 协议。原因是 RFC3550 定义了 RTCP 的四个功能，其中第四项可选功能描述为：RTCP 可以用在“松散控制”系统中，传递最小会话控制信息。比如，标准定义了 BYE 消息，用于通知源已经不再处于激活状态。我们在此基础上扩展了建联的信令消息，包括请求、临时响应、最终响应以及最终响应 ACK 。

同时，我们选择 RTCP 消息中的 APP 消息承载我们的私有信令。APP消息是RTCP 提供的一种为新应用、新功能使用的一种扩展协议，即它是 RTCP 提供的一种官方扩展方式，应用层可以自己定义消息类型以及内容。此外，选择此协议也基于以下考虑：

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

▐ RTCP-APP 消息介绍

介绍下 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，是一种灵活的、扩展性高的二进制数据格式，它占用空间低。

▐ 私有协议媒体部分设计

媒体部分协议主体遵循标准 RTP/RTCP 规范以及 WebRTC 的相关规范，其中 H264 采用 rfc6184 规范，H265 采用 rfc7798 规范。

对 RTP 的扩展部分使用标准的RTP扩展，为了和 WebRTC 兼容，标准 RTP 扩展头部定义使用了 rfc5285 标准。

▐ 两种接入方式对比

标准 WebRTC 接入的优点：

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

标准 WebRTC 接入的缺点：

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

私有协议接入优点：

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

私有协议接入缺点：

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

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

▐ 流程协议设计原则

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

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

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

终端接入方案

▐ 基于 WebRTC 全模块的接入方案

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

这个方案的优缺点并存：

优点：

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

缺点：

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

▐ 基于 WebRTC 传输层的接入方案

我们目前终端的整体接入方案如上图，也是基于 WebRTC，但是我们只使用了 WebRTC 几个核心传输相关模块，包括 RTP/RTCP、FEC、NACK、Jitterbuffer、音视频同步、拥塞控制等。

我们在这些基础模块上进行了封装，将他们封装成 FFmpeg 插件注入到 FFmpeg 中。之后播放器可直接调用 FFmpeg 相关方法打开 URL 即可接入我们的私有低延迟直播协议。这样可极大减少播放器和推流端的修改，降低对低延迟直播技术对原有系统的侵入。同时，使用基础模块也极大减少了包大小的占用。

▐ 播放器针对低延迟直播的修改

上图是普通播放器的架构。播放器使用 FFmpeg 打开网络连接，读取音视频帧后会放入播放器缓冲，之后会依次对它进行解码、音视频同步及渲染。

接入低延迟直播系统后，整体架构如图下面部分：FFmpeg 增加低延迟直播插件支持我们的私有协议；将播放器的缓冲设置为0秒，FFmpeg 输出的音视频帧直接送入解码器进行解码，然后同步，渲染。我们将播放器原先的缓冲区移动到了我们的传输层SDK中，使用jitterbuffer可以根据网络质量好坏动态的调整缓冲区大大小。

整个方案对播放器的修改很小，基本不影响原有播放器的逻辑。

低延迟直播业务价值

低延迟直播技术目前已在淘宝直播中大规模应用，它的上线降低了淘宝直播的延迟，提升了用户的互动体验，这是最直接的价值。

所有的技术优化都是为了创造业务价值，所有体验的提升应该对业务提升有帮助。我们经过线上验证发现，低延迟直播对电商直播的成交有明显的促进作用，其中 UV 转化率提升4%，GMV 提升5%。

同时，低延迟直播技术也可支持更多业务形态，例如拍卖直播，客服直播等。

未来展望

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

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

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

————————————————————————————————————————

本账号主体为阿里巴巴淘系技术，淘系技术部隶属于阿里巴巴新零售技术事业群，旗下包含淘宝技术、天猫技术、农村淘宝技术、闲鱼、躺平等团队和业务，是一支是具有商业和技术双重基因的螺旋体。

刚刚入驻知乎，将会给大家带来超多干货分享，立体化输出我们对于技术和商业的思考与见解。

详情介绍可以看这里 阿里巴巴淘系技术介绍

欢迎收藏点赞关注我们！共同进步~ ：）

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

这是正道，别走弯路了。

---