How much latency does Full NDI add?

Full NDI typically adds 40 to 80ms glass-to-glass on a Gigabit LAN. This comprises approximately 16 to 33ms encode latency and 16 to 33ms decode latency, with transport latency under 1ms on a local network. Full NDI uses SpeedHQ intra-frame compression where every frame is independently compressed, giving the lowest latency of any IP video protocol.

Technical Reference · Authorised Magewell Supplier UK

Glass-to-Glass Video Latency
Comparison — Complete Reference 2026

End-to-end glass-to-glass latency figures for every major video transport protocol — HDMI, SDI, NDI, SRT, RTMP and HLS. Encode latency, transport latency, decode latency and total pipeline delay. Used by broadcast engineers, AV integrators, live production professionals and system designers worldwide.

Published: June 2026 Source: iView Data Ltd — Authorised UK Magewell Supplier Audience: Broadcast Engineers · AV Integrators · Live Production · IT Architects

🔍 People who use this reference searched for

glass-to-glass latency comparison NDI latency milliseconds SRT latency vs RTMP how much latency does NDI add HDMI vs SDI latency difference HLS latency how to reduce low latency live streaming protocol RTMP end to end delay what is glass to glass latency NDI vs SRT latency hardware encoder latency best protocol for low latency streaming SRT latency setting calculation video latency table comparison chart how to measure video latency

Contents

What is glass-to-glass latency?
Protocol overview
Full latency table
Latency breakdown
Use case guide
How to reduce latency
Common questions
Cite this reference

01 What Is Glass-to-Glass Latency? #what-is

Glass-to-glass latency is the total elapsed time from the moment light enters the camera lens to the moment the decoded image appears on the output display. It is the most meaningful latency measurement for live production because it captures the entire pipeline delay — not just the transport layer.

Many manufacturers quote only encode latency or transport latency in their specifications. These figures are misleading because they omit the other stages. A hardware encoder might advertise "sub-50ms encoding latency" while the full glass-to-glass pipeline including decode and display adds another 100–200ms.

The four stages of glass-to-glass latency

Glass-to-glass total = camera sensor delay + encode latency + transport latency + decode latency + display processing

Why this matters: For in-ear monitoring, tally systems and confidence monitors, any latency above 40–80ms becomes perceptible to a performer or presenter. For audience-facing displays in the same room as the live source, latency above 100ms causes visible lip-sync issues and disorientation.

02 Protocol Latency Overview #overview

Each protocol has a fundamentally different latency profile determined by its compression architecture, buffering strategy and delivery model. These are typical glass-to-glass figures under optimal network conditions.

HDMI / DisplayPort

HDMI & DisplayPort

~1–3 msglass-to-glass

Near-zero latency — electrical signal transmission with no compression. The benchmark reference latency for all other protocols.

Encode0 ms (none)

Transport0.5–2 ms

Decode0 ms (none)

Max distance~10m passive

SDI (3G/6G/12G)

SDI

~1–5 msglass-to-glass

Uncompressed broadcast standard. No codec latency. Coaxial cable at up to 100m+. Industry standard for live production.

Encode0 ms (none)

Transport1–4 ms

Decode0 ms (none)

Max distance100–300m coax

Full NDI

~40–80 msglass-to-glass

SpeedHQ intra-frame compression over Gigabit LAN. Lowest latency IP video option for local production networks.

Encode16–33 ms

Transport<1 ms (LAN)

Decode16–33 ms

EnvironmentGigabit LAN only

NDI HX3

~100–200 msglass-to-glass

H.265 inter-frame compression. Higher latency than Full NDI due to GOP structure but suitable for most monitoring and production use cases.

Encode50–100 ms

Transport<5 ms (LAN)

Decode30–80 ms

EnvironmentLAN / Wi-Fi

SRT

~100–500 msglass-to-glass

Configurable latency buffer — set 4× your round-trip time. For local LAN: ~100ms. For internet: 200–500ms. For 4G/satellite: 500ms+.

Encode30–80 ms

Transportuser-configured

Decode30–60 ms

EnvironmentLAN / WAN / 4G

RTMP

5–30 secondsglass-to-glass

Platform CDN buffering dominates. The encoder-to-ingest latency is low (<500ms) but platform buffering adds 5–30 seconds before viewers see the image.

Encode30–100 ms

Platform buffer5–30 seconds

Controllable?No — platform set

EnvironmentWAN / internet

HLS

6–45 secondsglass-to-glass

Segment-based HTTP delivery — highest latency of all protocols. LL-HLS reduces this to 2–4 seconds but requires compatible CDN and player.

Standard HLS6–45 seconds

Low-Latency HLS2–4 seconds

