实时视频流延迟

Question

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

提供视频和真实视频之间存在接近 30 秒的延迟时间。

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

第一个问题是为什么用户之间存在延迟（近 4 秒！）？ 第二个问题我怎样才能让这个滞后时间为零或低滞后？

编辑：

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

Answer 1

如前所述，您在发生的事情和用户看到的内容之间的延迟收集自：

1. 传感器延迟。也许是微秒
2. 编码器延迟。通常我们可以说不到 100 毫秒
3. 编码器软件延迟。如果这块没有坏，则小于 100 ms
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. 视频块完成后，将从相应的关键帧播放另一个视频块。

这或多或少会发生，无论是哪种流媒体。

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

您观察到的 4 秒意味着 ustream 块可能就是那个确切的长度。

“我怎样才能让这个延迟时间为零或低延迟？”

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

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

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