Ffmpeg GOP大小与实际延迟无关

据我所知，GOP大小应该与可观察到的视频延迟（延迟）相关。例如，如果GOP大小为2，则视频中的延迟应接近2秒，依此类推，至少在CBR情况下。但是，当我将GOP大小设置为2时，将流发布到摄取服务器，使用此流并测量延迟，它在0.8-1.2秒之间，而不是2秒以上（例外）。增加GOP大小会导致相同的结果：GOP4的延迟接近2.5秒，而不是4秒

我如何测量这种延迟：使用OBS从网络摄像头将工作秒表流到摄取服务器，并计算秒表值和摄取消耗的流中显示的值之间的差异。为了获得更高的测量精度，我用秒表拍摄了一张照片，并在一个视野中拍摄了摄取的实际图像

我的OBS设置是：

你能告诉我，为什么我会得到这样的结果，我关于GOP规模和视频延迟之间相关性的陈述有多重要？也许，H264的设置，比如“zerolatency”会带来一些魔力

---

谢谢。

对于流媒体，每组图片都由

ippppp

组成——一个关键帧，后面是一些秒数的p帧。原则上，编码器不需要产生任何给定长度的延迟。当您发送恒定比特率流时，会发生延迟，因为编码器有时必须以较低或较高的比特率重新编码某些帧。

对于GOP=2，编码器必须使用摄像机的原始数据至少2秒钟才能生成

IPPP…

，然后才将此数据发送到上游（ffmpeg、OBS等），不是吗？在任何情况下，播放器都必须等待至少两秒钟才能接收到第一个I帧并显示一些图片，而不是“黑色矩形”。所以，我无法理解，我的假设哪里有错误。也许，GOP=2并不意味着“2秒的实时”，而是其他的意思？不，编码器只需要延迟前瞻参考帧的数量。不是一个完整的共和党。播放器延迟由缓冲区大小和协议决定。因此，例如，编码器生成类似于

PBPB…

的数据，并立即将该数据发送到“上游”，而无需等待I帧出现。处理好了。但是，当播放器开始使用流（RTMP；零缓冲区大小，如

ffplay-fflags nobuffer

或具有相同设置的flash播放器）时，它无法开始播放，直到收到I帧，所以播放器可能会在最坏情况下等待%GOP size%秒来接收第一个I帧？