4、推流参数调优：编码器选择、码率控制、GOP大小设置、关键帧间隔
推流卡顿，很多时候不是网络不行，而是参数没调对。我见过太多人拿着默认配置就开推，结果画面一复杂就卡成PPT。这一章，咱们把编码器、码率、GOP、关键帧这几个核心参数掰开揉碎讲清楚。
核心结论先放这：没有万能参数组合。你得根据你的场景——是直播游戏、会议还是监控——来动态调整。但有一条铁律：编码器决定上限，码率控制决定稳定性，GOP和关键帧决定延迟与兼容性。
4.1 编码器选择：软编码还是硬编码？
编码器是推流的起点。选错了，后面再怎么调都白搭。我个人习惯把编码器分成两类：软件编码器（x264、x265）和硬件编码器（NVENC、QSV、AMF）。
| 特性 | 软件编码器 (x264) | 硬件编码器 (NVENC) |
|---|---|---|
| CPU占用 | 高（多核满载） | 低（专用芯片） |
| 画质/码率比 | 优秀（同码率更清晰） | 良好（略逊于软件） |
| 延迟 | 可控（取决于preset） | 极低（适合直播） |
| 适用场景 | 推流端CPU有富余 | 游戏直播、高帧率场景 |
我在项目中遇到过一个问题：用x264推1080p60的游戏画面，CPU直接飙到90%以上，游戏本身都开始掉帧。后来换成NVENC硬编码，CPU占用降到20%，画面质量也没差太多。说白了，如果你推流的同时还在做其他计算密集型任务，硬编码是更稳妥的选择。
我的建议：直播场景优先用硬件编码器（NVENC或QSV），录播或点播场景用x264。如果非要用x264推流，preset选"veryfast"或"faster"，别选"slow"——那会把你CPU吃干抹净。
FFmpeg命令行示例：
# 软件编码（x264）
ffmpeg -i input.mp4 -c:v libx264 -preset veryfast -b:v 2000k -f flv rtmp://server/live/stream
# 硬件编码（NVENC）
ffmpeg -i input.mp4 -c:v h264_nvenc -preset p4 -b:v 2000k -f flv rtmp://server/live/stream4.2 码率控制：CBR、VBR还是CRF？
码率控制模式，说白了就是决定「码率怎么花」。三种主流模式各有千秋，我直接给你对比表：
| 模式 | 特点 | 码率波动 | 推荐场景 |
|---|---|---|---|
| CBR（恒定码率） | 码率始终稳定在设定值 | 几乎无波动 | 直播、会议、弱网环境 |
| VBR（可变码率） | 复杂场景码率高，简单场景码率低 | 波动较大 | 点播、本地录制 |
| CRF（恒定质量） | 以质量为基准，自动分配码率 | 波动最大 | 离线转码、存档 |
你想想看，直播场景最怕什么？码率突然飙升导致网络拥堵，然后卡顿。所以直播推流我几乎只用CBR。VBR虽然画质更好，但码率波动会让接收端缓冲来不及调整。CRF就更不用说了——它根本不管码率上限，只追求画质，推流时很容易把网络撑爆。
避坑指南：我曾经在一个直播项目中用了VBR，结果游戏团战场景码率瞬间从2Mbps跳到6Mbps，观众端直接卡死。后来改成CBR + 合理的码率值，问题才解决。记住：直播用CBR，点播用VBR，离线用CRF。
FFmpeg中CBR的典型配置：
# CBR推流（关键参数：-b:v、-minrate、-maxrate、-bufsize 设为相同值）
ffmpeg -i input.mp4 -c:v libx264 -b:v 2000k -minrate 2000k -maxrate 2000k -bufsize 2000k -f flv rtmp://server/live/stream4.3 GOP大小设置：别让解码器等太久
GOP（Group of Pictures）大小，就是两个关键帧之间的帧数。这个参数直接影响两个东西：延迟和错误恢复速度。
为什么这么说？GOP越大，压缩效率越高（因为P帧和B帧可以跨帧参考），但一旦出现丢包或花屏，解码器必须等到下一个关键帧才能恢复画面。你想想看，如果GOP设成10秒，观众花屏了要等10秒才能恢复——这体验能好吗？
| GOP大小 | 压缩效率 | 错误恢复时间 | 推荐场景 |
|---|---|---|---|
| 1秒（30帧） | 低 | <1秒 | 强交互直播（游戏、会议） |
| 2秒（60帧） | 中等 | ~2秒 | 常规直播 |
| 4秒（120帧） | 高 | ~4秒 | 点播、监控 |
我个人习惯：直播场景GOP设2秒。太短了压缩效率低，太长了恢复慢。如果是游戏直播或视频会议这种对延迟敏感的，可以缩到1秒。
小技巧：GOP大小在FFmpeg中用-g参数设置。比如-g 60表示每60帧一个关键帧（假设帧率30fps，就是2秒）。别忘了同时设置-keyint_min，防止场景切换时强制插入关键帧导致码率尖峰。
# GOP设为2秒（30fps下就是60帧）
ffmpeg -i input.mp4 -c:v libx264 -g 60 -keyint_min 60 -f flv rtmp://server/live/stream4.4 关键帧间隔：场景切换时的救命稻草
关键帧（I帧）是GOP的起点。它不依赖任何其他帧，可以独立解码。所以关键帧的插入策略，直接决定了推流的「抗丢包能力」。
默认情况下，编码器会按固定间隔插入关键帧（就是GOP大小）。但有个问题：如果画面长时间不变（比如PPT翻页），固定间隔可能不够用。一旦画面突然变化，而关键帧还没到，解码器就只能靠P帧慢慢恢复——这中间会有明显的模糊或马赛克。
解决办法是开启场景检测（scenecut）。编码器会在检测到画面剧烈变化时，主动插入一个关键帧。这样既能保证压缩效率，又能快速响应场景切换。
关键帧间隔的黄金法则：
- 固定间隔：保证最坏情况下的恢复时间（比如每2秒一个I帧）
- 场景检测：在画面切换时额外插入I帧，减少模糊期
- 强制关键帧：推流端可以主动发一个关键帧请求（比如用RTMP的FCPriority）
FFmpeg中场景检测默认是开启的（scenecut=40）。你可以调整它的灵敏度：
# 开启场景检测（默认值40，数值越小越敏感）
ffmpeg -i input.mp4 -c:v libx264 -g 60 -sc_threshold 40 -f flv rtmp://server/live/stream
# 关闭场景检测（完全按固定间隔）
ffmpeg -i input.mp4 -c:v libx264 -g 60 -sc_threshold 0 -f flv rtmp://server/live/stream注意：场景检测太灵敏也不行。我曾经遇到一个案例，摄像头画面因为灯光闪烁被误判为场景切换，结果每秒钟插入好几个I帧，码率直接翻倍。后来把sc_threshold调到60才稳定下来。嗯，这里要记住：场景检测是双刃剑，要根据实际画面内容调整阈值。
4.5 实战组合：一套可复用的推流参数模板
说了这么多，直接给你一套我常用的推流参数模板。你可以根据自己的场景微调：
| 场景 | 编码器 | 码率控制 | GOP | 关键帧 | FFmpeg命令 |
|---|---|---|---|---|---|
| 游戏直播 | h264_nvenc | CBR 6000k | 2s (60帧) | scenecut=40 | -c:v h264_nvenc -b:v 6000k -minrate 6000k -maxrate 6000k -bufsize 6000k -g 60 -sc_threshold 40 |
| 视频会议 | libx264 | CBR 1500k | 1s (30帧) | scenecut=50 | -c:v libx264 -b:v 1500k -minrate 1500k -maxrate 1500k -bufsize 1500k -g 30 -sc_threshold 50 -preset veryfast |
| 监控摄像头 | libx264 | CBR 2000k | 4s (120帧) | scenecut=0 | -c:v libx264 -b:v 2000k -minrate 2000k -maxrate 2000k -bufsize 2000k -g 120 -sc_threshold 0 -preset medium |
这套模板我用了很久，基本覆盖了主流场景。你拿去用的时候，记得根据实际网络带宽和画面复杂度调整码率值。比如游戏直播，如果画面运动剧烈，6000k可能还不够，可以试试8000k。但别超过你的上行带宽上限——否则卡顿会教你做人。
最后一个小建议：调参的时候，别一次改太多。每次只改一个参数，观察效果，再改下一个。我见过有人一口气改了编码器、码率、GOP、关键帧四个参数，结果出问题了都不知道是哪个引起的。嗯，调参这事，慢就是快。