WebRTC现状与未来：专访W3C的WebRTC主席Bernard Aboba

WebRTC现状与未来：专访W3C的WebRTC主席Bernard Aboba

原创 媒矿工厂 媒矿工厂 1月7日

 

 

本文为媒矿工厂翻译的技术文章

 

原标题：WebRTC Today & Tomorrow: Interview with W3C WebRTC Chair Bernard Aboba

原文链接：https://webrtchacks.com/webrtc-today-tomorrow-bernard-aboba-qa/

翻译整理：袁靖昊 黄韦嘉

 

 

 

01

PART

WebRTC标准化状态

 

作为W3C WebRTC工作组的主席之一，Bernard是WebRTC标准化过程中的权威人物。首先，我向他了解有关工作组当前章程的问题。

 

Bernard:

正如2020年4月向W3C的演讲中所讨论的那样，WebRTC工作组章程描述了三个方面的工作：

1. 首先完成WebRTC对等连接（WebRTC-PC）以及相关规范，例如WebRTC-Stats。

2. 捕获，流和输出相关的规范，包括媒体捕获和流，屏幕捕获，来自DOM元素的媒体捕获，MediaStream图像捕获，MediaStream录制，音频输出设备 和内容提示。

3. WebRTC-NV，WebRTC的“下一个版本”。

 

WebRTC-NV是WebRTC的“下一个版本”。这是当前1.0规范之后的内容。

 

Bernard:

WebRTC-NV的工作分为四个主要类别。

1. WebRTC PeerConnection的扩展。这包括WebRTC扩展，WebRTC-SVC和可插入流。我要提到的是WebRTC提议建议书，所有工作都取决于RTCPeerConnection“统一计划”，这是所有浏览器中默认的SDP方言。因此，例如，在没有首先支持“统一计划”的情况下，不可能利用可插入流在应用程序中支持端到端加密。

2. 不满足WebRTC-PC 提议建议中的实现或成熟度要求的功能，例如WebRTC标识，WebRTC优先级控制 和WebRTC DSCP。

3. Capture的扩展，例如MediaStreamTrack可插入流，Media Capture和Streams扩展 以及MediaCapture深度流扩展 （最近恢复）。

4. 独立规范，它不一定依赖于RTCPeerConnection现有的Media Capture规范。WebRTC-ICE  （迄今为止已作为独立规范实现），W3C WEBRTC WG之外开发的API规范 例如WebTransport（在W3C WebTransport WG中），WebRTC-QUIC  （在ORTC CG中）也属于此类。和WebCodecs  （在WICG中）。

鉴于工作类别不同，“ NV”一词有些含糊，可能令人困惑。该术语最初指的是ORTC，但今天通常指的是多个规范，而不是单个文档。在当前用法中，存在歧义，因为“ NV”可能是对RTCPeerConnection现有Capture API的扩展，也可能是对与现有Capture API不相关的API的扩展RTCPeerConnection，例如WebTransport 和WebCodecs。因此，当有人提到“ WebRTC-NV”时，通常有必要提出后续问题，以了解他们打算使用的潜在含义之一。

 

1.1 成为完整建议书的历程

WebRTC中使用的协议由IETF定义， 而W3C 定义浏览器使用的API。W3C的正式标准化之路以及对其中应包含的内容的争论有时是一个有争议的话题。

 

Chad:

您能带领我们的观众了解W3C规范阶段吗？

 

Bernard:

第一个标准化阶段是CR –候选推荐书。候选建议书意味着该规范已经过广泛审查，符合WG要求并且可以实施。在CR，规范可能尚未完全实现（可能存在“功能存在风险”），并且浏览器之间可能存在互操作性问题。

 

Chad:

当您说最后一个CR时，我想这意味着可能存在多个CR或CR流程是一个多阶段的事情？

 

Bernard:

还有一个新的W3C流程，从本质上讲您有实时的规格说明。假设我们要提交关于这两个方面的建议建议之前，我们已经是最后一位了。

因此，PR [Proposed Recommendation]是您试图证明规范中的所有内容均已实现并且还通过了互操作性标准的阶段。然后是建议书，甚至超出了建议书。下一步是PR，我们正在收集您需要的所有数据。对于Peer Connection，它包含大量数据，因为您需要进行所有互操作性测试，其中包括WPT测试结果以及潜在的KITE测试结果。

 

Chad:

WPT是wpt.fyi，这是通用的自动化功能测试，而KITE是WebRTC特定的互操作性测试。

 

Bernard:

WebRTC WPT测试在单个浏览器上运行。WPT中没有用于WebRTC的服务器测试，但是有用于WebTransport之类的服务器测试。因此，WebRTC WPT测试无法证明浏览器之间或浏览器与会议服务器之间的互操作性，而KITE测试则位于浏览器与可能的多个实体之间。

 

Chad:

那是WebRTC特有的-您实际上是在将媒体发送到其他浏览器。

 

Bernard:

为了解WPT测试覆盖范围，我们对规范进行了注释。因此，除了测试结果外，您还想知道测试实际上涵盖了多少规范。

 

1.2 大流行减缓了标准制定工作

