寻找电视捕获 RTMP 延迟的瓶颈

Posted 2023-02-25

【中文标题】寻找电视捕获 RTMP 延迟的瓶颈

【英文标题】：Finding the bottleneck on TV capture RTMP latency

【发布时间】：2017-05-09 05:00:00

【问题描述】：

我正在尝试将电视捕获从一台计算机本地流式传输到另一台计算机，但我的延迟比我想要的要高。

我的设置是 12GB、i5 x4 3.2ghz、Geforce 970，带有 Elgato HD60 Pro 采集卡。这台机器正在运行一个安装了 nginx+RTMP (https://github.com/arut/nginx-rtmp-module) 的 Ubuntu 实例。

它带有捕获/流媒体软件，可让您调整带宽+分辨率。它设置为流式传输到rtmp://192.168.1.200/capture 的本地 RTMP。

在我的接收机器上，我尝试过使用 VLC（开放网络）和 FFPLAY（ffplay -fflags nobuffer rtmp://192.168.1.200/capture -loglevel verbose）。

FFPLAY 的延迟比 VLC 少，考虑到nobuffer 标志，这似乎是有道理的。但是，在我看到正确的更新之前仍然需要大约 2-3 秒。

捕获预览的响应时间几乎是即时的（可能约为 100 毫秒） FFPLAY 流的响应时间在 2-3 秒之间

我想这意味着 Elgato 和 RTMP 服务器之间或 RTMP 服务器和我的 ffplay 流之间或两者之间存在瓶颈。

我尝试过的事情：

在 1.00 到 8.00 之间增加捕获软件的 Mbps 将捕获质量从最高降低到最低 将捕获分辨率从 1080 降低到 720 到标准 将帧率从 60fps 降低到 30fps 使用 FFPLAY 代替 VLC

注意：我的 RTMP NGINX 配置中没有特殊选项。这是一个标准的live on，差不多就是这样。

诊断问题出在哪里的最佳方法是什么？我想得到它

谢谢！

【问题讨论】：

请保持建设性并按要求回答问题。设置是有原因的。我没有花时间设置/写这个问题，因为我忘记了 HDMI 电缆。

我发布的内容怎么没有建设性？我也在尝试调整您对所选技术的期望。我还建议 RTP。你可能不喜欢现实，但它就是现实。

我的问题特别是关于诊断哪一方有更多延迟并找到存在瓶颈的证据的最佳方法。它是粗体的。它不是在询问有关如何更改我的设置的建议。

可以使用带nobuffer的ffplayer来测试延迟，参考这个answer

【参考方案1】：

我的猜测是视频编码和视频解码引入了最大的延迟。假设您压缩到 H.264 (AVC) - 我会关闭 B 帧。

关于诊断 - 我会在客户端机器上运行 Wireshark。确保客户端和服务器时钟同步。然后我会将 RTMP 流中的时间戳与客户端的时钟进行比较。这应该让您对编码延迟有所了解。总延迟减去编码会给你解码延迟。您可能可以忽略网络缓冲和传输延迟。

这是一个有趣的问题，业界为此提供了一些解决方案 - 例如http://www.ineoquest.com/。

【参考方案2】：

我认为在您的情况下，瓶颈是视频处理。通常，软件视频编码不是那么快。 如果你降低视频质量、比特率等，你增加了更多的处理，只是增加了延迟。 如果您需要在距离源不太远的地方发送视频，只需使用 HDMI 等视频接口即可。它将通过视频它是如何（未经处理） 如果您真的对网络流媒体感兴趣，请考虑使用特殊的硬件编码器设备，例如 PCI 或外部设备。这些设备具有嵌入式硬件视频编码器，并且不使用 CPU 进行视频处理。通常使用硬件编码器的延迟小于 1s，但它仍然是正确的说法：“更多视频处理 = 更多延迟”