我也用 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
or
$ 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
or -qp 18
,越低越好)和目标 ip:port。
如果运行 Windows 使用dshow
代替x11grab
.
使用观看它ffplay udp://192.168.0.10:1234
or ffplay sdp://192.168.0.10:1234
.
请注意,这些选项都不会传输声音。在流式传输音频时我也无法获得如此低的延迟。可能是可行的,只是我不知道如何实现。
反应最快的客户是ffplay
, VLC
即使其网络缓存设置为零,也会引入太多的延迟 - 使用这样的缓存,它实际上变得更糟,因为它过于频繁地尝试“重新同步”流。
如果您需要更多详细信息,我做了一个post http://www.waitwut.info/blog/2013/06/09/desktop-streaming-with-ffmpeg-for-lower-latency/关于我的发现。希望能帮助到你。我很感激任何反馈。 ^_^