WebRTC对WebRTC产生了一些有趣的影响。它使WebRTC社区中的我们所有人都变得异常忙碌，更加关注所有新流量的扩展性和可靠性。但是，这种重点的改变可能会严重破坏现有流程。这也适用于标准化工作吗？

 

Bernard:

最重要的是，我们正在努力收集所有这些证据，这些证据将提交给W3C以声明我们已为建议的建议阶段做好了准备。这是非常重要的一步，但该病毒的进度已减慢。我的意思是，我们认为我们会在实施过程中取得进一步进展，但该病毒已使所有人放慢了脚步。

 

Chad:

是因为人们忙于做事来支持他们的产品，还是因为实际上您不能像以前那样频繁地聚会？

 

Bernard:

大流行使很多事情不安。例如，KITE互操作性测试通常是在IETF事件中亲自进行的，但我们还没有亲自进行过IETF的测试。我们一直在努力弄清楚如何完成测试，但是如果没有每个人都在同一地方，很难做到。如果您遍布世界各地，那么在同一地点和同一时间组织每个人的能力真的很难。想象一下，今天早上3点为您，您需要在不同时区与世界另一端的某人进行互操作性测试。

 

如汇合图所示，该病毒不仅破坏了测试，还影响了实施计划。虽然《建议书》中的几乎所有功能都已在至少一个浏览器中实现，但我们最初认为到2020年秋季，我们将在两个或多个浏览器代码库中实现更多功能。因此，实现进度和测试都并非我们期望的目标。

 

1.3 标准化有多重要

过去几年中，几乎所有更新的Web浏览器都实现了WebRTC。WebRTC正在支持全球IP语音（VoIP）流量的很大一部分。在这一点上，进入下一阶段的标准化是否重要？

Bernard指出，标准化不只是编写规范-它实际上涉及互操作性。

 

Bernard：

标准化将重点放在测试和稳定性上。WebRTC对等连接的最大挑战之一就是它的广度。我们每天都从会漏掉的bug（重要的bug）中学习。我们发现我们的覆盖范围不是我们理想的覆盖范围。我们还了解了拥有所谓的可接受的测试覆盖范围是多么困难。诸如复用之类的事情最近出现了很多错误，这些错误实际上对现有服务产生了重大影响，我们没有针对它们的测试。我们在许多这些错误中看到的是，它们不是WPT遇到的那种问题。它们本质上就是您需要像KITE框架那样的事情，而我们在KITE中的测试覆盖率还不到100％。

总的来说，我在实时通信与网络其他方面所经历的最大差异之一就是测试矩阵的巨大规模。甚至想像一下，如果我告诉您乍得，我想指派您进行开发，请获得95％的覆盖率。我认为通过测试的过程会有所帮助，但这也使我们意识到真正涵盖所有挑战的艰巨性。这很难。

 

 

02

PART

WebRTC扩展

 

使用WebRTC可以做的事情列表越来越长。正如伯纳德所说，WebRTC 1.0正在整个标准流程中发展，因此他们必须划定一条线，在某处添加新功能。正如Bernard会解释的那样，WebRTC扩展是WebRTC 1.0所没有的一些功能的所在地。

 

Bernard:

有一系列取决于的规范RTCPeerConnection。WebRTC扩展就是其中之一。这些是为WebRTC PC添加功能的规范。里面有很多东西，例如RTP标头扩展加密。WebRTC SVC（可伸缩视频编码）不在WebRTC扩展文档中，但我认为它是扩展。我认为可插入流是WebRTC PC（其编码版本）的扩展。这些都是假设你拥有的东西RTCPeerConnection。

 

 

03

PART

getCurrentBrowsingContextMedia

随着视频会议使用的增加，出现了一些关于网络摄像头出问题和意外屏幕共享的著名报道。同时，快速的网络摄像头访问通常是WebRTC服务的问题。使用隐私控制来平衡访问速度是一个难题。此外，使用getMediaDevices提供的媒体设备信息 进行指纹识别是一项持续的隐私挑战。

getCurrentBrowsingContextMedia  建议是解决这些挑战的一个尝试。

 

Chad:

我们可以报道getCurrentBrowsingContextMedia媒体的提议吗？

 

Bernard:

的确是扩展，我认为这是屏幕捕获的扩展。我只想谈谈[媒体]捕获的问题-捕获的许多重点都放在隐私和安全性上。我们发现，媒体捕获流对于保护隐私并不是很好。假设您将向应用程序提供设备上的所有信息，无论是否选择了设备，然后让它创建自己的选择器。好吧，这是指纹识别的真正问题，因为现在我知道您机器上的所有设备。即使您不想使用该相机，我也知道它在那里。因此，它确实可以为您提供指纹识别，并且Jan-Ivar一直建议我们改用另一种与屏幕捕获非常相似的模型。

在屏幕捕获中，您只能访问用户选择的捕获表面。因此，这并不是像我可以访问您所有的应用程序一样，我可以看到每个窗口，然后决定作为应用程序购买想要查看的内容。现在，用户选择了源，您只能访问该源。这就是Jan-Ivar提出的媒体捕获和流模型。本质上，它将成为浏览器选择器的一部分。该应用只能访问用户选择的设备上的信息。不过，这是一个很大的变化。它还对媒体捕获和尖叫的一些基础提出了质疑。例如，如果用户无论如何都要选择约束的目的是什么？

 

