我也尝试过与VLC相同的情况,并且在3秒内无法获得延迟.FFmpeg创造了奇迹并最终提供了1秒的延迟.
mpeg2video和UPD提供了最好的结果,RTP延迟感觉有点差但非常接近.迁移到x264可以提高质量以换取更多的延迟,但这实际上取决于有多少动态内容以及CPU的速度.我只有x264使用UDP,但必须有一种方法来使用RTP.
我不确定这是否可行.服务器将承受繁重的工作负载,延迟将会很明显 - 至少在Linux上,不了解Windows.
在Linux上,尝试以下命令之一:
$ ffmpeg -f x11grab -s 1600x900 -r 50 -vcodec mpeg2video -b:v 8000 -f rtp rtp://192.168.0.10:1234
要么
$ ffmpeg -f x11grab -s 1600x900 -r 50 -vcodec libx264 -preset ultrafast -tune zerolatency -crf 18 -f mpegts udp://192.168.0.10:1234
调整屏幕分辨率(-s <your resolution>),刷新率(-r <fps>),带宽(-b:v <bits/s>),质量(-crf 18或-qp 18越低越好)和目标IP:端口.
如果运行Windows dshow代替x11grab.
使用ffplay udp://192.168.0.10:1234或观看它ffplay sdp://192.168.0.10:1234.
请注意,这些选项都不会传播声音.流式传输音频时,我无法获得如此低的延迟.它可能是可行的,我只是没弄明白如何.
最响应的客户端ffplay,VLC即使网络缓存设置为零,也引入了太多的延迟 - 这种缓存实际上变得更糟,因为它试图经常"重新同步"流.
如果您需要进一步的细节,我发表了关于我的发现的帖子.希望能帮助到你.我感谢任何反馈.^ _ ^
| 归档时间： |
|
| 查看次数： |
12010 次 |
| 最近记录： |