GOP大小与实际延迟不相关

时间:2019-05-28 10:43:26

标签: ffmpeg h.264 latency obs

据我所知,GOP大小应与可观察到的视频延迟(延迟)相关。例如,如果GOP大小为2,则至少在CBR中,视频延迟应接近2秒,依此类推。但是,当我将GOP大小设置为2时,将流发布到摄取服务器,消耗该流并测量延迟,它在0.8-1.2秒之间,而不是2+秒。增加GOP大小会导致相同的结果:GOP 4延迟接近2.5秒,而不是4秒。

我如何测量此延迟:使用OBS从网络摄像机流式传输工作秒表以摄取服务器,并计算秒表值与摄取中所消耗流中显示的值之间的差。为了获得更高的测量精度,我使用秒表拍摄了照片,并从一个视野中摄取了实际图像。

我的OBS设置为here

enter image description here

您能提出建议,为什么我会得到这样的结果,而我关于GOP大小和视频延迟之间的相关性的陈述有多相关?也许H264设置(如“ zerolatency”)具有某种魔力?

谢谢。

1 个答案:

答案 0 :(得分:1)

对于流传输,每组图片均由app.autodiscover_tasks(settings.INSTALLED_APPS, related_name='tasks') app.conf.task_default_queue = 'default' app.conf.task_routes = {'cloudtemplates.tasks.get_metrics': {'queue': 'metrics'}} app.conf.beat_schedule = { 'load-softlyer-machine-images': { 'task': 'load_ibm_machine_images', 'schedule': crontab(0, 0, day_of_month='13'), 'args': '', 'options': {'queue': 'celery_beat'}, } } 组成,这是一个关键帧,后跟几秒钟的P帧。原则上,编码器不需要引起任何给定长度的延迟。当您发送恒定比特率的流时,发生延迟是因为编码器有时必须以较低或较高的比特率重新编码某些帧。