Chad:

这是否意味着设备选择器周围会有更多规格？

 

Bernard:

嗯，我认为它的作用是。但是，我们已经决定要比现有模型多或少地改进现有规范。然后，Jan-Ivar为该新模型创建了一个单独的规范，该规范可以解决所有这些问题。棘手的是，这是一个非常不同的模型。当人们习惯了应用程序选择器时，如何转换新模型？这可能需要很长时间。

 

 

04

PART

WebRTC NV

在标准内进行争斗的结果之一是不愿指定正式版本名称，因为每个人对于主要版本（即1.0、2.0）与次要版本（即1.1、1.2等）的构成有不同的看法。曾经有一种称为ORTC的替代建议，有时被定位为WebRTC的后继者，我们将对此进行大讨论。WebRTC 1.0已围绕我们讨论的当前规范进行合并。尽管如此，关于接下来会发生什么仍然有很多争论。他们最终决定使用平淡，不精确的术语命名接下来的所有内容：“ WebRTC Next Version”或WebRTC-NV。

 

Chad:

我们谈到了WebRTC的“下一个版本”中将会看到的内容–我想我们不称呼2.0是因为1.0还没有完成？

 

Bernard:

我想也许是时候考虑取消整个NV术语了，因为它确实可以指两个可能非常不同的事物。正如我提到的那样，其中之一就是对等连接的扩展，例如可插入流，WebRTC扩展，WebRTC SVC。我考虑的方式是，当您将所有这些规范放在一起时，它们加起来便达到了ORTC所具有的相同功能水平。因此，我们已经在WebRTC PC中合并了大多数ORTC对象模型。

另一个非常独立的轨道是我所谓的独立规格。其中包括WebTransport，WebCodecs，WebRTC ICE之类的东西-这些是完全独立的并且不依赖的东西RTCPeerConnection。因此，这确实是与现在的下一代突破。

显然，还很早。WebTransport是一项原始试用版。WebCodecs是Chrome中的原始试用版。现在这是非常不同的，因为您曾经作为整体WebRTC PC的一部分获得的许多东西现在必须用Web Assembly编写。因此，这是一个非常非常不同的开发模型。

有些东西不在那里。例如，WebTransport现在本质上是客户端服务器。我们已经编写了一个对等扩展，并且有一段时间的原始试用版，但是目前它是客户端服务器。因此，您不能仅使用WebCodecs和WebTransport编写完整的WebRTC PC用例。

我要说的是，WebRTC NV发生的另一件事已经变得非常重要，那就是人们真正专注于机器学习和对原始媒体的访问。这是ORTC没有提供的。从某种意义上讲，我要说的是WebTransport或WebCodecs模型在这方面比ORTC更低。ORTC不允许您直接访问解码器和编码器。那就是从WebCodecs获得的东西。因此，我认为我们已经采纳了ORTC的想法，并且将其甚至运用于运输中。

 

4.1 ORTC怎么了

对象RTC（ORTC）是WebRTC的替代模型，它提供了不使用SDP的低级控件。伯纳德（Bernard）是其作者之一，微软推出了最初的Edge，并支持ORTC。我们对ORTC的了解不多，所以发生了什么事？正如伯纳德（Bernard）不久前解释的那样，其中很多已被纳入WebRTC核心标准中。这是ORTC愿景的失败还是胜利？

 

Chad:

您是原始ORTC规范的作者之一。您如何将我们今天的状况与您最初的ORTC愿景进行比较？

 

Bernard:

对象模型在Chromium浏览器中完全存在。因此，我们几乎拥有来自ORTC的所有对象-数据通道中的Ice Transport，DTLS Transport，SCTP Transport-现在，所有这些对象都位于WebRTC PC和Chromium浏览器中。

ORTC还具有我们已合并的高级功能，例如同时广播和SVC。另外，我们还提供了比原始ORTC更高的端到端加密功能，可以通过可插入流支持它。因此，通过对象模型和所有这些扩展，我们使WebRTC PC等效于ORTC。

我们期待的场景是诸如物联网之类的仅专注于数据传输的事物。您可以看到这反映在WebRTC和用例中–这些场景就像对等数据交换一样。

 

 

05

PART

网络运输

WebTransport是另一个W3C规范，具有自己的工作组和规范。您会看到其中涉及WebRTC的大多数熟悉的名称，包括Bernard。

QUIC是一种改进的传输协议–类似于WebTransport可以使用的“ TCP / 2”。

 

Chad:

那么WebTransport是什么，它来自哪里，又与WebRTC有什么关系？

 

Bernard:

WebTransport都是一个API，在W3C WebTransport组中。它也是IETF中的一系列协议（一系列传输）。协议包括基于QUIC的WebTransport（已称为QUIC传输）以及基于HTTP / 3以及可能的HTTP / 2的WebTransport。因此，W3C中的WebTransport API仅适用于QUIC和HTTP / 3。HTTP / 2被认为是故障转移传输，它可能具有单独的API。

