Back

Blog details

CTRL K

Glass-to-Glass Latency Explained: What It Actually Means

AIOZ Network

7 min readAugust 22, 2026

aioz-streamguide

TL;DR:

Glass-to-glass latency is the time from a frame leaving the camera lens to that same frame lighting up on a viewer's screen, the full pipeline, not just what a protocol or encoder adds.
Seven stages contribute: capture, encoder, packager, contribution network, CDN, player buffer, and decoder/display. Added together, everything except the player buffer rarely exceeds one second.
The player buffer is almost always the biggest number in the chain, because classic HLS holds back three full segments before it starts playing.
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 half a second).
Vendor-quoted latency numbers often measure something narrower than glass-to-glass. Measuring it yourself takes nothing more than a phone, a mirror, and a stopwatch app.

Ask three streaming vendors for their latency number and you'll often get three different definitions of latency, not just three different numbers. One measures from encoder input. Another measures from CDN edge. The only number that matches what a viewer actually experiences is glass-to-glass: camera to screen, the whole chain, no stage skipped.

What "glass-to-glass" actually means

Glass-to-glass latency measures the elapsed time between the moment a frame leaves the lens of the camera (the first "glass") and the moment that same frame is rendered on the viewer's screen (the second "glass"). It's the industry-standard, full-pipeline measurement, and it's stricter than a few terms that get used loosely as synonyms.

End-to-end latency usually refers to something narrower: encoder output to decoder input, which quietly excludes camera capture time and display rendering time. Protocol latency measures only what the delivery protocol's player logic adds on top of an already-packaged stream. Contribution latency and first-mile latency measure just the leg from encoder to origin. Each of these is a real, useful number for debugging a specific stage, but none of them is what a viewer feels. If a vendor quotes "under 1 second latency" without saying which of these they mean, ask.

The seven stages that add up to your total

Per the pipeline breakdown documented by streaming infrastructure engineers at Fora Soft, glass-to-glass latency is the sum of seven contributors:

Capture and ingest buffer (10 to 200 ms): camera sensor exposure, image signal processing, audio capture.
Encoder (50 to 400 ms): dominated by lookahead depth and B-frame settings; aggressive lookahead alone can add 300+ ms.
Packager (50 ms to 4 s): cuts the encoded bitstream into segments or chunks. This is the single largest controllable variable in the whole pipeline.
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 determines how fast a segment reaches a viewer's nearest server.
Player buffer (0.1 to 30 s): the range is enormous because this is the stage a player operator has the most direct control over, and where most of the actual latency usually lives.
Decoder and display (30 to 100 ms): hardware decode, frame queue, and the display's own refresh cycle.

Add up everything except the player buffer, and the total rarely clears one second. Which means one stage is doing almost all the damage. Encoder lookahead is worth calling out specifically, since it's an easy setting to leave on defaults and forget: it's a real quality tool, letting the encoder look ahead at upcoming frames to make smarter compression decisions, but every frame of lookahead is also a frame the encoder has to hold before it can output anything. A live sports broadcast tuned for maximum quality and a live auction tuned for minimum delay should not be using the same lookahead setting, even if they're running the same encoder software.

Why the player buffer dominates almost every time

Classic HLS players hold back three full segments before starting playback, a long-standing safety margin meant to absorb network jitter without stalling. At the common 6-second segment length, that's 18 seconds of buffer alone, on top of encode, package, and CDN time. Add it up and classic HLS routinely lands around 25 seconds glass-to-glass, a number that has almost nothing to do with your CDN's speed and almost everything to do with that fixed 3-segment rule.

Low-latency HLS attacks this exact stage. Instead of buffering three full segments, an LL-HLS player holds back roughly two to three multiples of a much smaller part duration, which is one reason it lands in the 2 to 5 second range instead of 25. If you want the mechanics of how it does that, we covered partial segments, preload hints, and blocking playlist reloads in depth in our LL-HLS explainer.

How much protocol choice actually matters

