智能视频会议系统：前向纠错 FEC 与重传机制 NACK 协同策略

在弱网、高丢包、高延迟的复杂网络环境下，保障视频会议的流畅度与清晰度是实时通信（RTC）领域的核心挑战。单一的抗丢包手段难以覆盖全场景，业界主流方案演进至 前向纠错（FEC）与负确认重传（NACK）协同 的混合抗丢包架构。本文将从协议原理、协同决策模型、关键参数自适应算法、工程落地难点四个维度，深度解析该技术体系的设计与实践。

一、 核心机制原理与适用边界分析

1.1 前向纠错（FEC）：以带宽换确定性低延迟

FEC 在发送端通过冗余编码生成修复包，接收端无需反馈即可本地恢复丢失数据。

• 分组策略：视频流按 Frame（帧） 或 GOP（关键帧间隔） 划分保护组。关键帧（I帧）通常采用更高冗余度（如 1:1 甚至 2:1），P/B帧采用动态冗余。

• 编码算法选型：

  • Reed-Solomon (RS) 码：系统码，编解码复杂度 $O(k(n-k))$，适合小分组（$k<32$），恢复上限固定。
  • RaptorQ / LDPC：喷泉码/低密度奇偶校验码，支持大分组、渐进式恢复，编解码复杂度线性，更适合 4K/8K 大帧保护，但实现复杂度高。
• 适用边界：单向时延 < 100ms、丢包率 5%-20%、抖动较大 场景。优势是零 RTT 恢复，劣势是固定带宽开销（Overhead），高丢包时冗余包亦可能丢失导致恢复失败。

1.2 负确认重传（NACK）：按需补发，带宽利用率高

接收端检测到序列号空洞，发送 NACK（RTCP Feedback, RFC 4585）请求重传，发送端从缓存队列中取出原包补发。

• 触发机制：序列号间隔检测 + NACK 抑制定时器（随机抖动 $T_{dither} in [0, T_{rtt}]$）防止反馈风暴。
• 关键约束：RTT 决定恢复下限。若 $RTT > 150ms$，重传包到达往往晚于解码截止时间，导致“迟到的重传”无效甚至干扰抖动缓冲区。
• 适用边界：RTT < 100ms、丢包率 < 10%、突发丢包 场景。优势是无冗余开销，劣势是引入至少 1 个 RTT 的额外延迟。

1.3 协同必要性：互补而非替代

二、 协同决策模型：基于网络状态的动态策略切换

核心在于构建 网络状态感知模块，实时估算 $P_{loss}$（丢包率）、$RTT$、$Jitter$（抖动）、$B_{est}$（可用带宽），驱动状态机在四种工作模式间切换。

2.1 四象限策略状态机

stateDiagram-v2
    [*] --> MODE_PURE_NACK: 低丢包/低RTT
    MODE_PURE_NACK --> MODE_FEC_PRIMARY: 丢包率上升/RTT上升
    MODE_FEC_PRIMARY --> MODE_HYBRID: 高丢包/中等RTT
    MODE_HYBRID --> MODE_FEC_ONLY: 极高丢包/反向链路断
    MODE_FEC_PRIMARY --> MODE_PURE_NACK: 网络恢复
    MODE_HYBRID --> MODE_FEC_PRIMARY: 丢包率下降

1. MODE_PURE_NACK（纯重传模式）：$P_{loss} < 2% land RTT < 80ms$。关闭 FEC，仅维护 NACK 缓存，带宽利用率最高。
2. MODE_FEC_PRIMARY（FEC 主导模式）：$2% le P_{loss} < 10% lor RTT ge 80ms$。开启 灵活 FEC (FlexFEC)，保护关键帧及参考帧，冗余率 $alpha = f(P_{loss}, RTT)$。NACK 作为兜底处理非参考帧丢包。
3. MODE_HYBRID（深度协同模式）：$10% le P_{loss} < 30%$。全帧 FEC 保护 + 激进 NACK。引入 冗余分层：基础层 (Base Layer) 100% FEC，增强层 (Enhancement Layer) 低冗余 + NACK。
4. MODE_FEC_ONLY（纯 FEC/单向模式）：$P_{loss} ge 30% lor$ 反向链路不可用。最大化冗余（可达 50%-100%），放弃 NACK，转为单向流模式，牺牲画质保连接。

2.2 关键决策函数：最优冗余率计算

目标函数：在带宽约束 $B_{fec} le beta cdot B_{est}$ 下，最大化帧级恢复概率 $P_{recover}$。

