说明：
本文为阿里云视频云翻译的技术文章
原文标题：WebRTC Today & Tomorrow: Interview with W3C WebRTC Chair Bernard Aboba
原文链接：https://webrtchacks.com/webrtc-today-tomorrow-bernard-aboba-qa/
作者：乍得・哈特（Chad Hart）
翻译：忘篱、致凡、开视、仲才、海华
Bernard 是一直聚焦在 RTC 领域的专家，W3C WebRTC 联席 Chair，WEBTRANS 和 AVTCORE 的联席 Chair，ORTC、WebRTC-SVC、WebRTC-NV 用例、WebRTC-ICE、WebTransport 和 WebRTC-QUIC 等文档的主编，微软 Teams 媒体组的首席架构师。
WebRTC 标准现状
作为 W3C WebRTC 工作组的 Chair 之一，Bernard 是 WebRTC 标准的权威人物，所以我们从工作组的章程开始聊起。
Bernard: W3C WebRTC 工作组的主要工作包括以下三个方面：
- 目前最重要的工作，是完成 WebRTC Peer Connection (WebRTC-PC) 标准化，以及相关的标准比如 WebRTC-Stats。
- Capture，Streams 和 Output 相关的标准，包括 Media Capture and Streams，Screen Capture，Media Capture from DOM Elements，MediaStream Image Capture，MediaStream Recording，Audio Output Devices，以及 Content-Hints。
- 下一代 WebRTC，也就是 WebRTC-NV。
WebRTC-NV 是下一代 WebRTC，在当前 WebRTC 1.0 之后的标准。
Bernard: WebRTC-NV 的工作主要是四个方面。
- 第一类是对 WebRTC PeerConnection 的扩展。这包括 WebRTC Extensions, WebRTC-SVC, 以及 Insertable Streams。我特别强调这些工作都依赖于 “Unified Plan”，现在已经是默认的 SDP 规范了。例如，如果要使用 Insertable Streams 来支持 E2EE (End-to-End Encryption，端到端加密)，那么首先要支持 “Unified Plan”。
- 第二类，和 WebRTC-PC 相比，还不够成熟和完善，比如 WebRTC Identity，WebRTC Priority Control 和 WebRTC DSCP。
- 第三类是对 Capture 的扩展，比如 MediaStreamTrack Insertable Streams，Media Capture and Streams Extensions，和 MediaCapture Depth Stream Extensions。
- 第四类是独立的标准，它们没有必要依赖
RTCPeerConnection或者 Media Capture。比如 WebRTC-ICE，目前就是独立的标准。有些标准不是 W3C WebRTC 小组定义的，比如 WebTransport，由 W3C WebTransport 小组定义；WebRTC-QUIC，由 ORTC 小组定义；WebCodecs，由 WICG 定义。有时候 “NV” 很含糊而且挺令人迷惑的，它最初是指 ORTC，但今天它主要是指多个标准，而不是某一个单一的标准。目前 “NV” 比较含糊，有时候指的是
RTCPeerConnection的扩展，或者 Capture APIs，或者其他的 API 比如 WebTransport 和 WebCodecs，所以当提到 “WebRTC-NV” 时，最好能确认下到底是指什么。
WebRTC 标准的流程
WebRTC 的协议由 IETF 定义，而浏览器相关的 API 则由 W3C 定义。在标准化的过程中，是存在一些争议的。
Bernard 介绍了标准化过程的一些背景。
Chad: 能介绍下 W3C 标准制定的阶段吗？
Bernard: 第一个阶段是 CR，Candidate Recommendation。CR 意味着被广泛 Review 过了，符合标准工作组的要求，并且是可以实现的。在 CR 阶段，标准可能还未被完全实现，可能存在一些有风险的功能，或者浏览器之间的互操作性（interoperability）问题。
完整流程可以看这个链接。
Chad: 您刚才提到最后一个 CR 阶段，请问这意味着在整个 W3C 的 specification 流程中会有多个 CR 阶段，还是整个 CR 阶段内还有多个子阶段？
Bernard：现在 W3C 有新的流程，适用于讨论定稿的活跃标准。不管是上述哪种情况，我们讨论的是在进入 PR 阶段前的最后一次 CR 阶段。
在 PR (Proposed Recommendation) 这个阶段时，标准中的内容都已经被实现，并且通过了互操作性测试。PR 时会收集足够需要的数据，例如 Peer Connection 涉及到了海量的数据，包括 WPT 测试结果，以及 KITE 测试结果。
WPT 是指 web-platform-tests，属于 W3C 实现的 API 的功能性验证测试，可以参考 https://wpt.fyi
KITE 是一个开源项目，属于 WebRTC 专门的互操作性测试。Dr. Alex Gouaillard 在这篇文章中有详细讨论 Breaking Point: WebRTC SFU Load Testing。
Chad: WPT 是通用的功能测试，而 KITE 是 WebRTC 专门的互操作性测试。
Bernard: WebRTC 的 WPT 测试，只跑在单一的浏览器上；WebRTC 的 WPT 测试没有针对服务器的测试，而 WebTransport 是有的。因此 WebRTC WPT 测试，无法验证浏览器的互操作性，也无法验证浏览器和服务器的互操作性；而 KITE 测试是覆盖了这些方面。
Chad: 这实际上是 WebRTC 的特点，从一个浏览器发送媒体数据到另外一个浏览器。
Bernard: 为了能更方便的看到 WPT 的测试覆盖率，我们在规范中做了标记。所以除了测试结果，你还可以看到标准已经有多少被测试覆盖和验证了。
新冠对标准工作的影响
新冠对 WebRTC 产生了有趣的影响。一方面，新冠导致 WebRTC 使用量剧增，让整个社区很繁忙，也更关注扩展性和可靠性。另外，对现有的工作流程也有打断，这是否也影响到了 W3C 标准化工作？
Bernard: 我们努力向 W3C 证明，我们已经准备好进入 PR 阶段了。这是非常大的一步，但总体上还是因为新冠导致进展变慢了。虽然我们取得了很大的进展，但是新冠让大家都慢了下来。
Chad: 是因为大家忙于支持自己暴增的业务，还是没法把大家聚在一起工作？
Bernard: 新冠打乱了很多事情。例如 KITE 互操作性测试，是需要人工参与的，所以现在我们需要很费劲才能测试，因为现在大家不能在一个地方工作，特别大家还是在全球各地；想象下如果按照其他人正常上班的时间，你可能要凌晨 3 点配合测试，这是多么痛苦。
新冠不仅打乱了测试，也影响了代码实现的进度，具体可以看下面的图。目前几乎所有 PR 中的功能，都已经在至少一个浏览器中实现了，但是之前我们预期是 2020 年秋季在两个以上浏览器实现。所以目前测试和代码实现都比我们预期的慢。
WebRTC 标准有多重要？
WebRTC 目前在主流的浏览器中都已经支持，现在 WebRTC 承载了世界上主要的 VoIP 的流量，这个节点上开始下一阶段的标准化工作是否很重要？
Bernard 认为标准化不仅是写文档，更重要的是关于互操作性 (interoperability)。
Bernard: 标准主要关注测试和稳定性。WebRTC PC 最大的一个挑战就是它包含了太多的能力，只要稍微看下它相关的主要的 Bug，就可以发现对它的覆盖率远远不够；即使我们不要求完整覆盖，而只考虑 “可接受” 的覆盖率，也非常的困难；比如在复用 (Multiplexing) 方面，我们有个 Bug 影响了线上服务，但是我们却没有覆盖它。我们看到有很多 Bug 都是 WPT 覆盖不到的，这些只有 KITE 这种互操作性测试才能覆盖到，但是目前我们在 KITE 中还没有达到 100% 覆盖。
我在 RTC 领域中，碰到的最大的挑战之一，就是海量的测试用例。Chad，想象下如果让你去做测试，即使要达到 95% 的覆盖也是非常的有挑战的。当然完整的测试非常有帮助，我们当然也要考虑完整覆盖带来的巨大挑战，真的非常的难。
WebRTC 扩展
WebRTC 正在渗透越来越多的行业和场景。WebRTC 1.0 还在标准化的过程中，所以必须要想清楚如何添加新的功能。正如 Bernard 解释的，WebRTC Extensions 包含了很多没有添加到 WebRTC 1.0 的功能。
Bernard: 有很多标准都依赖
RTCPeerConnection，例如 WebRTC extensions，还有比如，RTP header extension encryption，WebRTC SVC (Scalable Video Coding)。我认为 Insertable Streams 也算 WebRTC PC 的扩展。一般情况下，都是假设使用RTCPeerConnection的前提下。
更安全的访问媒体设备
随着视频会议的广泛使用，出现了摄像头被错误使用，以及意外的屏幕共享等问题。另外，一般来说，在 WebRTC 服务中如何快捷访问摄像头通常是一个问题，如何平衡好隐私问题和便捷性是一个难题。此外，媒体设备可能会被恶意标识和获得个人身份信息 (fingerprinting)，这对隐私保护造成很大的挑战。
而 getCurrentBrowsingContextMedia，是尝试解决这个难题的提案之一。
Chad: 是否能聊聊
getCurrentBrowsingContextMedia提案？
Bernard: 这个是一个扩展标准，我认为它是 Screen Capture 的扩展。让我们先看看 Media Capture 的问题吧，主要是关于隐私和安全方面的问题。我们发现 Media Capturing Streams 对隐私很不友好；假设你把所有的媒体设备信息都给了应用，包括你没选中的设备，那么这就会造成身份信息的一个隐私问题，因为我知道了你所有的设备信息，尽管你可能不想使用的某个涉及隐私的摄像头，我也知道你有这个摄像头了。这些设备能帮助获得和标识个人身份信息 (fingerprinting)，所以 Jan-Ivar 提交了一个提案，设计了和 Screen Capture 很类似的一个模型。
在 Screen Capture 共享屏幕时，应用只有获取用户选中的 Surfaces 的权限，用户没有选中的没有权限。所以并不是我能获取你打开的所有页面的权限，不然就可能看到你的一些隐私页面，比如正在购买的东西等。只有当用户选择某个页面后，应用才能获取权限并启动 Screen Capture，这就是 Jan-Ivar 提案的模型。它也会成为浏览器 Picker 的一部分，应用只能获取用户选中的页面的权限。这是个很大的变化，也引入了 Media Capture 和 Media Streams 的一些问题，比如都让用户选择指定的设备了，那么 Constrains 的意义在哪里，如果不匹配呢？
Chad: 这是否意味着，关于设备 Picker 会有更多的标准出来？
Bernard: 嗯，是的。当然我们会不断改进我们的模型，Jan-Ivar 会提交一个单独的标准，解决所有这些问题。这里麻烦的是，这是一个全新的模型，如何让大家能使用起来，可能需要花很长时间。
TPAC slide on getBrowserContextMedia proposal. 来源: TPAC-2020-Meetings
WebRTC 下一代标准
标准之争的结果之一，就是不愿给出版本号，因为大家可能会有分歧，比如应该用大版本（1.0、20），还是小版本（1.1、1.2）。曾经有段时间 ORTC 是作为 WebRTC 的候选标准。WebRTC 1.0 整合了很多我们讨论到的内容。关于后续版本，最终还是使用了一个温和和不确定的名字：“WebRTC Next Version”，或 “WebRTC-NV”。
Bernard 解释了这到底是什么意思。
Chad: 我们聊到 WebRTC 的 “Next Version”，但不是 WebRTC 2.0，是因为 WebRTC 1.0 还没完成吗？
Bernard: 我们是时候考虑不用 NV 这个词了，因为它代表两个完全不同的东西。其一，NV 是只 Peer Connection 的扩展，比如 Insertable Streams、WebRTC Extensions、WebRTC SVC 等，这些差不多就是 ORTC 定义的东西，不过已经整合到了 WebRTC-PC 中了。
其二，NV 指的是前面我提到的独立的标准，比如 WebTransport、WebCodecs、WebRTC ICE，这些完全是独立的，并不依赖 RTCPeerConnection。所以这确实是一个很大差异的版本，和之前很不一样，可以称为 “下一代” 的东西。
当然现在属于很早的阶段，WebTransport 还是 Origin Trial，WebCodecs 也是一样。以前都在 WebRTC PC 这个单体 (monolithic) 中，而现在你需要用 Web Assembly 自己实现，所以这个是非常非常不同的开发模型。
有些还没有加进去，例如 WebTransport 目前还是 client-server 模型，我们正在写一个 peer-to-peer 模型，不久就会进入到 Origin Trial 版本。所以，目前只使用 WebCodec 和 WebTransport，还无法实现 WebRTC-PC 对应的用例。
现在大家越来越关注 Machine Learning，所以需要访问 RAW Media，这是 WebRTC NV 很重要的场景，而 ORTC 没有提供这个能力。某种意义上说，WebTransport 和 WebCodecs 比 ORTC 提供了更底层的访问能力，比如 ORTC 不支持直接访问 Decoders 和 Encoders，而 WebCodecs 可以做到。我想我们已经采纳了 ORTC 的想法，并将这个想法带到了更底层的传输层。
我们将会继续讨论 ML 和 WebRTC，但先让我们继续聊聊 ORTC。
ORTC 咋样了？
Object RTC (ORTC) 是 WebRTC 的一个替代模型，它不依赖 SDP，提供更底层的组件和控制能力。Bernard 是作者之一，Microsoft 在最初的 Edge 浏览器中，支持了 ORTC，而现在却没什么声音了，那么 ORTC 发生了什么？Bernard 一个月前解释过，ORTC 很多能力，都吸收到了 WebRTC 的标准中。
Chad: 你是 ORTC 标准的作者之一，ORTC 现在是否达到了它的愿景？
Bernard: Object Model 存在于 Chromium 浏览器中，所以我们有大部分 ORTC 定义的对象，比如 Ice Transport、DTLS Transport、SCTP Transport，所有这些都在 WebRTC PC 和 Chromium 中。
ORTC 还有高级功能也被采纳了，比如 Simulcast 和 SVC，我们还实现过原始版本的 E2EE。所以目前而言，WebRTC PC 可以等价于 ORTC，加上对象模型和这些扩展。
我们也在关注一些新场景的应用，比如 IoT 的数据传输的部分，这在 WebRTC 中也有体现，比如 P2P 的数据交换。
WebTransport 新的传输
WebTransport 是由 W3C 一个专门的工作组定义的，当然和 WebRTC 有很紧密的关系。
QUIC 是一种改进的传输协议，有点像 WebTransport 可以使用的 “TCP/2”。
那么什么是 WebTransport，它是从哪里演化来的，和 WebRTC 又是什么关系？
Bernard: WebTransport 是一组 API，由 W3C WebTransport 组定义的；同时，WebTransport 也是一系列的协议，由 IETF 定义的。这些协议包括 WebTransport over QUIC，简称 QUIC Transport；也包括 WebTransport over HTTP/3，也可能 HTTP/2。因此，WebTransport 的 API 不仅仅支持 QUIC，也支持 HTTP/3，以及 HTTP/2（主要考虑 Fail-over 的回退）。
WebTransport 的 API 是一个 CS 模型的 API，构造和函数都很像 WebSocket。在 WebTransport 的构造函数中，你需要指定一个 URL。但是和 WebSocket 不同的是，WebTransport 支持可靠传输的流传输，也可以支持不可靠的数据报。
数据报，例如 UDP，应用在快速但是非可靠的传输场景中。
Bernard: 而且它是双向的，一旦客户端发起了 WebTransport，服务器也可以主动发起一路传输流。
双向的？比如像 WebSocket？
Bernard: WebScoket 只是客户端发起的，不能由服务器发起；而 WebTransport 可以由服务器发起。另外，WebTransport over QUIC 时连接是非 Pooled，而 WebTransport over HTTP/3 是 Pooled，这创造了一些新的应用场景，有些在 IETF BoFs 中由提到过。这意味着，在同一个 QUIC 连接中，你可以传输很多内容，比如 HTTP/3 请求和响应、WebTransport、Streams 和 Datagrams。
Justin Uberti 提出过一个标准 IETF RIPT BOF，就是将这些不同的东西放在了一起。在这个场景下，有来回的 RPC 请求，也包括服务器主动发起的请求。比如一个客户端，发出请求说要播放一个电影，或者进入一个游戏，或者加入视频会议，然后服务器就开始主动发起多路不同的视频流的传输了。
我认为 WebTransport 有可能会给 Web 带来革命性的变化，HTTP/3 本身就是对 Web 的一种革命。而这些关键变化，是 HTTP/3 Pooled Transport；相比之下，QUIC 就更简单了，它只是给了一个 Socket 一样的能力，你可以发送和接收数据。
WebTransport 还有多久才会上？
Bernard: 其实 WebTransport API 已经相当完善了，而且它已经完成了它的 Origin Trial 版本，在 M88 版本中。还有一些 Bug，有些部分还不能很好的工作，但是 API 基本比较稳定了；你可以写比较复杂的用例了。我们很快会提供比较完整的例子，可以让大家尝试使用。
而在服务器端，还有一些 QUIC 的互操作性问题。现在使用较多的是 Python aioquic，当然你可以用 quiche，可惜我们没有一个 Nodejs 版本。
正如 Bernard 提到的，WebTransport 是客户端服务器模型，而不是 WebRTC 这种 P2P 模型。不过，我们看到有个 P2P QUIC 的预览版了。实际上 Flippo 早在 2019 年，实现过一个 QUIC DataChannels，这个和 WebTransport 的差别是什么？
Bernard: Flippo 实现的 RTCQuicTransport，是用的 ORTC 版本，不支持 W3C Streams，用的也是 gQUIC 协议，而不是 IETF QUIC 协议。WebTransport 是基于 W3C Streams，使用的是 IETF QUIC 协议。所以，RTCQuicTransport 是过时的代码，它是老的 API 和老的协议，这部分代码已经从 Chromium 中移除了。
那么在实时场景下，我们现在如何使用 P2P WebTransport？
Bernard: 我们有个扩展标准，依然在 ORTC 工作组中。大概你可以认为是 WebTransport，不过它是用 RTCIceTransport 构造，而不是一个 URL。当然在构造函数中，需要传递一个 ICE Transport，而不是传 URL。
关于 P2P 部分，基本可以从 RTCDtlsTransport 抄过来，而且这个扩展规范本身不多，差不多 95% 的东西和 WebTransport 规范本身是一样的。
Chad: 有人这么做过吗？
Bernard: 我们目前还没有可以工作的新版本 API 和新的 QUIC 库。RTCQuicTransport 是独立的，现在 WebRTC ICE 也是独立的，不依赖 WebRTC PC；当使用 RTCIceTransport 构造 RTCQuicTransport 时，它们不会和 PC 复用。
在过去，RTCIceTransport 必须使用独立的端口，因为 gQUIC 没有复用 RTP/RTCP、STUN 和 TURN，而现在 IETF QUIC 是和这些协议复用的。
gQUIC 是 Google 的 QUIC 版本。
gQUIC 不复用端口，看起来会对端口使用，以及穿越防火墙，产生比较大的影响。
Bernard: 开发者是否想让 QUIC 和其他媒体复用同样的端口？今天在 WebRTC PC 中，Bunding 是非常非常常见的，基本上 99% 的情况下都是复用一个端口。那么 QUIC 也应该一样支持端口复用，那么我们就不应该使用之前的 API 从 URL 构造 RTCQuicTransport，而应该使用 RTCIceTransport 构造它。
这变得有点奇怪了，因为现在部分的 WebTransport 开始依赖 RTCPeerConnection。
RPC setup to send media via WebTransport. Source: IETF 107 – Justin Uberti, 107-ript-rtc-implementation-experiences
Simulcast 多播
WebTransport 看起来确实挺有潜力的。另外，几乎主流的会议服务厂家，都使用了 Simulcast，而 Simulcast 是困扰 WebRTC 的棘手问题之一，在标准和互操作性上也一直在挣扎和挤牙膏状态。
Chad: Simulcast 现在是什么情况？
Bernard: 目前已经支持了，Chromium 支持的编解码器都已经支持了 Simulcast，至少目前存在于 Chromium 中的编解码器已经支持了。所以理论上，不管是 H.264、VP8 和 VP9，都是可以用 Simulcast 的。
我们正在找 Bug，也遇到了一些比较难搞的 Bug，例如 H.264 无法正常工作。除了 KITE 全量测试之外，我们还建立了 LoopBack 测试，可以快速测试基本的能力，所以 Fippo 写了 LoopBack 测试。
如果你感兴趣，Fippo 写的关于 “Simulcast Playground” 的文章在这里。
Bernard: 而这些 LoopBack 测试，没有在所有浏览器通过。原因是因为发送端是 RID，而接收端是 MID，比如发送了三条流，那么每个流会有个不同的 MID；而 Firefox 不支持 RTP 头中的 MID 扩展，所以导致了测试失败。
我们也发现，只要我们开始测试，就能发现一些不对的地方。
再举一个诡异的例子，我们开启了硬件加速，发现它不仅仅是编码速度加快，还改变了编码的字节流，这就导致互操作性测试失败了。有可能开启 Simulcast 后，你的 SFU 就扑街了。我很想和相关朋友见面聊聊，也想做更多的 Simulcast 测试，就像 Dr. Alex 做的一样，这样可以更好知道目前的状况。
如果大家都在推动和使用 Unified Plan 标准，那么我们会越来越好。
Unified Plan 是一个新的 SDP 标准，在 SDP 中定义了如何支持 Simulcast。Unified Plan 就是我们的康庄大道啊。现在情况怎样？
Bernard: 如果大家都使用 Unified Plan，那么互操作性会工作得很好；但我们离这个目标还差得挺远。目前我们还只是支持了这个功能，而且测试覆盖率在下滑，当然也不必所有浏览器都支持所有功能了才能商用，实际上很多商业应用，并不是要求支持所有的浏览器，而是支持某几个常用的浏览器。
所以关注这个问题，比较好的办法是看下测试矩阵，看主流的厂商和浏览器的运行结果，这样能知道目前是在什么状态。
当然这不是令人振奋的消息，在绝大多数浏览器上都支持当然是更好的了，不过有时候就是这样，有些功能在不同的浏览器上支持是不太一样的。
SVC 可伸缩编码
在发送方和接收方各种限制不同的场景中，SVC（Scalable Video Coding）被认为是一种比较好的方式，比如发送方发送 “多” 流，而接收方每个条件不同，有些接收高码率有些低码率。它也带来了复杂性，Sergio & Gustavo 这篇文章讨论了这个话题。
如果 Simulcast 没有准备好，我们是否能用 SVC？
Bernard: SVC 某种程度上比 Simulcast 稍微简单点，目前 Chromium 中 SVC 是实验性的功能，叫 Temporal Scalability。另外，PlanB 也支持 Temporal Scalability。所以 SVC 目前是支持的，而且也有会议服务器支持这个特性。所以对于很多会议服务商，要想达到同样的效果，SVC 实际上是更容易实现的一种方式，比支持 RID 和 MID 容易。
MID 是 SDP 中的 Media Identifier，参考 SDP Anatomy，而 RID (Restriction Identifier) 是新增的一个标准，用来表达独立的流。这部分从略，请大家自己了解相关的文档。
很多会议服务器支持 RID 和 MID，我认为 Medooze 和 Janus 都支持。而 VP8 和 VP9 是默认都支持的，解码器必须支持它，因此不用协商。当然 SFU 也可以不丢弃 SVC 的某些层，当然如果某些场景下丢弃某些层，效果肯定会比较好。
AV1 新编解码器
Chris Wendt 在很久以前写过一篇文章，关于 H.26X 和 VPX 的编解码之争，以及是否会出现一个统一的编解码器一统天下。今天，这个统一的编解码器就叫 AV1。
WebRTC 计划什么时候支持 AV1？
Bernard: 当前还没有很多设备能支持较高分辨率的 AV1 编码，因此目前 AV1 面对的挑战，是如何在这种情况下让 AV1 用起来。
Chad: 我应该向大家解释下，AV1 是下一代、开源的、免费的编解码器。
Bernard: 支持 AV1 并不会改变 WebRTC PeerConnection，反过来也是。但是 AV1 支持了很多有用的新的 Scalability 能力，如果要用到这些新能力，就是我们之前提到的 SVC 的内容了。
另外，AV1 有一个非常高效的屏幕编码（Screen Content Coding）算法，大家可能想开启它。所以我们增加了 Content Hints 的功能，这样 AV1 的屏幕编码才能用起来。
Florent Castelli 提交过一个提案，关于混合编码的 Simulcast。这个提案允许不同层（Simulcast Layer）使用不同编码；比如你可以在低码率层用 AV1 编码，分辨率 360p 或 720p，可以用软件编码，也不用硬件加速；而高分辨率层，你可以用另外的编码器，比如 VP8 或 VP9。
这个提案，允许你部分使用 AV1，而不是全用或全不用；这样就可以在 WebRTC PC 中，很快就可以用 AV1。我想大家不是很在意用的是否是 AV1，而是很在意 AV1 提供的这些新的能力，以及更小的 API 变化。我们的目标就是尽快让它用起来。
我们离 AV1 用起来也不远了，编码器和解码器库都已经准备好了，并没有特别难的问题。Dr. Alex 正在写测试用例。RTP 封装支持 AV1 也不难，这些都很简单。
那么，最难的是什么呢？
Bernard: 难点是在 RTP 扩展头的描述，一般用在 SFU 转发中，这是会议服务器中支持 AV1 最棘手的部分。另外一个难点，是 AV1 天生就支持 E2EE（端到端加密），它是基于 Insertable Streams 实现的。
AV1 作为一个编解码器，并不像它的名字那样有很大的变化。它更多是 VP8、VP9 的继续演进版本。它有 H.264 那样的 NALU 语法，所以它有点像 VP9 和 H.264 之间的过渡。
如果从会议服务器的角度看，由于天生支持 E2EE，AV1 是非常不一样的。因此，SFU 无法解析 AV1 OBU，SFU 只能依据之前的描述来做判断。本质上说，SFU 已经进入了下一个模型，在这模型中是和编解码器不相关的，SFU 独立于编解码器。
SFrame 和 E2EE
Insertable Streams 是和 E2EE（端到端加密）直接相关，和编解码器相对独立的话题。实际上我们发表过相关的文章。Emil Ivov 在 Kranky Geek 深入探讨过 e2ee。
我想和 Bernard 探讨下 Insertable Streams API。
Slide on insertable streams from TPAC. Source: TPAC-2020-Meetings
Bernard: E2EE 不只是一个简单的使用场景，Insertable Streams 实际上是提供了你访问 Frame 的能力。你可以对 Frame 做一些修改，但是你不能修改 RTP 头或扩展或类似的东西。当然你也不能大幅改变 Frame 的尺寸，比如不能添加大量的 Metadata 到 Frame。你可以修改 Frame，然后把它打包并发送。
提供 Frame 级别的操作能力的 API，主要是 WebCodecs 和 Insertable Streams。可以认为它们是对 MediaStreamTrack 的扩展，因为它们不依赖 RTCPeerConnection。在这些 API 中，你可以获取一个原始的 Frame，或者一个编码过的 Frame，然后做一些修改后，打包并发送。
目前还有一些 Bug，VP8 和 VP9 工作良好，但是 H.264 估计还不支持。
E2EE 的关键想法，是不限制开发者使用什么 Key Management。我们正在制定 E2EE 相关的标准，就是 SFrame（Secure Frame）；目前还没有在 Key Management 上达成一致。事实证明，不同场景下需要不同的 Key Management。
SFrame 是一个新的标准提案，允许通过 SFU 转发 E2EE 的媒体；E2EE 的加密是在 Frame 上，而不是在 Packet 上。由于每个 Frame 可能会被分成多个 Packet，所以这样也很高效。
Source: IETF Secure Frame (SFrame) proposal
Bernard: SFrame 在 Frame 上加密，比在 Packet 上加密更灵活。比如如果要对 Frame 做签名，只需要签名一次；而对每个 Packet 签名是不可行的，比如对于关键帧，就需要签名很多个 Packet，而 SFrame 则只需要一次签名。
所以这也意味着减少了很多签名的开销，这样就可以做到 Origin Authentication，可以知道这个包是谁发出来的，而基于 Packet 的签名无法做到这点。
看起来每个人都同意，只需要一种 SFrame 的格式，但是对于 Key Management 会很麻烦。我们在 TPAC 上讨论过，是否能在浏览器中实现 SFrame，在 Key Management 上还未达成一致，这可能会导致出现多种 Key Management。
WebCodecs 新编解码能力
WebCodecs 给了开发者更底层的访问能力。
Bernard: WebCodecs 是开放给了开发者更底层的能力，这些能力已经在浏览器中了。WebCodecs 和 Insertable Streams 类似，都是 Frame 级别的操作。比如，你可以操作一个编码后的 Frame，或者你可以输入一个未编码的 Frame 然后拿到一个编码后的 Frame。
Chad: 所以，这是一个更底层的能力，包括编码器和解码器？
Bernard: 是的，解码器这部分，和 MSE 很类似。
Chad: MSE，Media Source Extensions?
Media Source Extensions，以及 Media Source API，主要是替代 Flash 的媒体能力，可以用标准 JS 代替 Flash。MSE 允许开发者输入一个封装好的媒体，比如 fMP4 切片，也支持 DRM，详细参考这里。
那么 WebCodecs 和 MSE 的区别是什么呢？
Bernard: WebCodecs 解码部分和 MSE 很类似，不过输入的是编码后的 Frame，而没有外层的封装。
有朋友问，“这些东西该如何配合使用？”，我举个例子，如果你要做流媒体视频或游戏业务，你可以使用 WebTransport 接收编码好的媒体数据，然后你可以使用 MSE 或者 WebCodecs 解码和渲染。MSE 的输入是封装好的数据，而 WebCodecs 是编码好的 Frame。MSE 支持 DRM，而 WebCodecs 目前还没有。
那么在编码方面，MSE 和 WebCodecs 的差别呢？
Bernard: 这个是个有趣的话题，因为在云游戏或者电影，或者其他从云端下载的流媒体场景中，你并不需要在浏览器上编码，只需要解码。因此这些场景并不需要 WebCodecs，只有在视频上传的场景中才需要编码。如果你需要上传视频，那么你可以用 WebCodecs，然后使用 WebTransport 发送，可以用可靠流也可以用 Datagrams，如果是 Datagrams 那就要自己做 FEC 了。
如果你不是很关心延迟，那么用可靠流就很好了。只有在需要编码的场景下，WebCodecs 才具备真正的优势，不需要使用奇怪的技巧。
敢问路在何方？
发送视频是 WebRTC 很重要的能力，是否这个能力可以被 WebCodec 和 WebTransport 或者 WASM 取代呢？实际上，Zoom 就是这么做的。
Zoom 的方案是更好的方案吗？是否是未来的趋势？
Chad: 这是我们需要搞清楚的方向吗？还是这些方案都会同时存在？
Bernard: 嗯这确实是一个问题。如果端到端都是你自己的应用，那么你可以随意选择。但今天，有很多人希望使用开源的 SFU 服务器，这就必须使用标准接入了，不能随意发送任何媒体格式给 SFU。如果只是简单的视频上传的场景，可能也问题不大；不过在会议场景中，涉及的网元和终端可能会很多，保持标准接入总是一个好事情。
除了 SFU，性能也是非常关键的因素。我知道有些朋友用 WebTransport 实现会议能力，但我对这个方案表示怀疑，因为目前会议的与会者越来越多了，比如 7x7，甚至 11x11。
似乎需求永远不会被满足，比如在线课堂中，老师希望看到班上的每个人，而一个班的人数可能远不止 11 人。在这种场景下，流的数目会非常的多，而且很多都是高清流，这时候性能就真的是一个很大的问题了。WASM 或者 WebTransport 这种方式，内部有很多内存拷贝，比如在 WebTransport 中有两份拷贝，传给 WASM 时又需要拷贝一次，它们可能还不在一个线程中，这对性能优化有非常大的挑战。
Chad: 我想在这种场景下如何优化资源的使用，还是可以做很多事情的。
Bernard: 嗯没错，虽然人们总是抱怨 WebRTC 是单体应用，但是另外一方面，单体应用相对很容易做性能优化。而在 WebTransport+WebCodecs+WASM 这种模型中，很难避免大量的拷贝，也很难做深度的性能优化。
ML 机器学习
ML 是现在计算机科学界很普遍的话题，几年前甚至 Kranky Geek 2018 的主题都是 RTC AI。现在也看到 JS ML 有了很大进展，比如 Don’t Touch Your Face，以及各种 WebRTC 应用中的虚拟背景。然而 WebRTC 底层却没有太多和 ML 相关的内容，我请教了 Bernard 这个问题。
Bernard: 我们在 WebRTC-NV 的用例中，讨论大家正在尝试的热度很高的事情。我们发现，除了 E2EE（端到端加密）之外，大家最热衷做的事情就是访问 RAW 媒体，这也给 ML 打开了大门。
Chad: 我也要确认下，访问 RAW 媒体，是为了获取更低延迟吗？我做了一些尝试，发现当整个调用 Stack 很深时，很难做到低延迟。
Bernard: 很多场景都涉及到了客户端处理，比如，你获取了媒体帧，你希望先对媒体帧做一些改变，然后再发送出去。在 Snapchat 中很多特效，都是这种方式实现的，比如戴上一个虚拟的帽子或其他东西。另外一个很受欢迎的功能，就是虚拟背景，或者类似的东西。
当然，很多 ML 是在 Cloud 运行的，比如语音转换或者翻译。我不知道是否客户端也能做到这点，但目前主要是发送到 Cloud 处理。可能客户端能完成的，主要是面部识别和身体姿态识别。
长期的目标，是 Native 能实现的，都可以在 Web 实现。这不仅仅是访问 RAW 媒体，而且是要实现高效的访问。比如，在 Native 方案中，我们经常发现媒体内容只停留在 GPU，而不需要额外拷贝；目前 Web 还做不到这一点，还是存在很多拷贝。
Source: Kranky Geek Virtual 2020 – Google WebRTC project update https://youtu.be/-THOaymtjp8?t=704
在 Kranky Geek 的活动中，Google 提到了如何实现 GPU 零拷贝。
Bernard: 这是 W3C 研讨会上提出来的一个话题，出现了一个概念叫做 Web 神经网络，目前已经有很多基于 WebGL 或者 WebGPU 的 TensorFlow 的库了。如果仔细考虑，你会发现这不是高效的方式。实际上你需要的是一些基本操作，比如矩阵乘法的运算，用 WebGPU 或者 WebGL 来实现矩阵乘法这些基本操作不一定合理。所以 WebNN 从更高的层面来解决这个问题，让矩阵乘法成为一种基本运算。
这里的关键，是协调这些 API 一起工作，把数据放到正确的地方，这样才能避免拷贝。比如 WebCodecs 支持了 GPU 缓冲区，但目前这个缓冲区是只读的，如果你希望对 GPU 缓冲区的内容做 ML，这就不行了因为无法修改它，你只能用拷贝实现。
2020 年 NVIDIA 的一个产品引起了我的注意，NVIDIA 使用运行在 GPU 上的 GAN，捕获关键帧的面部信息。然后它将面部信息和关键帧结合起来，重构了整个流。这样就只需要传递面部特征信息，这可以节约很多带宽，NVIDIA 声称可以做到 H.264 码率的 1/10。这个模型还可以用在超分（辨率），面部调整，或者是模拟表情等。
这似乎是 ML 在 RTC 的革命性的应用。是否有相关的标准？
Bernard: 如果你正关注下一代编解码器的相关研究，很多都是和 ML 相关的。
新冠导致了周围发生了很多变化，包括娱乐和会议的结合。很多电视节目，包括《Saturday Night Live right》，制作过程使用了会议技术。我注意到有些剧院，已经开始使用虚拟背景。而会议本身也有很多变化，比如 Microsoft Teams 推出的 Tegother 模式，将用户从视频中抠出来放到虚拟的会议室中。在体育运动中，运动员和球都是真实的，而观众席上的观众是虚拟的或远程的。
那么实际上我们涉及到了 AR 或 VR 的范畴，重新构造了环境。我看到了娱乐和 RTC 在很多场景下的融合，这反映在了 WebTransport 或者 WebCodecs 这种工具中，它既可以用在流媒体传输中，也可以用在 RTC 中。
ML 也可以是导演，它也可以是摄影师，还可以是编辑，它可以把所有这些事情串联在一起。实际上每个方面都将可以受到 ML 的影响。
我不认为这只影响到了传统流媒体，我也不认为我们要继续使用老的 RTC 的 API。在现有 RTC 系统中，要用新的 API 重写部分服务，估计没人有动力肝这事，但是，我还是认为 WebRTC 新的 API，将开启一个流媒体和 RTC 融合的新时代，这里面有很多新东西可能我们今天都无法想象到，很多都和 AR/VR 相关。
未来已来
Chad: 最后想和大家说点啥？
Bernard: 我们聊到的很多新技术，都已经有了 Origin Trial，大家可以获取到。把它们串起来使用，非常具有启发性；当然也会发现很多不足。我并不是说它们一致性很好，实际上不是，但是能给你一个印象，那就是未来你大概能做什么。这些技术会很快面世，这会大大超过大家的预期。甚至使用这些技术的商业应用，在 2021 年就可能上线了。所以走过路过千万不要错过，这不是未来，是很快到来的现在，好好把握机会。「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。