{"id":965,"date":"2026-04-23T10:02:31","date_gmt":"2026-04-23T03:02:31","guid":{"rendered":"https:\/\/liveapi.com\/blog\/what-is-video-latency\/"},"modified":"2026-04-23T10:03:03","modified_gmt":"2026-04-23T03:03:03","slug":"what-is-video-latency","status":"publish","type":"post","link":"https:\/\/liveapi.com\/blog\/what-is-video-latency\/","title":{"rendered":"What Is Video Latency? Causes, Types, and How to Reduce It"},"content":{"rendered":"Reading Time: <\/span> 11<\/span> minutes<\/span><\/span>

Video latency is the time between when a video is captured and when a viewer sees it on screen. For a football match, it’s the seconds between a goal being scored and the celebration reaching your audience. For a live auction, it’s the gap between a price changing and a bidder acting on outdated information.<\/p>\n

For developers building live streaming applications, video latency determines whether your product feels real-time or falls flat. A viewer engaging with chat who receives responses to questions that were answered 20 seconds ago, or a betting platform where odds on screen no longer reflect the actual game state \u2014 these aren’t edge cases. They’re product failures.<\/p>\n

This guide covers what video latency is, how it’s measured across your streaming pipeline, what causes it at each stage, and how to bring it down based on your specific use case.<\/p>\n

\n

What Is Video Latency?<\/h2>\n

Video latency<\/strong> is the total time delay between when a camera captures a video frame and when a viewer’s screen displays that same frame. This end-to-end delay is commonly called glass-to-glass latency<\/strong> \u2014 referring to the journey from the camera lens (one pane of “glass”) to the viewer’s display (the other).<\/p>\n

Glass-to-glass latency spans every stage in the streaming pipeline:<\/p>\n

    \n
  1. Camera capture<\/strong> \u2014 The camera sensor records a frame<\/li>\n
  2. Encoding<\/strong> \u2014 Raw video is compressed into a streamable format (H.264, H.265, AV1)<\/li>\n
  3. Ingest<\/strong> \u2014 The encoded stream is sent from the encoder to an origin server<\/li>\n
  4. Processing<\/strong> \u2014 The server segments and packages the stream<\/li>\n
  5. CDN delivery<\/strong> \u2014 Packaged content travels to edge servers worldwide<\/li>\n
  6. Network transit<\/strong> \u2014 Data crosses the internet to the viewer’s network<\/li>\n
  7. Decoding<\/strong> \u2014 The player decompresses the video<\/li>\n
  8. Rendering<\/strong> \u2014 The frame is displayed on screen<\/li>\n<\/ol>\n

    Each stage adds time. Glass-to-glass latency is the sum of all of them. Understanding which stages contribute most gives you a clear target for where to focus your efforts.<\/p>\n

    \n

    How Video Latency Is Measured<\/h2>\n

    The most direct way to measure video latency is the clock comparison method: display a running clock or timestamp on the source device, then photograph both the source screen and the playback screen at the same moment. The difference between the two displayed times is your glass-to-glass latency.<\/p>\n

    Wall-clock time<\/strong> is the reference point \u2014 the actual real-world time when content was captured. Comparing wall-clock time at capture versus wall-clock time at playback gives you a reliable latency measurement without specialized hardware.<\/p>\n

    For production monitoring, you can log ingest timestamps via API and compare them to the player’s reported playback position. This gives per-session latency data you can track over time and alert on when it drifts.<\/p>\n

    A practical shortcut during development: if you’re delivering via adaptive bitrate streaming<\/a>, most player SDKs expose a latency<\/code> or liveDelay<\/code> property you can read programmatically and log alongside other session metrics.<\/p>\n

    \n

    Types of Video Latency<\/h2>\n

    Video latency exists on a spectrum. The right target depends on your application \u2014 not every use case requires sub-second delivery.<\/p>\n\n\n\n\n\n\n\n\n\n
    Latency Type<\/th>\nDelay Range<\/th>\nProtocol Examples<\/th>\nTypical Use Cases<\/th>\n<\/tr>\n<\/thead>\n
    Real-time<\/td>\n< 300ms<\/td>\nWebRTC, WHIP\/WHEP<\/td>\nVideo calls, remote control<\/td>\n<\/tr>\n
    Ultra-low latency<\/td>\n300ms\u20131s<\/td>\nWebRTC SFU, SRT<\/td>\nInteractive streaming, gaming<\/td>\n<\/tr>\n
    Low latency<\/td>\n1\u20136s<\/td>\nLL-HLS, LL-DASH, SRT<\/td>\nSports betting, live shopping<\/td>\n<\/tr>\n
    Standard latency<\/td>\n6\u201330s<\/td>\nHLS, MPEG-DASH<\/td>\nBroadcast TV, live events<\/td>\n<\/tr>\n
    High latency<\/td>\n30s+<\/td>\nHTTP progressive<\/td>\nVOD, archived content<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Real-Time Latency (< 300ms)<\/h3>\n

    Above 300\u2013400ms, two-way conversations become uncomfortable \u2014 speakers overlap because they can’t gauge real-time feedback from the other side. WebRTC<\/a> is the standard protocol for sub-300ms delivery, transmitting media over UDP with minimal buffering. The tradeoff is scalability: WebRTC is designed for small-group sessions and requires a Selective Forwarding Unit (SFU) to reach large audiences without a massive server footprint.<\/p>\n

    Ultra-Low Latency (300ms\u20131s)<\/h3>\n

    Achievable with WebRTC SFU architectures or SRT ingest paired with aggressive player buffer tuning. Suitable for live events where viewers need to act on real-time information \u2014 live betting markets, real-time social interactions, or interactive gaming streams where a one-second lag breaks the experience.<\/p>\n

    Low Latency (1\u20136s)<\/h3>\n

    The sweet spot for most live streaming applications. LL-HLS<\/a> (Low-Latency HLS) and LL-DASH achieve 2\u20135 seconds in real-world deployments. This range supports large audience scales, works with standard CDN infrastructure, and covers a wide range of devices without requiring special player builds.<\/p>\n

    Standard Latency (6\u201330s)<\/h3>\n

    Traditional HLS streaming<\/a> operates here by default, with 6\u201310 second segments and 2\u20133 segment buffers. Sufficient for broadcast news and live events where viewer interaction isn’t the focus \u2014 the stream is live, but the exact timing gap doesn’t matter to most viewers.<\/p>\n

    High Latency (30s+)<\/h3>\n

    HTTP progressive download or large-segment HLS. Appropriate for VOD and pre-recorded content where real-time delivery is irrelevant.<\/p>\n

    \n

    What Causes Video Latency?<\/h2>\n

    Video latency builds up at every stage of your pipeline. Here are the five main sources.<\/p>\n

    1. Encoding and Compression<\/h3>\n

    Before a stream travels anywhere, the encoder compresses raw video frames into a format that can be transmitted over the internet. This takes time.<\/p>\n

    Two common encoding approaches:<\/p>\n