WebRTC进阶--red+ulpfec深度解析3-FEC--冗余控制机制深度解析

文章目录

- 摘要
- [1. 整体架构与决策流程](#1. 整体架构与决策流程)
- [2. 核心参数与计算公式](#2. 核心参数与计算公式)
- - [2.1 有效速率（Bits Per Frame）](#2.1 有效速率（Bits Per Frame）)
  - [2.2 空间分辨率归一化因子](#2.2 空间分辨率归一化因子)
  - [2.3 有效速率查表索引](#2.3 有效速率查表索引)
- [3. FEC 保护因子查表（kFecRateTable）](#3. FEC 保护因子查表（kFecRateTable）)
- - [3.1 表结构](#3.1 表结构)
  - [3.2 查表示例](#3.2 查表示例)
  - [3.3 触发 FEC 的最小丢包阈值](#3.3 触发 FEC 的最小丢包阈值)
- [4. 关键帧保护增强](#4. 关键帧保护增强)
- [5. 从原始保护因子到最终冗余率](#5. 从原始保护因子到最终冗余率)
- [6. 实际 FEC 包数计算](#6. 实际 FEC 包数计算)
- [7. 典型配置与测试建议](#7. 典型配置与测试建议)
- [7.1 强制开启 FEC](#7.1 强制开启 FEC)
- [7.3 关键日志](#7.3 关键日志)
- [7.4 作用位置](#7.4 作用位置)
- [8. fec参数使用](#8. fec参数使用)
- - [8.1. FEC 包个数怎么算？](#8.1. FEC 包个数怎么算？)
  - [8.2. 怎么保护（生成 FEC 包）？](#8.2. 怎么保护（生成 FEC 包）？)
  - - [8.2.1 生成保护掩码](#8.2.1 生成保护掩码)
    - [8.2.2 填充 XOR 载荷](#8.2.2 填充 XOR 载荷)
    - [8.2.3 完成 FEC 头](#8.2.3 完成 FEC 头)
- [9. 总结](#9. 总结)

摘要

前向纠错（FEC）是 WebRTC 中对抗网络丢包的关键技术之一。WebRTC 内部实现了一套动态 FEC 冗余率决策算法，基于实时网络状态（丢包率、RTT）、编码参数（码率、帧率、分辨率）和视频内容（关键帧/增量帧）来动态调整保护强度。本文深入剖析 WebRTC 中 FEC 冗余计算的完整流程，包括保护逻辑、查表机制、关键参数的含义以及源码实现细节，帮助开发者理解并调试相关行为。

1. 整体架构与决策流程

WebRTC 的 FEC 控制由两个核心类协作完成：

FecControllerDefault：对外接口，负责接收网络反馈（丢包率、RTT、估计码率）和编码数据（帧大小、帧类型），触发保护决策。
VCMLossProtectionLogic + VCMFecMethod / VCMNackFecMethod：实现具体的丢包滤波、保护因子计算和 FEC 冗余率生成。

整个决策流程如下：
#mermaid-svg-PPWmdcWy0TRxnite{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-PPWmdcWy0TRxnite .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-PPWmdcWy0TRxnite .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-PPWmdcWy0TRxnite .error-icon{fill:#552222;}#mermaid-svg-PPWmdcWy0TRxnite .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-PPWmdcWy0TRxnite .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-PPWmdcWy0TRxnite .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-PPWmdcWy0TRxnite .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-PPWmdcWy0TRxnite .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-PPWmdcWy0TRxnite .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-PPWmdcWy0TRxnite .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-PPWmdcWy0TRxnite .marker{fill:#333333;stroke:#333333;}#mermaid-svg-PPWmdcWy0TRxnite .marker.cross{stroke:#333333;}#mermaid-svg-PPWmdcWy0TRxnite svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-PPWmdcWy0TRxnite p{margin:0;}#mermaid-svg-PPWmdcWy0TRxnite .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-PPWmdcWy0TRxnite .cluster-label text{fill:#333;}#mermaid-svg-PPWmdcWy0TRxnite .cluster-label span{color:#333;}#mermaid-svg-PPWmdcWy0TRxnite .cluster-label span p{background-color:transparent;}#mermaid-svg-PPWmdcWy0TRxnite .label text,#mermaid-svg-PPWmdcWy0TRxnite span{fill:#333;color:#333;}#mermaid-svg-PPWmdcWy0TRxnite .node rect,#mermaid-svg-PPWmdcWy0TRxnite .node circle,#mermaid-svg-PPWmdcWy0TRxnite .node ellipse,#mermaid-svg-PPWmdcWy0TRxnite .node polygon,#mermaid-svg-PPWmdcWy0TRxnite .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-PPWmdcWy0TRxnite .rough-node .label text,#mermaid-svg-PPWmdcWy0TRxnite .node .label text,#mermaid-svg-PPWmdcWy0TRxnite .image-shape .label,#mermaid-svg-PPWmdcWy0TRxnite .icon-shape .label{text-anchor:middle;}#mermaid-svg-PPWmdcWy0TRxnite .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-PPWmdcWy0TRxnite .rough-node .label,#mermaid-svg-PPWmdcWy0TRxnite .node .label,#mermaid-svg-PPWmdcWy0TRxnite .image-shape .label,#mermaid-svg-PPWmdcWy0TRxnite .icon-shape .label{text-align:center;}#mermaid-svg-PPWmdcWy0TRxnite .node.clickable{cursor:pointer;}#mermaid-svg-PPWmdcWy0TRxnite .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-PPWmdcWy0TRxnite .arrowheadPath{fill:#333333;}#mermaid-svg-PPWmdcWy0TRxnite .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-PPWmdcWy0TRxnite .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-PPWmdcWy0TRxnite .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-PPWmdcWy0TRxnite .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-PPWmdcWy0TRxnite .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-PPWmdcWy0TRxnite .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-PPWmdcWy0TRxnite .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-PPWmdcWy0TRxnite .cluster text{fill:#333;}#mermaid-svg-PPWmdcWy0TRxnite .cluster span{color:#333;}#mermaid-svg-PPWmdcWy0TRxnite div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-PPWmdcWy0TRxnite .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-PPWmdcWy0TRxnite rect.text{fill:none;stroke-width:0;}#mermaid-svg-PPWmdcWy0TRxnite .icon-shape,#mermaid-svg-PPWmdcWy0TRxnite .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-PPWmdcWy0TRxnite .icon-shape p,#mermaid-svg-PPWmdcWy0TRxnite .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-PPWmdcWy0TRxnite .icon-shape .label rect,#mermaid-svg-PPWmdcWy0TRxnite .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-PPWmdcWy0TRxnite .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-PPWmdcWy0TRxnite .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-PPWmdcWy0TRxnite :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 网络丢包 fraction_lost
丢包滤波 LossFilter
滤波后丢包率 packet_loss_enc
编码参数: 码率/帧率/分辨率/每帧包数
有效速率计算 BitsPerFrame
查表 kFecRateTable
得到原始保护因子 codeRateDelta/codeRateKey
空间分辨率归一化调整 resolnFac
关键帧保护因子提升 BoostKey
转换为RTP模块期望的保护因子 ConvertFECRate
最终冗余率 _protectionFactorD/K

2. 核心参数与计算公式

2.1 有效速率（Bits Per Frame）

FEC 保护强度取决于平均每帧的比特数，但需要排除时间层的干扰------FEC 通常只应用于基础层（TL0）。计算公式如下：

cpp 复制代码

// media_opt_util.cc - VCMFecMethod::BitsPerFrame
float bitRateRatio = SimulcastRateAllocator::GetTemporalRateAllocation(numLayers, 0, ...);
float frameRateRatio = powf(1 / 2.0, numLayers - 1);
float bitRate = parameters->bitRate * bitRateRatio;
float frameRate = parameters->frameRate * frameRateRatio;
return (bitRate / frameRate) * 1000 / 8;   // 转换为字节
bitRateRatio：基础层在总码率中的占比（例如两层时 TL0 占 60%）。

frameRateRatio：基础层的帧率占比（两层时 TL0 帧率为总帧率的 1/2）。

2.2 空间分辨率归一化因子

不同分辨率下，相同丢包对视频质量的主观影响不同。WebRTC 引入了一个缩放因子 resolnFac：

cpp 复制代码

float spatialSizeToRef = (width * height) / (704.0 * 576.0);   // 4CIF 参考
float resolnFac = 1.0 / powf(spatialSizeToRef, 0.3f);

参考分辨率 704×576 对应标清（4CIF）。

当分辨率大于参考值时，spatialSizeToRef > 1，resolnFac < 1，从而降低 FEC 冗余率（因为高分辨率下每个包丢失对主观质量影响相对较小）。

当分辨率小于参考值时，resolnFac > 1，提高 FEC 冗余率（低分辨率下丢包更容易引起块效应）。

指数 0.3 是经验值，用于平滑缩放幅度。

2.3 有效速率查表索引

经过分辨率缩放后的有效速率：

cpp 复制代码

uint16_t effRateFecTable = resolnFac * BitsPerFrame(parameters);
uint8_t rateIndexTable = clamp((effRateFecTable - 5) / 5, 0, 49);
//5 为速率步长，0~49 共 50 个等级。

丢包率等级：packetLoss = 0~128（对应实际丢包率 0~50.2%）。

最终一维索引：index = rateIndexTable * 129 + packetLoss。

3. FEC 保护因子查表（kFecRateTable）

3.1 表结构

kFecRateTable 是一个静态预计算表，大小为 50 × 129 = 6450 字节。表中每个元素为 unsigned char（0~255），表示原始 FEC 保护因子，真实冗余率 = 保护因子 / 255。

行：速率等级 0~49，码率从低到高。
列：丢包等级 0~128，丢包率从 0% 到 50.2%。

3.2 查表示例

假设某帧：

有效速率 effRateFecTable = 20，得 rateIndex = (20-5)/5 = 3。
滤波后丢包 packetLoss = 25（对应约 9.8%）。
索引：3 * 129 + 25 = 412。
查表得 kFecRateTable[412]（表中数据见源码，此处假设值为 56）。
原始冗余率 = 56/255 ≈ 22%。

3.3 触发 FEC 的最小丢包阈值

从表中可以发现：

packetLoss = 0 时，大部分表项为 0，即无丢包不会触发 FEC。
packetLoss ≥ 1 后，许多条目变为正数（如 11、39）。因此，即使丢包率仅为 0.4%（1/255），在中等以上码率时也会产生少量 FEC 冗余。

实际测试中，想要可靠触发 FEC，建议模拟丢包率 ≥ 10%（packetLoss ≈ 25）。

4. 关键帧保护增强

关键帧（I 帧）比增量帧（P 帧）更重要，因此 WebRTC 会对其施加更强的 FEC 保护。增强系数 BoostKey 由下式决定：

cpp 复制代码

uint8_t BoostCodeRateKey(uint8_t packetFrameDelta, uint8_t packetFrameKey) const {
    uint8_t boostRateKey = 2;
    uint8_t ratio = 1;
    if (packetFrameDelta > 0) {
        ratio = packetFrameKey / packetFrameDelta;
    }
    ratio = max(boostRateKey, ratio);
    return ratio;
}

通常 ratio 至少为 2，即 I 帧的 FEC 保护因子至少是 P 帧的两倍。
同时，rateIndexTable 会乘以 ratio 后再查表，进一步提高 I 帧的冗余率。

最终 I 帧的保护因子取三者最大值：

text 复制代码

codeRateKey = max(packetLoss, max(boostKeyProt, codeRateKey))

5. 从原始保护因子到最终冗余率

原始查表得到的 codeRateDelta / codeRateKey 定义为冗余包数 / (源包数 + 冗余包数)。但 RTP 模块中的 FEC 编码器期望的保护因子定义为冗余包数 / 源包数。因此需要转换：

cpp 复制代码

uint8_t ConvertFECRate(uint8_t codeRateRTP) const {
    return (uint8_t)(0.5 + 255.0 * codeRateRTP / (255.0 - codeRateRTP));
}

例如原始因子 51（20%），转换后约为 255 * 0.2 / 0.8 ≈ 64（25% 冗余相对于源包数）。转换后的值才会传递给 protection_callback_->ProtectionRequest。

6. 实际 FEC 包数计算

WebRTC 中 FEC 包数量由 RTP 发送模块根据保护因子和源包数量决定，并未在 FecControllerDefault 中直接计算。典型公式为：

text 复制代码

fec_packets = ceil(source_packets * fec_rate / (1 - fec_rate))

source_packets：一帧被分割成的 RTP 包数量。
fec_rate：_protectionFactorD 或 _protectionFactorK 转换后的值（除以 255）。
结果取整。

例如：源包 10 个，fec_rate = 0.25，则 fec_packets = ceil(10 * 0.25) = 3 个。

7. 典型配置与测试建议

7.1 强制开启 FEC

若要在测试中强制 WebRTC 生成 FEC 冗余包，可以直接设置丢包率 ≥ 10%，或修改源码强制 packetLoss 为正值（例如 10）。更彻底的方法是修改 VCMFecMethod::ProtectionFactor，设定一个最低保护因子。

7.2 使用 NetEm 模拟丢包

bash 复制代码

# 添加 10% 随机丢包
tc qdisc add dev eth0 root netem loss 10%

# 删除规则
tc qdisc del dev eth0 root

7.3 关键日志

在 FecControllerDefault::UpdateFecRates 中添加日志可查看冗余率：

cpp 复制代码

RTC_LOG(LS_INFO) << "FEC rates: delta=" << (int)delta_fec_params.fec_rate 
                 << " key=" << (int)key_fec_params.fec_rate;

7.4 作用位置

这里计算的结果会在RtpVideoSender的ProtectionRequest中设置给每一路流的RTPSenderVideo的SetFecParameters，实现如下：

cpp 复制代码

void RTPSenderVideo::SetFecParameters(const FecProtectionParams& delta_params,
                                      const FecProtectionParams& key_params) {
  rtc::CritScope cs(&crit_);
  delta_fec_params_ = delta_params;
  key_fec_params_ = key_params;
}

使用是在RTPSenderVideo::SendVideo方法中，主要代码如下：

cpp 复制代码

  if (flexfec_enabled() || ulpfec_enabled()) {
    rtc::CritScope cs(&crit_);
    // FEC settings.
    const FecProtectionParams& fec_params =
        video_header.frame_type == VideoFrameType::kVideoFrameKey
            ? key_fec_params_
            : delta_fec_params_;
    if (flexfec_enabled())
      flexfec_sender_->SetFecParameters(fec_params);
    if (ulpfec_enabled())
      ulpfec_generator_.SetFecParameters(fec_params);
  }

8. fec参数使用

在 forward_error_correction.cc 中，FEC 包的数量和如何保护都有明确的实现。下面为你提炼核心逻辑。

8.1. FEC 包个数怎么算？

由 NumFecPackets() 函数决定：

cpp 复制代码

int ForwardErrorCorrection::NumFecPackets(int num_media_packets,
                                          int protection_factor) {
  // 结果按 Q0 舍入（即整数除法，但带有四舍五入）
  int num_fec_packets = (num_media_packets * protection_factor + (1 << 7)) >> 8;
  // 如果保护因子 >0 但计算结果为 0，强制生成至少 1 个 FEC 包
  if (protection_factor > 0 && num_fec_packets == 0) {
    num_fec_packets = 1;
  }
  return num_fec_packets;
}

protection_factor：范围 0~255，对应 0%~100%（例如之前查表得到的 _protectionFactorD 转换前的原始值）。
实际 FEC 包数 = 媒体包数 × protection_factor / 256，向上或向最近取整。

例如：媒体包 10 个，protection_factor = 51（≈20%），计算结果 = (10×51 + 128)/256 = 2.9 → 2 个 FEC 包。

注意：这个函数返回的 num_fec_packets 就是最终生成的冗余包数量。

8.2. 怎么保护（生成 FEC 包）？

核心流程在 EncodeFec() 中：

8.2.1 生成保护掩码

cpp 复制代码

internal::GeneratePacketMasks(num_media_packets, num_fec_packets,
                              num_important_packets, use_unequal_protection,
                              &mask_table, packet_masks_);

为每个 FEC 包生成一个比特掩码，长度 = packet_mask_size_ 字节。
掩码的每一位表示该 FEC 包保护哪一个媒体包。
支持不等保护（UEP）：重要包（如关键帧的前几个包）可被更多 FEC 包覆盖。

8.2.2 填充 XOR 载荷

GenerateFecPayloads() 中，每个 FEC 包初始化为全零，然后对它所保护的每个媒体包进行 XOR：
XorHeaders：XOR RTP 头的前 8 字节（V、P、X、CC、M、PT、长度、时间戳）。
XorPayloads：XOR 媒体包的 RTP 载荷部分。

最终 FEC 包成为所有被保护媒体包的 XOR 和。

8.2.3 完成 FEC 头

FinalizeFecHeaders() 写入 FEC 包的 RTP 头（SSRC、序列号基址、保护长度、掩码等）。

9. 总结

通过上述机制，WebRTC 能够在不浪费带宽的前提下，为不同分辨率、不同丢包环境提供恰当的前向纠错保护，从而有效提升弱网下的实时通信质量。