该API是客户端服务器API。构造函数和所有东西都非常类似于WebSockets。在构造函数WebTransport构造函数中，给它提供一个URL，然后将获得一个WebTransport。尽管从某种意义上说，您可以创建可靠的流和数据报，但它有所不同。

 

Chad:

数据报，例如UDP中用于快速但不可靠传递的数据报。

 

Bernard:

从某种意义上讲，它是双向的，一旦客户端启动了WebTransport，但是一旦建立了连接，服务器就可以向客户端启动单向双向流，并且数据报可以来回流动。

 

Chad:

双向–像websocket一样？

 

Bernard:

嗯，WebSocket实际上只是客户端。WebSocket不能由服务器启动，但WebTransport可以。在QUIC上的WebTransport中，连接未建立连接。在用于HTTP / 3的WebTransport中，可以将其合并-创建了很多非常有趣的场景，其中一些恢复了IETF BoF。考虑的方式是您可以同时进行HTTP / 3请求响应和WebTransport，包括通过同一QIUC连接进行的流和数据报。

贾斯汀·乌贝蒂（ Justin Uberti）在IETF召开的RIPT BOF会议上曾出现 过这样一种情况，这种情况令人震惊。在那种情况下，您有一个来回的RPC（请求-响应，但是RPC），从而导致从服务器到客户端的流。因此，就如客户所说，我想播放电影或参加游戏或参加视频会议，然后从中获得可能是可靠的QUIC流或数据报流，服务器的结果。

我认为WebTransport有潜力为网络带来革命性的变化。HTTP / 3本身是Web的革命性变化。革命的大部分内容来自更复杂的版本，即HTTP / 3池传输。QUIC传输要简单得多，它只是给了我一个套接字，我将通过它来回发送东西。

 

Chad:

WebTransport有多远？

 

Bernard:

我想说WebTransport API现在已经相当完善了，并且它刚刚完成了其原始版本试用，该试用以M88结尾。有一些错误，有些事情无法正常运行，但是API相对完善。您可以使用它编写相当复杂的示例代码。我认为它已经在我们的规范中更新了实际的代码。因此，如果您阅读此规范，则实际上可以在代码中完成这些工作。希望我们很快会在其中提供一个完整的示例，您可以尝试一下。

在服务器端，仍然存在一些QUIC互操作问题。因此，我认为人们使用的服务器是aioquic（Python库），您也可以将quiche用作服务器，但它并没有集成到框架中。不幸的是，我们没有Node.JS服务器，因为它真的很不错–可能很遥远。

 

Chad:

正如Bernard所说，WebTransport是客户端服务器，而不是像WebRTC一样的对等（P2P）。但是，我们已经看到了P2P QUIC的预览。实际上，Fippo早在2019年2月就在QUIC DataChannels上发表 了一篇文章。与这种新的WebTransport方法相比，它有何不同？

 

Bernard:

那是ORTC风格。它不支持WHATWG / W3C流，它也基于gQUIC协议，而不是IETF的QUIC。WebTransport（使用Chrome中的代码）基于WHATWG传输的内容，也基于IETF QUIC。因此，该RTCQuicTransport代码非常过时，因为它既是较旧的API，也是较旧的协议。该代码已从Chromium中删除。

 

Chad:

那么，如何在低延迟情况下使用Peer-to-Peer WebTransport？

 

Bernard:

我们有一个扩展规范，仍在ORTC CG中。基本上将其视为WebTransport，但您可以将其运行RTCIceTransport而不是URL。因此，要进行构建，您不会给它提供URL，而是给它提供ICE传输。

这就是您构造它的方式。几乎没有ORTC内容基本上是从RTCDtlsTransport您添加来进行点对点的东西中获取的。但是扩展规范只有几页。它非常非常小，例如WebTransport规范的95％完全相同。

我们还没有使用新API和新QUIC库的工作版本。没有包含新内容的版本。的功能之一RTCQuicTransport是它是独立的。今天，Chromium中有称为WebRTC ICE的代码。考虑一下WebRTC PC的ICE传输–这是它的独立RTC版本。RTCQuicTransport从中构造时RTCIceTransport，它不会与您的对等连接对象复用。

它在单独的端口上。现在，在过去的情况下，我们不得不这样做  RTCQuicTransport，因为gQUIC无法与RTP / RTCP STUN和TURN复用。IETF QUIC可以复用。

 

Chad:

gQUIC是Google的QUIC的原始版本。这可能会对IP端口的使用产生重大影响，而捆绑有助于限制端口的使用并通过防火墙。

 

Bernard:

开发人员是否想在所有其他音频和视频内容的同一端口上使用QUIC？如今，在WebRTC PC中，捆绑非常流行。每个人都将所有内容放到同一个端口上-占WebRTC使用总量的99％以上。有人可能会认为QUIC会有类似的需求。如果那是他们真正想要的，我们就不想RTCQuicTransport从ORTC风格化的传输中构造。您希望能够从WebRTC PC ICE传输中构造它。

 

 

06

PART

联播

WebTransport似乎是一种全新的潜在处理方式。但是，如今困扰WebRTC实现的一些棘手问题又如何呢？几乎每一个主要的WebRTC视频会议服务中都有Simulcast，参与者众多，并且在标准化和互操作性方面一直处于挣扎状态。

 