Controllable?Partially

EnvironmentCDN / browser

RTSP

1–3 secondsglass-to-glass

Pull-based streaming over LAN. VLC and NVR players add buffering. Suitable for monitoring and IPTV but not real-time production.

Encode30–80 ms

Player buffer0.5–2 seconds

Controllable?Partially

EnvironmentLAN only

03 Full Latency Reference Table #main-table

All figures are glass-to-glass under optimal conditions on a well-provisioned network. Real-world latency may be higher depending on hardware encoder model, network congestion, player buffering and display processing time.

Protocol	Encode latency	Transport latency	Decode latency	Glass-to-glass total	Controllable?	Best use case
HDMI 2.0/2.1	0 ms	0.5–2 ms	0 ms	~1–3 ms	N/A	Confidence monitors, IEM, local display
SDI (3G/6G/12G)	0 ms	1–4 ms	0 ms	~1–5 ms	N/A	Broadcast production, studio, OB van
Full NDISpeedHQ intra-frame	16–33 ms	<1 ms (LAN)	16–33 ms	40–80 ms	Yes — buffer	IP production, tally, vMix/OBS sources
NDI HX3H.265 inter-frame	50–100 ms	<5 ms (LAN)	30–80 ms	100–200 ms	Partial	PTZ cameras, Wi-Fi sources, monitoring
NDI HX2H.265 inter-frame	80–150 ms	<5 ms (LAN)	50–100 ms	150–300 ms	Partial	Preview monitoring, remote sources
SRT (LAN)H.264 or H.265	30–80 ms	20–80 ms	30–60 ms	80–220 ms	Yes — full	Local contribution, inter-building
SRT (internet)H.264 or H.265	30–80 ms	120–300 ms	30–60 ms	200–500 ms	Yes — full	Remote contribution, outside broadcast
SRT (4G/satellite)H.265 recommended	30–80 ms	300–800 ms	30–60 ms	400 ms – 1 s	Yes — full	Field production, 4G streaming
RTMPEncoder to ingest	30–100 ms	100–500 ms	Platform CDN	5–30 secondsplatform buffer dominates	No	YouTube, Facebook, Twitch delivery
RTMP Ultra LowYouTube / Twitch ULL	30–100 ms	100–500 ms	Platform CDN	1–3 secondsultra low latency mode	Limited	Interactive streams, live Q&A
HLS (standard)Segment-based	30–100 ms	CDN segmentation	Player buffer	6–45 seconds	No	VOD, CDN delivery, browser players
LL-HLSLow-Latency HLS	30–100 ms	CDN partial	Player buffer	2–4 seconds	Partial	Browser delivery with latency constraints
RTSPPull-based LAN	30–80 ms	<10 ms (LAN)	500 ms – 2 splayer dependent	1–3 seconds	Partial	LAN monitoring, NVR, IPTV
ZixiManaged broadcast	50–100 ms	100–400 ms	50–100 ms	200–600 ms	Yes — full	Broadcast contribution, satellite replacement

Important: RTMP and HLS glass-to-glass latency is dominated by platform CDN buffering which is set by the platform operator, not the encoder. No encoder setting can reduce YouTube's 5–30 second viewer delay — only the platform's "Ultra Low Latency" mode affects this, and only partially.

04 Latency Stage Breakdown #breakdown

Understanding which stage contributes the most latency in your pipeline allows you to target the right optimisation. Reducing transport latency on an HLS stream is pointless — the CDN segmentation is the dominant factor. Reducing encode latency on an RTMP stream is equally pointless — the platform buffer is the constraint.

Protocol	Dominant latency stage	Encode stage	Transport stage	Decode/buffer stage	Optimisation target
HDMI / SDI	Cable propagation	None	1–4 ms	None	Cable length only
Full NDI	Encode + decode (equal)	16–33 ms	<1 ms	16–33 ms	Reduce buffer depth in device settings
NDI HX3/HX2	Encode (GOP structure)	50–150 ms	<5 ms	30–80 ms	Switch to Full NDI if latency critical
SRT (LAN)	SRT latency setting	30–80 ms	20–80 ms	30–60 ms	Reduce SRT latency to 4× RTT
SRT (internet)	SRT latency setting	30–80 ms	120–300 ms	30–60 ms	Reduce SRT latency — measure RTT first
RTMP	Platform CDN buffer	30–100 ms	100–500 ms	5–30 seconds	Use platform ULL mode — nothing else works
HLS	CDN segmentation + player	30–100 ms	CDN segments	6–45 seconds	Switch to LL-HLS or SRT instead

05 Protocol Selection by Latency Requirement #use-cases

