I have also tried the same with VLC and couldn't ever get latency bellow 3 seconds. FFmpeg did wonders and finally provided a latency bellow 1 second.
mpeg2video and UPD provided the best results, RTP latency felt a bit worse but very close. Moving to x264 improves quality in exchange for a bit more latency, but that really depends on how much dynamic content is there and how fast the CPU is. I only got x264 working with UDP, but there must be a way to do it with RTP.
I'm not sure it's feasible for playing. The server will be under a heavy workload and latency will be noticeable - at least on Linux, don't know about windows.
On Linux try one of the following commands:
$ 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
Adjust for screen resolution (-s <your resolution>
), refresh rate (-r <fps>
), bandwidth (-b:v <bits/s>
), quality (-crf 18
or -qp 18
, the lower the better), and target ip:port.
If running Windows use dshow
in place of x11grab
.
Watch it using ffplay udp://192.168.0.10:1234
or ffplay sdp://192.168.0.10:1234
.
Mind you that none of those options will stream sound. I was unable to get such low latencies when streaming audio as well. It might be doable, I just didn't figured out how.
The most responsive client was ffplay
, VLC
introduced too much latency even with its network cache set to zero - with such cache it actually got worse, since it tried to 'resync' the stream too often.
If you need further details I made a post about my findings. Hope it helps. I appreciate any feedback. ^_^