$$ alpha^* = argmax_{alpha} P_{recover}(alpha, P_{loss}, k) quad s.t. quad alpha cdot R_{video} le beta cdot B_{est} $$

其中 $k$ 为源包数量，$R_{video}$ 为视频码率，$beta$ 为 FEC 最大带宽占比（建议 0.2~0.3）。
工程近似解（基于二项分布模型）：

$$ P_{recover} approx sum_{i=0}^{n-k} binom{n}{i} P_{loss}^i (1-P_{loss})^{n-i} $$
$$ alpha_{target} = minleft( alpha_{max}, maxleft( alpha_{min}, frac{P_{loss} + gamma cdot sigma_{loss}}{1 - P_{loss}} right) right) $$

• $gamma$：安全系数（通常 2~3，对应 95%~99% 置信度）。
• $sigma_{loss}$：丢包率波动标准差（EWMA 估算），应对突发丢包。

三、 关键技术难点与工程化解决方案

3.1 问题一：NACK 与 FEC 的“竞态恢复”与资源浪费

现象：接收端收到 FEC 修复包恢复了数据，但 NACK 定时器未超时，仍发送 NACK 导致发送端无效重传。
解决方案：NACK 抑制与撤回机制

1. 接收端抑制：解码器成功利用 FEC 恢复帧后，立即从 NACK 待发队列中移除对应序列号。
2. 发送端去重：发送端维护 SentNackCache (序列号 -> Timestamp)。收到 NACK 时，若该包已在 $T_{rtt}$ 内因 FEC 反馈或主动重传发送过，则丢弃该 NACK 请求。
3. 显式撤回 (FIR/NACK-Cancel)：扩展 RTCP Feedback 类型，接收端主动发送 NACK_Cancel(SSRC, SeqNum)，告知发送端“已由 FEC 恢复，请勿重传”，节省上行带宽。

3.2 问题二：重传包挤占关键帧带宽导致“雪崩效应”

现象：弱网下带宽骤降，重传队列堆积，新关键帧无法及时发送，导致后续帧无法解码，画质断崖式下跌。
解决方案：优先级感知的发送调度队列
构建三级优先级发送管道：

1. P0：关键控制帧 - I帧、FIR 请求、关键 FEC 修复包（绝对优先，可抢占）。
2. P1：参考帧与重传包 - P帧、NACK 重传包（按 RTT 截止时间排序，EDF 算法）。
3. P2：非参考帧与常规 FEC - B帧、常规冗余包（低优先级，拥塞时优先丢弃）。

调度伪代码逻辑：

def schedule_packet(pacer_budget_bytes):
    # 1. 优先发送 P0
    send_from_queue(P0_QUEUE, pacer_budget_bytes)
    
    # 2. 计算重传截止时间
    now = get_current_time()
    valid_nacks = [p for p in P1_NACK_QUEUE if p.deadline > now + MIN_PROCESSING_TIME]
    
    # 3. EDF 调度：截止时间最近的重传包优先
    valid_nacks.sort(key=lambda p: p.deadline)
    send_from_list(valid_nacks, pacer_budget_bytes)
    
    # 4. 剩余带宽发送常规媒体包
    send_from_queue(P1_MEDIA_QUEUE, pacer_budget_bytes)
    send_from_queue(P2_QUEUE, pacer_budget_bytes)

3.3 问题三：FEC 分组大小与延迟的权衡

困境：分组越大（$k$ 越大），编码增益越高，但编码延迟 $T_{enc} propto k^2$ (RS码) 或 $k log k$ (RaptorQ) 显著增加，且首包等待时间拉长。
自适应分组策略：

• I帧：强制小分组 ($k le 16$)，甚至逐包 FEC (Unequal Error Protection, UEP)，确保首屏秒开。
• P帧：动态 $k = min(MaxK, lfloor frac{TargetFecLatency}{FrameInterval} rfloor)$。目标 FEC 延迟建议控制在 10-20ms 以内。
• 硬件加速：必须调用 SIMD (NEON/AVX2) 或 GPU (CUDA/OpenCL) 实现 GF(256) 乘法，将 RS 编码延迟压缩至 亚毫秒级（1000包/ms 量级）。

四、 典型弱网场景仿真验证与效果评估

4.1 测试环境配置

• 编码器：H.264 High Profile / VP9 SVC (3层)
• 码率：1080p @ 2.5Mbps / 720p @ 1.2Mbps

