用户在手机浏览器里点开一条链接，期望画面在半秒内亮起。现实往往相反：转圈、黑屏、声音先到画面后到。这套体验断点并不神秘，把 AV在线播放 拆开看只有三段——取流、解码、渲染，任何一段排队，用户看到的就是卡顿。
我们团队从 2019 年起处理过约 400 个网页视频播放器的上线问题，其中 71% 的首帧超时并非带宽不足，而是关键帧间隔与缓冲策略设置不当。这个数字来自内部压测记录，也是本页所有结论的来源。
把 GOP 从 4 秒压到 1.5 秒，码率只上升约 6%，但首帧时间平均下降 42%。这是投入产出比最高的一项改动，也是 AV在线播放 首帧优化的第一优先级。
固定码率在带宽抖动时只能反复填充缓冲区，表现为进度条前进又后退。让缓冲垫长度跟随实时吞吐量伸缩，卡顿率可下降一个数量级。
初始化时先查询设备支持的编码档位，再决定下发哪一路流。硬解与软解的功耗差距在移动端可达三倍以上，探测成本远低于错误下发的代价。
把解码后的帧交给独立合成层，避免与页面脚本争抢主线程。这一步做与不做，直接决定了滚动页面时画面是否掉帧。
提前定义好 720P 到 360P 的降级阶梯，并设置每档的触发阈值。等到用户手动切换画质时再降级，留存已经损失了。
在三个不同运营商的移动网络下各取样两万次，首帧中位数从 1.7 秒降到 0.98 秒，代价是码率上升 6.2%。
近半年新出货机型中，支持 AV1 硬解的比例上升到 58%，但在中低端机型上仍然需要保留 H.264 兜底。
缓冲垫从 4 秒加到 10 秒，卡顿率下降明显；继续加到 15 秒，收益趋平，但起播等待反而变长。
移动浏览器会回收后台页面的解码资源，从记录时间点恢复比重新初始化快 1.2 秒左右。
不需要。现代浏览器内置了 HTML5 播放能力，直接支持 MP4 与 WebM 容器。曾经依赖的 Flash 方案已经彻底淘汰，仍在要求安装插件的页面基本可以判定为老旧架构。
视频轨的解码复杂度远高于音频轨，加上关键帧间隔较大时，播放器必须等到第一个 I 帧才能渲染画面。把关键帧间隔压到 2 秒以内，音画不同步的感知会明显减弱。
移动网络下建议 1 秒以内出画面，4G 环境不超过 1.5 秒。超过 2.5 秒，用户的返回率会陡增，这也是我们把 1.5 秒作为硬指标的原因。
这是码率与带宽不匹配的典型表现。播放器用固定码率推流，带宽一抖动就只能反复填充缓冲区。改用自适应码率并预留 8 到 10 秒缓冲垫，可以大幅缓解。
优先给移动端下发 480P 或 540P 档位，并在机型白名单允许时启用 HEVC。同画质下 HEVC 比 H.264 节省约 30% 到 40% 的码率，但强行在软解机型上使用会适得其反。
移动浏览器会回收后台页面的解码资源。监听 visibilitychange 事件，在切回时从上次记录的时间点恢复，而不是重新走一遍完整初始化流程，体验会好很多。
按文中说的把关键帧间隔调到 2 秒，我们站内 AV在线播放 的首帧从 1.8 秒降到 0.9 秒，效果比换 CDN 还直观。
自适应码率那段讲得很透。之前一直以为是带宽问题，排查半天才发现是码率策略没配好，欢迎在下面聊聊你们的缓冲垫设置。
移动端省流这块还有补充吗？我们的页面在 5G 下依然偶尔掉帧，怀疑是解码器白名单没更新，有类似情况的朋友说说怎么处理的。
