传统多媒体业如何应用 WebRTC

本文介绍了 WebRTC 低延迟的应用方向、传统多媒体业如何应用 WebRTC、WebRTC 如何适应变化网络环境以及WebRTC 在工业界的未来方向等内容。

来源：THE VIDEO INSIDERS
主持人：Mark Donnigan, Dror Gill
演讲者：Ryan Jespersen
整理：李昊勇——煤矿工厂

开场

Mark 和 Dror 首先介绍了来自 Millicast 的 Ryan Jespersen。Ryan 从 2010 年就开始从事视频点播和直播行业，曾经在 Wowzer 工作了超过 5 年，并在离开 Wowzer 后加入了 Cosmos Software，也就是 Milicast 的父公司，并在过去的三年里主要都在研究基于 WebRTC 的 Milicast 产品。

低延迟的应用方向

Ryan 主要使用 WebRTC 并非用于直接的视频通信等，而是用这个协议来进行低延迟流媒体传输。WebRTC 在刚出现时被视为一种用于 VOIP 或是端到端通信的技术。作为一个用于网页的端到端的音视频传输技术，相对于传统的广播业，它的并发能力差，且需要工程师具有一定的工程能力来让它投入实用。从原本的广播业看来，对于 SDI 和编码层以下的内容应如同一个黑盒不需要太多的关心，但是对于 WebRTC 来说，从上到下的几乎所有过程都需要工程师来进行参与调试。

由于 WebRTC 是一个首先强调延迟的协议，这一点与一直以来的传统传输协议不同，但是也导致它可以实现秒级的交互媒体。即使是基于原本的卫星或蜂窝网络，也可以达到全球范围的 3-5 秒的最大延迟。这些新兴的多媒体形式可能成为流媒体和广播业的一个新的浪潮。其中一些内容是十分显然的，如观众对实时性要求很高的内容，但是更多的是去融合那些包含虚拟观众以及线上活动的多媒体内容。在网页原生以及秒级延迟对交互式媒体流的支持方面，WebRTC 现在还没有其他技术上的竞争对手。

传统多媒体业如何应用 WebRTC

在 Ryan 最初创始 Milicast 时，有很多需求内容都是将原本的在工作室内的商业级设备以及工作流程迁到公网上成为用户级的工作流，而一大实现这一点的方式就是使用浏览器作为工具，而 WebRTC 正面对应了这项需求。有很多企业包含了远程协作制作工作流程或后期制作工作流程，如 NBC, HBO, NFL, ESPN，都使用了当时 Ryan 参与搭建的 Evercast 来使用浏览器加摄像头完成这些远程和后期的工作流程，如后期制作，颜色调整，声音编辑以及动作动画等。这个方向在当时很快成为了 Ryan 主要从事的工作内容，直至今日在好莱坞和许多其他国家还有很多的后期制作工作室。而现在有更多人一同涌进了这个实时的浪潮，NASA 就是一个很有趣的例子，他们不希望通过卫星或者地面来发送内容，导致 TV 端会带来庞大的成本，他们转而尝试发送 WebRTC 高质量 4K 内容给代理端，而这些代理端就可以获取这个内容，处理为数字生产或者广播并交付给传统的卫星或地面来进行投放。

作为一种生产方式，WebRTC 已经成为了行业内主导性地位的角色，部分情况下代替了 RTMP 甚至 SRT。Ryan 认为从协议角度上说，WebRTC 最大的特点是不仅解决了供应方的需求，同时也解决了消费方的需求。SRT 作为一个供应商的解决方案非常合适，可以在一端有一个 Haivision 编码器并在另一端安装 Haivision 解码器推给 SDI，但如果用户希望能够在浏览器上体验呢，那就不得不再更换成 HLS，但是 HLS 又不能很好的适用在交互性体验上。这就是为什么 Ryan 认为 WebRTC 作为一个 Web 标准，提供了一种很好的端到端的全新的工作流。

WebRTC 如何适应变化网络环境：SVC

WebRTC 强调低延迟也就允许了服务中出现的丢包，但是也就使它能够在各种各样的网络环境下，都保持着一个较低的延迟。很多人可能觉得当考虑到防火墙问题时 WebRTC 会出现很多麻烦，但实际上就以 Ryan 所使用的 Millicast 平台来说，可以直接使用一个 TURN 服务器把端口转到一个一般都会面对防火墙开启的端口，如端口号 80。现在绝大部分的 WebRTC 使用都会使用 TURN 服务，如 Twilio 等，但实际上就以 Ryan 的 Millicast 平台上来说，基本上就只有大概 2% 的用户会有这样被限制的网络条件去真的需要使用 TURN 服务，现在绝大部分的端口都会对大部分网络直接开启，所以防火墙本身并不是什么大问题。

