Glass-to-Glass Latency: What It Is and How to Measure It

Glass-to-glass latency is the time between a frame entering the camera lens and the same frame appearing on your viewer's screen. It covers every stage in between, so it's the one latency number that matches what viewers feel. Classic HLS lands near 25 seconds; WebRTC stays under one second.

TL;DR:

• Glass-to-glass latency is the full camera-to-screen delay, not just what a protocol or an encoder adds.
• Seven stages contribute: capture, encoder, packager, contribution network, CDN, player buffer, and decode/display. Everything except the player buffer rarely adds up to more than one second.
• The player buffer is usually the biggest number, because a classic HLS player starts at least three segments back from the live edge.
• Protocol choice, not network speed, explains most of the gap between classic HLS (around 25 seconds), low-latency HLS (2 to 5 seconds) and WebRTC (under a second).
• You can measure it yourself with a phone stopwatch, a camera and one photo.

Updated Oct 19, 2026: rewrote the AIOZ Stream section now that live streaming has shipped (RTMP ingest from OBS or PRISM Live Studio, HLS playback, Low Latency Mode in beta), added a seven-stage diagram, moved the measuring method to its correct source, and added a References list.

What does glass-to-glass latency mean?

The first "glass" is the camera lens and the second is the viewer's screen. Glass-to-glass latency is the elapsed time between the two for a single frame. It's stricter than several terms vendors use as if they meant the same thing.

End-to-end latency often means encoder output to decoder input, which leaves out camera capture and display time. Protocol latency covers only what the player logic adds on top of a packaged stream. Contribution or first-mile latency is just the hop from encoder to origin. Each one helps when you debug a single stage, but none of them is what your viewer feels. If a vendor quotes "under 1 second latency" without saying which one they mean, ask.

The seven stages that add up to your total

The streaming engineers at Fora Soft break glass-to-glass latency into seven contributors, each with a typical range:

• Capture and ingest buffer (10 to 200 ms): sensor exposure, image signal processing, audio capture.
• Encoder (50 to 400 ms): mostly set by lookahead depth and B-frame settings.
• Packager (50 ms to 4 s): cuts the encoded stream into segments or chunks. It's the largest stage you can tune directly.
• Contribution network (20 to 200 ms): the RTMP, SRT or RIST hop from encoder to origin.
• CDN (20 to 200 ms): origin-to-edge propagation, including the edge node fan-out that decides how fast a segment reaches the server nearest your viewer.
• Player buffer (0.1 to 30 s): the safety reserve the player keeps ahead of the playhead.
• Decoder and display (30 to 100 ms): hardware decode, frame queue and the screen's refresh cycle.

Add up every stage except the player buffer and you rarely pass one second, as Fora Soft notes, so one stage does almost all the damage. Encoder lookahead deserves a mention anyway, because it's an easy setting to leave on defaults. Lookahead lets the encoder study upcoming frames to compress better, but it must hold each of those frames before it outputs anything. A sports feed tuned for picture quality and an auction tuned for speed shouldn't share that setting, even when they run the same encoder.

Why does the player buffer dominate?

A classic HLS player starts well behind the live edge on purpose. RFC 8216, section 6.3.3 says a client should not start on a segment less than three target durations from the end of the playlist. With 6-second segments, that's 18 seconds of buffer before encoding, packaging and CDN time. That's why classic HLS often lands around 25 seconds, whatever your CDN's speed.

Low-latency HLS goes after this exact stage: the player holds back a few small parts instead of three full segments, which is why it lands in the 2 to 5 second range. Our LL-HLS explainer covers the mechanics behind it, including partial segments, preload hints and blocking playlist reloads.

Protocol choice matters more than CDN speed

The gap between about 25 seconds for classic HLS and about 0.4 seconds for WebRTC is roughly 60x, and protocol design drives almost all of it, not network conditions. A viewer on gigabit fiber watching classic HLS still waits about 25 seconds. A viewer on average Wi-Fi watching WebRTC sees the stream in well under a second.

That's why "which protocol" usually matters more than "which CDN" when latency is your goal. A faster CDN might trim a few hundred milliseconds from stage five while leaving the 18-second player buffer untouched. Our HLS vs WebRTC guide walks through that choice use case by use case.

How do you measure glass-to-glass latency?

You don't need lab equipment for this, and Fora Soft calls the simplest approach the stopwatch-in-frame method. Run a millisecond stopwatch on a phone and point the camera that feeds your live stream at it. Then take one photo that shows both the phone and a monitor playing your stream of that same phone. The difference between the two times in that photo is your glass-to-glass latency.

