WebRTC API 2024 年第二季度更新情况

本文快速更新了 2024 年第二季度修改后的 WebRTC API。如果您是开发人员，请看看这些变更，了解它们可能对您的应用程序产生哪些影响。

这里讨论的一些 API 并非由 WebRTC 工作组定义，而是 WebRTC 生态系统的一部分。

此处的信息是从 Chrome 浏览器、Safari 和 Firefox 浏览器的可用发布说明中收集的。

WebRTC 旧版 API

以下是浏览器为完成 WebRTC API 的实施所做的更改。

RTCIceTransport（Firefox）

从 Firefox 125 开始，现在支持RTCIceTransport.state和RTCIceTransport.gatheringState 属性及其相关事件statechange和gatheringstatechange，以及RTCDtlsTransport.iceTransport。

RTCIceCandidate (Firefox)

从 Firefox 126 开始，除了未实现的 relayProtocol 和 url 属性外，现在支持所有 RTCIceCandidate 属性和方法，并与规范相匹配。

支持的新属性包括：foundation、component、priority、address、protocol、port、type、tcpType、relatedAddress和relatedPort。usernameFragment

Firefox 填补了旧版 API 实现中的空白。

RTCIceCandidate (Chrome)

从 Chrome 124 开始，RTCIceCandidate.relayProtocol和RTCIceCandidate.url属性现在受支持。

您不再需要从priority属性中推导中继协议。现在可以通过 relayProtocol 属性直接获得。

RTCRemoteOutboundRtpStreamStats (Chrome)

从 Chrome 125 开始（我没有找到 Chrome 125 的 WebRTC 发行说明），getStats API 现在返回remote-outbound-rtp 缺失的视频报告。

注意：remote-outbound-rtp的报告已可用音频流。这次我们为视频提供了相同的报告。此新报告可与 inbound-rtp 视频报告关联，以获得相关入站流的所有统计信息（主要是 RTT）。

RTCPeerConnectionStats、RTCMediaSourceStats（Firefox）

由于我从 Firefox 107 开始就没有检查过，以下报告显示 RTCPeerConnectionStats 和 RTCMediaSourceStats 现在在 Firefox 中可用。我在 Firefox 124 中看到过。

这也许不是什么新东西，但我在发行说明中没有找到任何相关信息。

注意：roundTripTime、roundTripTimeMeasurements和totalRoundTripTime在报告中仍然缺失RTCRemoteOutboundRtpStreamStats。

WebRTC 扩展 API

在这里，我们可以找到为扩展 WebRTC 现有 API 界面而定义的其他 API。

MediaStreamTrackAudioStats (Chrome)

从 Chrome 125（？）开始，音轨现在公开了一个stats用于访问界面的属性MediaStreamTrackAudioStats。

该接口来自规范文档WebRTC Media Capture and Streams Extensions。

可使用以下计数器: deliveredFrames, totalFrames, deliveredFramesDuration, totalFramesDuration, latency, 以及其他一些平均和最小/最大延迟。

我在P2P通话中使用了deliveredFrames这个接口，奇怪的是，在麦克风静音的情况下，我无法成功屏蔽计数器。

我尝试按下麦克风的物理静音按钮或使用内置的Audio Midi 设置应用程序。即使音轨被标记为静音，计数器仍然会增加，尽管规范规定“如果没有声音流动，例如如果音轨被静音或禁用，计数器不会增加”。

就像框架仍在泛滥……也许我错过了什么，或者实现尚未完成。

对于远程轨道，我不确定如何解释latency……

ImageCapture (Safari)

该接口来自规范文档MediaStream Image Capture。

Safari 预览版 194 中提供了 ImageCapture 接口。除了 grabFrame() 方法必须返回 ImageBitmap 对象外，其他所有 API 均可用。您只能使用 takePhoto() 获取 Blob 对象。

注意：在 Firefox 中，ImageCapture 仍然是一个标志。需要在 about:config 中设置 dom.imagecapture.enabled 标志。

非捆绑 WebRTC API