Different applications have different latency tolerances. Use this guide to select the correct protocol for your latency requirement — not just for transport convenience.

Use case	Maximum acceptable latency	Recommended protocol	Why
In-ear monitoring (IEM)	<40 ms	HDMI / SDI	Any IP protocol adds too much latency for performers
Confidence monitors (same room)	<80 ms	HDMI / SDI / Full NDI	Visible lip-sync issues above 80ms on same-room displays
Tally light systems	<100 ms	Full NDI / SDI	Tally via NDI is reliable — NDI HX adds too much delay
PTZ camera control	<200 ms	Full NDI / NDI HX3	Pan/tilt response feels sluggish above 200ms
Multi-camera switching	<500 ms	Full NDI / NDI HX3 / SRT LAN	Cut response and preview monitoring latency
Remote contribution (OB)	<1 second	SRT over internet	200–500ms acceptable for contribution — not viewer delivery
Interactive live stream (Q&A)	<3 seconds	RTMP ULL / LL-HLS	Standard RTMP/HLS makes real-time interaction impossible
Broadcast / sports delivery	Any — viewer accepts delay	RTMP / HLS	Viewers accept 15–30s delay for reliability and quality
Surveillance / CCTV monitoring	<3 seconds	RTSP / NDI HX	RTSP native to most IP cameras and NVR systems
Medical imaging display	<50 ms	HDMI / SDI / USB capture	Real-time procedure display requires near-zero latency

06 How to Reduce Video Latency #reduce

Latency reduction strategies depend entirely on which stage is the bottleneck. Applying the wrong fix wastes time and may introduce instability without improving latency.

Latency symptom	Root cause	Fix
NDI source delayed 80ms+	Full NDI default buffer depth	Reduce video buffer in Pro Convert web GUI → NDI settings. Use low-latency mode in vMix source settings.
NDI HX camera feels sluggish	H.265 GOP structure encode delay	Switch to Full NDI source if available. Use NDI HX3 minimum — avoid HX2 for latency-sensitive applications.
SRT stream delayed 1+ seconds	SRT latency setting too high	Measure round-trip time with ping. Set SRT latency to 4× RTT. For 50ms RTT set 200ms SRT latency — not 2000ms.
RTMP viewer sees 20–30 second delay	Platform CDN buffering	Enable "Ultra Low Latency" in YouTube Studio or Twitch dashboard. Accept 3–5 seconds as minimum — this is platform-imposed.
HLS player shows 30+ second delay	HLS segment size and playlist depth	Reduce HLS segment duration to 1–2 seconds. Implement LL-HLS. Or switch to SRT/RTMP for latency-sensitive delivery.
RTSP feed delayed in VLC	VLC default buffer	In VLC: Tools → Preferences → Input/Codecs → Network caching. Reduce from 1000ms to 100–300ms.
Hardware encoder adds unexpected delay	Encoder buffer depth or GOP size	Set GOP/keyframe interval to 1× frame rate (e.g. 60 for 60fps). Reduce encoder buffer depth in web GUI. Use H.264 over H.265 for lower encode latency.

Golden rule: Always measure your actual glass-to-glass latency with a reference clock — point both a camera and a display at the same clock, record with a phone camera, count the frames of difference. Manufacturer specs are best-case figures under ideal conditions. Real deployments are always higher.

07 Common Questions #faq

What is the minimum achievable glass-to-glass latency with IP video?

The minimum practical glass-to-glass latency with IP video is approximately 40ms using Full NDI on a well-provisioned Gigabit LAN with hardware designed for low-latency operation. This is achievable with Pro Convert encoders feeding vMix or OBS on the same local network with buffer depth minimised. Below 40ms requires uncompressed transmission — HDMI or SDI — as any compression codec introduces at least one frame of encode latency plus one frame of decode latency.

Why does my YouTube stream have a 20–30 second delay even though my encoder is fast?

The delay is caused by YouTube's CDN buffering, not your encoder. YouTube buffers between 15 and 30 seconds of video before making it available to viewers — this is designed to absorb network jitter and ensure smooth playback for millions of simultaneous viewers. Your encoder delivers the stream to YouTube's ingest servers in under a second. YouTube then holds it in a buffer before distributing it to viewers. The only way to reduce this is to enable Ultra Low Latency mode in YouTube Studio → Go Live settings, which reduces the delay to approximately 3–5 seconds at the cost of slightly reduced buffering stability.

What SRT latency setting should I use?