• 网络模型：NetEm 模拟 3G/4G/弱 WiFi 典型轨迹

  • 场景 A：随机丢包 5%，RTT 60ms
  • 场景 B：突发丢包 (Gilbert-Elliot 模型，平均丢包 15%，Burst 长度 5-10 包)，RTT 120ms
  • 场景 C：高抖动 (Jitter 50ms)，单向丢包 20%，反向链路正常

4.2 核心指标对比 (对比基线：仅 NACK / 仅 固定 20% FEC)

数据解读：

1. 协同策略在 场景 B (突发丢包+中高 RTT) 优势最大：FEC 吸收突发头包，NACK 补尾包，避免了纯 FEC 冗余不足或纯 NACK 超时。
2. 带宽节省显著：良好网络下自动降级至纯 NACK，较固定 FEC 节省 ~15% 上行带宽，降低自拥塞风险。
3. 延迟可控：通过严格限制 FEC 分组延迟 (<20ms) 和 NACK 截止时间 (<80ms)，端到端延迟仅比纯 FEC 略高，远优于纯 NACK。

五、 落地检查清单与演进建议

5.1 必须落地的工程细节

• [ ] 序列号空间统一：媒体包、FEC 包、重传包共享同一 16bit/32bit 序列号空间，简化接收端去重与 NACK 逻辑。
• [ ] FEC Payload Type 协商：SDP a=rtpmap:127 flexfec-03/90000 及 a=fmtp:127 repair-window=10000000 正确协商，支持多流保护。
• [ ] NACK 处理幂等性：发送端重传逻辑必须幂等，防止恶意/重复 NACK 导致缓存穿透。
• [ ] 统计上报标准化：上报 fec_packets_sent, fec_packets_received, nack_requests_sent, nack_unique_recovered 至监控大盘，支撑策略迭代。

5.2 未来演进方向

1. 网络层协同 (QUIC / WebTransport)：利用 QUIC 流级可靠性替代应用层 NACK，利用 DATAGRAM 帧承载 FEC，减少头部开销，统一拥塞控制视野。
2. AI 驱动的预测性 FEC：引入轻量级 LSTM/Transformer 模型，输入历史丢包序列、带宽序列，输出未来 200ms 丢包概率分布，实现 “丢包发生前预发冗余”，将抗丢包从“被动响应”升级为“主动防御”。
3. 跨层联合优化 (JSCC)：联合源信道编码，将视频编码器的比特重要性 (ROI、参考关系) 直接映射到物理层调制编码或应用层 FEC 保护等级，突破香农极限分离定理的工程约束。

结语

FEC 与 NACK 的协同并非简单的功能叠加，而是一套 “感知-决策-执行-反馈” 闭环的自适应控制系统。其核心价值在于：用最小的带宽冗余代价，在不可控的公网环境中，换取确定性的低延迟恢复能力。对于智能视频会议系统而言，掌握动态冗余率计算、优先级调度、竞态抑制等关键工程技术，是构建“弱网也能开会、强网更高清”产品体验的技术基石。

智能视频会议系统：FEC 与 NACK 协同策略（进阶篇）—— 分层编码保护、拥塞联合控制与端云协同演进

接上篇核心协同模型与单层流优化，本文进一步聚焦 可扩展视频编码 (SVC/Simulcast) 场景下的差异化保护策略、抗丢包模块与拥塞控制的深度耦合、服务端转发侧 (SFU/MCU) 的增强逻辑，以及 主观质量驱动的参数自适应闭环，构建生产级可落地的全链路抗弱网技术体系。

一、 SVC/Simulcast 分层流场景下的差异化 FEC-NACK 保护策略

现代会议系统普遍采用 SVC (H.264/SVC, VP9 SVC, AV1 SVC) 或 Simulcast 实现自适应码率。不同层级的帧重要性差异巨大，“均匀保护”极其低效，必须实现基于层级语义的精准资源分配。

1.1 层级重要性建模与冗余预算分配

定义视频流为基础层 (BL, L0) + 增强层 (EL, L1/L2...)。引入 层级失真权重 $W_l$ 量化丢包影响：

• $W_{BL} approx 1.0$：基础层丢包导致全层解码失败、画面花屏/冻结，影响最大。
• $W_{EL} approx 0.3 sim 0.5$：增强层丢包仅降低分辨率/帧率，画面可降级观看。