Chad:

联播如何进行？

 

Bernard:

据称，在Chromium中，所有[编解码器]都支持[编解码器] –或至少其中的所有编解码器。因此，从理论上讲，您应该能够使用H.264，VP8和VP9做到这一点。

我们一直在寻找错误。我们遇到了一些非常可怕的错误，例如H264无法正常工作。我们已经进行了完整的KITE测试，但是我们需要一个简单的回送测试，在这里我们可以测试基本操作，您可以在其中向自己发送联播。因此，最终Fippo编写了回送测试。

该测试并未在所有浏览器上通过。它之所以没有通过，是因为您发送了RID，被SDP欺骗了，并以MID的形式接收了它们。因此，从本质上讲，如果您发送了三个流，则可以取回三个流，但是它们各自位于不同的MID上。

Firefox不支持MID RTP标头扩展。因此，实际上该环回测试无效。

 

Chad:

统一计划是一种新的，标准化的SDP格式，除其他外，它指定了应如何在SDP中处理联播流。统一计划不应该成为节省一天的规范吗？

 

Bernard:

如果每个人都对所有编解码器都使用统一计划，并且[互操作测试]都很高兴，那么您会知道一切正常。我们还不在附近。让我这样说–我们功能完善。我认为这是事实，但是事情在测试范围内不断下滑。我不会说每个浏览器都具有发布商业应用程序所需的所有功能。举例来说，例如，我认为确实有很多商业应用程序都在多个浏览器上发布，但我认为在所有浏览器上都发布的应用很少。

因此，考虑到这种情况的一种方法（可能比所有这些测试结果要容易一些）是，如果您对所有主要会议服务及其运行的所有浏览器以及所有不同的模式进行了矩阵分析，则可能会发现最好看看我们实际上在哪里。

 

 

07

PART

可分层编码（SVC）

 

SVC可以说是处理来自同一发送方的多个媒体流以处理组呼叫中每个接收方变化条件的更好方法。但是在很多方面，SVC也会更加复杂。Sergio & Gustavo对此主题发表了精彩的文章。如果Simulcast还没有准备好的话，SVC能做哪些工作呢？

 

Bernard:

在某些方面，SVC比Simulcast容易一些。如今，它已经在Chromium中进行了时间可伸缩性的实验性部署。在备份计划中，也支持时间可伸缩性。因此SVC实际上已经开始被应用了，并且会议服务器都支持它。因此，对于大多数会议服务而言，从某些方面来说，这实际上是一个更轻松的进步，例如，同时支持RID和MID。

MID是SDP媒体标识符（请参阅本SDP解剖），而RID是用于限制单个流的较新的限制标识符。我将它留给读者查看各种SDP规范，以获取有关这些规范的更多信息。

我认为许多会议服务都支持RID和MID，Medooze和Janus都支持。关于SVC的理解之一是，在VP8和VP9中都是必需的-解码器必须支持这一点。因此，没有什么可以谈判的。编码器可以将其推出。如果不希望，SFU甚至不必丢弃[SVC层]，但这显然更好。

 

 

08

PART

AV1

 

很久以前，Chris Wendt在这里写了一篇文章，内容涉及H.26X和VPX阵营之间的编解码器之战，以及一个编解码器统治所有编解码器的潜力。今天，该编解码器已经存在，它被称为AV1。那么WebRTC何时将AV1作为标准？

 

Bernard:

使用AV1面临的挑战是设法在大量设备支持全分辨率编码之前弄清楚如何使其有用和可用。

 

Chad:

我应该向听众解释说AV1是下一代的开源免费编码解码器。

 

Bernard:

AV1本身不需要对WebRTC PeerConnection进行任何更改。但是作为示例，AV1支持许多新的可伸缩性模式。因此，您需要该控件，这就是WebRTC SVC的用处。

另一件事是AV1具有非常有效的屏幕内容编码工具，您希望能够将其打开。因此，我们添加了一个称为内容提示的内容 ，可能会导致AV1内容编码器工具打开。

Floren t [Castelli]提出了一种混合编解码器联播。这样做的想法是，例如，你可以使用AV1对较低码率的内容进行编码，例如需要对360P或720P的内容进行编码，并且你拥有可以做到的机器。你可以在软件中做到这一点，并且不需要硬件加速。然后，在较高分辨率下，你将使用另一个编解码器，例如VP8或VP9。

这样一来，您而不必纠结只有这一种编码器，可以立即引入AV1编码。随着混合编解码器联播和内容提示，基本上只要AV1编码器和解码器进入的WebRTC PC，就可以正常使用AV1了。我认为人们对AV1的考虑不多，但是通过这些扩展（对API的调整很少），我们的目标是立即使它可用。

Alex博士正在编写测试套件。编码器和解码器库在那里，因此并不特别复杂。RTP封装也不是特别复杂，它非常非常简单。

 

那么，什么使它变得困难呢？

 

Bernard:

诀窍在于所谓的依赖项描述符报头扩展，这是SFU用于转发的内容。那是要在会议服务器中建立支持的棘手部分。另一部分是AV1固有地构建为允许端到端加密[e2ee]，这是可插入的流进入的地方。

