直播推流参数检查
画面糊、推流卡，往往是码率和上行带宽没对上。把分辨率、帧率、码率和实际上传速度一起填进来，看余量还剩多少。
分辨率
编码
兼容性最好，所有平台都吃，同画质码率最高
上行占用 32%；建议至少留 25% 余量给重传、协议头和同屋其他设备。
bpp 低于 0.04 时细节基本保不住；0.05 到 0.09 是 H.264 直播的常见区间。H.265 和 AV1 可以用更低的 bpp 达到相近观感。
平台常见码率区间
| 平台 | 常见区间 | 和当前设置相比 |
|---|---|---|
| B 站直播 | 4,000 – 8,000 kbps | 高于区间 |
| 抖音直播 | 4,000 – 8,000 kbps | 高于区间 |
| 视频号直播 | 3,000 – 6,000 kbps | 高于区间 |
| YouTube Live | 4,500 – 9,000 kbps | 在区间内 |
| Twitch | 4,500 – 8,500 kbps | 高于区间 |
区间只反映量级，各平台会随活动和套餐调整。以推流后台显示的推荐值为准，这里用来判断「是不是差了一个数量级」。
推流参数怎么配
先把上行测准。用测速工具在直播同一时段、同一网络下测三次，取最低值，再乘 0.75 作为可用的推流预算。比如实测 40 Mbps，预算就是 30 Mbps，而不是把 40 全部用掉——TCP 重传、协议头和同屋设备都要占。
码率和分辨率要匹配。1080p60 用 H.264 大约 6 到 9 Mbps，1080p30 大约 4 到 6 Mbps，720p30 大约 2.5 到 4 Mbps。码率给低了，编码器会把细节抹平，暗部和快速运动先糊；给高了，平台可能二次压缩，观众端反而不见得更清楚。
帧率是第二个杠杆。运动不多时把 60 帧降到 30 帧，带宽需求大约降到六成，省下来的码率可以换更高的分辨率或更低的压缩。游戏、体育、舞蹈这类快速运动才值得上 60 帧。
关键帧间隔设 1 到 2 秒。间隔太长，新观众进来要等半天才出画面；太短又会挤占码率。编码器预设优先选硬件编码（NVENC、QSV、VideoToolbox），CPU 占用低、掉帧少，画质差距在直播码率下通常看不出来。
常见问题
为什么上传 30 Mbps，推 8 Mbps 还是卡？
运营商说的带宽是峰值，实际稳定上行往往只有标称的六七成；RTMP 走 TCP，丢包会触发重传和拥塞控制，占用会继续上升。再加上路由器、无线回程和同屋其他设备，真正能稳定留给推流的余量比想象中少。建议按「所需码率不超过实测上行的 75%」来配。
1080p60 到底该推多少码率？
H.264 大约 6 到 9 Mbps，H.265 可以降到 4 到 6 Mbps。具体还要看画面复杂度：静态讲课 5 Mbps 就够，高速运动或满屏树叶、水花、噪点就需要更高。码率低于推荐值六成时，暗部和快速运动会出现明显的块状噪点。
帧率越高越耗带宽吗？
是。同样分辨率下 60 帧的数据量大约是 30 帧的两倍，但实际编码器不会线性增长，通常高帧率码率需求是 1.5 到 1.8 倍。如果不做游戏或运动直播，30 帧更划算，省下的带宽可以用来提画质。
关键帧间隔设多少？
直播一般 1 到 2 秒。间隔太短，关键帧占比高、同码率下画质变差；太长，新观众进入或网络卡顿恢复时要等更久才能出画面。高帧率（50/60fps）建议取 1 秒或 2 秒，对应 GOP 60 或 120 帧。
RTMP 和 SRT 怎么选？
平台只收 RTMP 时没得选。自己的链路（比如把现场信号传到导播台）优先 SRT：基于 UDP，自带重传和缓冲，弱网下比 RTMP 稳，代价是多占一点带宽、延迟可调。WHIP/WebRTC 延迟最低，但码率控制不如 RTMP 精细。
为什么平台推荐的码率比我算的低？
平台要兼顾大多数观众的解码能力和 CDN 成本，给的往往是「够看」而不是「最好」。超过平台上限的部分会被二次转码，画质不会更好，反而白占上行。先按平台区间推，确认观众端清晰度后再说。