实时视频流滞后

Question

我的应用程序使用实时视频流，实时向用户显示一些演示文稿（！）。我有一台ip摄像头和视频编码器安装了我的电脑和一台为视频提供服务的服务器（ustream）。

服务视频和真实视频之间的延迟时间接近30秒。

这个问题对我的情况来说是微不足道的问题。但在我的情况下，所有用户必须同时看到相同的屏幕。 （没有滞后）就像一个实时视频游戏！

第一个问题是用户之间存在滞后（接近4秒！）的原因？ 第二个问题我怎样才能将这个滞后时间变为零或低滞后？

编辑：

Stream Provider是ustream.com，h264编码360p 750fps

Answer 1

如前所述，您收集的内容与用户看到的内容之间的延迟来自：

1. 传感器延迟。也许微秒
2. 编码器延迟。通常我们可以说不到100毫秒
3. 编码器软件延迟。如果这件作品没有破损，则小于100毫秒
4. 编码器到服务器的网络延迟。这里它可能偏离30毫秒到1000毫秒。如果有任何平衡器，请添加更多500毫秒
5. 内部服务器延迟。这可能是10毫秒到500毫秒。例如，如果服务器不信任编码器并解压缩和重新排序帧，则它将高达200-500毫秒
6. 流媒体协议延迟。如果它是rtmp，它可能几乎是0毫秒，HLS它将高达30 000毫秒。
7. 服务器 - 客户端网络延迟。 UDP提供较小的延迟（当然，这里要讨论许多问题），TCP提供更大的延迟。
8. 客户端软件延迟
9. 客户端解码器延迟
10. 客户端视频子系统延迟。如果您还不知道，但是当您在现代PC上按键时，跨越海洋和返回的时间比在显示器上绘制新信件所需的时间短。

所以我希望你能看到你需要优化多少东西才能使延迟小于1000毫秒。

我们已经实施了WebRTC服务器，从IP摄像头到服务器以及从服务器到浏览器都实现了大约300毫秒的延迟。因此常规普通浏览器在300毫秒后获取视频。视频从莫斯科转移到阿姆斯特丹并返回。

WebRTC确实是一种很好的方式来满足您的需求。

Answer 2

让我回答你的问题：

“为什么用户之间会有延迟（接近4秒！）？”

这主要是因为播放器中的用户之间没有时间同步，这不是一件容易的事。

首先让我们考虑一下当用户在UTC时间启动视频时会发生什么：

1. 用户从服务器获取流信息（可以是RTMP连接或m3u8 / dash清单）
2. 然后，用户开始接收视频块，每个块从keyframe开始 - 这是其他帧所引用的完整图片。只能从关键帧开始播放块。
3. 当完成视频块时，将从相应的关键帧播放另一个。

这或多或少会发生什么，无论它是什么类型的流媒体。

所以现在，当其他一些用户，几秒钟后，启动相同的流 - 他们将打开相同的块（因为这是“最新的”）并从相同的关键帧开始，但这次它已经有几秒钟了。 / p>

你观察的4秒意味着ustream块可能是那么精确的长度。

“我怎样才能将这个滞后时间变为零或低滞后？”

我必须声明我从未尝试过在多个用户之间同步视频，但我确实曾与同事争论过这是可能的，这是我采取的方法：

1. 首先，您需要同步用户之间的时间（了解计算机时钟与绝对时间之间的偏差，here's a good question on this
2. 播放器将告诉您当前的视频时间，您需要计算与服务器时间的偏差。
3. 播放和服务器时间之间的时间偏差是您应暂停视频的时间。

如果一切顺利，所有用户都会在完全相同的时间（或至少低于单帧持续时间的40毫秒）看到视频。