实际上，AV1作为编解码器在编解码器方面并没有太大的区别。我认为这是VP8 VP9系列中的下一个。它具有某种H.264类型的MAL单元语义，因此有点像H.264和VP9之间的交叉。

但是从会议服务器的总体使用模型的角度来看，它非常独特，因为您具有端到端加密，因此，例如，您不应该解析AV1 OBU。SFU应该纯粹基于对描述的依赖来做出前向决策，以允许端到端加密。因此，从本质上讲，您已经进入了下一个模型，在此模型中，SFU现在可能可以独立于编解码器。

 

 

09

PART

可插入的流和SFrame

 

可插入的流是与编解码器独立性松散相关并且与端到端加密（e2ee）直接相关的一个主题。实际上，我们已经在该主题上发表了文章，而Emil Ivov几周前在Kranky Geek上深入探讨了e2ee。我将让Berard谈谈可插入流API的应用。

 

Bernard:

端到端加密不仅仅是一个简单的用例。可插入流实际上是这个想法，在可插入流API模型中，一种思考方法是您可以访问框架。您可以对框架执行操作，但是您无法访问RTP标头或RTP标头扩展或类似内容。您不应显着改变框架的大小。因此，您无法向其中添加大量元数据。您应该在帧上进行操作，然后将其实质上返回给打包器，然后打包器将其打包为RTP并发送出去。因此它与RTP有一定联系。

还有其他正在开发的API也可以按照为您提供视频帧的相同思想进行操作。其中最突出的是WebCodecs以及用于原始媒体的可插入流。考虑这一点的方法是对媒体流跟踪的扩展，因为可插入流，原始媒体不依赖RTCPeerConnection，而可插入流和编码媒体则依赖。在所有这些API中，您都可以访问视频帧（原始帧或编码帧），然后可以对其执行操作，然后从本质上将其返回。在插入流的情况下，它被打包并通过有线发送。

有一些棘手的方面。已经提交了一些错误。它现在可以与VP8和VP9一起使用，它不能与H264一起使用。我不确定不能使其与H264一起使用，但是我们有一个仍在处理的错误。

这里同样重要的想法是，我们不会试图告诉开发人员如何进行他们的加密或使用哪种密钥管理方案。我们正在开发端到端加密格式的标准，即SFrame，并在那里进行IETF标准化工作。我们还没有完全同意密钥管理方案。事实证明，有多种情况可能需要不同的密钥管理。

 

安全帧或SFrame是一种较新的提议，用于通过对整个媒体帧进行加密而不是对单个数据包进行加密来允许通过SFU的端到端媒体。由于每帧可以有多个数据包，因此可以更有效地运行。

 

Bernard:

关于SFrame的一件很酷的事情，它可能具有更大的可扩展性，你可以在整个框架上进行操作，而不是在数据包上进行操作。这就是说，如果您进行签名，则整个框架只需签名一次。对每个数据包进行数字签名被认为是不可行的。例如，对于暗示您可能对许多数据包进行签名的关键帧。但是对于SFrame，您只需要对每个帧进行签名。

因此，它实际上导致签名开销的大幅减少。因此，实际上已经可以进行原始身份验证，知道每个数据包模型中不可能出现的每个帧的来源。

每个人似乎都同意您只需要一种SFrame格式，但是对于密钥管理而言，这是一件棘手的事情。我们在TPAC上讨论过有关潜在地将SFrame构建到浏览器中的问题，具有SFrame的本机实现。我们还没有达到可以进行本机密钥管理的地步。这是一件非常棘手的事情，因为您最终可能会获得进入浏览器的五种密钥管理方案。

 

 

10

PART

Web编解码器

 

WebCodecs是为开发人员提供更深入的访问和对RTC堆栈的更多控制的主题。我将让Bernard解释一下这是什么：

 

Bernard:

Web编解码器的作用是使您可以较低级别访问浏览器中已经存在的编解码器。因此，从本质上讲，您可以考虑的方式是它与可插入流的相似之处在于您可以访问框架。因此，例如，您可以访问编码的帧，也可以输入原始帧并获得编码的帧。

 

Chad:

好吧，这是更底层的直接访问另一端的编码器和解码器的方法吗？

 

Bernard:

是的。在解码方面，它类似于我们所谓的MSE。

 

Chad:

媒体来源扩展？

 

Media Source Extensions和Media Source API取代了Flash在标准化JavaScript中为流媒体所做的许多工作。即使开发人员具有DRM内容保护，它也允许开发人员将任何容器化的媒体播放到浏览器中。这是MDN链接，以获取更多信息。那么，这与MSE有何不同？

 

Bernard:

在解码方面将其视为WebCodecs的方式与[MSE]类似，不同之处在于未对媒体进行容器化。它将在编码的视频帧中。因此，它们在这一点上是相似的。

例如，当人们问我“如何一起使用这些东西？”时，如果要进行游戏流或电影流之类的东西，则可以连接WebTransport来接收编码的媒体。然后，您可以使用MSE进行渲染，也可以使用WebCodecs进行渲染。MSE的区别在于，您将必须运输容器化的介质。使用WebCodecs不会将其打包，而是将其打包。所以有一些细微的差别。在MSE的功能中，您实际上将获得内容保护支持。在WebCodecs中，至少在今天，您不会这样做。

 

