3. 性能指标体系

推流端是整个直播链路的起点。源头出了问题，后面再怎么优化也是白搭。我这些年排查过的卡顿问题，十有八九都能追溯到推流端——要么是网络抖动没处理好，要么是编码参数设置得太激进。

这一章，咱们就聚焦三个核心点：网络抖动怎么扛、GOP结构怎么设、B帧和丢帧策略怎么选。说白了，就是让推流端在恶劣网络下也能输出稳定的码流。

3.1 网络抖动：推流端的头号敌人

网络抖动，说白了就是带宽忽高忽低、延迟忽大忽小。你想想看，推流端刚发出去一个关键帧，网络突然卡了，接收端那边画面直接卡住——这种体验谁受得了？

我个人习惯把网络抖动处理分成四个层次：

1. 发送缓冲区——给网络波动一个缓冲空间
2. NACK/重传——丢包了怎么办？重传！
3. 码率自适应——网络变差了，主动降码率
4. FEC前向纠错——发送冗余数据，丢包也能恢复

3.1.1 发送缓冲区：给网络一点喘息空间

发送缓冲区的大小，直接决定了推流端对网络抖动的容忍度。缓冲区太小，网络稍微波动就丢包；缓冲区太大，延迟又上去了。

我在项目中遇到过这样一个案例：一个直播App在4G网络下频繁卡顿，排查后发现发送缓冲区只有50ms。后来调整到200ms，卡顿率直接降了60%。当然，延迟也增加了150ms——这就是典型的trade-off。

场景	推荐缓冲区大小	说明
实时互动（视频通话）	50-100ms	延迟敏感，抖动容忍度低
直播推流（普通）	200-500ms	平衡延迟与稳定性
弱网环境	500-1000ms	优先保证流畅，接受较高延迟

3.1.2 NACK与重传：丢了就补

NACK（Negative ACK）机制，就是接收端告诉发送端：“我丢包了，快重传！”

但这里有个坑——重传需要时间。如果RTT（往返时延）是100ms，重传一个包至少需要100ms。对于实时性要求高的场景，这个延迟可能不可接受。

我曾经踩过一个坑：在RTT超过200ms的网络上，NACK重传导致视频帧到达时间严重不规律，播放端反而更卡了。后来我加了一个重传超时限制——超过300ms还没收到重传包，就直接跳过，不等了。

3.1.3 码率自适应：网络差就降质

码率自适应，说白了就是让推流端根据网络状况动态调整编码码率。网络好时用高码率，网络差时自动降下来。

我常用的策略是基于拥塞控制的码率调整：

// 伪代码：码率自适应逻辑
if (rtt < 50ms && 丢包率 < 1%) {
    // 网络良好，尝试提升码率
    目标码率 = min(当前码率 * 1.05, 最大码率);
} else if (rtt > 150ms || 丢包率 > 5%) {
    // 网络恶化，快速降码率
    目标码率 = max(当前码率 * 0.7, 最小码率);
} else {
    // 网络一般，保持当前码率
    目标码率 = 当前码率;
}

嗯，这里要注意——码率调整不能太频繁。我见过有人每秒钟调整一次码率，结果画面质量忽高忽低，用户体验极差。我建议至少间隔2-3秒才做一次调整。

3.1.4 FEC前向纠错：用冗余换稳定

FEC（Forward Error Correction）的原理很简单：发送端在原始数据之外，额外发送一些冗余数据。接收端即使丢了一部分包，也能通过冗余数据恢复出完整信息。

举个例子：每10个原始包，额外发送2个冗余包。这样即使丢了2个包，也能恢复。代价是带宽增加了20%。

我个人习惯在弱网环境下开启FEC，但冗余比例要动态调整——网络越差，冗余越多。但冗余比例不要超过50%，否则带宽浪费太严重。

3.2 GOP结构：延迟的隐形杀手

GOP（Group of Pictures）结构，说白了就是视频帧的分组方式。一个GOP包含一个IDR帧（关键帧）和若干P帧、B帧。

