HTTP流桌面到浏览器的巨大延迟

Question

I'm trying to put together a reliable, reasonably low (<2s) latency desktop window share to browser solution. Currently I have:

client sender using FFMPEG:

ffmpeg -f gdigrab -i "title=notepad.exe" -r 10 -framerate 10  -c:v libx264 -g 50  -preset fast -tune zerolatency -f rtp rtp://192.168.1.85:1234

server re-stream to HTTP using VLC:

vlc -vv test.sdp  --sout=#transcode{vcodec=theo,vb=1600,scale=1,channels=1,acodec=none}:http{dst=:8080/webcam.ogg} :no-sout-rtp-sap :no-sout-standard-sap :sout-keep 

where the sdp file is generated from the output of the ffmpeg command

Client browser:

<video  id="video" autoplay loop muted preload="auto">
<source src="http://192.168.1.85:8080/webcam.ogg" type="video/ogg"/>
</video>

This works and gives good quality. But the latency is terrible (around 10s) and I'm at a loss to know how to tune it. I know that the latency is in the VLC transcoding/restreaming - displaying the RTP stream from the client on the server only has around 1s lag.

I guess there are two questions - can this approach be sensibly tuned, or is the approach wrong to start with?

Answer 1

Sub 2 second over http is near impossible. Latency can be reduced, but you probably need to change out you http origin software, switch delivery to chunked transfer, optimize your encoding pipeline, and manage your player buffer. Even then I doubt you will get to 2 seconds.