这里的情况更为复杂。通过这些 API，您可以建立自己的机制来处理媒体流和必要的传输层。

WebTransport（Safari）

WebTransport 界面出现在最新的 Safari 194 预览版中。我以前在 17.4 版中没有看到过。WebTransportBidirectionalStream 和 WebTransportDatagramDuplexStream 均可用。

WebCodecs（Safari）

在最新的 Safari Preview 194 中实现了许多新接口：现在可使用 EncodedAudioChunk、AudioData、AudioDecoder 和 AudioEncoder 接口。

其他有趣的 API

这些 API 与 WebRTC 没有直接关系，但在 WebRTC 应用程序中可能很有用。

Pressure API

从 Chrome 125 开始，您现在可以使用新的 Pressure API 来获取系统的 CPU 压力。这有助于使您的应用程序适应当前的系统负载，避免出现性能和/或电池问题。

如今，通过使用 getStats API，我们可以知道我发送给他人的媒体是否受到了限制。通过 qualityLimitationReason 属性，可以检索到系统当前的最大 “限制因素”。这个指标是按发送的音轨计算的。根据这一指标，我们可以推断出系统是否存在影响体验的 CPU、带宽或其他问题。

在此，我们建议重点关注 CPU，并获得 4 级压力：

正常：压力、温度和/或能量处于可接受水平。对电池和系统性能没有影响。
一般：系统正在执行任务，导致压力、温度和/或能耗略有升高。可以听到风扇的声音，电池受到影响。
严重：系统超载，压力、温度和/或能耗持续偏高。保持这样的水平会大大降低笔记本电脑、平板电脑或移动设备的电池寿命。
很严重：主要影响系统温度升高。冷却效率可能会降低，系统可能会减速以避免过热。系统性能会受到严重影响。

正如您所理解的，与 CLI 加载命令不同，Pressure API 不会返回过去 N 秒内系统的平均负载。该 API 给出的是压力水平。这更像是一个 “健康 “指标，您的应用程序可以跟踪并利用它来调整自己的行为。

下面是一个如何使用Pressure API 的示例：

const pressureObserver = new PressureObserver((change) => {
    //do something when the pressure changes
});

// Observe the CPU pressure every 3 seconds
pressureObserver.observe('cpu', {sampleInterval: 3000});

// Stop observing the CPU pressure
pressureObserver.unobserve('cpu');

就是这样。每次压力水平发生变化时，回调函数都会调用新的压力水平。

{
  "source":"cpu",
  "state": "nominal",
  "time": 1716218985845.574
}

目前，cpu 是唯一可用的源。将来可能会添加其他来源。

与 qualityLimitationReason 指标不同，Pressure API 公开了系统的全局指标。应用程序可自行决定是否调整其行为。

可用性：目前仅适用于 Chrome 浏览器。

WebSocketStream API

WebSocket API 是客户端与服务器之间进行通信的强大工具。但它并不总是那么容易使用，尤其是当你需要发送大量数据时。

从 Chrome 浏览器 124 开始，您现在可以使用新的 WebSocketStream API 以更高效的方式发送和接收数据。

WebSocket API 有两个主要问题：

发送消息时：您需要依靠缓冲数量属性来确定是否可以发送更多数据

接收信息时： onmessage 事件处理程序可能会被大量信息淹没，而无法为应用程序提供异步控制。您的应用程序可能无法响应，或者浏览器内存不足而停滞。

由于使用了 ReadableStream 和 WritableStream，WebSocketStream API 可以管理背压。

const streamSocket = new WebSocketStream('wss://example.com');

const {readable, writable} = await streamSocket.opened;
const reader = readable.getReader();
const writer = writable.getWriter();

while (true) {
  const {value, done} = await reader.read();
  if (done) {
    break;
  }
  const result = await process(value);
  await writer.write(result);
}

在这个例子中，应用程序先读取一些数据，然后对其进行处理，最后才读取下一个数据块。因此，您的流水线处于受控状态。

注：WebTransport 还能管理背压，在支持 QUIC 的网络上可替代 WebSocketStream。

可用性：目前仅限 Chrome。