冗余预算优化模型（带宽约束 $B_{fec} le beta B_{est}$）：
$$ max sum_{l} W_l cdot P_{recover}^{(l)}(alpha_l) quad s.t. sum_{l} alpha_l R_l le beta B_{est} $$
利用拉格朗日乘子法求解最优冗余率向量 $vec{alpha}^* = [alpha_{BL}^*, alpha_{EL1}^*, ...]$：
$$ alpha_l^* propto sqrt{frac{W_l cdot R_l cdot ln(1/P_{loss})}{lambda}} $$
工程简化策略：

关键点：L0 层采用 不等保护 (UEP, Unequal Error Protection)。将 I 帧头部、SPS/PPS、Slice Header 单独构成“超级保护组”，冗余率高达 200%，确保解码器同步点绝对不丢。

1.2 依赖关系感知的 NACK 抑制与请求合并

SVC 中 EL 依赖 BL。若 BL 丢包已触发 NACK/FEC 恢复中，EL 的 NACK 请求应延后或抑制，避免重传风暴。

• 依赖图跟踪：接收端维护 FrameDependencyGraph。收到 NACK 触发条件（序列号空洞）时，检查该包所属帧的参考链。

• 抑制逻辑：

  复制

  bool ShouldSuppressNack(PacketLossEvent loss) {
      Frame* f = loss.frame;
      // 1. 若基础层同帧已在恢复队列中，抑制增强层 NACK
      if (f->layer > 0 && f->base_layer_frame->is_recovering) return true;
      // 2. 若参考帧 (Ref) 丢失且正在重传，抑制当前帧 NACK (无法解码)
      if (f->ref_frame && f->ref_frame->is_recovering) return true;
      return false;
  }

• NACK 合并：发送端收到同一帧不同层的 NACK，合并为单次重传调度，减少数据包头部开销与调度抖动。

二、 抗丢包模块与拥塞控制 (GCC/NADA) 的联合优化

核心矛盾：FEC 增加发送码率 $rightarrow$ 触发拥塞控制降码 $rightarrow$ 视频质量下降 $rightarrow$ 丢包率上升 $rightarrow$ 需要更多 FEC。单向优化会陷入“死亡螺旋”。

2.1 有效吞吐率模型修正拥塞控制带宽估计

标准 GCC (Google Congestion Control) 通过接收端计算接收率 $R_{recv}$ 反馈给发送端。引入 FEC/NACK 后，“有效视频吞吐率” $R_{goodput} neq R_{recv}$。

$$ R_{goodput} = R_{media} cdot (1 - P_{loss_residual}) $$
$$ P_{loss_residual} = P_{loss} cdot (1 - P_{fec_recover}) cdot (1 - P_{nack_recover}) $$

发送端带宽估计修正：
发送端维护 EffectiveRateEstimator，输入：媒体码率 $R_{media}$、FEC 开销 $alpha$、NACK 重传率 $rho$、反馈丢包率 $P_{loss_fb}$。
$$ hat{B}_{available} = frac{R_{media}}{1 + alpha + rho} cdot frac{1}{1 - P_{loss_residual}} $$
拥塞控制器 (如 NADA/BBR) 以 $hat{B}_{available}$ 而非原始链路容量作为目标发送率上限，为 FEC 冗余预留显式带宽配额。

2.2 拥塞信号反馈至 FEC 决策：显式拥塞感知的冗余熔断

当网络进入拥塞状态（RTT 梯度上升、ECN 标记、丢包率飙升），盲目增加 FEC 冗余会加剧拥塞崩溃。

熔断策略状态机：

1. 正常态：按 2.1 模型动态调整 $alpha$。
2. 预警态 (RTT 增长 > 20% 或 ECN-CE > 5%)：冻结 FEC 冗余增长，$alpha leftarrow alpha_{current}$；NACK 截止时间收紧 20%。
3. 拥塞态 (丢包率 > 30% 且 RTT > 300ms)：强制降级 FEC ($alpha leftarrow max(alpha_{min}, 0.5 alpha_{current})$)，优先保障 L0 层 FEC；触发编码器强制降码率 (Target Bitrate $times$ 0.7)。
4. 恢复态：拥塞信号消失持续 3 RTT 后，缓慢恢复 $alpha$ (加性增 AIMD)。

工程实现：在 NetworkController 接口中暴露 GetCongestionState() 供 FecController 调用，避免模块解耦导致的控制环振荡。

三、 服务端侧 (SFU/MCU) 的转发增强与转码协同

