Understanding each part of the latency budget
Live streaming stitches together several stages—capture, encoding, network transport, buffering, and playback. Each stage adds a slice of delay to the experience. This calculator treats the end-to-end latency as the simple sum shown above. That makes it easy to communicate trade-offs: if you shave 100 ms off encoding, you usually shave about 100 ms off the viewer’s delay, assuming other stages stay constant.
Capture delay (C)
Capture delay begins the moment photons strike a camera sensor (or when a frame is produced by a game engine). Consumer cameras may buffer lines, apply gain, and run noise reduction before delivering frames to the host computer. Some devices use rolling shutter readouts, meaning the bottom of the image is captured milliseconds after the top. USB capture cards can add buffering, and operating systems may queue frames for synchronization with the graphics subsystem. For gameplay streaming, screen capture APIs can introduce similar queues, especially when vsync is enabled.
Encoding delay (E)
Encoding delay arises when raw frames are compressed into formats like H.264, HEVC, or AV1. Codecs often operate on groups of pictures (GOPs), analyzing multiple frames to exploit temporal redundancy. A longer GOP can improve compression efficiency but may increase latency because the encoder needs more context. Hardware encoders trade compression ratio for speed; software encoders can be tuned for latency by reducing lookahead, disabling B-frames, or lowering resolution.
If you are targeting low latency, common tactics include: shorter GOPs, fewer reference frames, reduced lookahead, and “zerolatency” presets. The best settings depend on your bitrate constraints and the stability of your network.
Network delay (N)
Network delay is more than a single number, but RTT is a useful approximation for planning. Video may traverse CDNs, proxy hops, and congested
links. Wireless connections add variability, especially on mobile devices. Packet loss and jitter can inflate effective delay beyond what a
simple ping suggests. When budgeting, it’s often helpful to test multiple RTT values (for example, 30 ms for local viewers and
150 ms for international viewers) to see how your experience changes.
Player buffering (B)
Player buffering is the deliberate accumulation of data before playback. Traditional HLS/DASH workflows request multi-second segments and buffer several before rendering begins. This smooths out network hiccups at the cost of latency. Low-latency approaches (WebRTC, LL-HLS, CMAF chunked transfer) reduce buffer requirements but demand more stable connections and careful tuning. In many real deployments, buffer policy is the biggest lever for reducing latency—until stalls become unacceptable.
Startup delay (S)
Startup delay represents the one-time initialization cost when a viewer presses play. Browsers may initialize decoders, perform DRM handshakes, fetch manifests, or render preroll advertisements. On the broadcaster side, starting an encoder can require hardware ramp-up or keyframe alignment. For interactive applications, reducing startup delay improves the “time to first frame” and makes the stream feel more responsive.
Sample latency budgets (illustrative)
The table below shows example budgets for common scenarios. These are not universal defaults—treat them as starting points. Your actual values depend on camera hardware, encoder settings, protocol choice, CDN topology, and viewer devices.
| Scenario | C (ms) | E (ms) | N (ms) | B (ms) | S (ms) | Total L (ms) |
|---|---|---|---|---|---|---|
| Webcam chat | 50 | 100 | 40 | 100 | 200 | 490 |
| Gaming stream | 80 | 250 | 80 | 300 | 500 | 1210 |
| Sports broadcast | 100 | 400 | 120 | 600 | 1000 | 2220 |
Practical guidance for reducing latency
Latency optimization is usually a set of trade-offs rather than a single “fix.” Reducing encoding delay by shrinking GOP size can increase bitrate, which may worsen network performance for some viewers. Slashing the player buffer can make chat feel more immediate but increases the risk of stalling. A good workflow is to identify the largest contributor in your current budget, change one variable, and re-measure.
Common improvements include: using lower-buffer capture paths (HDMI/SDI vs. high-latency USB modes), choosing low-latency encoder presets, placing ingest closer to the broadcaster, selecting a protocol designed for low latency, and tuning player buffer targets. If you need a single number to report, measure glass-to-glass; if you need a plan to improve it, use the budget breakdown.
Privacy
All calculations run locally in your browser. The values you enter are not sent anywhere by this page.