GOP结构对延迟的影响，很多人容易忽略。你想想看：如果GOP长度是10秒，接收端要等10秒才能收到下一个IDR帧。这期间如果发生丢包，画面可能一直花着——因为P帧依赖前面的帧，丢了就恢复不了。

3.2.1 GOP长度怎么选？

GOP长度越短，延迟越低，但码率越高（因为IDR帧比P帧大得多）。反之亦然。

GOP长度	延迟影响	码率影响	适用场景
0.5-1秒	极低延迟	码率增加20-30%	视频通话、云游戏
2-3秒	低延迟	码率增加5-10%	直播推流（低延迟模式）
5-10秒	中等延迟	码率影响小	普通直播、点播

我在项目中遇到过这样一个场景：一个游戏直播平台要求延迟低于1秒，但画面质量不能太差。我最终选择了1秒GOP长度，配合码率自适应，效果还不错。

3.2.2 开环GOP vs 闭环GOP

开环GOP（Open GOP）允许B帧跨GOP参考，压缩效率更高，但容错性差。闭环GOP（Closed GOP）的B帧只在GOP内部参考，容错性好，但压缩效率略低。

我的建议很简单：弱网环境下用闭环GOP。虽然压缩效率低一点，但至少不会因为一个丢包导致整个GOP花掉。

3.3 B帧与丢帧策略：该丢就丢

B帧（双向预测帧）能提高压缩效率，但也会增加编码延迟和内存消耗。更重要的是，B帧的依赖关系复杂——一个B帧丢了，可能影响前后多个帧的解码。

3.3.1 B帧数量：不是越多越好

H.264/H.265允许在P帧之间插入多个B帧。B帧越多，压缩效率越高，但延迟也越大。

我常用的配置：

• 实时互动场景：0个B帧（只使用P帧），延迟最低
• 低延迟直播：1-2个B帧，平衡压缩与延迟
• 普通直播：3-4个B帧，追求压缩效率

记得有一次，一个客户抱怨他们的直播延迟太高。我一看配置，B帧数量设成了8个——编码器要等8帧才能编码一个P帧，延迟能不高吗？改成2个B帧后，延迟从3秒降到了1秒以内。

3.3.2 丢帧策略：优先级降级

当网络拥塞时，推流端需要主动丢帧。但丢帧不是随便丢的——要按优先级来。

我习惯把帧分成三个优先级：

1. 最高优先级：IDR帧、P帧（被其他帧参考的）——绝对不能丢
2. 中等优先级：非参考P帧——可以丢，但会影响画面流畅度
3. 最低优先级：B帧——优先丢弃，不影响后续帧解码

丢帧策略的核心逻辑：

// 伪代码：丢帧策略
if (发送缓冲区 > 阈值) {
    // 缓冲区快满了，开始丢帧
    if (当前帧是B帧) {
        丢弃当前帧;
    } else if (当前帧是非参考P帧) {
        丢弃当前帧;
    } else {
        // IDR帧或参考P帧，不能丢
        // 降码率或等待缓冲区清空
        触发码率自适应;
    }
}

3.3.3 非参考帧丢弃：最安全的降码率方式

非参考帧丢弃（Non-Reference Frame Drop），说白了就是只丢那些不被其他帧参考的帧。B帧和非参考P帧都属于这一类。

这种策略的好处是：丢帧后，后续帧的解码不受影响，最多就是画面跳帧。用户可能感觉画面有点卡，但至少不会花屏。

我建议在推流端实现一个丢帧率监控——如果丢帧率超过10%，说明网络确实太差了，这时候应该主动降码率，而不是继续丢帧。

3.4 综合优化策略：把三块拼起来

网络抖动处理、GOP结构、B帧与丢帧策略，这三块不是孤立的。我习惯把它们组合成一个整体方案：

1. 网络稳定时：使用短GOP（2秒）、2个B帧、小发送缓冲区（100ms）
2. 网络波动时：动态增大发送缓冲区（200-500ms），开启FEC（冗余比例10-20%）
3. 网络恶化时：优先丢B帧，触发码率自适应，必要时切换到闭环GOP
4. 网络恢复后：逐步恢复码率，缩小缓冲区，关闭FEC