一场活动直播的延迟，不是平台单方面决定的，而是推流、编码、中转、分发每一环叠加出来的。这篇从技术角度拆开，方便要调延迟的同学对照，也讲讲我们怎么定位延迟的大头在哪。
延迟从哪来
摄像机采集有采集延迟，编码器压帧有编码延迟，推流到服务器有网络传输延迟，中转转推再叠加一跳，而观众端播放器自身还带缓冲。每一环几秒，加起来就是观众看到的延迟。想压延迟，得先知道哪环是大头，别盲目调设备。
协议决定下限
RTMP、SRT 这类推流协议，端到端延迟通常在几秒到十几秒；WebRTC 能压到一秒以内，但对网络和服务器要求高。我们按活动对同步的要求选协议：要互动的用低延迟方案，纯展示的用稳一点的协议，不盲目追低延迟，低延迟往往意味着更容易卡，得不偿失。RTMP 虽然稳，但延迟下限就在几秒这一档，想更低得上 SRT 或 WebRTC，链路成本和运维难度都不同。
编码与 GOP
编码器的 GOP 长度和帧率设置，直接影响起播和延迟。GOP 太长，观众进直播间要等一个完整 GOP 才能出画，延迟就高；适当缩短 GOP，起播快、延迟低，但码率会略升。我们一般按活动类型调，互动场把 GOP 调短，展示场放宽，平衡起播和画质。GOP 太短也有代价，切片变多、编码负担上升，所以互动场取折中值，不盲目压得太短。
中转与 CDN
多平台分发时，中转服务器每转推一跳就多几秒；CDN 边缘节点离观众越近，末一段延迟越低——前提是节点选得近，离得远照样拖。我们把中转跳数尽量压少，并选离受众近的节点，末端一段不拖后腿。中转那台机器要稳，它一挂所有平台一起黑，所以中转机接独立不间断电源。
播放端缓冲
观众端播放器为了不卡，会预缓冲几秒，这部分延迟用户侧难改，只能靠服务端把前面的延迟压下来，给播放端留出余量。我们习惯在推流端把总延迟控制在一个目标值内，不让某一环失控，播放端缓冲才有空间。有些平台还强制带固定缓冲，这部分推流端改不了，只能认。
怎么测出大头
我们进场会跑一路样流，用手机逐端进直播间看起播和延迟，哪端慢就在哪环找原因。多数场次大头在播放端缓冲和中转跳数，先把这两块压下来，总延迟就降一大截。测样流这步不能省，凭感觉定参数，直播中才现原形，现场补救成本高。
压延迟的取舍
延迟越低，对上行、服务器、网络稳定性的要求越高，成本也越高。我们按「活动需不需要互动」来定目标延迟，够用就好，不为极低的数字堆设备。把采集、编码、协议、中转、CDN 五环都看一遍，延迟才压得有理有据，也压得稳。
摄行影像，专注直播技术与影像制作。
