视频已经变模糊了，为什么还是会卡？-优快云博客

视频刚开始很清楚，过一会儿人物的脸模糊了。再等几秒，画面清晰回来，却又突然转圈。

用户看到的是画质来回变，播放器面对的则是两个不断变化的量：接下来能多快下载，以及手里还存着多少秒能播放的内容。选择清晰度时，只看前一个，很容易高估自己撑得住多久。

本文讨论点播视频。视频通话对实时性的要求不同，不能直接套用这里的缓冲思路。

用一个简化例子说明。某段视频长 4 秒，平均码率约 2 Mbps，对应视频数据约 8 Mb。若可用下载吞吐只有 1 Mbps，光传这段视频就要约 8 秒，还没有计入音频、协议开销和额外等待。

正常播放这 8 秒的过程中，播放器只补进来 4 秒内容，缓冲库存就在减少。假如原本还有 12 秒缓冲，暂时不会卡；继续这样下载，迟早会耗尽。

在这里插入图片描述
图 1｜简化示意：播放消耗 8 秒，下载只补入 4 秒，缓冲净减少 4 秒。实际分段大小与下载时间会变化。

这也是为什么“我刚测速挺快”不能说明当前片段一定来得及下载。测速发生的时刻、连接、目标服务，可能都不一样。即使同一条连接，刚下载完的小片段也未必能代表下一段。

缓存命中还会让一次读取显得特别快。如果把本地读数据的速度当成网络带宽，随后的升档就容易过于乐观。

自适应播放需要有可选档位。服务端只给了一个固定码率文件，客户端不能凭一个“自动”按钮变出低码率版本。以 Media3 为例，轨道选择参数可以限制分辨率、码率并影响轨道选择，最终仍受媒体提供的轨道和设备支持情况约束。

有了多档资源，也不是选低一档就立刻不转圈。已经请求的大片段可能还没完成，新档位往往要在后续片段上体现。若此时缓冲只剩一点，来不及下载的部分仍会造成停顿。

升档也不宜过急。一次下载变快就提高码率，下一段变慢又降回来，清晰度会频繁跳动。通常需要结合持续一段时间的吞吐估计、缓冲余量和切换成本，给升降档设置不同的条件。具体阈值应由自己的片源、播放器和目标设备验证，不能照抄一个百分比就认为解决了问题。

对用户来说，稳定的中等画质常常比几秒高清、几秒转圈更能接受。但如果用户明确锁定了高清，也要说清楚播放器是否允许自动降级，避免界面写着一个档位，实际却按另一套规则运行。

测试前先确认同一个视频有哪些可播放档位，并固定开始位置、播放速度和缓存状态。每次都换视频，片段大小与编码复杂度跟着变，结果很难比较。

我们开发的「弱网管家」支持分别设置上下行带宽。做点播测试时，可以主要调整下行，先找出哪些档位在这档网络条件下能持续播放。下面是带宽配置入口；这里填写的是模拟参数，实际吞吐仍要从播放器下载记录中观察。

在这里插入图片描述
图 2｜实机带宽设置页。按片源码率安排多档条件，不能把某一个限速值当作所有视频的通用标准。

接着可以设计“稳定低速”“高速后降速”“降速后恢复”几轮。手动切换模板时，记下实际切换时间；同一次测试里先不要再混入随机丢包，否则很难解释是哪类变化触发了切档。

设置中的悬浮窗便于留在待测播放器里切换条件，网络抓包和 HTML／CSV 报告则用于辅助保留过程。报告的查看与分享权限以当前版本和账号权益为准。

在这里插入图片描述

图 3｜设置页入口。网络记录不能代替播放器的码率、缓冲时长与卡顿事件日志。

软件限速也不会自动制造 CPU 解码瓶颈。如果缓冲充足、下载按时完成，画面却掉帧，应继续查解码和渲染，别把所有不流畅都算成弱网卡顿。

一次十秒的停顿与五次两秒的停顿，对观看的打断方式不同。建议保留每次停顿的开始和结束时刻，另外记录首帧等待、缓冲时长、实际轨道变化，以及各片段的下载耗时。

上表是建议用例，本文没有运行对应播放器实验，也没有把工具参数当成性能成绩。

分析一轮结果时，试着把片段下载、轨道切换和缓冲曲线画在同一条时间线上。通常就能看清：是升档太早、降档太晚，还是这段视频根本没有合适的低码率版本。找到这个原因以后，再调播放器参数，才能知道改动到底改善了什么。