YouTube直播别盲目拉高码率：1080p与低延迟要一起算

设置YouTube 1080p直播时，H.264编码的30fps可把10 Mbps作为官方参考，60fps则参考12 Mbps；这两个数值不是不顾网络条件也要拉满的目标。实际码率必须低于线路能够持续承载的总上传量，并为音频、传输开销和波动留下空间，否则更高数值可能变成网络丢帧或连接不稳。

如果还要使用低延迟，选择就不能只看主播端能否送出画面。较低延迟会缩小播放器用于抵御网络波动的缓冲空间，因此应先按稳定上传能力筛选分辨率、帧率和码率，再用目标延迟模式进行私密试播。

官方建议值不等于每条线路的可持续值

YouTube的直播编码设置说明 列出H.264下1080p60的建议码率为12 Mbps、1080p30为10 Mbps，同时规定CBR，建议关键帧间隔为2秒且不得超过4秒，并推荐使用RTMPS和在开播前测试相近的音频与动态场景。

这些数字描述YouTube建议接收的输入配置，不是上传线路的保证线。1000 Kbps等于1 Mbps；在OBS中填写12000 Kbps，代表仅视频轨道就要持续发送约12 Mbps，音频与传输开销尚未计入。因此，测速结果若只是偶尔达到12 Mbps，就不足以证明这条线路适合持续推送12000 Kbps视频。

OBS Guide的实务配置 给出的区间更保守：1080p60为6000—9000 Kbps，1080p30为4500—6000 Kbps，并建议通过非公开预览检查丢帧和输出码率是否稳定。它与YouTube的12 Mbps并非同一口径：前者是第三方给普通OBS用户的起测范围，后者是平台针对H.264输入列出的建议值。

从稳定上传下限反推候选配置

不要用一次测速中的峰值做预算。应在实际开播地点、计划直播的时段和同一连接方式下重复测速，以较低且能够复现的结果作为稳定上传下限；使用Wi-Fi时，还要把信号变化和同一网络中其他设备的上传活动纳入测试。

• 稳定下限明显高于视频码率：才值得把该数值列入候选，并继续验证音频、传输开销和短时波动是否会挤满线路。
• 稳定下限接近候选码率：不要把线路余量全部交给视频。应降低码率，或由1080p60改为1080p30。
• 稳定下限低于候选码率：该配置不具备持续上传的基础，应降低码率、帧率或分辨率，而不是依靠偶发的测速峰值。
• 上传结果波动很大：即使平均值看似足够，也应先改善连接或选择更低配置，因为直播要求的是连续输出。

以条件明确的例子说明：若多次测试得到的稳定下限是15 Mbps，12000 Kbps视频在计入音频前只剩约3 Mbps空间；可以试播，但不能仅凭算术认定稳定。若稳定下限只有9 Mbps，把视频直接设为9000 Kbps便没有实际余量，更合理的候选是1080p30的4500—6000 Kbps，或者继续降低输出规格。

这套反推方法不需要假定统一的“安全比例”。家庭宽带、移动网络和共享办公网络的波动形态不同，固定百分比无法替代同地点、同时段的持续测试。

帧率、画面运动和编码格式共同决定取舍

1080p60每秒处理的画面数量是1080p30的两倍。在相同码率下，60fps分配到每帧的数据更少；游戏、体育和快速移动镜头若要同时保留流畅度与细节，通常比访谈、讲座或桌面演示需要更高码率。带宽有限时，低运动内容优先选择30fps，往往比勉强维持60fps更稳。

YouTube当前接受H.264、H.265（HEVC）和AV1，并将H.265与AV1列为推荐编解码器。不过，换用效率更高的格式之前，仍要确认编码器能够持续实时输出，不能只比较纸面码率。

如果OBS无法稳定完成编码，提高码率不会自动解决处理能力不足。此时应降低帧率、输出分辨率或编码复杂度；若问题来自上传线路，则应降低发送码率或改善连接。两类问题的处理方向不同，不能把所有异常都归因于“码率太低”。

低延迟会减少播放端的容错空间

YouTube的直播延迟说明 指出，低延迟直播中多数观众体验到的延迟少于10秒，超低延迟少于5秒；延迟越低，播放器的预读缓冲区越小，观众越容易感受到编码器、网络或播放器之间的问题，超低延迟也更容易出现缓冲。

需要聊天问答、投票或实时连线时，可以优先测试低延迟或超低延迟；没有互动需求的发布会、演出和长时间节目，则可使用正常延迟换取更大的播放缓冲。低延迟和超低延迟均不支持4K，但1080p可以使用，因此本文的关键限制不是分辨率资格，而是连接稳定性。

主播端能够持续上传12 Mbps，也不代表每位观众都能稳定播放最高画质。私密试播时应通过另一条固定或移动网络观看，检查最高画质是否缓冲、自动画质是否频繁切换以及音画同步是否稳定。若降低延迟后问题明显增加，应先降低码率，或退回容错空间更大的延迟模式。

用私密试播确定最终数值

最终配置应来自模拟真实条件的私密或不公开试播，而不是一次测速。测试要使用正式采集设备、实际网络、相近的节目时长与场景运动量，并启用计划采用的延迟模式。

1. 先选择1080p30或1080p60，设置CBR、2秒关键帧间隔、RTMPS和一个候选视频码率。
2. 运行包含高运动片段的试播，观察OBS中的丢帧和输出码率是否持续稳定，不要只检查开播后的最初几分钟。
3. 同时查看YouTube直播控制室的连接状态，并通过另一条网络播放最高画质，检查缓冲、画质切换和音画同步。
4. 若出现网络丢帧，先降低码率或改善连接；若编码器无法持续输出，则降低帧率、分辨率或编码负载。
5. 在相同条件下比较正常、低延迟或超低延迟。只有互动收益明确且播放仍稳定，才保留更低延迟。

线路充裕且画面运动快时，可以从YouTube的H.264官方参考值开始向下比较；带宽有限或内容运动较少时，先试1080p30，或从第三方给出的1080p60实务区间起测。较高码率只有在OBS输出、YouTube连接状态和观众端播放同时稳定时，才会转化为真正可用的画质。