MSE与WebCodecs一起进行编码又如何呢？

 

Bernard:

那是一个有趣的事情，因为如果您考虑一下它，如果它是云游戏或电影或云中传下来的东西，则您永远不会在浏览器上进行编码，而只会解码。因此，这种情况实际上不需要WebCodecs进行任何编码。编码方案将是例如视频上传。因此，如果您要进行视频上传，则可以使用WebCodecs对视频进行编码，然后通过WebTransport进行发送。您可以使用可靠的流将其发送，也可以使用数据报来发送。如果使用数据报进行处理，则必须进行自己的重传和自己的前向纠错。

如果您不太在意视频上传的延迟控制，则可以使用可靠流。因此，在这种情况下，您可以使用WebCodecs作为编码器，而我认为这种情况或用例是WebCodecs真正具有优势的，因为您无需做任何奇怪的技巧，例如将其放入画布或其他东西，或者随你。

 

 

11

PART

面对这些替代方案，WebRTC是否有未来？

 

发送视频是WebRTC要做的一件大事。使用其他API（例如WebCodecs或在WASM中构建自己的编解码器）的WebTransport会取代WebRTC吗？实际上，这就是Zoom所做的（如我们所讨论的），并且Google Chrome小组的一些成员甚至在上一个web.dev live上对此进行了推广。

视频链接：https://youtu.be/nhTxJBgTywc

那是更好的方法吗？那是我们要去的地方吗？

 

Chad:

是让人们自己弄清楚并自己做这些事情的方向吗？还是您认为还会有平行的途径来标准化其中一些机制？

 

Bernard:

嗯，这是一个真实的问题。从某种意义上说，您可以自由地做任何您想做的事情，如果您的世界上的一切都是端到端的，那很好。以今天为例，许多人都想使用开源SFU。您不能只是将您想要的任何东西发送到开源SFU －它对将要获得的东西抱有期望。在像视频上传之类的简单场景中，这可能并不重要，但是在诸如会议服务之类的东西中，您肯定希望有一个标准来知道期望的内容。

现在，要考虑的另一件事是性能，因为我知道人们提高了尝试使用WebTransport制作会议服务器的可能性。我对此感到非常不安，因为特别是在今天，如果您看会议服务，那么对越来越大的画廊的需求很大，例如七乘七的画廊，或者谁知道他们会成为多大的画廊，十一乘十一的人。

因此，似乎有无法满足的需求–讲师希望看到班上的每个人，而且班上人数可能很大。因此，在这样的情况下，您将获得数量惊人的流，可能是高清流。在这种情况下，性能实际上至关重要。因此，对于这种分解模型存在真正的疑问，即WASM中运行的许多代码是否会在整个地方复制所有内容数十亿次。这就是今天的工作方式。例如，在WebTransport中，您收到了两个副本。每当您将任何内容发送到WASM时，您都有一个副本。并非所有内容都转移到单独的线程中。

 

Chad:

我想资源利用效率低下的可能性很大，而且浏览器在管理所有这些资源方面也有很大的潜力。

 

Bernard:

对。因此，人们确实抱怨WebRTC是整体的，但是另一方面，当WebRTC是一个没有运行所有JavaScript的整体代码库时，则存在巨大的优化机会。您可以消除分解模型中可能存在的大量副本

 

 

12

PART

机器学习

 

ML是一个遍及计算机科学的主题。几年前，我们甚至将Kranky Geek 2018的大部分活动都献给了RTC的AI。我们已经看到JavaScript中的ML有所改进，例如我的“别碰你的脸”实验， 以及各种WebRTC应用程序中背景移除/替换的进展。其中大多数都围绕WebRTC运行，而不是直接与WebRTC一起运行。实际上，WebRTC的底层似乎似乎没有ML。我问了伯纳德。

 

Bernard:

在开始讨论WebRTC-NV时，我们要做的一件事是制作 NV用例，并尝试评估人们热衷于做什么。事实证明，除了端到端加密之外，人们最热衷的事情之一就是访问原始媒体，因为这打开了整个机器学习的世界。

 

Chad:

我也要澄清一下–仅为了降低延迟而访问原始媒体吗？在我的实验中，我发现当堆栈中有很多固有延迟时，很难使这些东西实时运行。

 

Bernard:

我们看到的许多场景都涉及本地处理。举个例子，您已经捕获了，并且想要在将其发送出去之前在捕获的媒体上进行操作。例如，Snapchat中的许多效果都是通过这种方式完成的。这就是我们所说的有趣的帽子，您可以在这些位置查看面部位置，然后在其上戴帽子。自定义背景是一个非常受欢迎的功能，您可以在其中自定义背景并以某种方式对其进行更改-具有动态背景以及所有类似的东西。

如今，机器学习的许多其他方面都在云中完成。例如，语音转录或翻译通常在云中完成。因此，您将其发送到云中。我不知道我们是否能够以本地方式做到这一点，更不用说在网络浏览器中了。还有其他一些事情可以在本地完成–诸如此类的面部姿势和身体姿势。

