Delay in a stream is not one thing that can be switched off. It is an accumulation, contributed to by every stage between the sensor and the screen, and no stage gives any of it back. Understanding where it collects is the difference between reducing it and merely complaining about it.
The budget, stage by stage
The sensor reads out and the camera assembles a frame. The encoder takes frames and compresses them, and how it does that matters: schemes that reference future frames must wait for those frames to exist before emitting anything, so the compression that gives the best picture per unit of bandwidth is also the compression that waits longest.
The packager then cuts the stream into pieces for delivery over ordinary web infrastructure. Delivery over that infrastructure adds its own transit. And the player at the far end holds a reserve before it begins, so that it has something to show while the next piece is arriving.
The player's reserve is usually the largest single item, and it is the one people reach for first. That is reasonable, and it comes with the consequence below.
The buffer is not waste
A buffer exists to absorb variation in the network. Packets do not arrive at an even rate, and the reserve is what lets an uneven supply produce an even picture. Shorten it and the delay falls; shorten it too far and every momentary congestion becomes a visible stall.
This is the central trade in the whole subject. Latency and resilience are bought from the same budget, and a stream tuned for the lowest possible delay on a good connection is a stream that breaks up on a mediocre one. The right setting depends on who is watching and on what they will do about a stutter.
How low is worth going
Segmented delivery with conventional settings sits in the region of several seconds to tens of seconds. Techniques that deliver partial pieces as they are produced bring that down substantially while keeping most of the resilience. Peer-oriented protocols designed for conversation reach well under a second and give up much of the robustness and most of the scale.
The question worth asking is what the delay actually breaks. A concert watched passively is unharmed by ten seconds. A stream with live chat is harmed, because the audience is discussing something the performers finished a paragraph ago. A remote performer playing along with the stage is defeated by a fraction of that.
Sound and picture take different routes
Audio and video are captured, processed and transported separately and are reassembled by timestamps. Anything that disturbs the timestamps, or that inserts processing on one path and not the other, separates them.
Human tolerance for that separation is not symmetrical. In the physical world sound always arrives after light, so a viewer forgives audio that lags the picture far more readily than audio that precedes it. The detectability and acceptability thresholds are set out in a recommendation from the International Telecommunication Union, a standards body rather than a vendor, and the asymmetry is the part worth carrying into a control room: if the two must be wrong, the sound should be late.
In practice the usual culprit is an audio path that skipped the video processing chain. Sound taken directly from a console and video that has passed through a switcher, a scaler and an encoder will not line up, and the correction is a deliberate delay on the audio rather than an apology.
Two screens, two answers
As soon as a production feeds more than one destination, the streams diverge. A picture sent to the foyer, a picture sent to the internet and a picture sent to a relay monitor take different paths with different budgets, and they will not agree with each other.
This is audible before it is visible. A foyer screen running several seconds behind the room means latecomers hear applause through the doors and see it later; two displays in sight of each other showing the same event at different moments reads as a fault even when both are working exactly as designed. The remedy is to decide which destinations must agree and to delay the faster ones deliberately to match the slowest of that group, rather than letting each find its own level.
The delay that matters inside the building
Streaming is the visible case, and it is not the urgent one. Relay video to a conductor, to a chorus room, to a stage manager's desk or to performers working to a screen has to be effectively immediate, because somebody is synchronising their body to it.
A direct video path adds almost nothing. Sending the same picture over a network with an encoder at one end and a decoder at the other adds frames, and a conductor relay delayed by even a few of them is not a conductor relay. This is a case where the older, less flexible distribution is simply correct, and where mixing the two produces the worst outcome: some monitors ahead of others.
What we cannot verify
Latency figures for encoders, delivery platforms and players are published by the companies selling them, measured end to end under network conditions that are rarely described, and they vary with resolution, bitrate and load. We reproduce none of them. The thresholds for synchronisation error are defined in the recommendation named above under specified viewing conditions; a single number lifted out of it would misrepresent it. The reliable measurement is the one made on the actual path, from camera to the device an audience will really use.
The short version
- Latency is an accumulation; every stage adds and none give any back.
- The player's reserve is usually the largest item and the first one people cut.
- Latency and resilience are bought from the same budget.
- Ask what the delay breaks: passive viewing, conversation, or playing along.
- Viewers forgive late sound far more than early sound.
- A conductor relay must take the direct path, not the encoded one.