因为 WebRTC 默认是使用浏览器运行，因此很多编解码的参数和功能都被设好了。假设现在一名用户正在使用 JavaScript 的浏览器，浏览器会探测它当前网络环境的带宽来适应网络。这对于单个用户来说非常合理，但是对于一个广播站就有些麻烦了，因为它需要提供具有差异化的编码。但是 WebRTC 有一个非常大的优点，就是它是完全“编码器无关的”，WebRTC 中没有任何的内置的分辨率或带宽限制。Ryan 有很多的广播业客户在用下一代编解码器进行 4K，8K 编解码，来生产高质量杜比内容，也就是说 WebRTC 是可以强制设定在一个高分辨率进行工作的。而最重要的唯一一个真正会阻挡广播和推流使用 WebRTC 的点是：WebRTC 中的视频质量是一个问题。在 Ryan 的平台上，他们的 CTO 可以让AV1，SVC 在 Chrome 上运行，疯狂的是如果你看向市场上低于 5000 美元的编码器，可能都不会有一个能支持 AV1，SVC。SVC 这么重要是因为它淘汰了 ABR，淘汰了多播。并非像 ABR 一样先生产高质量内容发布给一个传统的源端服务器，再由服务器来通过 HLS 等来生产不同码率的内容进行推流。SVC 可以把视频直接在空间分层进行编码，不需要添加任何其他的分辨率。这是在整个广播推流业内只有 WebRTC 可以做到的，因为他是一个“编码器无关的”协议。

另外一点是，由于在使用 SVC 流时，不需要对中间的媒体内容做更多处理，这就意味着我们可以做真正的从编码到解码的端到端加密，这对于企业政府或者军事中的所有人都是相当有用的，因为它消除了数据流中对其他模块的依赖性，真正意义上的数据安全。且其中的 SVC 与加密部分完全不相关，你可以选择任何想要的加密协议。

总的来说就是 SVC 只会有单个编码流里包含了可能各种不同的分辨率、帧率或码率的视频，并在供应端进行编码加密，在经过整个互联网后在客户端可以直接解码解密后在其中选择一个合适的层来播放，在整个网络中间不需要其他媒介来进行参与。

更换 HTTP 协议为 WebRTC 的权衡是什么

HLS，DASH 和 HTTP 传输协议显然都是为了服务器的需求产生的，他们能够以很小的代价去把内容进行扩展。CDN 非常青睐这样的做法，因为扩展基于 HTTP 的内容是非常经济实惠的，以至于对于 CDN 这已经成为了一种必需品。但是问题在于这些协议在当时解决了问题，在现在也解决了 90% 的直播需求，但是一旦当你希望加入一些交互式元素，市场上尽管有一些工具可以用于同步客户端收到的内容，但是实际上为了达到同步这些客户端之间的内容，你还是会在同步这一步骤中加入相当的延迟，因为你需要每个人都在同样的正确的时间，尽管这些协议在做一些升级来弥补延迟方面的不足，但是对于用户的体验还是很难合格，因为这个协议从根本上就并不是为了实时交付和实时互动诞生的。

说到可扩展性，这就是 WebRTC 一直都存在的一个问题，只有行业内的少数专家才对如何真正地扩展 WebRTC 业务。很多 CDN 和推流供应商都没有深入研究 WebRTC 的原因是它某种程度上偏离了最原始的服务器模式：一个终端服务器进行转码并推流给 CDN 服务器。供应商认为加入扩展性的成本远比传统无差别模式 CDN 的成本要高，但是 Ryan 认为 WebRTC 带来的新架构中的低延迟、可交互能力所具备的价值要远远比其他的无差别模式多媒体具备的要大，在考虑商业价值时，需要把交互能力这一最新互动方式包含的隐性价值纳入考虑。另一个传统推流业内比较抵触 WebRTC 的原因是：不同于那些已经相对成熟的协议，如 RTMP, HLS 等，有很多自带的功能，WebRTC 需要实现者将那些功能自己部署进去，放入数据信道里。但是归根结底，如果你想要搭建一个交互性和沉浸式的环境，Ryan 认为 WebRTC 就是最合适的，因为它是基于 web 的，且不需要任何第三方插件。

支持广播能力的 WebRTC 扩展工作

