WebRTC 的现状和将来：专访 W3C WebRTC Chair Bernard Aboba

WebRTC 无疑推进和改变了互联网视频，而这仅仅是刚刚开始，除了你们熟悉的 WebRTC-PC、Simulcast 和 SVC，有太多的新技术和新架构出如今 WebRTC 新的标准中，好比 WebTransport、WebCodecs、AV一、E2EE、SFrame、ML 等等，这篇文章详细介绍了将来的 WebRTC-NV，不容错过。

说明：
本文为阿里云视频云翻译的技术文章
原文标题：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 工做组的主要工做包括如下三个方面：

1. 目前最重要的工做，是完成 WebRTC Peer Connection (WebRTC-PC) 标准化，以及相关的标准好比 WebRTC-Stats。
2. Capture，Streams 和 Output 相关的标准，包括 Media Capture and Streams，Screen Capture，Media Capture from DOM Elements，MediaStream Image Capture，MediaStream Recording，Audio Output Devices，以及 Content-Hints。
3. 下一代 WebRTC，也就是 WebRTC-NV。

WebRTC-NV 是下一代 WebRTC，在当前 WebRTC 1.0 以后的标准。

Bernard: WebRTC-NV 的工做主要是四个方面。

1. 第一类是对 WebRTC PeerConnection 的扩展。这包括 WebRTC Extensions, WebRTC-SVC, 以及 Insertable Streams。我特别强调这些工做都依赖于 “Unified Plan”，如今已是默认的 SDP 规范了。例如，若是要使用 Insertable Streams 来支持 E2EE (End-to-End Encryption，端到端加密)，那么首先要支持 “Unified Plan”。
2. 第二类，和 WebRTC-PC 相比，还不够成熟和完善，好比 WebRTC Identity，WebRTC Priority Control 和 WebRTC DSCP。
3. 第三类是对 Capture 的扩展，好比 MediaStreamTrack Insertable Streams，Media Capture and Streams Extensions，和 MediaCapture Depth Stream Extensions。
4. 第四类是独立的标准，它们没有必要依赖 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 年秋季在两个以上浏览器实现。因此目前测试和代码实现都比咱们预期的慢。

来源：TPAC-2020-Meetings

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.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.26四、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 做为一个编解码器，并不像它的名字那样有很大的变化。它更可能是 VP八、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 年就可能上线了。因此走过路过千万不要错过，这不是将来，是很快到来的如今，好好把握机会。

「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。