The studio adds less than one second. On top come the SRT latency of your connection, which you set yourself, and the platform's delay, which is several seconds for the viewers.
So most of the time between your camera and a viewer's screen arises at the platform, not in the studio.
What the delay is made up of
| Stretch | Size | Who determines it |
|---|---|---|
| Camera and encoder | depends on device and app | your source |
| SRT link to the studio | at least 200 ms, otherwise the value from your app | you, in the app |
| Studio | less than one second | fixed |
| Platform to the viewer | several seconds | the platform and its settings |
The first three stretches together give how late your picture is in the program. The fourth comes on top for the viewers.
The SRT latency is your control
The SRT latency is the time window in which lost packets are delivered again. Your studio receives with 200 ms. If your app asks for more, the larger value applies.
On a good link it stays at about 200 ms. On mobile data 500 to 2000 ms make sense, depending on the network. You buy this time on purpose: it prevents picture errors. Which value fits which connection is in Setting the SRT latency.
What the platform adds
Twitch, YouTube and Kick process your stream and deliver it to the viewers in pieces. That takes several seconds. How many depends on the platform, on its latency settings and on the viewer's player. This time arises with every stream, also when you send straight from OBS to the platform. The studio changes nothing about it.
The platforms usually offer a low-latency mode. If a fast reaction to chat matters to you, look in your channel's settings.
What that means for you
For chat. Between a message in chat and your answer in the stream lies above all the platform's delay. The studio's scant second and an SRT latency of 200 ms hardly matter next to it. At 2000 ms of SRT latency you notice the difference more readily.
For the desk. What you see on the desk is later than reality by the time of the first stretches. A cut takes effect in the program at once, because all inputs keep running in the background. It reaches the viewers after the platform's delay.
For several cameras. Every source brings its own delay along. If two cameras show the same thing happening and send with different SRT latency, you see a small jump in time when you cut. Give such cameras the same latency value.
For picture and sound. The delay hits a source's picture and sound together. If the two drift apart anyway, the cause is the source, and it can be corrected per input. See Picture and sound drift apart.
For conversations over the stream. Whoever sees the program only on the platform sees it several seconds too late. For a conversation between two people in two places that is too much. Take a call of your own for that. See Streaming as two from two cities.
How to keep the delay small
- Set the SRT latency only as high as your connection needs. On fiber and good Wi-Fi about 200 ms are enough.
- Check whether your app or encoder buffers itself. Some have a setting of their own for that.
- Switch on the low-latency mode at the platform if there is one.
- Mind the unit of the latency. Most apps count in milliseconds, ffmpeg in microseconds.
Do not save in the wrong place. An SRT latency that is too tight for your network gains a few hundred milliseconds and costs picture errors and gaps in the sound.
Where the servers are
The servers are in Germany. The stream is handed over to Twitch and YouTube at their nearest ingest in Frankfurt. For streamers in Europe the way to the studio is short. If you send from far outside Europe, you have a longer way to the studio. Plan more SRT latency there.