直播延迟与DVR回看：YouTube两份说明里的时间从哪里算起

YouTube Help把stream latency定义为摄像头捕捉事件到观众看到该事件之间的延迟。[1] 这条关系连接拍摄端与显示端，而DVR连接的是观众在一场直播中已经播放到哪里：文档说，它允许暂停、倒回和继续，继续时从暂停的位置播放。[2] 对直播服务的资料交接，两者虽然都涉及时间，却有不同的起点与终点。

延迟说明首先谈播放器的read-ahead buffer，也就是预先留存的播放数据。原页说，延迟越低，播放器可保留的预读缓存越少，并把预读缓存的数量称为直播延迟的主要来源。[1] 因而，拍摄事件与观众所见之间的间隔，不能只被写成某次网络故障：文档本身已把播放器预留的数据放进定义背景。这里整理的是平台文字，不是对任何直播间测得的延迟值。

网络变化又与这份预留数据发生联系。帮助页说，即使网络能够维持平均直播码率，网络拥堵及其他因素仍可能造成延迟。播放器通常会保留额外直播数据，以应对网速变化，这项功能在Stats for Nerds中名为Buffer Health。[1] “平均码率可以维持”与“过程完全不发生变化”不是同一个判断。资料若只有平均值，便不能据此删除文档所说的变化情形；Buffer Health在这里也不是本篇替观众实际读出的监测结果。

同页列出Normal、Low和Ultra-low三类延迟模式。Normal支持全部分辨率和直播功能，Low与Ultra-low则都不支持4K。[1] 这是文档列出的模式条件，不能因为两个名称都带low，就把它们与Normal视为只换了一个速度标签。另一条条件涉及直播入口：webcam和mobile的延迟无法在该页所述方式下设定。模式类别与入口条件同时存在，不能将三项名称扩写为每一种直播入口都能自由选择的清单。

DVR的时间范围则从已开始的直播向后看。帮助页明确，观众不能回到开播之前；直播超过十二小时，DVR可能受限或不可用，Apple TV、AirPlay与旧版本应用的限制更低，暂停后继续也受这些限制。[2] 这不是一条把拍摄与显示间隔设为十二小时的定义。十二小时在该段联系长直播的DVR可用范围，“可能受限”也不能改成每场直播一到该时长就必然相同地停止回看。

直播期间的回退，与完整录制可用又是两个条件。文档说，关闭DVR时，观众在直播中不能向后定位，但完整录制可用后仍可以观看。[2] 因而，一项“直播时不能回退”的描述没有自动排除后来观看录制的可能；反过来，录制后来存在也不证明当时每位观众具有同样的回看范围。帮助页还注明，webcam与mobile直播不支持关闭DVR，这项条件与上一页不能设定延迟的说明各自有明确对象。

若DVR状态在直播中改变，文档将影响范围限定为改变之后才开始播放的观众。[2] 这使资料交接还要保留观众的开始播放时间：同一场直播的状态变化，不能直接写成所有已经在场的人都同时得到新行为。本文只解释这些平台概念，没有更改直播、编码或网络设置，也没有保证商品展示完整、实际响应速度或录制必然可用。两页首次发布日期均未知，所述条件限定于此次读取的YouTube Help文字。