4. QoS与QoE指标

FEC（前向纠错）在WebRTC里是个老话题了。但说实话，真正把它用对的人不多。

我见过不少团队，一遇到丢包就盲目加大FEC冗余。结果带宽浪费了，视频反而更卡。为什么？因为FEC不是万能的，它是一把双刃剑。

这一章，我们就把FEC的底裤扒干净。从ULP FEC到Flex FEC，从保护级别计算到编解码实战，一步到位。

4.1 ULP FEC：WebRTC的元老级方案

ULP FEC，全称Uneven Level Protection。它是WebRTC最早支持的FEC方案。

它的核心思路很简单：对媒体数据包进行异或运算，生成冗余包。接收端如果丢了某个包，可以用其他包和冗余包一起恢复出来。

ULP FEC的关键特性：

  • 基于异或（XOR）运算，计算量小
  • 支持多级保护（Uneven Level），不同重要性的数据包获得不同保护强度
  • 与RTP协议紧密耦合，封装在RTP扩展头中
  • 只能恢复连续丢包，对随机丢包效果一般

我在项目中遇到过一个问题：ULP FEC在丢包率超过20%时，恢复率急剧下降。原因很简单，异或运算要求所有参与包都到达才能恢复。丢包一多，恢复条件就难以满足。

4.1.1 ULP FEC的保护级别

ULP FEC支持多级保护。你可以为不同重要性的数据包设置不同的冗余度。

举个例子：视频的I帧比P帧重要得多。你可以给I帧分配更多的FEC包，给P帧少一些。这就是"Uneven Level"的含义。

保护级别 适用场景 冗余度 恢复能力
Level 0 音频、P帧 10%-20% 低
Level 1 视频I帧、关键数据 30%-50% 中
Level 2 信令、同步数据 50%-100% 高

注意：ULP FEC的保护级别不是越高越好。冗余度过高会占用大量带宽，反而导致网络拥塞，丢包更严重。我曾经见过一个案例，某团队把FEC冗余开到80%，结果视频完全卡死。后来降到30%，反而流畅了。

4.2 Flex FEC：新一代的灵活方案

Flex FEC是WebRTC后来引入的FEC方案。它比ULP FEC灵活得多。

说白了，ULP FEC是"固定套路"，Flex FEC是"自由组合"。你可以自定义FEC的保护组大小、保护模式、甚至保护哪些包。

4.2.1 Flex FEC的核心优势

  • 灵活的保护组：可以保护任意数量的包，不限于2的幂次
  • 多种编码模式：支持XOR、Reed-Solomon等多种编码
  • 独立于RTP：Flex FEC包有自己的RTP Payload Type，不依赖扩展头
  • 更好的恢复率：Reed-Solomon编码可以恢复任意位置的丢包

我个人习惯在丢包率超过15%的场景下使用Flex FEC + Reed-Solomon。虽然计算量稍大，但恢复效果明显优于ULP FEC。

4.2.2 Flex FEC的保护模式

Flex FEC支持两种保护模式：

  • 1-D模式：只对行进行保护，类似ULP FEC
  • 2-D模式：同时对行和列进行保护，恢复能力更强

你想想看，2-D模式相当于给数据包加了一个"网格"保护。即使行和列都有丢包，只要丢包不重叠，就能恢复。这在突发丢包场景下特别有用。

4.3 FEC保护级别与冗余度计算

这是FEC配置的核心。保护级别和冗余度怎么算？我直接给公式。

4.3.1 冗余度计算公式

冗余度 = FEC包数量 / 媒体包数量 × 100%

例如：
- 10个媒体包 + 2个FEC包 = 20%冗余
- 10个媒体包 + 5个FEC包 = 50%冗余

4.3.2 保护级别选择策略

在实际项目中，我一般这样配置：

丢包率 推荐方案 冗余度 说明
< 5% ULP FEC 10% 轻量保护，带宽开销小
5% - 15% Flex FEC (XOR) 20% - 30% 中等保护，平衡带宽和恢复
15% - 30% Flex FEC (RS) 30% - 50% 强保护，Reed-Solomon编码
> 30% Flex FEC (RS) + NACK 50% - 100% 混合方案，FEC+NACK联合