客户端协同仅解决“最后一公里”，服务端作为流量汇聚点，具备全局视角，可实施更激进的优化。

3.1 SFU 选择性转发与 FEC 感知调度

SFU 不解码媒体，但可解析 RTP Header Extension (如 FRAME_MARKING, DEPENDENCY_DESCRIPTOR)。

• FEC 包优先转发：下行带宽不足时，SFU 队列调度优先级：Keyframe + FEC > Delta Frame + FEC > Pure Media > NACK Retransmission。
• 动态层开关：根据下行用户网络画像，SFU 主动切断高层流 (L2/L1)，仅转发 L0 + FEC，降低下行带宽压力，避免下行拥塞导致的 FEC 包丢失。
• NACK 聚合与抑制：多个下游用户请求同一上游包的 NACK，SFU 合并转发单个 NACK 至上游，上游重传一次，SFU 扇出分发给所有请求者，减少上游链路压力 50%+。

3.2 MCU/转码侧的参考帧重构与冗余注入

MCU 需解码合流，拥有完全的编码控制权。

• 服务端侧 FEC 注入 (Server-Side FEC)：针对不支持 FEC 的老旧终端/浏览器，MCU 在编码输出前插入 FlexFEC/ULPFEC 包。终端无感知，仅需支持标准 RTP 解包。

• 长期参考帧 (LTR) 主动刷新策略：

  • 检测到关键用户持续高丢包 (>15%) 时，MCU 强制编码器生成 IDR 帧 或 LTR 帧，并标记为“高优先级恢复点”。
  • 同步下发 FIR (Full Intra Request) 至发送端，配合 FEC 保护该 IDR/LTR，实现秒级画面修复，避免错误传播累积导致的“绿屏/花屏”持续数十秒。
• 冗余编码 (RED) for Audio：音频包体积小，MCU 强制开启 RED (RFC 2198)，每个 RTP 包携带前 1-2 帧冗余，配合 Opus PLC (Packet Loss Concealment)，在 30% 丢包下仍保持语音可懂度。

四、 客户端解码器协同：从“丢包恢复”到“丢包隐藏”的无缝衔接

网络层恢复 (FEC/NACK) 终有极限 (延迟预算、带宽上限)。解码器端的丢包隐藏 (PLC) 与错误隐藏 (EC) 是最后一道防线，需与网络层状态联动。

4.1 解码器状态反馈指导网络层策略

解码器向网络模块上报关键状态事件（非周期性统计）：

• OnFrameDecodeFailed(frame_id, layer, reason)：参考帧缺失、Slice 丢失、参数集错误。
• OnConcealmentTriggered(frame_id, duration_ms)：启动隐藏算法（运动矢量外推、冻结帧、降级渲染）。

网络层联动动作：

1. 收到 DecodeFailed 且原因非参考帧缺失 $rightarrow$ 判定为残留比特错误，触发 即时 NACK (绕过抑制定时器) + 临时提升 FEC 冗余 5%。
2. 收到 ConcealmentTriggered 持续 > 500ms $rightarrow$ 判定为突发丢包未恢复，触发 强制 IDR 请求 (FIR/PLI) + 进入 MODE_FEC_PRIMARY。
3. 连续 5s 无 Concealment $rightarrow$ 网络恢复，允许降低 FEC 冗余。

4.2 参考帧管理优化：DPB (Decoded Picture Buffer) 保护策略

• 参考帧标记保护：解码器维护 ReferenceFrameScore。网络层恢复成功的帧，若为参考帧，标记 Score += 10；丢包隐藏生成的帧，Score -= 20。
• 编码器侧参考控制 (RPS 调整)：发送端根据接收端反馈的 ReferencePictureSelectionIndication (RPSI) 或隐式推断，避免参考“低分帧”。编码器生成 P 帧时，参考列表优先选择高分帧，切断错误传播链路。

五、 主观质量驱动的参数自适应闭环 (VMAF/MOS 导向)

传统指标 (PSNR, 丢包率, 延迟) 与用户主观体验 (MOS) 相关性较弱。引入 轻量级无参考质量模型 (NR-VMAF / ITU-T P.1203) 指导策略收敛。

5.1 在线质量估计模型部署

• 输入特征：瞬时丢包率、FEC 恢复率、NACK 重传延迟、帧冻结时长、分辨率切换频率、编码器 QP 值。
• 模型：蒸馏后的 MobileNetV3 / Tiny BERT 模型 (< 500KB, 推理 < 5ms/帧)，输出 预测 MOS 分值 (1-5) 及 置信度。
• 部署：客户端本地推理 (保护隐私，无网络延迟)，每 2s 上报一次 PredictedMOS 至服务端/控制平面。

