11、视频编解码：H.264编码参数、VP8编码调优、码率控制策略
聊到视频编解码，很多同学第一反应就是“调参数”。嗯，这话没错，但也不全对。我做了这么多年WebRTC，见过太多人把编码参数调得天花乱坠，结果画质反而更差。说白了，编码器不是参数越多越好，而是你得知道每个参数背后到底在干什么。
今天这一章，咱们就聚焦三个核心话题：H.264的参数配置、VP8的调优技巧，以及码率控制策略。这三个东西，是WebRTC音视频通话质量的地基。
核心观点：编码参数没有“万能配置”，只有“场景最优解”。你是在做视频会议，还是在做直播推流？不同的场景，参数策略天差地别。
一、H.264 编码参数：别乱调，先搞懂这几个
H.264 在 WebRTC 里用得最广，兼容性也最好。但它的参数多到让人头疼。我个人习惯，只关注下面这几个核心参数，其他的保持默认就好。
1. Profile 和 Level
Profile 决定了编码器的“能力集”。WebRTC 里最常用的是 Constrained Baseline (CBP) 和 Main Profile。CBP 去掉了 B 帧，延迟更低，适合实时通话。Main Profile 画质更好，但延迟稍高。
我的建议：做视频通话用 CBP，做直播推流用 Main Profile。别为了兼容性去用 Baseline，那玩意儿太老了，画质差。
Level 限制了分辨率、帧率和码率的上限。比如 Level 3.1 支持 720p@30fps，Level 4.0 支持 1080p@30fps。你想想看，如果你设了个 Level 3.0，却想推 1080p，编码器会直接报错。
2. GOP 和 IDR 间隔
GOP（Group of Pictures）就是两个关键帧之间的帧组。IDR 帧是关键帧中的关键帧——它一出现，解码器就完全刷新。
我在项目中遇到过一个问题：GOP 设得太长（比如 5 秒），结果用户切换网络时，画面卡了 5 秒才恢复。后来我把 IDR 间隔强制设为 2 秒，配合丢包重传，体验好多了。
注意：IDR 帧太大，频繁插入会浪费带宽。一般建议 1-3 秒一个 IDR，具体看你的网络抖动情况。
3. QP 和参考帧数量
QP（Quantization Parameter）控制压缩程度。QP 越小，画质越好，码率越高。QP 越大，画质越差，码率越低。WebRTC 里通常让编码器自动调整 QP，但你可以设一个范围，比如 [18, 42]。
参考帧数量也很关键。参考帧越多，压缩效率越高，但解码延迟也越大。实时通信场景，我一般限制在 2-3 帧。
// WebRTC 中 H.264 编码器配置示例
webrtc::VideoCodec codec;
codec.codecType = webrtc::kVideoCodecH264;
codec.SetSimulcastByResolution(false);
// H.264 特定参数
webrtc::CodecSpecificInfoH264 h264_info;
h264_info.packetization_mode = webrtc::H264PacketizationMode::NonInterleaved;
h264_info.profile = webrtc::kProfileConstrainedBaseline;
h264_info.level = webrtc::kLevel3_1;
// GOP 控制
codec.SetFrameDropEnabled(true);
codec.SetKeyFrameInterval(2000); // 2秒一个关键帧
// QP 范围
codec.SetQpMin(18);
codec.SetQpMax(42);二、VP8 编码调优：Google 的亲儿子，别浪费了
VP8 是 WebRTC 的“原生”编码器，Chrome 和 Android 上都有硬件加速。说实话，VP8 的参数比 H.264 少，但调起来反而更讲究。
1. CPU 预设与实时性
VP8 有个 cpu_used 参数，控制编码器的“努力程度”。值越小，编码越精细，CPU 消耗越高。值越大，编码越快，但画质下降。
我记得有一次做移动端优化，手机发热严重。后来把 cpu_used 从 -5 调到 0，CPU 占用降了 30%，画质只损失了一点点。嗯，这里要注意：移动端建议用 0 到 2，桌面端可以用 -5 到 -2。
3. 自适应量化
VP8 支持自适应量化（Adaptive Quantization），它会根据图像复杂度动态调整 QP。简单区域（比如纯色背景）用高 QP，复杂区域（比如人脸）用低 QP。
这个功能默认是开启的，但我建议你检查一下。我在一个项目中遇到过自适应量化过度，导致人脸区域出现块效应。后来手动限制了 QP 变化幅度，问题就解决了。
4. 帧类型决策
VP8 的帧类型决策比 H.264 更灵活。它支持“黄金帧”（Golden Frame）和“交替参考帧”（AltRef Frame），用于场景切换时的快速恢复。
说白了，VP8 在丢包场景下比 H.264 更抗造。但代价是码率波动更大。如果你做的是弱网环境下的通话，VP8 可能是更好的选择。
// VP8 编码器调优示例
vpx_codec_enc_cfg_t cfg;
vpx_codec_enc_config_default(vpx_codec_vp8_cx(), &cfg, 0);
// CPU 预设：0 表示平衡模式
cfg.g_profile = 0;
cfg.rc_target_bitrate = 500; // 500 kbps
// 自适应量化
cfg.rc_undershoot_pct = 50;
cfg.rc_overshoot_pct = 50;
// 帧类型决策：允许使用黄金帧
cfg.g_lag_in_frames = 1; // 延迟帧数，0 表示无延迟
cfg.rc_dropframe_thresh = 30; // 丢帧阈值三、码率控制策略：别让编码器“放飞自我”
码率控制是视频编码的“方向盘”。没有它，编码器要么疯狂输出导致网络爆炸，要么压缩过度画面糊成一片。
1. CBR vs VBR vs CRF
| 模式 | 特点 | 适用场景 |
|---|---|---|
| CBR（恒定码率） | 码率稳定，画质波动 | 实时通话、带宽受限 |
| VBR（可变码率） | 码率波动，画质稳定 | 直播推流、存储场景 |
| CRF（恒定质量） | 质量恒定，码率不可控 | 本地录制、后期处理 |
WebRTC 里默认用的是 CBR 的变种——GCC（Google Congestion Control）。它会根据网络带宽动态调整码率。说白了，就是网络好时多传点，网络差时少传点。
2. GCC 带宽估计
GCC 是 WebRTC 的“大脑”。它通过 RTP 包的到达时间、丢包率、延迟抖动等信息，估算出当前可用带宽。然后告诉编码器：“兄弟，你现在只能跑 500 kbps，别超了。”
我踩过一个坑：GCC 的带宽估计太保守，导致明明有 2 Mbps 的带宽，编码器只用了 800 kbps。后来调整了 trendline 滤波器的参数，带宽利用率提升了 30%。
避坑指南：我曾经把 GCC 的丢包阈值设得太低，结果网络稍微抖动一下，码率就骤降。建议丢包率阈值设为 5%-10%，别太敏感。
3. 动态码率调整实战
在实际项目中，我通常会在应用层再加一层码率控制。比如，检测到用户切换到 4G 网络时，主动降低目标码率。检测到 WiFi 信号弱时，强制切换到低分辨率。
// 动态码率调整伪代码
void OnNetworkChanged(NetworkQuality quality) {
int target_bitrate;
switch (quality) {
case HIGH:
target_bitrate = 1500; // 1.5 Mbps
break;
case MEDIUM:
target_bitrate = 800; // 800 kbps
break;
case LOW:
target_bitrate = 300; // 300 kbps
break;
}
encoder.SetTargetBitrate(target_bitrate);
}总结一下：码率控制不是编码器一个人的事。它需要编码器、网络估计、应用层三方配合。你想想看，如果编码器自己在那猛输出，网络层却传不出去，那画面卡顿就是必然的。
好了，这一章的内容就到这里。H.264 的参数、VP8 的调优、码率控制的策略，这三块东西你吃透了，WebRTC 视频编码这块基本就稳了。下一章咱们聊聊更进阶的话题——但今天先消化这些吧。