弱网对抗技术方案
概述
在直播场景中，根据网络情况动态调整编码参数（即弱网对抗或自适应码率/QoS策略）是保证用户体验（QoE）的核心技术。
业界成熟的方案通常遵循一个闭环控制系统：网络探测（Sensing） -> 策略决策（Decision） -> 编码执行（Execution）。
以下是针对不同直播架构（WebRTC/实时互动 vs RTMP/CDN推流）的业界成熟方案详解：
一、核心逻辑闭环
1. 网络探测（Sensing）：怎么知道网络变差了？
这是基础，通常通过传输层协议反馈获取指标：
- 发送缓冲区堆积 (Buffer Level): RTMP/TCP场景下，如果本地发送Buffer变大，说明上行带宽不足。
- 丢包率 (Packet Loss): 接收端通过RTCP (RR) 或 NACK 反馈丢包情况。
- 往返时延 (RTT): 衡量网络拥塞程度的重要指标。
- 带宽估计 (BWE – Bandwidth Estimation): 这是最核心的技术（如 WebRTC 中的 GCC 算法）。
- 基于延迟 (Delay-based): 发现单向延迟增加（One-way delay variation），预示拥塞即将发生，降低码率。
- 基于丢包 (Loss-based): 发现丢包已经发生，急剧降低码率。
2. 策略决策（Decision）：该调哪个参数？
调整通常有优先级，业界通用的降级策略（Degradation Preference）如下：
- 调节码率 (Bitrate): 最平滑，优先调整。
- 调节帧率 (Framerate): 当码率降到一定阈值（如清晰度无法接受时），开始丢帧。保持画面清晰，但变卡顿。
- 调节分辨率 (Resolution): 最后的手段。降低分辨率会显著减少数据量，但画面变模糊。
3. 编码执行 (Execution)：如何落地？
调用编码器（如x264, MediaCodec, VideoToolbox）的接口动态重置参数。
二、业界成熟方案详解
方案 A：WebRTC / 实时音视频架构 (如 Zoom, 抖音连麦)
这是目前最先进、响应最快的方案，适用于低延迟互动直播。
1. 核心算法：GCC (Google Congestion Control)
- 原理： 结合基于延迟（Trendline滤波器）和基于丢包的评估器，实时计算出目标码率（Target Bitrate）。
- Transport-CC: 接收端记录每个包的到达时间，反馈给发送端，发送端统一计算带宽，这种方式更精准。
2. 编码调整手段
- Simulcast (多流发送): 客户端同时编码三路流（大、中、小流）。如果带宽不够，直接停掉大流，只发中流。这是最”暴力”但有效的切分辨率方案。
- SVC (Scalable Video Coding, 可伸缩编码): 将视频编码为基础层和增强层。网络差时，只发基础层（低清/低帧率），网络好时补发增强层。H.264 SVC 或 AV1 支持较好。
3. 动态调整策略
- 保画质模式 (Maintain Resolution): 优先降帧率，适合PPT分享、教学场景。
- 保流畅模式 (Maintain Framerate): 优先降分辨率，适合运动、游戏直播。
方案 B：RTMP / SRT / 移动端推流 (如 常见的秀场直播、电商直播)
这类场景通常基于TCP（RTMP）或 UDP（SRT），由于RTMP不支持中途动态改变分辨率（会导致花屏或播放器报错），策略略有不同。
1. 基于发送缓冲区的流控 (Sender-side Buffer Control)
这是很多开源推流SDK（如LFLiveKit, OBS）的基础策略。
- 监测： 每隔 500ms 检查 socket 发送缓冲区的大小。
- 策略：
- 阈值 1: 缓冲区轻微堆积 -> 降低视频编码码率（如从 2Mbps 降到 1.5Mbps）。
- 阈值 2: 缓冲区严重堆积 -> 主动丢弃视频帧（只丢P帧/B帧，保I帧），俗称”主动丢帧”以腾出带宽。
2. 软编码器动态配置 (Software Encoder Reconfiguration)
针对 x264/OpenH264：
- 动态码率: 调用
x264_encoder_reconfig修改i_bitrate_tovisit。 - 动态帧率: 并不直接修改编码器FPS，而是通过采集端控制。例如，原本30fps采集，中间抽帧变成15fps输入给编码器，同时修改PTS（显示时间戳），让编码器以为自己在编15fps的视频。
3. 升维/降维 冷却机制 (Cool-down)
- 网络波动是常态，不能频繁跳变。
- 下探快： 发现网络差，立即降码率（如 3秒内）。
- 上探慢： 网络恢复后，观察 10-20秒，确认稳定后再逐步提升码率，避免震荡。
三、具体的参数调整算法示例 (伪代码逻辑)
假设当前配置：1080P, 4Mbps, 30fps。
状态机逻辑
1. 探测阶段
- 实时计算
Current_Bandwidth(当前可用带宽)。 - 如果是 RTMP，计算
Buffer_Duration(缓冲区积压时长)。
2. 决策阶段
if Network_State == CONGESTED (拥塞):
# 步骤1：降码率
New_Bitrate = Current_Bitrate * 0.8 # 每次下调20%
if New_Bitrate < Min_Bitrate_1080P: # 如果码率撑不住1080P了
# 步骤2：降帧率 (如果场景允许)
Target_FPS = 15
if New_Bitrate < Min_Bitrate_720P:
# 步骤3：降分辨率 (RTMP慎用，WebRTC可用)
Target_Res = 540P
elif Network_State == GOOD (良好) and Cooldown_Timer_Expired:
# 缓慢回升
New_Bitrate = min(Max_Bitrate, Current_Bitrate + 200kbps)
3. 执行阶段（针对 RTMP 无法动态切分辨率的妥协）
- Trick: 如果必须在 RTMP 中降分辨率，通常做法是保持编码分辨率不变（如1080P），但实际上把图像缩小贴黑边，或者简单地忍受低码率带来的马赛克（块效应），而不去改变 SPS/PPS 信息。
四、进阶：AI 辅助的智能流控
现在的头部厂商（如声网、腾讯云、字节跳动）正在使用 AI/RL（强化学习）来做调整：
1. 场景识别
AI 识别当前是”人脸说话”（静态）还是”游戏打斗”（动态）。如果是静态，大力降帧率省带宽；如果是动态，优先保帧率降画质。
2. 网络预测
使用 LSTM 或 Transformer 模型根据过去 10秒的网络抖动，预测未来 5秒的带宽，提前调整，而不是等到丢包了再调整。
3. ROI 编码 (Region of Interest)
网络差时，把码率全部分配给人脸区域，背景极度模糊。这是一种”感官上”的参数调整。
总结建议
如果你需要自己实现一套方案：
起步阶段
基于发送缓冲区堆积率，只动态调整码率（Bitrate）。这是最安全、兼容性最好的方式。
进阶阶段
引入丢帧逻辑（Drop Frames），在应用层丢弃P帧。
高阶阶段（WebRTC）
移植 GCC 算法，实现精准的带宽估计，并结合 Simulcast 做分辨率切换。