WebRTC 基准测试：为什么一次看起来“干净”的通话恢复测试可能是错的
内容提要
WebRTC基准测试须先验证限速是否真实生效：Chrome内置限速未附着于通话连接，导致Meet视频绕过限制；Zoom Web视频经数据通道传输，标准统计中无帧率数据。测试显示Meet媒体未中断，但码率稳定常超20秒，或30秒内未恢复；Zoom因限速前码率已低于500kbps，多数接收端未真正受扰。建议将“稳定恢复”纳入验收标准，区分通话运行、遥测完整与质量恢复，缺失数据不得记为零。
延伸解读
限速未生效：基准测试的首要陷阱
文章指出，Chrome 内置限速若未附着于通话连接，Google Meet 视频可绕过限制，实测接收码率达 2.2 Mbps，远超设定的 500 kbps。这意味着测试环境看似正常，结果却完全失真。技术团队在跑基准前，必须用独立速度测试验证限速确实作用于媒体流，并记录施加与恢复时间戳，否则后续所有恢复数据都不可信。
缺失数据不等于零：统计口径决定结论
Zoom Web 通过数据通道传输视频，标准 getStats 中无帧率、分辨率或冻结计数，若将缺失字段记为零参与平均，会严重扭曲对比。文章强调应把“通话是否运行”“遥测是否完整”“质量恢复多好”分开报告，被剔除的运行需注明原因。读者在评估供应商或 SDK 时，应先确认统计字段是否可比，再谈性能优劣。
“媒体未中断”可能掩盖长时间低码率
测试中所有路径媒体均未中断，但 Google Meet 全部 22 个接收端的稳定码率要么超过 20 秒才恢复，要么在 30 秒窗口内未恢复。若验收标准只检查媒体是否恢复传输，就会放过视频长时间低于正常码率的产品。文章建议将“稳定恢复”写入验收标准，即码率连续三秒回到中断前中位数的 80% 以上，而非仅看连接是否存活。
同样的限速对不同平台并非同等中断
Zoom Web 在限速前码率已多在 500 kbps 以下，限速期间仍保持正常中位数的 90% 以上，20 个接收端中 15 个在网络恢复前就已在区间内。这并不说明 Zoom 恢复更快，而是限速几乎未对其造成有效中断。做竞品对比时，需先确认中断是否真正把各平台压到其正常速率以下，否则测得的“恢复时间”更多反映测试窗口设置，而非平台能力。
Q&A
为什么在WebRTC基准测试中，Chrome内置限速可能没有真正限制住Google Meet的通话视频？
Chrome内置限速（如DevTools功能）只限制普通网页流量，但Google Meet的通话连接在页面加载时就建立，若在测试步骤之间清除再重设限速，后续通话就逃出了限制。因此速度测试显示约490 kbps，但Meet接收视频在“500 kbps”设置下仍达2.2 Mbps。
为什么Zoom Web的视频质量数据在标准WebRTC统计中缺失？
Zoom Web通过WebRTC数据通道传输视频，而非标准视频流，因此标准统计（getStats）中没有帧率、分辨率或冻结计数可读。基于这些统计生成的报告对Zoom而言没有画质数据。
在WebRTC恢复测试中，“稳定恢复”是如何定义的？
稳定恢复定义为从网络恢复时刻（T0）起，到入向视频码率连续三个采样点达到中断前中位数的至少80%的时刻（T3）为止，稳定恢复时间即T3减T0。80%的区间和连续三个采样的规则是基准标准，并非WebRTC标准。
Google Meet和Zoom Web在网络中断后的恢复表现有何关键差异？
所有路径上媒体均未中断，但Google Meet在全部22个接收端中，稳定码率要么用了超过20秒，要么在30秒窗口内未恢复；Zoom Web因限速前码率已大多低于500 kbps，20个接收端中有15个在网络恢复前就已在区间内，限速几乎未造成中断，可测的恢复很少。
进行WebRTC基准测试时，如何确保限速条件真实生效？
需在每台设备上从页面加载到通话结束全程保持限速附着，每台设备上下行独立限速，并在每次通话前用独立速度测试证明确实生效，同时精确记录施加与恢复的时间戳。每次运行还应将真实媒体速率与限速阈值比对。
为什么说“媒体恢复传输”不等于“质量恢复”？
媒体恢复传输只表示视频字节数和解码帧数重新增长，但码率可能仍远低于正常水平。例如Google Meet媒体从未中断，但稳定码率要么超过20秒才恢复，要么30秒内未恢复。若验收只检查媒体是否恢复传输，就会放过长时间低码率的产品。
在WebRTC基准测试报告中，如何处理缺失的统计数据？
缺失不等于零。不支持的字段、被重置的计数器或提前终止的采集都应如实标注，绝不以0参与平均。同时应把通话是否运行、遥测是否完整、质量恢复得多好三类结果分开，被剔除的运行需连同原因一并列出。
