一、概述
视频卡顿的核心原因是解码帧率低于发送帧率，主要由两类因素导致：
1. 传输不稳定：网络波动、丢包导致接收帧率低，解码端无连续数据可解；
2. 解码速度慢：设备硬件性能不足或解码逻辑低效，无法及时处理接收数据。
本文档聚焦传输不稳定场景的优化策略，通过「预缓存防抖+动态帧控」平衡抗抖能力与画面延迟，解决接收帧率波动导致的卡顿。
针对传输不稳定，优化核心是在接收端预先缓存一定时长的视频数据，通过缓存“缓冲”传输波动，避免因短暂断流导致卡顿。缓存时间与抗抖能力、画面延迟存在强关联：
| 缓存时间特性 | 抗抖能力 | 画面延迟 | 适用场景 |
|---|---|---|---|
| 缓存时间长（如2s） | 强（可抵御较长时间传输波动） | 高（用户观看到的是2s前的画面） | 网络波动频繁场景（如弱网、远距离传输） |
| 缓存时间短（如1s） | 弱（仅能抵御短暂传输波动） | 低（接近实时画面） | 对延迟敏感场景（如实时监控、互动场景） |
平衡抗抖能力与延迟，建议缓存时间取值为1-2s，可根据实际场景（网络质量、延迟敏感度）动态调整。
二、发送帧率（SendFps）计算
发送帧率是缓存帧数计算、帧控时长设定的基础，需通过接收帧的时间戳实时计算，确保适配设备码率自适应场景。
APP端从接收帧的 FRAMEINFO_t 结构体中提取 timestamp（单位：毫秒），通过相邻两帧的时间戳差计算单帧发送间隔：
// 单帧发送间隔计算公式 SendIntervalMs = CurrentTimeStampMs - PrevTimeStampMs;
单次采样易受帧丢失、传输延迟突变影响，需通过多次采样（建议10次）取平均值，同时剔除偏离正常范围的异常值（如帧丢失导致的间隔突变），确保计算准确性。
// 示例：10次采样数据（单位：ms） SendIntervalMs 采样数组 = [40, 40, 80, 40, 40, 40, 40, 41, 40, 39] // 步骤1：剔除异常值（80为帧丢失导致的异常值，予以剔除） 有效采样数组 = [40, 40, 40, 40, 40, 40, 41, 40, 39] // 步骤2：计算平均发送间隔 AvgSendIntervalMs = (40+40+40+40+40+40+41+40+39) / 9 = 40ms
通过平均发送间隔计算发送帧率（单位：帧/秒，fps）：
// 发送帧率计算公式 SendFps = 1000 / AvgSendIntervalMs // 示例计算（AvgSendIntervalMs=40ms） SendFps = 1000 / 40 = 25fps
• 需在整个解码过程中实时计算SendFps，避免设备码率自适应导致发送帧率变化，未更新SendFps引发卡顿；
• 异常值判断标准：建议剔除与中位数偏差超过50%的数值（如中位数40ms，偏差超过20ms的数值视为异常）；
• 采样次数可灵活调整（5-15次），采样次数越多，结果越稳定，但实时性略有下降。
三、缓存策略
缓存策略核心是确定「缓存帧数」和「缓存时机」，确保在抗抖与延迟之间达到平衡。
缓存帧数 = 发送帧率（SendFps）× 缓存时间（TS，单位：s），即：
// 缓存帧数计算公式 CacheFrameCount = SendFps × TS // 示例计算（SendFps=25fps，TS=2s） CacheFrameCount = 25 × 2 = 50帧（需缓存50帧后再开始解码）
缓存时机直接影响用户体验，需根据场景选择，三种常见时机对比：
| 缓存时机 | 用户体验 | 适用场景 | 注意事项 |
|---|---|---|---|
| 出图前缓存（先缓存再解码） | 出图延迟高（需等待缓存满），但出图后流畅 | 对初始出图延迟不敏感的场景（如回放、非实时监控） | 需告知用户“正在缓冲”，避免用户误以为设备故障 |
| 出图后缓存（先解码1-2帧，再后台缓存） | 出图快，用户感知好，但可能出现短暂卡顿后恢复 | 对初始出图延迟敏感的场景（如实时监控、快速预览） | 需处理缓存不足时的过渡动画（如loading），避免体验割裂 |
| 动态补缓存（缓存帧数低于阈值时重新缓存） | 平衡出图速度与流畅度，适应性强 | 网络波动不稳定的复杂场景 | 阈值建议设为 CacheFrameCount 的60%（如50帧的阈值为30帧） |
优先选择「动态补缓存」策略：初始出图前缓存 CacheFrameCount 的30%（快速出图），出图后后台继续缓存至目标帧数；后续若缓存帧数低于阈值（60%×CacheFrameCount），则暂停部分解码节奏，补充缓存至目标帧数后再恢复正常播放。
四、解码帧控
缓存帧数达到目标后，需通过「帧控」控制解码节奏，确保解码帧率与发送帧率一致，避免因解码过快或过慢导致缓存溢出或耗尽。帧控核心是在每帧解码完成后加入 sleep 时长，两种常见实现方式：
sleep时长固定为「平均发送间隔（AvgSendIntervalMs）」，解码节奏稳定，实现简单：
// 固定时长帧控伪代码
while (缓存帧数 >= 1) {
解码当前帧;
sleep(AvgSendIntervalMs); // 固定sleep 40ms（对应25fps）
从缓存中移除已解码帧;
}| 优点 | 缺点 | 优化措施 |
|---|---|---|
| 实现简单，无复杂逻辑；解码节奏稳定 | 易出现延迟累积（如每次sleep多1ms，100帧后延迟增加100ms） | 每解码10-20帧，检查缓存帧数：若超过目标帧数的120%，则清缓存至目标帧数，重置延迟 |
以 AvgSendIntervalMs 为中值，根据当前缓存帧数动态调整sleep时长，通过多档位细分实现精细调控，减少延迟累积和画面抖动：
| 缓存帧数状态 | sleep时长档位（基于AvgSendIntervalMs=40ms） | 调控目的 |
|---|---|---|
| 缓存帧数 > 120%×CacheFrameCount（缓存溢出风险） | 30-35ms（缩短sleep，加快解码） | 快速消耗缓存，避免溢出 |
| 缓存帧数 80%-120%×CacheFrameCount（正常范围） | 38-42ms（接近中值，小幅调整） | 维持解码节奏，保持流畅 |
| 缓存帧数 < 80%×CacheFrameCount（缓存耗尽风险） | 45-50ms（延长sleep，减慢解码） | 给缓存补充时间，避免断流卡顿 |
| 缓存帧数 < 60%×CacheFrameCount（严重不足） | 60-80ms（大幅延长sleep） | 紧急补充缓存，优先保障流畅度 |
• 固定时长帧控：适合网络稳定、对延迟不敏感的场景，开发成本低；
• 可变时长帧控：适合网络波动频繁、对体验要求高的场景，调控更精细，用户感知更流畅；
• 档位划分建议：3-5档即可，档位过多会增加逻辑复杂度，边际收益递减。
五、可变时长的帧控播放（进阶优化）
可变时长帧控的核心是「平滑调控」，避免因sleep时长突变导致画面快播/慢播的明显感知，需遵循以下两大原则：
每次调整sleep时长的幅度不宜过大，建议不超过 AvgSendIntervalMs 的20%，避免画面节奏突变。例如：
• 当前sleep时长40ms，下次调整后最长不超过48ms（+20%），最短不低于32ms（-20%）；
• 若需大幅调整（如缓存严重不足），可分多次逐步调整（如从40ms→45ms→50ms），而非一次性跳至80ms。
调控灵敏度（调整频率、幅度）与当前缓存帧数相关：缓存帧数越接近目标值，调控越迟钝；缓存帧数偏离目标值越多，调控越灵敏。具体逻辑：
// 灵敏度动态调整逻辑伪代码
float currentCacheRatio = 当前缓存帧数 / CacheFrameCount; // 缓存占比
if (currentCacheRatio >= 0.8 && currentCacheRatio = 0.6 && currentCacheRatio < 0.8) {
// 轻度偏离：中灵敏度（每3帧调整1次，幅度±5ms）
if (解码帧数 % 3 == 0) {
sleep时长 += 随机±5ms;
}
} else {
// 严重偏离：高灵敏度（每1帧调整1次，幅度±8ms）
sleep时长 += 随机±8ms;
}
// 限制sleep时长边界（避免过度调整）
sleep时长 = max(20ms, min(100ms, sleep时长));• 可变时长帧控需结合缓存状态实时调整，不可仅依赖固定规则；
• 若网络持续恶化（如缓存帧数长期低于阈值），需触发降级策略（如降低视频码率、分辨率），而非单纯依赖帧控；
• 调控过程中需记录历史调整记录，避免频繁反向调整（如40ms→45ms→40ms→45ms）导致画面抖动。