The gap between roughly 25 seconds for classic HLS and roughly 0.4 seconds for WebRTC is about a 60x difference, and it's driven almost entirely by protocol design, not by network conditions. A viewer on gigabit fiber watching classic HLS still waits 25 seconds. A viewer on a mediocre WiFi connection watching WebRTC still sees the stream in well under a second. This is the practical reason "which protocol" is usually a more important question than "which CDN" when latency is the priority. Throwing a faster CDN at a classic HLS stream might shave a few hundred milliseconds off the CDN stage in the table above, while leaving the 18-second player buffer completely untouched, which is most of the actual number a viewer experiences. For a fuller picture of how a decentralized delivery network fits around these protocol choices, see our overview of AIOZ Stream's decentralized video infrastructure.

How to actually measure your own glass-to-glass latency

You don't need lab equipment to get a real number. The simplest version of the mirror method, described in detail by Momento's streaming documentation, works like this: start a millisecond-precision stopwatch on your phone, point a camera that's feeding your live stream at that phone screen, and then take a single photo that captures both the phone (showing the real time) and a monitor playing back the resulting stream of that same phone (showing the delayed time) in the same frame. The difference between the two times in that one photo is your glass-to-glass latency, measured end to end with no assumptions about where the delay is coming from.

It's worth doing this yourself rather than trusting a dashboard number, because a platform's own reported "latency" metric is often measuring one of the narrower definitions above, not the full camera-to-screen chain a viewer actually experiences. It's also worth measuring more than once. Network conditions between your encoder and the CDN's ingest point vary hour to hour, and a single reading taken during a quiet network moment can undersell what viewers on a busier connection actually see. A handful of measurements spread across a normal broadcast window gives you a real range instead of one optimistic data point.

Where this leaves AIOZ Stream today

AIOZ Stream's live streaming product isn't available yet. Today's product is built around VOD delivery through the AIOZ DePIN network, where glass-to-glass latency in the live-streaming sense doesn't apply, since there's no camera-to-screen gap to close when nothing is being captured in real time. Once live streaming ships, the pipeline stages above (and which protocol AIOZ Stream's live product uses) will determine where it lands on the spectrum between classic HLS and something closer to real time. That's a claim to verify against the actual shipped product when it launches, not something to speculate about ahead of it.

FAQ

Is glass-to-glass latency the same as buffering?
No. Buffering is a playback interruption where the video stops and waits for more data. Glass-to-glass latency is the steady-state delay between when something happens in front of the camera and when a viewer sees it, even when playback is running perfectly smoothly with zero stalls.

Why do different tools report different latency numbers for the same stream?
They're usually measuring different segments of the pipeline. A CDN dashboard might report origin-to-edge time only. A player SDK might report from manifest fetch to first frame. Neither one is wrong, they're just answering a narrower question than "camera to screen."

Does a bigger player buffer always mean a worse experience?
Not necessarily. A larger buffer absorbs more network jitter before the player has to stall, so for content where a few extra seconds of delay doesn't matter, like a background broadcast, a bigger buffer trades latency for playback smoothness on purpose.

Can you get WebRTC-level latency out of HLS by just shrinking segment size?
Only partially, and it comes at a cost. Shorter segments do reduce the buffer's contribution, but push segments too short and you multiply the number of files your CDN has to serve while still paying a full request round trip for each one. LL-HLS's partial segments and preload hints solve the round-trip problem directly instead of just shrinking the segment size further.

Is the "3x segment duration" rule a hard requirement or just a default?
It's a conservative default most player implementations ship with, not a protocol requirement. Some players and platforms tune it down for specific use cases, but doing so trades away some of the jitter protection that default is there to provide.

Does audio latency matter separately from video glass-to-glass latency?
Yes, and it's a common blind spot. Audio and video can drift out of sync even when the overall glass-to-glass number looks fine, since audio and video are often encoded, packaged, and buffered through slightly different paths before being resynced at the player.

We only send updates when meaningful changes ship, and you can unsubscribe anytime