Ryan 正尝试往 WebRTC 中加入一个信令标准，并正在申请 IETF。当采用 WebRTC 解决方案时，WebRTC 系统内部有很多细节都没有定义，等待实现者自己根据需求进行实现，在数据信道中，媒体传输层，即如何广播音视频，定义是十分完善标准的，但是其他部分还没有非常标准的定义。如信令层如何区分平台和工具来与其他 WebRTC 沟通。

接着 Ryan 开始介绍 WHIP：WebRTC Http Ingest Protocol，某种程度上就是实现一个 WebRTC 上的 RTMP 的 URI。WebRTC 中的信令层没有完善的标准实现，Ryan 和他的同事在做的就是实现他们自己的 OBS 版本，实现一些其他的工具。他们厌倦于各种各样不同的信令标准，并决定制作一套标准并提交给 IETF，这样，所有的设备，包括编码器、平台在互相连线时，如 Millicast，Wowzer 或一个新的生产协议都可以在一个标准信令层下进行。Ryan 认为这也会简化软硬件编码器增加新的功能的流程和难度，因为每个不同开发商的产品都能够互通，而不是为了每一个特定的 WebRTC 平台单独设计一套信令流程。

市场上不同的 WebRTC 平台间差异

首先 Ryan 介绍了 Medooze 多媒体服务器，是一个在 github 上开源的多媒体服务器，其实就是一种 SFU(Selective Forwarding Unit) 方案，可以获取 WebRTC 和 RTMP 内容并发送给客户端。另一个很有名的开源平台就是 JANICE，还有很多传统的媒体服务器技术供应商如 WOWZA 就有着 WebRTC 的实现。而当你真的尝试去实现一个方案时，如果你的需求就只是一个像谷歌会议一样的功能，差不多放入 10-15 个用户的话，你可以直接通过 P2P 实现，或者在中间放置一个中介服务器，也就成为了 SFU 的架构。这个规模的扩展一般比较简单，而且部署很快。SFU 做的就是一个音视频内容转发路由的功能，和 MCU(Master Control Unit)的区别非常大。MCU 很类似一个传统的根服务器架构，就和 WOWZA 一样。当你想要尝试去扩展其实现真正的大量用户的广播时，这就开始变得十分困难了。你必须要搭建你自己的 WebRTC CDN，这十分困难，Ryan 推荐还是更好去使用供应商所提供的服务。Millicast 显然就是这样的服务商之一，但除此之外还有很多的不同类型，各自面向着不同市场，比如 ClubHouse 背后的 Agora、已经在市场一些时间的 Twilio、Twilio 的竞争对手 Dolby.IO 等。

Ryan 对于这些不同服务商所能提供的扩展能力并不清楚到数字，但是他们自己的平台可以测试到有百万级并发，在生产中，他们在如虚拟观众或者实时赌博等直播活动中可以在单个流中有成百上千的并发用户。Ryan 是在云端部署的，并可以在有请求时自动开启一个服务器并在请求结束后关闭服务器。他使用了 DigitalOcean 作为他们的数字服务器，对他最大的限制就是数字服务器本身的带宽。大部分的云服务器的带宽差不多是 1Gbps，而由于 Ryan 不对媒体进行转码和处理，他们直接使用服务器进行转发，这并不很吃内存或者 CPU，带宽上限就成为了瓶颈。但是他也有他们自己的负载均衡来在服务器之间根据质量和并发用户的数量对内容进行调整，并认为其他服务商应该也都有类似的机制。

WebRTC 在工业界的下一个方向

Ryan 认为人们有些满足于工业界现有的内容，当有些模式成为了沿用多年的标准后，人们就满足于在舒适圈内，而一些可能更适用于一些新场景的技术的发展也就受到了一些限制。WebRTC 非常好的一点就是整个技术是开源的，形成并决定 WebRTC 标准的委员会是由成千上万个从不同的供应商公司，主要的服务商，通信会议成员的工程师共同组成的。甚至是在 FPGA 硬件层都有开发人员参与 WebRTC 项目。浏览器与广播的结合，WebRTC 创造了两个领域的交集。

Ryan 认为在大概十年时间后，市场上就不会再有硬件编码器，用户只需要将硬件设备连接到一个网络浏览器，网络浏览器直接就可以成为一个编解码的方式。除 WebRTC 以外没有任何一项技术可以在未来的发展路线上可能实现这一点。Ryan 十分期待这样的变化，因为 WebRTC 非常合适于把这种新的交流沟通方式嵌入到传统的工业界中。