经验之谈：不要静态配置FEC冗余度。我建议根据实时网络状况动态调整。WebRTC的带宽估计模块会输出丢包率，你可以用这个值作为输入，实时计算FEC冗余度。

4.4 FEC编解码实战

理论说完了，上代码。我们以Flex FEC为例，演示编解码过程。

4.4.1 FEC编码示例

// 伪代码：Flex FEC编码
// 输入：媒体包列表 media_packets
// 输出：FEC包列表 fec_packets

function encodeFEC(media_packets, protection_level) {
    let fec_packets = [];
    let k = media_packets.length;  // 媒体包数量
    let n = k * (1 + protection_level);  // 总包数（含FEC）
    let r = n - k;  // FEC包数量
    
    // 使用Reed-Solomon编码
    let rs = new ReedSolomon(k, r);
    
    // 构建编码矩阵
    let data_matrix = [];
    for (let i = 0; i < k; i++) {
        data_matrix.push(media_packets[i].payload);
    }
    
    // 生成FEC包
    let fec_data = rs.encode(data_matrix);
    for (let i = 0; i < r; i++) {
        fec_packets.push({
            ssrc: media_packets[0].ssrc,
            sequence_number: base_seq + k + i,
            payload: fec_data[i]
        });
    }
    
    return fec_packets;
}

4.4.2 FEC解码示例

// 伪代码：Flex FEC解码
// 输入：接收到的包列表 received_packets（含媒体包和FEC包）
// 输出：恢复后的媒体包列表 recovered_packets

function decodeFEC(received_packets, k, r) {
    let recovered = [];
    let received_count = received_packets.length;
    
    // 检查是否满足恢复条件
    if (received_count < k) {
        console.log("收到的包太少，无法恢复");
        return [];
    }
    
    // 提取有效数据
    let data_matrix = [];
    let erasure_positions = [];
    
    for (let i = 0; i < k + r; i++) {
        let pkt = received_packets.find(p => p.sequence_number === base_seq + i);
        if (pkt) {
            data_matrix.push(pkt.payload);
        } else {
            data_matrix.push(null);
            erasure_positions.push(i);
        }
    }
    
    // 使用Reed-Solomon解码
    let rs = new ReedSolomon(k, r);
    let decoded = rs.decode(data_matrix, erasure_positions);
    
    // 提取恢复的媒体包
    for (let i = 0; i < k; i++) {
        if (received_packets.find(p => p.sequence_number === base_seq + i)) {
            // 已收到，跳过
            continue;
        }
        recovered.push({
            sequence_number: base_seq + i,
            payload: decoded[i]
        });
    }
    
    return recovered;
}

避坑指南：我曾经在解码时犯过一个错误——没有检查FEC包的SSRC是否与媒体包一致。结果在SFU场景下，不同源的包混在一起，解码全乱了。记住：FEC包和它保护的媒体包必须属于同一个SSRC。

4.5 FEC知识体系总览

下面这张图总结了FEC的核心知识点和决策路径。你可以把它当作配置FEC的快速参考。

WebRTC FEC知识体系与决策路径 WebRTC FEC 知识体系与决策路径 FEC 方案选择 ULP FEC Flex FEC XOR 编码 多级保护 RTP扩展头 XOR / RS 编码 1-D / 2-D 模式 独立Payload Type 冗余度计算 编解码实现 决策建议：丢包率 < 5% 用 ULP FEC，5%-30% 用 Flex FEC，> 30% 用 Flex FEC + NACK 混合方案

4.6 本章小结

FEC是WebRTC丢包恢复的重要武器。但记住：没有银弹。

  • ULP FEC适合低丢包率场景，实现简单，计算量小
  • Flex FEC适合中高丢包率场景，灵活性强，恢复率高
  • 冗余度计算要动态调整，静态配置容易浪费带宽或保护不足
  • 编解码实现要注意SSRC一致性、保护组大小等细节

嗯，这一章的内容就到这里。FEC的配置和调优需要结合实际网络环境反复试验。我建议你在自己的项目中先跑通基础流程，再逐步优化冗余度和保护级别。

← 上一章 📖 返回目录 下一章 →