20、屏幕共享延迟优化：NACK/FEC机制、jitter buffer、低延迟编码配置
屏幕共享这个场景，说实话对延迟的要求比普通视频通话还要苛刻。你想想看，演示PPT翻页、展示代码、操作软件，如果延迟超过500ms，观众那边就会觉得「卡卡的」、「跟不上」。我自己做过好几个屏幕共享项目，踩过不少坑，今天就把延迟优化的三板斧分享给你。
一、延迟从哪来？先搞清楚敌人是谁
屏幕共享的延迟，说白了就是三个环节在捣乱：
- 编码延迟：把屏幕画面压缩成视频流，需要时间
- 网络传输延迟：数据包在网络上跑，遇到丢包还得重传
- 接收端缓冲延迟：为了对抗网络抖动，接收端要攒一批数据再播放
这三个环节互相影响。比如你为了降低编码延迟，用了更快的编码器，结果码率变大了，网络更容易丢包，反而更卡。嗯，这里要注意，优化是个系统工程。
核心原则：屏幕共享的延迟优化，本质是在「编码效率」和「抗丢包能力」之间找平衡点。
二、NACK/FEC：丢包了怎么办？
屏幕共享最怕丢包。丢一个关键帧，观众那边可能直接花屏好几秒。WebRTC 给了我们两把武器：NACK 和 FEC。
2.1 NACK 重传机制
NACK 的原理很简单：接收方发现丢包了，就发个消息告诉发送方「哥们，包 X 丢了，再发一次」。发送方收到后，从历史缓冲区里找到这个包重新发送。
我在项目中遇到过一个问题：屏幕共享时画面变化剧烈（比如全屏切换），NACK 请求会瞬间爆发。发送方忙着重传旧包，新包反而发不出去，形成恶性循环。
我的经验：NACK 请求不要无限制重传。设置最大重传次数（比如3次），超过就放弃。另外，发送方的历史缓冲区不要保留太久，300ms 以内的包才值得重传。
2.2 FEC 前向纠错
FEC 是另一种思路：发送方在发数据包的同时，额外发一些冗余包。接收方即使丢了一两个包，也能通过冗余包把原始数据算出来。说白了就是「多带点备胎」。
WebRTC 里 FEC 有两种模式：
- ULP FEC：基于 XOR 运算，冗余率固定，适合丢包率稳定的场景
- Flex FEC：更灵活，可以针对不同媒体类型配置不同的保护力度
我个人习惯在屏幕共享场景下，把 FEC 冗余率设置在 20%-30%。太低保护不够，太高浪费带宽。你想想看，屏幕共享的码率本来就高，再加 50% 的冗余，网络可能先扛不住了。
注意：FEC 不是万能的。如果丢包率超过 20%，FEC 的冗余包也会丢，这时候反而浪费带宽。我的建议是：丢包率 < 10% 用 FEC，> 10% 用 NACK，两者结合效果最好。
三、Jitter Buffer：让播放更平滑
网络是有抖动的。有时候 10ms 一个包，有时候 200ms 才来一个。如果没有缓冲，播放器就得跟着网络节奏忽快忽慢，用户体验极差。
Jitter Buffer 就是用来吸收这种抖动的。它把收到的包先存起来，等攒够了再按固定节奏播放。
3.1 静态 vs 动态
| 类型 | 原理 | 延迟 | 适用场景 |
|---|---|---|---|
| 静态缓冲 | 固定缓冲深度（如 100ms） | 固定，可预测 | 网络稳定的局域网 |
| 动态缓冲 | 根据网络抖动自动调整深度 | 可变，但更智能 | 互联网、移动网络 |
WebRTC 默认用的是动态 Jitter Buffer。它会实时统计网络抖动的方差，然后动态调整缓冲深度。网络好的时候，缓冲浅一点，延迟低；网络差的时候，缓冲深一点，防止卡顿。
我记得有一次做远程桌面产品，用户反馈「操作鼠标后，画面要等半秒才动」。查了半天，发现是 Jitter Buffer 设置得太保守了，缓冲深度达到了 400ms。后来我把最大缓冲深度限制在 150ms，延迟降下来了，偶尔丢一帧用户反而感觉不到。
关键参数：在 WebRTC 中，可以通过 RtpReceiver::SetJitterBufferMinimumDelay() 来设置最小缓冲延迟。屏幕共享场景，我建议设置在 50-100ms 之间。
四、低延迟编码配置
编码器是延迟的大头。一个配置不当的编码器，可能引入 200ms 以上的编码延迟。我们来逐个击破。
4.1 VP8/VP9 编码器
VP8 和 VP9 在 WebRTC 里用得很多。关键参数是 CPU_USAGE 和 NUMBER_OF_THREADS。
// VP8 低延迟配置示例
webrtc::VideoCodec codec;
codec.codecType = webrtc::kVideoCodecVP8;
codec.SetSimulcastConfig(/*numberOfSimulcastStreams*/1, /*simulcastStream*/...);
// 关键：CPU_USAGE 设为 -8（值越小越快）
codec.VP8().complexity = webrtc::VP8Complexity::kComplexityLower;
codec.VP8().numberOfTemporalLayers = 1; // 关闭时域分层
// VP9 类似
codec.codecType = webrtc::kVideoCodecVP9;
codec.VP9().complexity = webrtc::VP9Complexity::kComplexityLower;
codec.VP9().numberOfTemporalLayers = 1;
codec.VP9().interLayerPred = webrtc::InterLayerPredMode::kOff;
为什么关闭时域分层？因为屏幕共享的画面变化是离散的（翻页、点击），不像摄像头视频那样连续。时域分层反而会增加编码延迟，得不偿失。
4.2 H264 编码器
H264 在硬件编码器上表现更好。关键参数是 tune 和 profile。
// H264 低延迟配置（使用 x264 或硬件编码器）
// 关键：tune=zerolatency，关闭 B 帧
codec.codecType = webrtc::kVideoCodecH264;
codec.H264().profile = webrtc::H264Profile::kProfileBaseline;
codec.H264().frameDroppingOn = true;
codec.H264().keyFrameInterval = 2000; // 2秒一个关键帧
// 如果是硬件编码器，还要设置：
// encoder.SetRateControlMode(webrtc::RateControlMode::kCBR);
// encoder.SetTune(webrtc::Tune::kZeroLatency);
这里有个坑：H264 的 B 帧（双向预测帧）虽然压缩率高，但会引入至少 2 帧的延迟。屏幕共享场景，我建议直接用 Baseline Profile，关闭 B 帧。压缩率低一点没关系，延迟必须压下来。
避坑指南：我曾经在某个项目中用了 H264 High Profile，结果编码延迟飙到 300ms。后来改成 Baseline Profile，延迟降到 50ms 以内。虽然码率涨了 15%，但用户反馈「终于不卡了」。
4.3 关键帧间隔
屏幕共享的关键帧（I帧）间隔不能太长。因为屏幕内容变化是突变的，如果关键帧间隔太长，用户翻页后要等好几秒才能看到清晰画面。
我个人习惯把关键帧间隔设置在 1-2 秒。同时配合 requestKeyFrame() 接口，在检测到画面大面积变化时主动请求关键帧。
// 检测到画面变化超过 30% 时，主动请求关键帧
if (screenChangeRatio > 0.3) {
videoEncoder->RequestKeyFrame();
}
五、综合调优建议
说了这么多，最后给一套我常用的配置组合：
- 编码器：VP8 或 H264 Baseline，关闭 B 帧，CPU_USAGE 调最低
- FEC：开启 Flex FEC，冗余率 20%
- NACK：最大重传 3 次，历史缓冲区 300ms
- Jitter Buffer：最小延迟 50ms，最大 150ms
- 关键帧：间隔 1-2 秒，画面变化大时主动请求
这套配置在大多数网络环境下，能把端到端延迟控制在 150ms 以内。当然，具体数值还得根据你的实际网络情况微调。嗯，优化没有银弹，多测试、多观察才是王道。
最后说一句：屏幕共享延迟优化，说白了就是跟网络抖动赛跑。NACK/FEC 是跑鞋，Jitter Buffer 是缓冲垫，编码配置是发动机。三样都调好了，才能跑得又快又稳。