WebRTC 无疑推动和改变了互联网视频,而这仅仅是刚刚开始,除了大家熟悉的 WebRTC-PC、Simulcast 和 SVC,有太多的新技术和新架构出现在 WebRTC 新的标准中,比如 WebTransport、WebCodecs、AV1、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 StreamsScreen CaptureMedia Capture from DOM ElementsMediaStream Image CaptureMediaStream RecordingAudio 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 IdentityWebRTC Priority ControlWebRTC DSCP
  3. 第三类是对 Capture 的扩展,比如 MediaStreamTrack Insertable StreamsMedia 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 比如 WebTransportWebCodecs,所以当提到 “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、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 年就可能上线了。所以走过路过千万不要错过,这不是未来,是很快到来的现在,好好把握机会。

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