Point a camera at a screen showing its own feed. Measure how long a frame takes to come back around.
On commodity hardware, doing nothing else at all — no encoding, no network, no decoding — that loop takes about 110 milliseconds.
Which means sub-80ms glass-to-glass is not a difficult target. It is an unavailable one. The camera and the screen have already spent the budget before anything you build gets involved.
That is not an accusation against anyone's marketing, including ours. It is an argument that the number is meaningless without a measurement point — and that once you state the measurement point, sub-80ms becomes both true and useful.
Two numbers that get treated as one
Network round-trip time is what WebRTC's own statistics report: the time for a packet to reach the far endpoint and an acknowledgement to return. It measures the network. It excludes capture, encode, decode and display entirely.
Glass-to-glass is the time from a photon striking the camera sensor to the corresponding photon leaving the far display. It measures everything.
These are not variations on a theme. They measure different spans of the same pipeline, and on real hardware they differ by more than an order of magnitude. When a vendor says "sub-80ms" without qualification, the reader hears glass-to-glass and the vendor almost always means something closer to the first.
The measurement that settles it
Transitive Robotics ran the infinite-mirror test properly: a camera pointed at a screen displaying its own feed, high-precision timestamps overlaid on the image, measured across many cycles. Three USB3 cameras — a RealSense D435, a Logitech C925e and a 2MP wide-angle — on an Ubuntu desktop at 30 fps capture with a 60 Hz display. Remote testing routed through a cloud relay from California to Oregon.
Totals: about 110 ms with no codec involved at all, 130 ms encoded over a local network, 170 ms remote through a relay.
The two ends nobody thinks about — the camera and the screen — cost more than the encoder, the network and the decoder combined.
A 30 fps camera cannot produce a frame more often than every 33 ms, and a 60 Hz display cannot show one more often than every 17 ms, before either has done any processing. Add USB transfer, sensor readout and compositing, and 100 ms is not a bad result. It is roughly what that hardware costs.
So what is sub-80ms video latency actually measuring?
Network transport plus codec. Which is to say: the part of the chain a video platform actually controls.
Read the table again with that in mind. Encode at 10 ms, decode at 10 ms, network at 30 ms — that is 50 ms for everything between the camera's output and the display's input. Sub-80ms for that span is entirely achievable and genuinely hard to hit, requiring efficient routing, short geographic paths and disciplined buffering.
So the claim is not false. It is incomplete. It describes a real engineering achievement over the span a vendor is responsible for, and then gets read as a claim about a span that includes hardware the vendor has never touched.
The honest formulation is a span, not a number: sub-80ms from ingest to egress, or from encoder input to decoder output. Say which, and the claim becomes checkable. Leave it off, and it is unfalsifiable — which is the real problem, not the figure.
Where the rest of the time goes
Three places, in descending order of size.
Capture and display dominate, as measured. This is a hardware property: sensor readout, USB or MIPI transfer, driver buffering, compositor, panel refresh and pixel response. A 30 fps webcam and a 60 Hz monitor are not built for minimum latency and were never intended to be.
Buffering is the invisible middle. The jitter buffer holds frames on purpose, reordering packets and releasing frames at a steady cadence so playback is smooth rather than stuttering. It is adaptive: a more variable network gets a deeper buffer and therefore more delay. Nobody sets this per call, and almost nobody counts it when quoting a number.
Format conversion, where it exists, is pure addition. Anything that transcodes or repackages between protocols pays for it in milliseconds — which is exactly why RTSP cameras and the browser gap is a latency question as much as a compatibility one.
How the floor actually gets lowered
The 100 ms is a property of commodity hardware, not a law. Purpose-built capture equipment, global-shutter sensors, direct capture paths that bypass the usual driver stack, and low-persistence displays at 120 Hz or higher all cut it substantially — which is why professional broadcast and competitive-gaming figures look different from webcam figures.
That is worth stating plainly because it explains an apparent contradiction. When someone reports genuinely low glass-to-glass latency, they are usually not using a Logitech webcam and an office monitor. The pipeline in the middle may be identical; the ends are not.
For anything running in a browser on equipment your users already own, the commodity floor is the one that applies. Which raises the more useful question: how low does it actually need to be?
What latency actually buys you, by application
Different jobs have genuinely different thresholds, and most of them are nowhere near 80 ms.
For conversation, ITU-T Recommendation G.114 puts one-way transmission time up to 150 ms as acceptable for most applications, with 150–400 ms usable if the effect is understood, and beyond 400 ms unacceptable for general planning. That recommendation addresses mouth-to-ear voice delay rather than video, so treat it as the well-established anchor for conversational tolerance rather than a video specification — but it makes the point that human conversation does not need 80 ms, and never did.
The pattern is that latency matters most where a human is closing a control loop. Steering a camera is harder than streaming it for exactly this reason, while a one-way broadcast tolerates seconds without anyone noticing.
And for the operational cases, the stream latency is usually the smallest term. The intervention latency budget and what live-view latency costs on a video wall both show the same thing: detection, decision and human reaction dominate, and shaving 20 ms off transport changes an outcome far less than the marketing implies.
The question worth asking
One sentence, for any latency claim including ours:
Measured from where to where?
A good answer names a span — ingest to egress, encoder input to decoder output, glass to glass — and says what hardware it assumes. A vague answer is not necessarily dishonest; it usually means network RTT, quoted by someone who has not thought about where the reader will assume the measurement starts.
A second question is worth asking too: measured under what conditions? A figure from an unloaded server on a short path is a different figure from one under production load across regions. Both are real; only one describes your deployment.
Build, Buy, or Deploy
Three routes, with the honest boundary on each.
Build on open source
Building against mediasoup, Janus, Pion or LiveKit gives you direct access to the parts of the budget you can actually influence: routing path, buffer configuration, codec choice. It also gives you the measurement instrumentation, which matters more than it sounds — most teams cannot say what their real latency is because nothing is measuring it end to end.
Buy a cloud video API
Per-minute providers typically deliver good transport latency through large distributed footprints, which is genuinely valuable and hard to replicate. The limits are that you cannot choose the routing path, you usually cannot see the jitter buffer behaviour, and the published figure is theirs rather than yours.
Deploy a commercial platform
The middle path runs a commercial platform on infrastructure you choose. Samvyo is one such option: based on SFU architecture, shipping embeddable SDKs, with the media path, TURN and recording kept on infrastructure you control. Path length is the relevant part here, since where the media path sits relative to your users is one of the few levers that genuinely moves transport latency. It is resilient by design rather than something you assemble.
Where it does not fit: if your application tolerates seconds — one-way broadcast, most monitoring — latency is not your selection criterion and you should choose on cost or operational fit instead. And if you need latency below the commodity floor, the answer is capture and display hardware, not a different platform.
The Bottom Line
A commodity camera and screen consume roughly 110 ms before any encoding, so sub-80ms glass-to-glass is not slow or fast — it is arithmetically unavailable on that hardware. Every sub-80ms claim in this category, ours included, describes network transport plus codec: the span a platform actually controls.
That span is a legitimate and hard-won number. State it as a span rather than a bare figure, ask any vendor to do the same, and then check whether your application needs it at all — because most of them need far less than 80 ms, and the ones that need more than the stream can give are limited by the human in the loop, not the pipeline.
What's Next
For where each millisecond sits in the pipeline, the full chain between two video tabs walks all eight stages and what fails at each. For the operational side — what live-view delay actually costs someone watching a wall — what live-view latency costs on a video wall covers the same arithmetic from the operator's seat.
Frequently Asked Questions
What does sub-80ms video latency actually mean?
In practice it means network transport plus codec — the span between an encoder's input and a decoder's output, which is the part a video platform controls. It does not mean glass-to-glass, because a commodity camera and display consume roughly 110 ms on their own before any encoding happens.
What is the difference between glass-to-glass latency and network RTT?
Network RTT measures a packet's round trip between endpoints and is what WebRTC's own statistics report; it excludes capture, encode, decode and display. Glass-to-glass measures from photon at the sensor to photon at the far display, including all of that. On real hardware they differ by more than an order of magnitude.
Is sub-80ms latency possible in a browser?
For network transport plus codec, yes, and it takes real engineering — efficient routing, short geographic paths, disciplined buffering. For glass-to-glass on a standard webcam and monitor, no. Measured figures put capture, USB transfer and display rendering alone at around 100 ms.
Why is my video latency higher than the number my vendor published?
Most likely three reasons. Your camera and display are included in what you are experiencing and were excluded from theirs. Your jitter buffer is deeper because your network is more variable. And their figure was probably measured on a short path under light load rather than across regions in production.
How much latency does a video call actually need?
Less than the marketing suggests. ITU-T Recommendation G.114 puts one-way delay up to 150 ms as acceptable for most applications — that is a voice recommendation rather than a video one, but it establishes that conversation does not require 80 ms. Latency matters most where a human closes a control loop, such as steering a remote camera.
Does a jitter buffer add latency?
Yes, deliberately. It holds arriving packets briefly to reorder them and release frames at a steady cadence, trading delay for smooth playback. It is adaptive, so a more variable network produces a deeper buffer and more delay, and it is routinely left out of quoted latency figures.
How do I measure my own video latency?
The infinite-mirror method is the honest one: point the camera at a screen showing its own feed with a high-precision timestamp overlaid, and measure the difference between the live timestamp and the one visible in the loop. It captures the whole chain including capture and display, which per-component measurements and getStats figures do not.