5.2 基于 MOS 的强化学习 (RL) 策略微调

将协同策略参数 ($alpha_{base}, alpha_{enhance}, NackDeadline, FecGroupSize$) 视为 Action Space，PredictedMOS 为 Reward。

• 算法：Contextual Bandit (LinUCB/Thompson Sampling) 或轻量级 PPO。
• Context：当前网络状态向量 ($P_{loss}, RTT, Jitter, B_{est}$)、设备性能等级 (高/中/低端机)、会议场景 (屏幕共享/人像/文档)。

• 训练流程：

  1. 离线预训练：利用历史会议日志 (网络指标 + 事后用户评分/投诉) 训练初始策略网络。
  2. 在线微调：客户端/服务端运行 Bandit 算法，每分钟探索一次参数微调 ($pm 5%$)，观测 MOS 变化，更新策略。
  3. 安全约束：硬性限制 Action 范围 (如 $alpha le 30%$, Delay $le 200ms$)，防止 RL 策略发散导致严重卡顿。

效果：相比固定启发式规则，RL 策略在 中度弱网 (10%-20% 丢包) 场景下，可将 MOS 提升 0.3-0.5 分，并在带宽利用率上节省 8%-12%。

六、 移动端专项优化：电量、热功耗与后台生存

移动端 (iOS/Android) 受限于 CPU/GPU 频率调度、后台执行限制、电池策略，协同策略需“轻量化”。

6.1 计算负载自适应降级

• 硬件加速强制要求：移动端 必须 通过 MediaCodec / VideoToolbox / OpenCL 实现 RS 编解码的 GF(256) 乘法加速。纯软实现会导致 1080p 下 CPU 占用 > 30%，触发降频。

6.2 网络切换无缝衔接

WiFi $leftrightarrow$ 4G/5G 切换时，IP 变更导致连接中断。

• 连接迁移：基于 QUIC / Multipath QUIC 实现连接迁移，保持加密上下文与流控状态。
• 状态同步：切换瞬间，客户端立即同步 FEC State (Group ID, SeqBase), NACK Window, Decoder Reference State 至新路径，避免重新建连后的 2-3 秒黑屏/花屏期。
• 预测性预连接：利用 OS 网络回调 (iOS NWPathMonitor, Android ConnectivityManager.Callback)，在信号强度低于阈值时预建立备用连接，并同步少量探测包校验可用性。

七、 可观测性体系建设：从“会不会丢”到“为什么丢”

生产环境问题定位依赖全链路可观测性，建议建立 “三维诊断矩阵”：

7.1 关键指标仪表盘

7.2 分布式链路追踪

引入 TraceID 贯穿：App -> SDK -> Network Stack -> Kernel -> Server (SFU/MCU) -> Backhaul。

• 单次会议建立、弱网触发、恢复全过程生成一条 Trace。
• 关键 Span：FecEncode, PacketSent, PacketLost(Simulated), NackReceived, RetransmitSent, FecDecode, FrameRendered。
• 快速定位：通过 Trace 水fall 图，一眼识别“FEC 编码耗时过长”、“NACK 往返超时”、“SFU 队列丢包”、“解码器参考帧缺失”等典型瓶颈。

八、 总结与架构演进路线图

FEC 与 NACK 的协同，本质是 在不确定性网络环境中，通过“有状态的冗余”与“按需的重传”，在延迟、带宽、质量、算力四维约束下寻找帕累托最优解。

演进路线图

给架构师的建议：

1. 模块解耦接口标准化：定义清晰的 INetworkController, IFecController, INackManager, IDecoderFeedback 接口，便于单元测试、A/B 实验与算法热插拔。
2. 配置下发平台化：所有阈值、权重、模型参数下发至配置中心，支持分人群、分版本、分网络类型灰度发布，避免硬编码发版。
3. 建立弱网回放基因库：收集典型弱网场景的 PCAP + RTP Log + 编码器 Log，构建 CI/CD 流水线中的自动化回归测试集，每次策略变更必跑回放，对比 MOS/VMAF/卡顿率，防止回归。

通过上述体系化建设，智能视频会议系统可实现从“能连通”到“弱网流畅、强网高清、极弱网可用”的全场景覆盖，真正落地“音视频技术普惠”的产品价值。