WebRTC getStats 的重大变化

使用getStatsAPI 并不像看起来那么简单。不是因为要编写代码，而是因为您需要花时间了解显示的统计信息，正确解释它们并跟踪 Chrome 和其他浏览器版本的变化。

而在这里，Web开发者的底层复杂性主要来自以下几个方面：

• Chrome 引入了许多从未以这种方式标准化的统计数据。您可以阅读 BlogGeekMe 写的这篇优秀文章，以更好地理解这是从哪里来的我可以相信 WebRTC getStats 的准确性吗？
• 由于引入了 WebRTC 堆栈的更改，需要改进统计信息。
• 有关此主题的有限文档。除非在解决堆栈供应商的 W3C 规范中，否则不会向开发人员描述或解释统计信息。
• （为了好玩）Web 开发人员和他们的用户不可能坚持使用浏览器的版本（如果我们排除 ESR 版本）。

所有这些加在一起使统计数据的使用变得复杂。

本文重点介绍需要尽快处理的最近（重大）更改以及将在下一版本的浏览器中进行的一些更改。

检测 WebRTC JS API 中的重大变化？

对于使用根据此方案版本化的库的开发人员来说，事情很清楚：每次第一个数字发生变化时，至少有一个重大变化。这意味着升级到这个版本很费力，但如果所有者完成了他的工作，就会有一本手册来成功克服任何易碎的变化。

在这里，知道有一个更复杂的重大变化：

• 首先你要知道去哪里找资料：Discuss-WebRTC貌似是官宣的地方。为什么所有重大更改都没有出现在Chrome 路线图中？为什么完整的变更日志不是Chrome 发布博客或Chromium 博客的一部分？
• 然后一旦在正确的位置，您需要知道如何检测组中发布的所有消息的重大更改。可以通过选择以PSA开头的消息来完成第一个过滤器。PSA 代表公共服务公告。它用于在特定点上引起开发人员的注意，并且大多数时候（100% 的时间？），这些消息来自 Google 团队。不幸的是，不一定要宣布重大变化……
• 最后，根据 PSA 帖子，您可以自行了解它是否涉及libWebRTC API 或 JavaScript Web API。

因此，毫无疑问，对于 Web 开发人员来说，缺乏真正的变更日志和解释来克服这些最近的变更。

我一直不明白为什么浏览器供应商不提供 JavaScript API 文档，他们更喜欢依赖 MSN 和 W3C，而不是提供反映其实现水平、行为和选择的文档……

由此，您可以理解为什么有些人迟迟未能应用最近的重大更改。您还记得有关迁移到统一计划的所有谈判吗？

也就是说，这是我从最近所做的更改中了解到的。

注意：对于每个新的 Chrome 版本，都有一个相关的WebRTC 发行说明，可以在 WebRTC 组中找到。但大部分要点都针对libWebRTC。乍一看并不清楚哪些要点针对 Web 开发人员……

getStats 中的最新重大更改

这是最近重大更改的列表。

统计标识符的重大更改

此更改已于 2006 年 9 月在帖子 Discuss-WebRTC 中宣布，并在 Chrome M107 中引入。

在此更改之前，报告的统计标识符包含一个字符串，用于区分报告的类型。例如：RTCOutboundRTPAudioStream_3138056031。在此示例中，我们可以清楚地识别统计信息与出站音频报告相关联。

但是，决定让 ID 更简洁，例如使用随机标识符。

问题是没有人向开发人员解释即使这是一种识别报告类型的便捷方式，也不应该用于此原因。开发人员从没想过他们珍爱的标识符有一天会改变……

因此，所有将标识符用作“类型”或对标识符进行某些解析的应用程序都必须克服重大更改。

注意：以同样的方式，在标识符前加上“DEPRECATED”也是一个破坏性的变化……

处理此更改的 Chrome 107 于 10 月 25 日发布；公告后 50 天。

如果您的应用程序依赖统计信息 ID 而您没有进行更改，则访问统计信息时应该会出现问题。

编解码器报告的重大变化

在同一时期，Chrome 发布了一个关于编解码器报告的更改，可以看作是次要的，但在某些配置的版本 107 之前，一个简单的调用可以生成数百个编解码器报告（如本期getStats所述）

因此提供了修复。最近，添加了一项新更改，将编解码器报告限制为通话中使用的编解码器报告（在 Chrome Canary M113 中观察到）。

如果出于任何原因，开发人员正在使用这些编解码器报告进行一些实时或事后分析，例如尝试列出不同的分析，即使这不是正确的方法，这也可能导致他的代码。

