寻找电视捕捉RTMP延迟的瓶颈
我试图从一台计算机到另一台计算机本地播放电视捕捉，但我的延迟比我想要的要高。
我的设置是12 an，i5 x4 3.2ghz，Geforce 970，带有Elgato HD60 Pro捕获卡。这台机器正在运行一个安装了Nginx+RTMP (https://github.com/arut/nginx-rtmp-module)的Ubuntu实例。
它附带了捕获/流软件，允许您调整bandwidth+resolution。它被设置为流到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 is )
- FFPLAY流的响应时间在2-3秒之间。
我想这意味着Elgato和RTMP服务器之间或者RTMP服务器和我的ffplay流之间或者两者都有瓶颈。
我尝试过的事情：
- 从捕获软件增加Mbps在1.00到8.00之间
- 将捕获质量从最高降低到最低
- 将捕获分辨率从1080降至720，降至标准。
- 将框架从60 from降低到30 from。
- 使用FFPLAY代替VLC
注意:在我的RTMP NGINX配置中没有特殊的选项。这是一个标准的live on，差不多就是这样。
，诊断问题所在的最佳方法是什么？，我想得到它< 1s。
谢谢!
回答 2
Stack Overflow用户
发布于 2017-05-11 15:38:18
我猜是视频编码和视频解码带来的最大延迟。让我们假设您的压缩到H.264 (AVC) -我会关闭B帧。
关于诊断-我会在客户端机器上运行Wireshark。确保客户端和服务器时钟同步。然后，我将RTMP流的时间戳与客户端的时钟进行比较。这应该会给你一个关于编码延迟的想法。总延迟减去编码会给你解码延迟。您可能会忽略网络缓冲和传输延迟。
这是一个有趣的问题，业界为它提供了一些解决方案--例如http://www.ineoquest.com/。
Stack Overflow用户
发布于 2017-05-11 13:40:19
我认为在你的情况下，瓶颈是视频处理。通常，软件视频编码不是那么快。如果你降低视频质量，比特率等，你增加了更多的处理，只是增加了延迟。如果您需要发送的视频不太远的来源，只需使用视频接口，如HDMI。如果你真的对网络流感兴趣，可以考虑使用特殊的硬件编码器设备，比如PCI或外部设备。这些设备有嵌入式硬件视频编码器，不使用CPU进行视频处理。通常与硬件编码器的延迟小于1s，但它仍然是真实的声明：“更多的视频处理=更多的延迟”。
https://stackoverflow.com/questions/43861479
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号