End-to-end latency, sometimes called encoder-to-decoder latency, isolates the network and protocol portion of the chain. It is what you measure when you do not care about (or cannot control) the camera, the lens or the display. It is the natural unit for comparing two delivery protocols — HLS vs LL-HLS vs WebRTC — because each side of the comparison faces the same capture and render constraints.
The chain components are: encoder output buffer, contribution protocol (RTMP, SRT, RIST, WebRTC), origin/packager, CDN edge, last-mile network, decoder input buffer. Each adds latency: SRT typically 100–500 ms depending on retransmit window, packager adds a segment duration, CDN edge is bound by RTT and HTTP/2 head-of-line, and the player adds a buffer of 2–10 segments. The sum is what end-to-end measures.
A clean trick to measure it without specialised gear: timestamp every encoded frame with NTP time (most encoders can embed time-of-day metadata or SCTE-104), then in the player read the presentation timestamp and compare it to the wall clock. The difference is end-to-end latency. The result depends on clock sync quality, so most operations teams use a single NTP source for both encoder and player monitoring.
The book · Volume 2 of 7
Video Streaming: A Complete Guide to Video Delivery: From Network Protocols and Transport to Ingest, HLS, and MPEG-DASH
End-to-end latency isolates the network and protocol part of the delay, which makes it the fair number for comparing delivery options. Volume 2 covers end-to-end latency in detail: the glass-to-glass latency budget, live versus near-live delivery, TCP versus UDP, HLS, DASH and CMAF. Written by Nikolay Sapunov, CEO at Fora Soft.
Need to cut end-to-end latency without switching your whole stack?
We will measure end-to-end latency stage by stage in your pipeline and show which changes cut the most seconds. 250+ video products shipped since 2005.