如果您的应用程序依赖于这些报告中的编解码器列表，您现在应该看到一个非常短的列表，并且肯定不是完整的受支持编解码器列表。

Stream 和 Track 报告的重大变化

弃用的跟踪报告已于 2022 年 7 月在Discuss-WebRTC帖子中发布，9 月，流报告Discuss-WebRTC也发布了相同的公告。

最初计划在 Chrome M109 中引入此更改，但由于它导致 Twilio SDK 中断（请参阅此处的错误），因此进行了回滚。

新计划是在 Chrome M112 中进行此更改，对于那些之前无法进行更改的用户，可以注册一个Origin 试用版，这将允许访问这些报告，包括 Chrome M115（9 月 24 日）。

总结一下：

• 类型的报告track将stream被删除
• 属性trackId将从类型inbound-rtp和的所有报告中删除outbound-rtp。

这是 M112 中应该可用的报告的新地图：

原始数据RTCMediaStreamStats 和RTCMediaStreamTrackStats报告将加入一长串过时的统计数据，这些数据越来越像一座巨大的墓地。

如果您的应用程序依赖于track和stream报告，则迫切需要在 M112 之前更新您的代码。将您现有的代码映射到可从其他报告访问的统计数据应该并不复杂。

getStats 中的其他更新

而且这个清理还没有完成。以下是一些即将推出的浏览器更新。

Chrome：基于遗留的 getStats 的突破性新变化

在 Chrome 中，有两个版本的 getStats()，一个符合规范并返回一个承诺，另一个是非标准的并且使用回调作为第一个参数。

弃用和删除涉及 getStats() 的非标准版本。该声明于 2023 年 2 月在这篇文章中发布Intent to Deprecate and Remove: Legacy callback-based RTCPeerConnection.getStats() API

经过多次讨论，最后的倒计时应该像下面这样（来自帖子）：

• 在 M113（发布日期：2023 年 5 月 2 日）中添加弃用警告，并可选择加入弃用试用。
• M114中Canary/Dev/Beta中不使用trial则抛出异常
• 如果在 M119（发布日期：2023 年 10 月 31 日）中未在稳定版中使用试用版，则抛出异常。
• 让 M121 成为试用版可用的最后一个版本（发布日期：2024 年 1 月 9 日）。换句话说，第一个完全删除试用版和旧版 getStats API 的版本是 M122（发布日期：2024 年 2 月 6 日）。

Chrome：新媒体播放报告

最近，Chrome M111 中出现了新的Media-Playout报告。

此报告提供有关音频播放路径的统计信息。

以下是可以从此报告中计算出的一些有趣的新指标：

• 合成播出的delta duration：如果短时间内大幅增加，应该会影响感知质量
• 平均播放延迟：对于前一个，检测到此延迟中的峰值可能是短暂音频降级的迹象
• 合成播放的百分比：它可以很好地指示播放路径是否能够产生音频。

类型的报告inbound-rtp包含一个新playoutId属性来链接此报告。

这些新的统计数据以及一些提醒应用程序的新事件应该很快就会在WebRTCMetrics中登陆。

Firefox：没有真正的进展……

我希望列出有关 Firefox 的一些改进，但我检查了从 Firefox 110 和夜间版本 112 获得的最新统计数据，没有看到任何重大进展。

Firefox 仍然缺乏统计数据和报告（比 Chrome 少大约 33% 的统计数据）。

例如，仍然没有类型为media-sourceand的报告transport。因此，我仍然必须使用报告selected中的属性candidate-pair来识别所使用的对。此属性不符合规范。

但另一方面，remote-outbound视频报告已实施。虽然我从来没有设法通过 Chrome 获得它（仅针对音频部分）。

Safari：等待下一个 libWebRTC 同步

我不知道我是否“错”了，但由于 Safari (Webkit) 与 libWebRTC 版本 M106 同步，下一次统计改进方面的重大更新应该在下次同步时完成。

我将最新的 Safari 技术预览版 (165) 与当前版本 (16.3) 进行了比较，正如预期的那样，我没有看到任何进展。

结论

APIgetStats隐藏了一个无法在博客文章或 MSN Web 文档中概括的复杂主题。

改进围绕此 API 的通信和文档应该有助于浏览器供应商向前发展并防止开发人员总是发现自己处于边缘。

作者：Olivier Anguenot

原文链接：https://www.webrtc-developers.com/breaking-changes-in-getstats/