Set your SRT latency to 4 times your measured round-trip time (RTT). First measure the RTT by pinging the destination address — for example ping destination-ip. If the RTT is 50ms, set SRT latency to 200ms. If the RTT is 20ms on a local LAN, set 80ms. If the RTT is 100ms over the internet, set 400ms. Setting latency too low causes packet retransmission failures and stream corruption. Setting it too high wastes glass-to-glass latency unnecessarily. The 4× rule provides enough buffer for packet retransmission under typical network conditions with up to 5% packet loss.

Is Full NDI or SRT lower latency for local network use?

Full NDI is lower latency on a local Gigabit LAN — typically 40–80ms glass-to-glass compared to 80–220ms for SRT on the same network. Full NDI uses SpeedHQ intra-frame compression where every frame is independent, which means the decoder can display each frame immediately without waiting for reference frames. SRT uses H.264 or H.265 inter-frame compression with a GOP structure, which requires the decoder to wait for a keyframe before it can decode. For tally systems, confidence monitors and IEM feeds on a local LAN, Full NDI is the correct choice. For contribution over the internet or 4G, SRT is the only option.

Can I use IP video for in-ear monitoring or confidence monitors?

For in-ear monitoring (IEM), the answer is no — any IP video protocol adds too much latency. Performers can perceive audio delay above 30–40ms, and even Full NDI at its best adds 40–80ms glass-to-glass. IEM feeds must use SDI or HDMI direct connections. For confidence monitors in the same room, Full NDI at 40–80ms is borderline acceptable — most presenters tolerate up to 80ms before the lip-sync becomes distracting. For remote confidence monitors in other rooms or buildings connected over a LAN, Full NDI is the standard solution.

How do I measure glass-to-glass latency accurately?

The most reliable method is the clock test. Display a millisecond-accurate digital clock on a monitor connected to the source. Point your camera at the clock — the camera's output goes through your encoding pipeline to a display. Film both the source clock and the display simultaneously using a high-frame-rate smartphone camera (120fps or 240fps). Count the frame difference between the two clocks in the recording — each frame at 120fps equals 8.33ms. This gives you actual glass-to-glass latency for your specific hardware and configuration, which is always more accurate than manufacturer specifications.

08 Cite This Reference #cite

This data is freely available for use in articles, guides, system designs and educational materials. Please attribute iView Data as the source using one of the formats below.

Citation formats

APA

iView Data Ltd. (2026). Glass-to-Glass Video Latency Comparison — HDMI, SDI, NDI, SRT, RTMP and HLS. Retrieved from https://iviewdata.com/video-latency-comparison/

Chicago / MLA

iView Data Ltd. "Glass-to-Glass Video Latency Comparison — HDMI, SDI, NDI, SRT, RTMP and HLS." iviewdata.com, June 2026. https://iviewdata.com/video-latency-comparison/

Inline / journalist reference

According to latency reference data published by iView Data (iviewdata.com), Full NDI glass-to-glass latency on a Gigabit LAN is typically 40–80ms, compared to 5–30 seconds for standard RTMP delivery to consumer platforms…

HTML link

<a href="https://iviewdata.com/video-latency-comparison/">Glass-to-Glass Video Latency Comparison — iView Data</a>

Data is reviewed and updated periodically. Please link to this page rather than copying the data, so your readers always see the most current figures. All latency figures represent typical values under optimal conditions — real-world deployments may vary.

¹ Glass-to-glass latency figures represent typical values under optimal conditions on well-provisioned hardware. Camera sensor processing, display panel processing and cable propagation delay all contribute additional latency not listed in protocol specifications.

² Full NDI latency figures assume SpeedHQ intra-frame compression with buffer depth set to minimum. Higher buffer depth settings increase latency proportionally.

³ RTMP and HLS glass-to-glass totals are dominated by platform CDN buffering, which is controlled by the platform operator and may change without notice. YouTube, Facebook and Twitch latency figures reflect typical values as of June 2026.

⁴ SRT latency is fully configurable and should be set to 4× the measured round-trip time. The figures stated assume a 50ms RTT for internet and 5ms RTT for LAN.

⁵ NDI is a trademark of NewTek Inc / Vizrt Group. SRT is an open-source protocol maintained by the SRT Alliance. iView Data Ltd has no affiliation with these organisations.

Need Low-Latency Hardware?

Browse professional encoders, decoders and capture cards supporting Full NDI, SRT and ultra-low-latency IP video — from UK stock with same-day dispatch.

Browse Encoders & Decoders Ask a Technical Question

Related Guides

Sid Ahmed

Broadcast & Streaming Specialist — iView Data Ltd

20+ years experience in IP video, broadcast infrastructure and AV hardware. Sid specifies and supports Magewell encoding, NDI, SRT and low-latency IP video deployments for broadcast, corporate, education and medical clients across the UK and Europe.

Glass-to-Glass Video LatencyComparison — Complete Reference 2026