1.前言
在基于webrtc的视频直播过程中，常常会遇到各种质量问题，例如卡顿、延迟过高、画面模糊等。这些问题不仅影响用户体验，还可能对业务造成负面影响。作为一名音视频前端开发者，我们需要有效地判断视频直播的质量，并及时排查和解决问题。
Chrome浏览器提供了一个强大的内置工具——chrome://webrtc-internals/，它可以帮助我们深入了解WebRTC连接的详细信息，监控实时的音视频传输数据。
本文将深入探讨基于视频直播下的chrome://webrtc-internals/工具并期望达成以下目的：1、通过讲解，让本人和读者对视频直播的建立、数据传输和解码等知识有一定基础认知。2、提供评估浏览器端视频直播质量的指标详解，帮助排查问题。
先点赞后收藏哈哈哈😄
2.了解 chrome://webrtc-internals/
2.1 什么是 chrome://webrtc-internals/
chrome://webrtc-internals/ 是Chrome浏览器提供的一个专用于调试和分析WebRTC连接的内部页面。它能够实时显示当前浏览器中所有WebRTC连接的详细信息，包括信令状态、媒体流、网络统计数据、事件日志等。
主要功能：
- 实时监控WebRTC连接： 查看所有活动的
RTCPeerConnection实例，了解其状态和参数。 - 查看详细的统计数据： 获取网络传输的关键指标，如比特率、帧率、丢包率、抖动等。
- 事件日志： 记录信令过程中的重要事件，帮助分析连接建立过程中的问题。
- SDP信息： 查看本地和远端的SDP（会话描述协议），了解媒体协商的细节。
2.2 如何访问和使用 chrome://webrtc-internals/
2.1.1 访问
遵循以下步骤
- 打开基于Chromium内核的浏览器，例如Google Chrome或Microsoft Edge。
- 在浏览器地址栏中输入
chrome://webrtc-internals/，然后按下回车键。 - 打开页面：你将看到一个显示当前所有WebRTC连接的页面，如果没有活动的WebRTC连接，页面将为空。
2.1.2 使用方法
-
启动WebRTC应用：在新的标签页或窗口中，运行WebRTC应用程序，开始音视频通信或直播
-
查看连接列表：返回到
webrtc-internals页面，您将看到一个或多个RTCPeerConnection实例，以标签的形式显示。 -
选择连接：点击对应的连接标签，展开查看详细信息。标签通常以页面URL和
RTCPeerConnection的标识符（如[id: 1, ...]）命名。
2.1.3 统计数据概览
- 概览信息：在展开的连接详情中，您可以看到信令状态（如
stable、have-local-offer）、ICE连接状态、媒体类型等。
- 统计图表：向下滚动，找到
Stats Tables和Stats Graphs部分。这里提供了丰富的统计数据，如比特率、帧率、抖动等，并以图表的形式实时更新。
3. 关键指标详解
3.1 网络相关指标
3.1.1 jitter相关指标
讲以上指标时，我们需要引入两个核心概念：jitter 和 jitterbuffer
抖动（Jitter）是指网络传输中，数据包到达接收端的时间间隔出现不一致的现象，即延迟的变化。由于网络拥塞、路由变化等原因，数据包可能以不均匀的间隔到达，这会导致视频播放出现卡顿、画面跳跃或音视频不同步。
抖动缓冲区（Jitter Buffer）是用于缓解抖动影响的机制。其目的是将 RTP 数据包重新组合成帧并具有平滑的播放效果。假定帧数据是仍然压缩且尚未解码的，它在接收端临时存储接收到的数据包，并按照稳定的速率向解码器提供数据。这种缓冲可以平滑数据包到达时间的波动，确保视频和音频的连续、流畅播放。
在视频直播中，引入抖动和抖动缓冲区的指标是为了监控和优化流媒体的传输质量。通过衡量抖动程度，系统可以动态调整抖动缓冲区的大小，平衡延迟和流畅度，提升用户的观看体验。这些指标有助于识别网络问题，实施适当的缓冲策略，确保即使在网络状况不佳的情况下，视频直播仍能保持稳定和高质量的播放。
1. jitter
- 定义：
数据包传输过程中延迟的波动程度，通常是数据包到达的时间间隔与预期间隔之间的差异。在网络传输中，数据包的到达时间不一致（时快时慢），这就是抖动（jitter）。单位是秒
- 影响
jitter的因素：
1、带宽不足或网络拥塞：会增加数据包的排队延迟，导致数据包到达接收端的时间不一致，进而增加抖动。
2、路由路径波动：数据包在传输过程中可能经过不同的路由路径，路径的变化可能导致不同的数据包有不同的传输延迟。
3、抖动缓冲区（Jitter Buffer）设置：抖动缓冲区用于平滑数据包到达时间的波动，确保连续的数据流传输给解码器。缓冲区设置不当（过大或过小）会影响对抖动的补偿效果，导致抖动增大或引入额外延迟。
4、效率低下的编解码器或媒体处理负载过高可能导致数据包处理延迟不一致，增加抖动。
jitter对视频的影响：
较大的抖动会导致解码器无法准确预测数据包的到达时间，从而影响 Jitter Buffer（抖动缓冲区）的工作，它可能会导致画面卡顿或音频不同步，尤其是在实时通信或视频直播的场景中。
2. JitterBufferDelay
- 定义：
指抖动缓冲区内存储并等待发送到接收端的音视频数据的时间，它表示缓冲区为抵消网络抖动所产生的延迟之和（以秒为单位）。
对于视频直播来说，每帧可以通过几个RTP分组接收，因此摄取时间戳（ingest timestam）是是该视频帧的最早的RTP包（属于该帧的第一个RTP包）进入抖动缓冲区的时间，而发射时间戳（emit timestamp）是当整个帧退出抖动缓冲器时的时间：每一帧的 jitterBufferDelay = emit timestamp−ingest timestamp，JitterBufferDelay在视频帧退出缓冲区时增加，
JitterBufferDelay对直播影响：
表示当前抖动缓冲区内的总延迟，JitterBufferDelay 过大可能导致视频播放的延迟增加，尤其是在低延迟要求的应用场景中。
3. JitterBufferDelay/jitterBufferEmittedCount_in_ms
-
定义：该指标是指
JitterBufferDelay除以已经从缓冲区中发出的数据包数量，表示每帧的延迟（单位为ms）。它反映了缓冲区消耗掉的延迟相对于每一帧已发出数据的平均延迟。较高的数值表示每帧视频数据所需的延迟较长。 -
JitterBufferDelay/jitterBufferEmittedCount_in_ms对直播影响：
当该值较高时，可能会影响视频的实时性，尤其是实时互动视频应用的质量。
4. JitterBufferMinimumDelay/jitterBufferEmittedCount_in_ms
JitterBufferMinimumDelay 是指抖动缓冲区允许的最小延迟，它表示在补偿网络抖动时，缓冲区维持的最低延迟水平；抖动缓冲区为了确保数据流畅播放，保持的最低延迟。即使网络状态非常好，WebRTC 系统也会维持至少这个最小延迟，以避免数据突发性变化。
JitterBufferEmittedCount 是指从抖动缓冲区成功发出的音视频数据包的总数量。它用于衡量缓冲区已成功处理并传输的帧数。 如果发出数据包的数量较低，说明数据包可能被丢弃或未及时传输，影响播放质量。
所以我们很容易得出这个指标的定义
- 定义：
该指标为抖动缓冲区最小延迟除以已发出数据包的数量，表示每帧的最小延迟。它表示在最理想的情况下，WebRTC 系统所能实现的每一帧的最小延迟。
JitterBufferMinimumDelay/jitterBufferEmittedCount_in_ms对直播的影响：
较高的最小延迟每帧值会导致实时性下降，影响用户体验。在低延迟场景中，最小延迟值应该尽可能保持低，以提高响应速度。
3.1.2 packets相关指标
1. packetsReceived/s
packetsReceived 表示自会话开始以来，接收端成功接收到的 RTP 数据包的总数量。
- 定义
packetsReceived/s 表示接收端每秒钟成功接收到的 RTP 数据包的数量，即数据包接收速率。该值取决于视频的编码参数（如帧率、分辨率、编码方式）和网络状况，对于一个 30 fps 的视频，如果每帧视频需要 10 个 RTP 数据包，则理论上每秒应接收到约 300 个数据包。
packetsReceived/s对直播的影响：
无法根据packetsReceived/s单个指标判断其对直播的影响，还需要结合packetsLoss、bytesReceived_in_bits/s等指标综合判断。一般来说，packetsReceived/s 的稳定性反映了网络传输的稳定性。若该值波动较大，可能表明网络状况不稳定。高的数据包接收速率需要更高的网络带宽支持。观察 packetsReceived/s 的实时曲线，可以发现网络拥塞、突发丢包等问题。
2. totalAssemblyTime/framesAssembledFromMultiplePackets_in_ms
在 WebRTC 中，视频数据通过 RTP 数据包传输，而一个完整的视频帧（例如 I 帧、P 帧）通常会被拆分成多个 RTP 数据包来传输，接收端需要将这些数据包重新组装起来，才能生成可供解码的完整视频帧。一个完整的视频帧通常由多个 RTP 数据包组成。
totalAssemblyTime指的是将多个RTP包组装成完整帧的累计时间，如果网络传输过程中丢失了某些数据包，可能导致帧无法完整组装，从而不计入此指标。
framesAssembledFromMultiplePackets 是指接收端从多个 RTP 数据包中成功组装出的完整视频帧的数量。较高的 framesAssembledFromMultiplePackets 表示接收端成功从多个 RTP 数据包中重建了许多完整的视频帧，网络传输和接收端处理相对可靠。如果此值低，可能表明接收端丢失了大量 RTP 数据包，或组装效率低，导致帧无法正常重建。
- 定义：
totalAssemblyTime/framesAssembledFromMultiplePackets_in_ms 表示接收端从多个 RTP 数据包中组装一个完整帧所需的平均时间（以毫秒为单位）。
这个指标表示接收端平均组装一个完整视频帧所花的时间。它反映了接收端的处理效率。在稳定的网络环境和高效的接收端性能下，totalAssemblyTime/framesAssembledFromMultiplePackets_in_ms 的值通常在几毫秒到几十毫秒之间，如果值过高，可能表明接收端在组装 RTP 数据包时出现性能瓶颈。
- 影响
totalAssemblyTime/framesAssembledFromMultiplePackets_in_ms的因素：
1、RTP 数据包到达顺序：如果数据包到达的顺序混乱，接收端可能需要更多时间重新排序和组装。
2、网络抖动和丢包：抖动和丢包会延迟数据包的到达，导致帧组装时间增加。
3、接收端处理性能：接收端的硬件性能和 WebRTC 的实现效率会直接影响组装时间。
4、视频复杂度：高分辨率或高码率视频帧的数据量较大，需要更多的数据包，组装时间可能更长。
3. retransmittedPacketsReceived
在实时音视频传输中，由于网络抖动、丢包、延迟等问题，接收端可能会发现部分数据包缺失。此时，接收端会向发送端发起重传请求（例如发送NACK）。发送端在收到请求后，会重新发送缺失的数据包。
- 定义:
retransmittedPacketsReceived 是一个用于统计接收端在WebRTC会话中成功接收的、经过重传机制（如NACK重传）再次发送的数据包数量的指标。其会在接收端成功拿到这些重传过来的数据包后累加计数。因此，此指标表示的是在网络非理想条件下，通过重传补救机制所成功恢复的数据量。
1、retransmittedPacketsReceived 的存在本身是一个补救措施的体现——如果没有重传机制，丢失的数据包将导致画面卡顿、音频中断、画质劣化等问题。重传成功的数据包有助于还原完整的媒体帧，从而提高用户的观看与聆听体验。
2、然而，重传并不是无代价的。重传需要额外的时间和带宽。在高延迟或高抖动的网络中，虽然重传可以减少数据丢失带来的直接损害，但可能增加整体延迟，使实时性下降。这对互动场景（如视频会议、在线游戏）尤为不利。此外，频繁的重传请求和处理会占用额外的网络带宽和处理资源。接收端需要持续监测数据包的丢失情况并发起NACK请求，发送端需要查找并重新发送丢失数据包。这些操作在低带宽或高负载的环境下可能使系统性能进一步恶化。
- 影响
retransmittedPacketsReceived的因素：
1、网络稳定性与丢包率：如果网络环境不稳定，丢包率上升，则接收端将更频繁地请求重传，从而提高 retransmittedPacketsReceived 的值。
2、带宽与传输策略：在带宽受限的网络中，发送端发送的码率可能过高，导致拥塞和丢包。当接收端请求重传时，同样会占用带宽，加剧拥塞的恶性循环。选择合适的传输码率和自适应码率控制策略可以减少重传需求。
3、编码参数与数据包分片策略：不同的编码参数（如帧大小、关键帧间隔）以及RTP数据包分片策略会影响丢包对画质的影响程度。当帧被分片为多个RTP数据包后，丢失其中某个分片就可能导致整帧无法完整解码，需要通过重传来弥补。因此，编码与分片策略的优化能减轻重传需求。
4、错误恢复与纠错机制：除了重传（NACK）机制，系统还可采用前向纠错（FEC）等技术。FEC在一定程度上可以减少对重传的依赖。如果FEC策略有效，当丢包发生时，不需要频繁重传也能恢复数据包，从而降低 retransmittedPacketsReceived 的增长速度
ps：retransmittedBytesReceived和retransmittedPacketsReceived类似，只是计量单位不同
3.1.3 码率相关指标
1. bytesReceived_in_bits/s
- 定义:
bytesReceived_in_bits/s通常用于表示接收端每秒接收到的媒体数据的比特率（bit rate），换言之，是单位时间内实际接收到的音视频负载（payload）流量，单位为比特每秒（bits/s）。bytesReceived_in_bits/s 较高，表示在当前网络下能够传输更多的数据，通常对应更高的分辨率或更高的码率；值较低则意味着实际使用的带宽较小，可能由于网络受限或编码码率降低。在自适应码率（ABR）场景下，如果网络带宽充裕，bytesReceived_in_bits/s 会增加，画质相应提高；反之，码率下降导致画质降低。如果观察到此指标出现大幅波动或显著下降，可能预示网络波动或拥塞，导致视频直播卡顿或画质劣化。
- 影响
bytesReceived_in_bits/s的因素：
1、网络带宽和稳定性：足够的带宽和低丢包率、低延迟有助于维持更高的传输速率；网络条件差时此指标会显著降低。
2、视频/音频编码的目标码率、分辨率、帧率等直接影响媒体数据大小，从而影响实时比特率。
3、自适应码率（ABR）算法：采用自适应码率技术，发送端会根据网络状况动态调整码率，导致bytesReceived_in_bits/s出现波动。
4、视频内容复杂度：场景变化、运动量大时，需要更高码率支撑相同画质；静态场景或背景时码率可相对降低
2. headerBytesReceived_in_bits/s
- 定义
headerBytesReceived_in_bits/s表示每秒接收到的协议头部数据速率（以比特每秒为单位），可以观察到网络传输中头部开销所占的带宽。若 headerBytesReceived_in_bits/s 长期占用较高带宽，意味着较高的协议开销，可能会降低实际媒体负载所能使用的带宽比例。在低带宽环境下，如果头部开销过高，就会相对减少给媒体负载的传输空间，影响视频/音频质量。
- 影响
headerBytesReceived_in_bits/s的因素：
1、数据包大小和分片策略：每个 RTP 包都附带了头部，更多的分片意味着头部总量上升，因此头部比特率也随之上升。
2、如果会话启用了 SRTP（安全RTP）、TURN 中继、ICE 打洞等额外协议层，头部长度会增加，提高头部比特率。
3、网络状况和码率变化：当视频码率波动时，RTP数据包数量可能随之变化，从而影响头部的总量和实时速率。
4、视频内容复杂度：在场景切换、帧率波动、关键帧增多时，RTP包发送频率变化也会影响头部比特率。
3.2 视频帧相关指标
3.2.1 接收/解码帧率相关指标
视频帧从成功组装到显示给用户，大致经历了以下步骤：
- 组装阶段：从分散的RTP数据包中重建完整的压缩视频帧。
- 解码阶段：对压缩的帧进行解码，获取可视像素数据。
- 渲染准备：可选的帧处理、同步控制和图层合成准备。
- 合成与显示：将视频帧与其他内容混合，并在屏幕刷新时输出显示。
framesReceived/s 表示了 组装阶段 的速度， framesDecoded/s 表示了 解码阶段 的速度
1. framesReceived/s
- 定义:
framesReceived/s ：表示接收端在单位时间内从网络成功接收到（并完整组装）的视频帧数量。这些帧是通过网络传输来的RTP数据包重组而成的完整帧。在统计此值时，要求该视频帧已成功从多个数据包中重新组装出来，可以进入后续的解码流程。
- 影响
framesReceived/s的因素：
1、 网络条件：低带宽、高延迟、高丢包率、高抖动（jitter）、网络拥塞均会对 framesReceived/s产生不利影响，比如使其值下降或波动
2、RTP 流的处理： RTP 包重组错误、 RTP 包的序列号和时间戳管理错误、FEC（前向纠错）和重传机制都会影响该指标
3、发送端因素：发送端设置的帧率过高可能超出网络或接收端的处理能力，或：发送端的带宽限制或动态调整策略会影响发送的视频数据量，都可能导致帧的丢失或接收速率下降。
4、 浏览器：不同版本或不同实现的浏览器对 WebRTC 的优化程度不同，可能影响帧的接收和组装效率。（这个笔者曾经踩过大坑，chrome误我！）
5、拥塞控制和流量控制机制：有效的拥塞控制策略可以优化数据传输，减少丢包，提高帧接收率。
6、WebRTC 库和组件性能：WebRTC 的底层库和组件在处理数据包、重组帧等方面的性能直接影响 framesReceived/s。
2. framesDecoded/s
- 定义:
framesDecoded/s： 表示接收端在单位时间内成功解码的视频帧数量。这些帧已通过解码器的处理，转化为可供渲染显示的图像帧。
- 影响
framesDecoded/s的因素：
1、视频源质量：高分辨率、高帧率的视频源会增加解码器的负担，可能影响解码帧率。
2、编解码器性能：不同的编解码器（如VP8、H.264、H.265）在解码效率和性能上有所差异，影响解码帧数。
3、设备性能：接收端设备的处理能力（CPU、GPU）直接影响解码速度和帧数。
4、软件优化：浏览器和WebRTC实现的优化程度也会影响解码效率。
- 在何种情况下这两个值可能出现不一致？
framesReceived/s>framesDecoded/s
1、解码器负载过重或性能不足：当接收端的解码器负载过高、CPU或GPU资源紧张时，可能无法及时解码所有接收到的帧。
2、帧丢弃策略（Frame Dropping） ：在实时传输场景中，为了维持低延迟，系统可能选择丢弃部分过期的帧（例如已经过时无意义的老帧）。
3、网络延迟、抖动和丢包引起的帧延时解码: 如果网络状况不佳，尽管已成功组装帧，但这些帧可能有依赖的参考帧丢失、或到达顺序不当，解码器可能需要等待相关数据，导致解码帧率低于接收帧率。
4、部分帧无法解码（数据损坏或不兼容）： 即便成功组装了帧，如果该帧数据异常（例如由于严重丢包导致数据损坏），解码器可能无法成功解码。
3.2.2 丢弃帧相关指标
1. framesDropped
- 定义:
framesDropped 指的是由于各种原因（如解码器性能不足、网络丢包、缓冲区溢出等）未能成功解码和渲染的音视频帧数量。这是在视频播放过程中被丢弃的帧数，意味着这些帧未能显示出来，可能导致视频画面不连贯。
- 影响该指标的因素：
1、解码器负载：当解码器处理不过来时，会丢弃一些帧以保持实时性。
2、网络丢包率：高丢包率导致部分帧数据缺失，无法解码，从而增加丢帧数。
3、缓冲区设置：缓冲区容量不足或配置不当，可能导致数据积压，进而丢弃帧。
4、设备性能：低性能设备无法高效处理高帧率视频，导致丢帧。
5、编解码器效率：某些编解码器在处理复杂视频内容时效率较低，增加丢帧风险。
3.2.3 关键帧相关指标
1. keyFramesDecoded/s
在视频编码中，关键帧（Keyframe），也称为 I帧（Intra-coded Frame） ，是指那些独立编码的视频帧，不依赖于前后帧的信息来进行解码。与之相对的是 预测帧（P帧）和 双向预测帧（B帧），它们需要参考前后的帧来进行解码。关键帧的存在对于视频的随机访问、错误恢复以及整体画质的稳定性至关重要。
- 定义：
keyFramesDecoded/s 表示接收端在单位时间内成功解码的关键帧（I帧）的数量。关键帧是视频流中无需参考其他帧即可独立解码的帧，通常用于初始化视频流或在网络条件恶劣时恢复视频质量。较高的 keyFramesDecoded/s 意味着视频流中关键帧的传输和解码效率较高，有助于保持视频画面的稳定性和清晰度，但是需要的码率会比较大。
- 影响该指标的因素：
1、关键帧间隔（Keyframe Interval）：编码器设置中，关键帧的出现频率（例如每隔多少帧插入一个关键帧）直接影响 keyFramesDecoded/s。较短的关键帧间隔会增加关键帧的数量，从而提高该指标。
2、网络状况： 稳定且高带宽的网络环境能够确保关键帧的高成功率传输。网络抖动、丢包或延迟高时，关键帧可能会丢失或延迟到达，导致 keyFramesDecoded/s 降低。
3、不同的编解码器（如 H.264、VP8、VP9、H.265）在关键帧的编码方式和压缩效率上有所不同，进而影响 keyFramesDecoded/s。某些编解码器在高压缩率下可能对关键帧的恢复能力更强。
4、视频内容复杂度：高运动量或复杂场景的视频内容需要更多的关键帧来维持画面质量，影响关键帧的生成频率和解码需求。
3.2.4 帧组装相关效率指标
1. totalDecodeTime/framesDecoded_in_ms
- 定义：
totalDecodeTime/framesDecoded_in_ms 即将“总解码时间”除以“成功解码帧数”后，得到的单帧平均解码时间。该指标反映了平均每帧的解码耗时，用于衡量解码器的效率。数值较低表示解码器性能出色，能够快速处理每个视频帧，减少播放延迟；数值较高。则说明解码过程较慢，可能导致播放时出现卡顿、延迟增加或帧率下降，影响用户观看体验。
- 影响该指标的因素：
1、高分辨率、高帧率的视频会对解码器带来更高的负载，增加单帧解码时间。
2、不同的编解码器（如 H.264、VP8、VP9、H.265）拥有不同的解码复杂度。压缩效率高但算法复杂的编码方式，可能需要更长的解码时间。
3、硬件加速（GPU 或专用解码单元）通常比纯软件解码更快，能降低平均解码时间；软件解码依赖 CPU，如果 CPU 性能不足，单帧解码时间会升高。
4、视频内容本身的复杂度（高动态场景、快速运动、噪点等）也会增加解码器运算量。
2. totalProcessingDelay/framesDecoded_in_ms
- 定义：
totalProcessingDelay/framesDecoded_in_ms 即单帧平均处理延迟（以毫秒为单位）。相较于纯解码时间，它可能还包括某些其他处理步骤（如排队、同步、缓冲等），不只局限于解码本身。数值较低意味着从帧到达到完成解码的整体流程延迟小，播放的实时性和流畅度更好；数值较高说明接收端在帧处理管线中（排队、解码、缓冲等）耗费时间较多，导致更大延迟，视频可能出现卡顿或延迟。
- 影响该指标的因素：
1、与解码时间相似，高性能硬件、硬件加速支持会显著降低处理延迟。
2、如果系统中存在排队、串行处理或音视频同步策略，可能需要在接收某帧后等待特定条件才进行解码，从而增加处理延迟。
3、网络抖动和丢包影响，若帧到达时存在缺包，需要等待重传或进行错误恢复机制，也会增加整体的处理延迟。
4、帧丢弃策略：某些场景下，为保证实时性，会丢弃滞后的帧而不进行处理。处理流程本身的“排队”时间可变。若丢弃策略不完善，也可能反映在处理延迟上。
5、浏览器或系统负载：当浏览器或系统正在执行其他高负荷任务（如多标签页视频播放、大量脚本运算等），可用资源不足，增加了处理过程中的等待时间。
3. interFrameDelayStDev_in_ms
- 定义：
interFrameDelayStDev_in_ms表示所有视频帧之间帧间延迟的标准偏差，单位为毫秒（ms）。标准偏差衡量的是帧间延迟的波动程度。低标准偏差：表示帧间延迟较为一致，视频播放流畅，用户体验良好。高标准偏差：表示帧间延迟波动较大，可能导致视频播放出现卡顿、跳帧或音视频不同步，影响用户体验。
- 影响该指标的因素：
1、高抖动导致数据包到达时间不一致或增加帧间延迟的不确定性，提升标准偏差。
2、数据包丢失和重传：数据包丢失导致帧无法及时组装，重传请求可能引入额外延迟，增加帧间延迟的不规则性，提升标准偏差。
3、抖动缓冲区设置：缓冲区用于平滑数据包到达时间的波动，缓冲区策略不当可能导致延迟波动，增加标准偏差。
4、视频内容复杂度变化：高运动量或复杂场景增加解码和渲染的处理负担，可能导致帧处理时间波动，提升标准偏差。
3.2.5 视频帧的宽高
1. frameWidth 和 frameHeight
- 定义：
frameWidth 表示视频帧的水平像素数，即每帧图像在水平方向上的分辨率；例如，frameWidth 为 1920 表示视频帧的宽度为 1920 像素。frameHeight 表示视频帧的垂直像素数，即每帧图像在垂直方向上的分辨率，frameHeight 为 1080 表示视频帧的高度为 1080 像素。 越高分辨率视频提供更细腻的图像（不绝对，图像质量也和码率有关）
- 影响该指标的因素：
1、自适应码率（Adaptive Bitrate, ABR）：根据网络条件动态调整视频分辨率，以平衡视频质量和带宽消耗。当网络状况良好时，提升 frameWidth 和 frameHeight；当网络受限时，降低分辨率以减少带宽需求。
2、用户设置与应用需求：用户或应用可以通过设置选择不同的分辨率，以适应不同的观看需求和网络条件。
3.3 异常指标
3.3.1 视频帧的冻结
讲以上指标时，我们需要引入一个核心概念：freeze(冻结)。如果帧持续时间（两个连续渲染帧之间的时间间隔）等于或超过 Max（3*avg_frame_duration_ms，avg_frame_duration_ms+150），则冻结，其中avg_frame-duration_ms是最后30个渲染帧持续时间的线性平均值。
1. freezeCount
- 定义
freezeCount 表示视频播放过程中画面冻结的次数。冻结通常指视频画面停滞不动，无法继续更新。高的冻结次数会导致视频播放中断，用户体验极差。
2. totalFreezesDuration
- 定义
totalFreezesDuration 表示视频流在播放过程中累计的画面冻结总时长，通常以秒为单位。
- 影响
totalFreezesDuration的因素：
1、网络好坏
2、缓冲区不足无法有效应对网络波动，导致更长时间的冻结。
3、解码和渲染性能好坏。