Do this yourself rather than trusting a dashboard figure, because a platform's own "latency" metric often uses one of the narrower definitions above. Measure more than once, too, because conditions between your encoder and the ingest point change through the day, and one reading at a quiet moment can flatter you. A handful of readings across a normal broadcast window gives you a range instead of one optimistic number.

How AIOZ Stream handles it

Live streaming on AIOZ Stream is documented and available: you send video from OBS Studio or PRISM Live Studio over RTMP, using a Server URL and a Stream Key from the dashboard. Viewers watch through the HLS playback URL, the player link or the embed code that AIOZ Stream returns for each session.

Here's how that path maps to the seven stages above:

• Encoder: the OBS guide recommends CBR, a 1-second keyframe interval, and the optional "zerolatency" tune for lower latency. These settings are yours to change.
• Contribution: the documented ingest protocol is RTMP only.
• Player buffer: the dashboard player view has a Low Latency Mode (Beta) toggle. The docs say it reduces the delay between you and your audience, and suggest it for Q&A, auctions and gaming.

The docs don't publish a latency figure for either mode, so measure your own stream with the stopwatch method before you promise viewers a number. To create a session through the API, the streamings reference documents this request (keys shown as placeholders):

curl --location --request POST 'https://api.aiozstream.network/api/live_streams/key_id/streamings' \
  --header 'stream-public-key: your_public_key_here' \
  --header 'stream-secret-key: your_secret_key_here' \
  --data-raw '{
    "title": "live_streaming_title",
    "save": true,
    "qualities": [
      { "resolution": "360p", "type": "hls", "container_type": "mpegts" },
      { "resolution": "720p", "type": "hls", "container_type": "mpegts" }
    ]
  }'

The response includes hls_url, player_url and iframe for the session. While you're live, the statistics endpoint reports frame rate and bitrate in and out, updated every 5 to 30 seconds. Next step: follow the Create Livestream guide to get your Stream Key.

FAQ

Is glass-to-glass latency the same as buffering?
No. Buffering is a playback interruption, when the video stops and waits for data. Glass-to-glass latency is the steady delay between something happening in front of the camera and your viewer seeing it, even when playback runs with zero stalls.

Why do different tools report different latency numbers for the same stream?
They usually measure different parts of the pipeline: a CDN dashboard might report origin-to-edge time only, while a player SDK might count from manifest fetch to first frame. Both answer a narrower question than "camera to screen."

Does a bigger player buffer always mean a worse experience?
No, because a larger buffer absorbs more network jitter before the player stalls. For content where a few extra seconds don't matter, a bigger buffer trades latency for smoother playback on purpose.

Can you get WebRTC-level latency out of HLS by shrinking segments?
Only partly, and at a cost: shorter segments shrink the buffer, but they multiply the files your CDN serves, and you still pay a full request round trip for each one. LL-HLS's partial segments and preload hints remove that round trip directly.

Is the three-segment rule a hard requirement?
No. RFC 8216 uses "SHOULD NOT," so it's a strong default rather than a must, and some players tune it down for specific use cases at the cost of part of the jitter protection it provides.

Does audio latency matter separately from video?
Yes, and it's a common blind spot, because audio and video are often encoded, packaged and buffered on slightly different paths. They can drift out of sync even when the overall number looks fine.

What latency does AIOZ Stream's Low Latency Mode reach?
The docs don't state a number; they describe Low Latency Mode (Beta) as reducing the delay for interactive broadcasts. Measure your own stream with the stopwatch method in this article.

Related reading

• What Is Low-Latency HLS (LL-HLS): how partial segments shrink the player buffer stage
• HLS vs WebRTC: picking a protocol by how much delay your use case tolerates
• WebRTC Mesh vs SFU vs MCU: how call topology affects the latency budget
• Live Streaming on AIOZ Stream: The Complete Guide: stream keys, sessions, restreaming and archiving
• Best OBS Encoder Settings for 1080p and 720p: the encoder stage in practice
• What Is QoE in Video Streaming: the viewer-side metrics that sit next to latency
• AIOZ Stream Explained: the stages from upload to playback on one network

References

• Fora Soft, Latency Glass-to-Glass Explained: the seven-stage ranges and the stopwatch-in-frame measuring method
• Momento, What is glass-to-glass latency?: definition and the components that contribute to it
• RFC 8216, HTTP Live Streaming, section 6.3.3: the three-target-duration starting rule
• Mux, Low-Latency Live Streaming for Developers: latency ranges for classic HLS, LL-HLS and WebRTC
• AIOZ Stream docs, Viewing and Sharing and Streamings API: Low Latency Mode (Beta) and the session request above