Hi pesi,

There is latency across the chain - out of the camcorder, into the capture card, then through vMix, then on the output, then the travel down the cable and then the projector output. Each component builds up to add to the total latency. The render time of vMix is at the lower left hand of the program.

Generally my rig is as follows:
Panasonic AG-UX90 HD prosumer camcorder - HDMI cable - Startech Hdmi to USB 3.0 capture device - into a Lenovo Laptop (i7 Quad) via its inbuilt USB 3.0 port - vMix (which is also streaming live but for this situation that can be ignored) - Hdmi Out cable (? length) to Projector (make/model varies) projecting only image without sound - the audio is being sent from the venue's PA audio mixer into their room speakers.

The reason for being concerned about latency in this situation is so that the projected image of the speakers should sync with what the audience is hearing through the venue's pa system.
I am given to understand that a latency of 100 ms or less is quite tolerable (?)

RTMP latency of FFMPEG/Typical Network Stack close server is approximately 1 - 1.5 seconds on the versions bundled with Vmix. Of course that will depend on Keyframes, buffering, cpu. Ultimately you then need to get that data via a LAN Adapter to a Switch to a Router to the Internet and to a server/cdn that will process and buffer maybe several times. Some even re-encode the video.

Best latency (RMTP H.264 as the protocol end to end) I've achieved is from Camera to Screen in Macau is 400ms (but was bad, had to add some more buffer). Using a custom (paid software) video player on a raspberry pi at the other end and Nimble Streaming Server in super low latency mode in the middle. Not using FFMPEG, using a H.264 encoder box set on the lowest latency settings (which they don't recommend) as the smallest glitch will result in dropped frames (but I desired that result). Basically I care more about maintaining latency then dropping a few frames.

Details here: http://blog.wmspanel.com...ing-nimble-streamer.html

Vmix Call was about 250ms - 350ms latency I used that primarily in 2017 it was easier to manage. Same deal, to Macau I do it every year.

I recommend if you need to do something low latency point to point. Use Vmix Call.

If you need to send to thousands of viewers < 2 seconds latency look into Nimble Streaming Servers. Most of the latency will be the buffering at the viewer's end. Flash or SLDP are what I've used for low latency. I still like Flash (RTMP), it's really solid at ultra low latency. However it's slowly going away because browsers are ditching it.

I've also read the Microsoft Service "Mixer" (FTL) is REALLY low latency.

https://watchbeam.zendes...treaming-With-OBS-Studio

The main problem I see is everybody needs a NVENC encoder/decoder (NVidia Video Card) in their computers. So you limit your audience to "gamers" which Mixer is pretty much targeted at.

So I think best to wait for this new alliance (http://www.srtalliance.org/) making SRT to become common and supported by Vmix, mobile devices and browsers. Ultimately it's no good having to ship custom hardware of software to your viewers to make it low latency. So you need to wait for the stuff your viewers already have before you can use it.

Hope I have not overloaded you with technical speak, this is based on my research and how I have applied it for my purposes, budgets and the type of content I stream. I'm happy to be corrected and explore better ways always.

The type of content will have a massive impact on what is good/bad/acceptable.

Softvelum (the people who make Nimble are part of the SRT alliance), along with Wowza another fine streaming server that is more popular. I imagine all the work they did back in 2015 on low latency has put them in a good position for SRT. They support it today, but I'm yet to use it as I don't have a web player yet. Vmix doesn't do SRT, so please add it Vmix. It's been requested in the Feature Requests forum and +1'd a few times. I suggest anyone reading this who wants SRT +1's it.

Projecting anticipated latency is a guessing game. The better approach is to actually measure it. It's long been said that you cannot manage what you cannot measure.

Thanks Guillaume,
I guess even processing introduces some element of latency (?)
Pesi