据我所知，GOP 大小应该与可观察到的视频延迟（延迟）相关。例如，如果 GOP 大小为 2，则视频延迟应接近 2 秒，依此类推，至少使用 CBR。但是，当我将 GOP 大小设置为 2，将流发布到摄取服务器，使用此流并测量延迟时，它在 0.8-1.2 秒之间，而不是 2+ 秒，例外情况除外。增加 GOP 大小会导致相同的结果：GOP 4 的延迟接近 2.5 秒，而不是 4 秒。
我如何测量这种延迟：使用 OBS 从网络摄像头流式传输工作秒表以摄取服务器，并计算秒表值与从摄取消耗的流中显示的值之间的差异。为了获得更高的测量精度，我使用秒表和在一个视野中摄取的实际图像制作了一张照片。
我的 OBS 设置是here:
您能否建议，为什么我会得到这样的结果？我关于 GOP 大小和视频延迟之间相关性的陈述有多相关？也许，像“zerolatency”这样的 H264 设置会带来一些魔力？
谢谢。
【问题讨论】：
对于流媒体，每组图片由IPPPPPP 组成——一个关键帧，后跟一些秒数的 P 帧。原则上，编码器不需要引起任何给定长度的延迟。当您发送恒定比特率流时，会发生延迟，因为编码器有时必须以较低或较高的比特率重新编码某些帧。
【讨论】：
IPPP...，然后才将此数据发送到上游（ffmpeg、OBS 等），不是吗？无论如何，播放器必须等待至少两秒钟才能接收到第一个 I 帧并显示一些图片而不是“黑色矩形”。所以，我不明白，我的假设在哪里出错。也许，GOP=2 的意思不是“2 秒的实时”，而是别的意思？
PBPB... 的内容并立即将该数据发送到“上游”，而无需等待 I 帧出现。处理了它。但是，当播放器开始消费流（RTMP；零缓冲区大小，如ffplay -fflags nobuffer 或具有相同设置的 Flash 播放器）时，它无法开始播放，直到收到 I 帧，所以播放器可能会在最坏的情况下等待 %GOP size% 秒接收第一个 I 帧？