长期的总体目标是能够执行您可以在网络上完成的任何本机工作。这不仅需要访问原始媒体，还需要以有效的方式访问原始媒体。因此，例如，在本机实现中，我们经常看到所有内容都保留在GPU上，并在其中完成了所有操作。我们还不在那里。为此，我们需要在没有副本的情况下捕获到GPU，然后允许进行机器学习操作，而无需将其复制回主内存，进行上传和下载。

上下文有所不同，在过去的Kranky Geek中，Google实际上提到了“零复制视频捕获”以将帧保留在GPU中：

 

Bernard:

这就是W3C研讨会上提出的一个话题。出现的概念之一是Web神经网络API。之前，您已经看到很多使用WebGL或WebGPU之类的TensorFlow之类的库。但是，如果考虑到这一点，那并不是一种完全有效的方法。实际上，您要尝试执行的操作是使基本运算（例如矩阵乘法）有效地运行，而仅将其提供给WebGPU或WebGL操作并不一定是实现该目标的方法。因此，WebNN确实尝试在更高层次上解决这些操作-就像对矩阵乘法器进行操作一样。

这里的关键事情之一是所有API必须协同工作，以便它们将数据传递到不需要复制的正确位置以及另一个API。因此，作为一个示例，您将看到WebCodecs确实支持GPU缓冲区的概念，但是存在局限性，因为很多时候这些GPU缓冲区不可写-它们是只读的。因此，如果您的目标是进行机器学习和更改，那么GPU缓冲区中的内容就没有副本就无法实现，但是也许您会尝试获得尽可能多的性能。

 

真正引起我注意的2020年产品公告是NVIDIA的Maxine。NVIDIA在其GPU上使用了通用对抗网络（GAN）来捕获少量关键帧，然后连续提取面部关键点。然后，它将关键帧数据与面部关键点结合起来以重建面部。NVIDIA声称这种方法使用的带宽是H.264的十分之一。由于还可以调整重建模型以执行超分辨率，面部重新调整或模拟化身等功能，因此它还提供了新功能。

视频链接：https://youtu.be/NqmMnjJ6GEg

这似乎是ML用于RTC的一种更具革命性的用途。这也是标准的发展方向吗？

 

Bernard:

如果您正在研究下一代编解码器研究，那么就从编解码器的角度来看，现在机器学习正在完成大量研究。

我考虑的方式是在大流行中环顾四周。我们看到的是娱乐与实时会议的融合。因此，您将看到很多节目–您的《周六夜现场》是由会议制作的。我已经看过剧院放上角色有自定义背景的地方。我们甚至还看到一些融合了会议技术的电影。在Microsoft团队中，我们已经看到了我们所说的“共同模式”，它实质上是从会议服务中吸收用户输入并将其输入到一个完全合成的新事件中。篮球运动员是真实的，但是它将比赛与实际上不在那儿的球迷结合在一起。

因此，您已经构建了环境– AR / VR。我看到娱乐和实时场景之间的融合。这反映在WebTransport和WebCodecs之类的工具中。它既是RTC，又是流媒体。所有这些情况都是一种。

机器学习可以是导演，可以是摄影师，可以是编辑器，并且可以将整个事物整合在一起。它的每个方面都可能受到机器学习的影响。

我不认为这只是传统媒体。我不认为我们应该尝试使用新的API进行相同的旧会议内容。对于任何人来说，只是使用这套全新的东西重写您的会议服务，这并不是很积极。但是我认为它可以实现一套全新的娱乐和会议场景组合，这是我们今天无法想象的。其中很多似乎都带有AR / VR风格。

 

好的，因此，更多由AI控制的实时媒体类型的融合。

 

 

13

PART

现在怎么办？

 

Chad:

在结束之前您还有其他想法吗？

 

Bernard:

关于这项新技术的事情很多，可以在Origin Trial中获得。尝试使用它并尝试将它们放在一起并查看它如何协同工作非常有启发性，因为肯定会发现很多缺点。我并不是说所有这些API在任何意义上都是一致的-它们不是。但是，我认为它会带给您一些可能的东西以及可以做什么的感觉。人们会对其中的某些技术很快面世感到惊讶。我想说的是，到2021年，一堆这样的东西实际上可能会开始出货，我们会在商业应用程序中看到其中的一些东西。因此人们经常将其视为今天不存在的东西，或者我不必考虑它，我认为他们会错的。以这种方式思考的人们将以一种不愉快的方式感到非常惊讶。

 

那是Bernard对WebRTC的状态和方向的非常明智的看法。如果您想了解有关WebRTC总体方向的更多信息，请查看2020年11月19日的一些Kranky Geek Virtual 2020演讲，您应该查看一下，我在本文中链接了其中的一些内容。Google的WebRTC团队涵盖了多个主题，包括WebRTC NV和编解码器。此外，Bernard加入了WebRTC浏览器面板，代表Edge以及来自Chrome，Firefox和Safari的潜在客户，讨论了WebRTC在浏览器中的状态以及每种浏览器的工作方式。

视频链接：https://youtu.be/YZROn-WsyO4