WebRTC

WebRTC有前途吗？

苹果一直不在safari上支持WebRTC，目前也没什么开源方案可以在iphone上使用WebRTC。大家觉得WebRTC的前途如何？
关注者
632
被浏览
234,224

40 个回答

在直播大趋势下，现在的 WebRTC 开源软件还不能很好地支持直播。

基于 WebRTC ，我们淘宝直播做了一些方案改造，实现了一秒内的低延迟直播。本文核心内容是对比下各传输方法间的优缺点，以及我们对 WebRTC 的创新实践和未来展望。

（点击头像关注我们，后续分享更多淘宝直播的技术方案）

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

低延迟直播技术选型

上图是我们基于 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 --- Web browsers with Real-Time Communications (RTC)。

WebRTC是一个免费、开放的项目。使web浏览器通过简单的JavaScript api接口实现实时通信功能。WebRTC组件已经被优化以最好的服务于这个目的。下图是已支持WebRTC的浏览器。

WebRTC是个准标准。由GOOGLE主导，目的是浏览器上实现视频实时通讯。它提供了基于API的标准化，标准化于W3C,IETF两个组织。 GOOGLE一直希望和致力于让WebRTC的技术成为HTML5标准之一。

相对应的是微软正试图推动万维网联盟(W3C)“可自定义的、无处不在的实时通信”(CU-RTC-Web)标准（微软的标准）。所以微软的IE浏览器现在不会，将来也不会支持WebRTC。

WebRTC是个开源的视讯软件。用C++实现，高效，跨平台，稳定。已被应用于数百万的终端中超过8年以上的时间。WebRTC的核心源于GIPS。

GIPS(Global IP Sound)原是世界顶尖的互联网音视频方案提供商，于2010年被GOOGLE 用6820万美元收购。视频主推On2(GOOGLE2009收购)的VP8,VPX。QQ还在使用GIPS方案，下图是最新版本QQ的截图。使用GIPS方案的还有Yahoo,AOL,IBM，SKYPE(原)等等

WebRTC是视讯技术的教科书，宝典和工具集。目前的视讯技术，特别是VOIP和基于互联网的视讯技术在WebRTC中找到解决方案。WebRTC极大的降低了音视频技术的门槛。

GOOGLE认为支持互联网的核心技术如HTML, HTTP, and TCP/IP是开放免费的，互联网也为此繁荣，所以音视频技术也必须免费并且高质量。

WebRTC是变革者。WebRTC彻底改变了media engines市场。使一种商品消失了。SPIRIT-DSP原来是GIPS的竞争对手。虽然GOOGLE帮助SPIRIT干掉了对手，但结果损失最大的却是SPIRIT。受影响的还有 Microsoft/Skype, Apple, Traditional conferencing vendors。。。

WebRTC是GOOGLE的野心。GOOGLE想控制媒体通道。建立WebRTC生态。

业内对WebRTC的看法

Polycom

CISCO

Cisco为WebRTC开源H.264. 开源项目叫openh264 openh264.org. 现已集成进WebRTC代码中。

华为

华为认为HTML5/WebRTC是基于浏览器的媒体通信技术，实现媒体交互应用。

Chrome/Firefox浏览器已经支持。Vidtel基于私有协议进行了WebRTC的商用。

促进融合、互通和标准化，开放和免费将降低软视频门槛，将对行业产生巨大变革影响。 华为的一些产品已使用WebRTC组件。

VIDYO


INTEL



Wainhouse

Wainhouse认为WebRtc是对UC的潜在破坏者。

腾讯

分析发现腾讯的微信已大量使用WebRTC组件。


最后，WebRTC能不能成为未来事实标准还不好说，但学习分析使用WebRTC一定有前途。


---------------------------------------------------------------------------------------------------------------

离上次回答已有一年半了，不觉中WebRTC也开源5周年，WebRTC持续的影响着实时音视频领域。下面引了微信号为 blackerteam 的文章。



原创

2016-06-23blacker

blacker blacker

2016年6月9日是WebRTC开源5周年的日子，Google WebRTC负责人Harald在社区里面写了一篇文章总结这几年的进展，并附上了自己5年前同样场景下写的一篇文章。为了便于大家更好理解过去5年在WebRTC上都发生了什么，我将这两篇给翻译过来了。

友情提醒：整个翻译并不是逐字逐句进行的，而是在理解了作者的意思后用自己的语言表达出来的，因为如果逐字逐句可能很多意思我们都无法正确理解。这就是为什么有些英文资料被翻译成中文后晦涩难懂。当然如果英语够好建议直接看原文。

招兵买马：如果您英语水平还行，也有兴趣帮我们一起来做这些有情怀的翻译，欢迎后台联系，全职、兼职、待遇和要求等都好谈。

5年前的感慨


今天谷歌开源了WebRTC技术，一个用于实时语音和视频通话的软件包，她即将被整合到Chrome。

这是我们的第一波贡献，一切都是为了一个伟大的使命——在统一的标准的API下实现所有浏览器间的音视频通话。


这个初始版本将提供我们设想的一些功能，具体详见：sites.google.com/site/w。

另外我们也积极与浏览器社区和W3C工作组合作，以便在未来数月内有越来越多的开发者基于现有API来创建相关应用。


我们发布的基本组件都是稳定的，接口也是跟工作组讨论之后确定下来的。当然我们后续还将继续跟W3C工作组保持沟通以便相关标准能尽快定稿。我们公司也将义无反顾地支持这些标准，最后我们真切期待您在未来几个月内的加入。


作者：Google Harald.


今天的总结

今天，回首往事，我们可以很自豪地说：“我们实现了我们所有的目标。”


现在音视频交互变得越来越重要，许多产品和服务都支持Web和Native之间的无缝交换，而他们之中绝大部分都是基于我们现在开放出的标准API——这些API的底层实现基本上都是基于WebRTC 。


一套通用标准促进了整个行业的发展，Firefox，Opera和微软都已经在支持WebRTC技术了。这已经导致超过20多亿浏览器用户使用了WebRTC技术，仅仅Chrome上每周就有超过10亿分钟的音视频通话，以及超过500T的数据传输（通过WebRTC的数据通道）。


WebRTC从一开始就秉持一种很开放的态度，向视频编解码免版税方向迈进。在WebRTC中80%音频通信采用Opus，而最近推出的VP9比VP8节省70%的带宽。


由于VP9的努力发展，媒体开放联盟在视频编解码免版税道路上又多了一种选择，以及增加了更多的合作空间。


今天，WebRTC技术在音视频领域已经证明了自己的强大，在接下来的几年里，我们期望看到一个更加强大的WebRTC。


接下来我们会持续改进音视频质量。


我们在WebRTC中愿意采用一些通用的编解码来实现交互通讯，但有一些互操作的问题要去解决。另外作为未来编解码的VP9，他后面在压缩率方面会持续改进，以便更好支持低带宽下的通讯。


今天的通信都发生在许多不同网络条件下，从EDGE到LTE。


WebRTC面临多样化的网络条件，所以必须能够做出相应的调整。所以我们一直在努力改善拥塞控制算法和优化媒体传输配置来适应各种状况，这里面也有很多机会和方法来改善和简化媒体协议以适应当今网络需求。


五年前，大多数通信发生在桌面上。但现在一切都变了，WebRTC技术已经发展到要满足各种移动通信应用的需求。展望未来，还有很多机会，如VR。


WebRTC这个平台只会随着时间推移而价值愈加明显，现在仅仅是开始。


我们要做的就是：努力做好WebRTC这个平台。


作者：Google Harald.