RTCRtpStreamStats - 提供有关 WebRTC 连接的详细统计信息
RTCRtpStreamStats 字典由 RTCPeerConnection.getStats()、RTCRtpSender.getStats() 和 RTCRtpReceiver.getStats() 方法返回，提供有关 WebRTC 连接的详细统计信息。
字典有一套基本的属性，这些属性在每一种情况下都存在。根据方法被调用的接口，还会添加额外的属性。
RTCRtpStreamStats 是所有 RTP 相关统计报告的基类。 它基于 RTCStats 并添加了以下附加字段。
注意： 在 2017 年春季规范更新之前，此接口被称为
RTCRTPStreamStats。检查桌面浏览器兼容性表以了解名称是否更改以及何时在特定浏览器中实现 .
属性
RTCRtpStreamStats 字典基于 RTCStats，并继承其属性。 此外，以下部分或全部属性可用。
包含所有媒体类型的标准字段
codecId
一个 DOMString，它是被检查以生成与此 RTP 流关联的 RTCCodecStats 对象的对象的唯一标识。
kind
如果关联的 MediaStreamTrack 是纯音频，则 DOMString 的值为 "audio"，如果轨道包含视频，则值为 "video"。此值将与 RTCCodecStats.codec 指示的媒体类型以及轨道的 kind 属性相匹配。 以前称为 mediaType。
ssrc
标识此 RTCRtpStreamStats 对象涵盖的 RTP 数据包源的 32 位整数。此值是根据 RFC 3550 规范生成的。
trackId
一个 DOMString，它是 RTCMediaStreamTrackStats 对象的唯一标识，表示关联的 MediaStreamTrack。它与 MediaStreamTrack.id 的值不相同。
transportId
一个 DOMString 表示被检查以生成与此 RTP 流关联的 RTCTransportStats 对象的唯一标识。
过时的字段
mediaType
在 2018 年 2 月的规范中重命名为 kind。参见 桌面浏览器兼容性 in [Page not yet written] 来确定浏览器何时做了转换。
仅限本地的测量数据
这些属性是在本地计算的，并且仅对接收媒体流的设备可用。 它们的主要目的是检查连接的错误恢复能力，因为它们提供有关丢失数据包、丢失帧以及数据压缩程度的信息。
firCount
发送方接收的完整内部请求（FIR）数据包的总数的计数。 此统计信息仅适用于接收流的设备，并且仅适用于视频轨道。FIR 数据包通过流的接收端发送，当它落后或丢失数据包并且无法继续解码流；
流的接收端在落后或丢包无法继续解码流时发送 FIR 包；流的发送端接收 FIR 数据包并通过发送完整帧而不是增量帧来响应，从而让接收器 “赶上”。 这个数字越高，这种性质的问题出现的频率就越高，这可能是网络拥塞或接收设备负载过重的迹象。
nackCount
接收方通知发送方通过发送负确认（NACK，也称为 “通用 NACK”）数据包来丢失一个或多个 RTP 报文的次数。该值仅适用于接收器。
pliCount
流的接收方向发送方发送图片丢失指示 (PLI Picture Loss Indication) 数据包的次数，表明它已经丢失了一帧或多帧的一定数量的编码视频数据。 只有接收方有这个值，并且只对视频轨道有效。
qpSum
与此 RTCRtpStreamStats 对象描述的视频轨道上的每帧相关联的量化参数（QP Quantization Parameter）值的总和。一般来说，这个数字越高，视频轨道越大。与 RTCReceivedRtpStreamStats.framesDecoded 或 RTCSentRtpStreamStats.framesEncoded 结合起来，你可以大致估算出这些帧的平均 QP。记住，即使在帧内，编解码器的量化值也经常变化。还要记住，QP 的值可能因编解码器而异，所以这个值只有在与同一编解码器比较时才有可能有用。
sliCount
接收方通知发送方一个或多个连续的（按扫描顺序）编码的视频宏块已经丢失或损坏的次数；该通知是由接收方用一个片断丢失指示（SLI Slice Loss Indication）数据包发送给发送方的。这是编解码器如何工作的一个相当技术性的部分。该值越高，则流中发生的错误越多。一般来说，大多数时候这个值只有非常感兴趣的硬核媒体开发人员才感兴趣。
规范
| 规范 |
|---|
| Identifiers for WebRTC's Statistics API #streamstats-dict* |
桌面浏览器兼容性
暂无兼容数据