YouTube直播延迟不是越低越好：低于5秒就要放弃4K

YouTube 的直播延迟说明写明：Low latency 下多数观众的延迟低于 10 秒，Ultra-low latency 下多数观众低于 5 秒；两档都不支持 4K，而 Ultra-low 更容易让观众遇到播放缓冲。需要 4K 画面时，选择 Normal latency；需要迅速接住观众提问时，才考虑 Ultra-low。

具体选择先看节目是否必须等待观众回应：不互动选 Normal，有投票等有限互动选 Low，实时问答选 Ultra-low。确定延迟档位后，再设定编码器的分辨率、帧率和码率，并核对开播地点实际可用的上传带宽。把延迟调低并不能弥补不稳定的推流；上传速度一旦波动，留给观众播放器维持连续播放的缓冲也会更少。

按互动节奏选择三个延迟档位

直播延迟是摄像机捕捉画面到观众看到画面之间的时间。播放器预先缓存一段直播视频，可以吸收传输速度的短暂变化；缩短等待时间，也就缩小了这段缓冲。因而延迟档位首先是节目节奏的选择，同时也是对播放稳定性的取舍。

• Normal latency：适合讲座、演出或画面展示等不需要根据聊天即时改变内容的直播。它支持全部直播分辨率和功能，观众端的缓冲风险也最低。
• Low latency：适合发起投票、偶尔读评论，但不必等某条回复才能继续的节目。主持人可以先完成一个段落，再处理观众反馈。
• Ultra-low latency：适合观众的问题会立即改变主持人下一句话或下一步动作的问答、对话。互动更紧凑，但网络波动对观看过程的影响也更明显。

投票不必自动归入最快的一档：若公布结果可以稍等，Low 已符合这种有限互动。反过来，实时问答也不意味着每位观众都会获得相同的等待时间；官方给出的是多数观众的情况，实际延迟仍会受观众网络和播放状况影响。节目若同时要求高分辨率展示与即时接话，应先决定哪一项更重要，再安排相应的直播环节。

在直播控制室设置，并先处理 4K 限制

使用编码器开播时，进入 YouTube Studio，选择“创建”并进入直播控制室；在对应直播的“直播设置”中找到“直播延迟”，再选择档位。用网络摄像头或手机直接开播的直播侧重互动，不能在这里手动指定延迟档位；找不到选项时，先确认自己采用的是哪种开播方式。

如果编码器送入的是 4K／2160p，YouTube 会把直播设为 Normal latency，无法通过切换选项获得低延迟的 4K 直播。需要观众快速回应，就应先选择低于 4K 的输入分辨率，再决定使用 Low 还是 Ultra-low；如果远景或细部展示更依赖 4K，Normal 才与这个画质要求相容。这项限制针对直播的输入设置，不能靠提高编码码率绕过。

直播控制室通常会自动识别编码器送入的分辨率与帧率。只有确实需要手动指定分辨率时，才需要创建自定义直播码并开启相应的手动设置。这样可以先在编码器里固定画面规格，再核对平台识别到的规格，避免把预期的 4K 直播误当成低延迟直播来规划。

把视频码率和上行余量放进同一张核对表

YouTube 的编码器设置说明分别列出 1080p 与 4K 在不同帧率、AV1／H.265 和 H.264 下的建议视频码率；它还建议立体声音频使用 128 Kbps、视频使用 CBR，关键帧间隔设为 2 秒且不超过 4 秒。下列视频码率取自对应的建议列，不能把 AV1／H.265 的数值直接套到 H.264 编码器上。

YouTube 的直播网络建议要求推流总码率不超过可用上传带宽，并建议额外留出 20% 余量；如果同时发送主备两路，两路都要计入。下面按单路推流、立体声音频计算，把视频与音频码率相加后乘以 1.2，并将所需上行向上取到一位小数：

• 1080p／30 fps：AV1 或 H.265 建议视频码率 10 Mbps，规划上行约 12.2 Mbps；H.264 建议 14 Mbps，规划上行约 17.0 Mbps。
• 1080p／60 fps：AV1 或 H.265 建议 12 Mbps，规划上行约 14.6 Mbps；H.264 建议 17 Mbps，规划上行约 20.6 Mbps。
• 4K／30 fps：AV1 或 H.265 建议 30 Mbps，规划上行约 36.2 Mbps；H.264 建议 42 Mbps，规划上行约 50.6 Mbps。
• 4K／60 fps：AV1 或 H.265 建议 35 Mbps，规划上行约 42.2 Mbps；H.264 建议 50 Mbps，规划上行约 60.2 Mbps。

这些上行数字是由建议码率算出的规划值，不是保证观众绝不缓冲的门槛。应比较的是开播地点实际可用的上传速度，而不是宽带套餐标称速度或下载测速结果；共享网络上的云端备份、文件上传也会占用这部分能力。若使用备用编码器同时发送第二路流，应先把第二路的码率加进总量，再计算余量。

平台会把收到的直播转成适合不同设备和网络的输出格式，因此表中的数值描述的是创作者送往 YouTube 的码率，并非每位观众都要下载同样的码率。编码格式也要以设备实际能稳定输出的格式为准：可用 AV1 或 H.265 时看对应列，使用 H.264 时看 H.264 列。更高帧率适合画面运动较快的节目，但从核对表可见，它也会提高建议码率和上行需求。

开播前按同一顺序检查

1. 先写下节目是否要等待观众回答，据此选择 Normal、Low 或 Ultra-low；若输入画面确定为 4K，就按 Normal 安排互动节奏。
2. 在编码器里确定分辨率、帧率、编码格式、视频码率与音频码率，再按单路或主备两路计算总上传量。不要只看画质选项，也不要只凭测速结果设定延迟。
3. 在正式开播的网络环境中测可用上行，并用接近正式节目的声音与动态画面试播。查看直播控制室的视频流状态和提示，同时从观众端确认播放是否连续。

若试播时推流不稳或观众频繁缓冲，先检查共享网络、编码码率和输入画面规格，再考虑是否保留最快的延迟档位。使用 OBS 时，OBS 上行带宽核算也可帮助对应编码器码率与实际可用带宽。最终应让互动速度、画质和持续上传能力符合同一场直播的条件。

相关阅读：

• OBS直播画面不稳？先按上行带宽反推码率
• YouTube直播越低延迟越容易卡：4K与互动只能先选一个
• YouTube直播别盲目拉高码率：1080p与低延迟要一起算