测速很快，为什么视频通话还是卡？-优快云博客

开会前测了一下网速，下载几十兆每秒，看起来绰绰有余。真正连上视频，却开始反复问：“能听见吗？”

对方说话断断续续，你回答一句，要隔一会儿才有反应。两个人同时开口，又同时停下，最后只好关掉摄像头。

测速结果没有骗人，它只是没回答视频通话最在意的问题：这段声音能不能及时、稳定地送到对方耳朵里。

下载文件时，一块数据晚到了，等它补回来就行。整个文件最终完整，任务就能完成。

通话里的声音有播放时机。你说“现在可以开始”，对方几秒后才听到，会议节奏就乱了。再把之前迟到的声音逐句补播，对话也没法正常进行。

所以实时业务既需要足够带宽，也需要较低的延迟。IETF 对实时媒体拥塞控制的要求就明确考虑了这种差异：交互式音视频与大文件传输的需求不同，需要尽量降低传输延迟。RFC 8836

测速通常更擅长告诉你一段时间内能传多少数据。它无法单凭一个下载数字，替你确认通话时的上行、抖动和远端链路是否正常。

视频通话至少涉及两个人。你说话用自己的上行，对方接收用他的下行；反过来又是一条方向相反的路径。

你本地摄像头预览流畅，不说明视频已经顺利送达。那只是手机在播放自己拍到的画面。上行拥堵时，你看自己很清楚，对方却可能只看到一张定格图片。

下载速度快，也不代表上传同样快。云相册备份、文件上传或其他设备抢占上行，都可能影响你把声音和画面送出去。

测试时因此需要看两端。只在一台手机上记录“通话连接正常”，很容易漏掉对方已经听不清的事实。区分上行和下行后，再讨论哪一边卡，排查才有方向。

声音数据不会每次都准时到达。这一批快一点，下一批慢一点，接收端如果来了就播，声音很容易断续。

常见的处理是先攒一小段，再按节奏播放。你可以把它理解成提前备一点货：后面偶尔晚到，手里还有一点内容能接上。

代价是等待。攒得越多，抗波动的余地通常越大，但声音到耳朵里也越晚。双方抢话，有时就与这种延迟有关：你以为对方说完了，实际上还有一段话正在路上或缓冲区里。

播放器需要在连续性和延迟之间调整，不能靠无限增加缓冲解决问题。语音会议、互动直播与看录播视频，对这个取舍的接受程度也不一样。

如果只观察“有没有静音”，可能会把一个缓冲很大、但对话迟钝的方案评成最好。测试还得让双方真正说几轮话，看看交流是否自然。

前面文章聊过丢包的顺序。对音视频来说，这个顺序尤其明显。

零星缺失时，接收端可能通过补偿、冗余数据或及时重传减轻影响。具体采用什么方法，取决于协议和媒体实现，并不是所有丢失都能补回来。

连续缺失一段就难得多。接收端手里没有足够信息，可能只能静音、保持上一帧，或等待后续可用内容。视频帧之间还可能存在依赖，因此数据缺失的影响不一定只持续一个瞬间。

于是，同样的平均丢包比例，分散在一分钟里和集中发生在两秒内，听感可能完全不同。记录一个百分比，解释不了用户说的“刚才整句话没听见”。

做测试时，随机丢包和短时连续丢包都值得覆盖。前者观察长期稳定性，后者更适合看静音、冻结和恢复过程。

可用带宽下降后，还强行发送原来的高清视频，数据可能越排越多，延迟也跟着升高。

应用通常会尝试降低码率，或者调整分辨率、帧率，把发送量降下来。语音优先的产品还可能先保住声音，让画面暂时让步。

这时画质下降未必是缺陷。会议里一张稍糊但能跟上说话的脸，常常比高清定格画面更有用。

不过降级也要看场景。屏幕共享需要读小字，降得太糊就无法工作；远程操作演示可能更在意动作连续。团队应该先明确用户此刻需要什么，再决定牺牲哪些东西。

恢复阶段也别漏掉。网络已经稳定，画质是否还长期停在低档？声音恢复后，视频能否跟上？提高质量是否太急，刚恢复就再次卡顿？这些问题需要把测试继续跑下去才能看到。

可以让两台设备建立通话，先记录正常网络下的表现，再一轮只改一种条件。

先测这些单独条件，定位清楚后，再组合成“进入电梯后恢复”一类的场景。

通话内容也要有一点安排。双方轮流读一段固定短句、交替提问，比一直对着镜头说“喂喂喂”更容易发现缺字和延迟。涉及他人声音或画面的录制，应先取得同意，也可以使用专门准备的测试素材。

记录至少包含两端发生了什么、异常开始和结束时间、恢复后是否需要手动操作。如果要测精确的单向时延，还需要校准时间基准或专门的音视频测量方法，不能直接用两台设备未经同步的时间戳相减。