What Is Video Latency? Streaming Latency By Protocol

Video latency, also called streaming latency, is the delay between when a camera captures a frame and when that frame plays on a viewer’s screen. Latency ranges from under 500 milliseconds with WebRTC to 30 seconds or more with standard HLS. Every stage of the streaming workflow can add to this live streaming latency, from ingest and transcoding to CDN delivery and player buffering.

This post breaks down how much latency each streaming protocol adds, why latency is hard to eliminate, how much latency Wowza Streaming Engine 4.12 adds to WebRTC, and how to reduce video streaming latency.

Key takeaways of this blog:

• Standard HLS and DASH deliver video in 10 to 30 seconds or more, LL-HLS in 2 to 5 seconds, and WebRTC in under 500 milliseconds.
• Segment length drives HTTP streaming latency, which is typically about three times the segment duration.
• Wowza Streaming Engine 4.12 only adds roughly 130 milliseconds to WebRTC streams in its default configuration, before network transit.
• Lower latency costs more per viewer, so the right protocol depends on whether the audience watches or interacts.

How Much Latency Does Each Streaming Protocol Add?

Streaming latency falls into four practical tiers. Standard Latency runs 10 to 30 seconds or more. Low Latency runs 1 to 5 seconds. Ultra-Low Latency runs under 1 second, sometimes under 500 milliseconds, hence why it is also called sub-second latency. The protocols at each stage of the workflow determine which tier a stream can reach. The table below lists the typical glass-to-glass range for each protocol, its primary role, and the Wowza source for each figure.

Why Is Latency Hard to Solve?

Latency is hard to solve because every stream crosses parts of the public internet that nobody on the operational side can control. The broadcaster controls the encoder and the media server, and the CDN controls its edge, but the viewer’s network round trip is dependent on the viewer. Each stage between camera and screen adds delay, and those delays compound into the final glass-to-glass latency. The pipeline breaks down into three major stages:

1. Ingest and Processing
2. Distribution
3. Playback

Managing buffering tolerances across all three of these pipeline stages is crucial. Every millisecond of latency introduced, especially at earlier stages, can have a sizeable and noticeable impact on the end viewer experience.

Lower latency requires smaller buffers, so reducing latency can come at the cost of some protection against network disruption.

Streaming Delay Causes During Ingest & Processing

During Ingest and Processing, the stream’s first hurdle is the initial encoding and transcoding process. After the camera captures footage, the encoder compresses it, and the transcoder converts it into multiple bitrates across an adaptive bitrate (ABR) ladder. Both steps add latency. For HTTP-based delivery, segment length has a direct impact on latency, whether the workflow uses 2-second or 6-second segments. The HLS specification, IETF RFC 8216, directs players not to start playback less than three segment durations from the end of the playlist. In other words, a standard 6-second segment results in roughly 18 seconds of glass-to-glass latency.

Encoding and transcoding also add a constant processing overhead. The encoder must process a chunk of video before it can output the first playable segment. Faster encoding presets reduce latency at the expense of video quality or file size. Higher-quality compression and more output renditions, like 1080p, 720p, and 480p, require more processing time. GPU acceleration reduces this overhead for high-volume workflows.

Where Distribution Adds Latency

Distribution delivers video segments to viewing devices, usually through a content delivery network (CDN). CDNs provide reliability and global reach by caching segments on edge servers close to viewers. This allows a CDN to absorb traffic spikes and serve millions of simultaneous viewers more reliably. HTTP delivery also requires the origin to finish each segment before the CDN can cache it, and players hold several segments in the cache. In older configurations with long segments, these combined effects can add 15 to 30 seconds to end-to-end latency.

Network conditions add delay as well. Congestion between data centers adds milliseconds, even in optimal conditions, and the last mile to each viewer adds a round trip that no streaming provider controls.

How Playback Adds Latency to Optimize Viewer Experiences

Finally, at the viewer’s end, Playback introduces the final opportunity for delay. Players are engineered to be robust against momentary network hiccups. Before starting playback, the player must load a minimum number of segments (often 2 to 3) to create a safe cushion of video data. This pre-loading creates a noticeable starting delay and adds to the overall operational latency. Buffers exist to smooth out packet jitter. The viewer’s device adds a final, smaller delay as it decodes each frame and renders it to the display.

How Much Latency Does Wowza Streaming Engine 4.12 Add to WebRTC?

Wowza Streaming Engine 4.12 adds roughly 130 ms of WebRTC latency in its default configuration and roughly 200 ms with packet loss recovery turned on, before network transit. Total glass-to-glass latency adds the network round trip between the publisher, the server, and the viewer. Both results sit well inside the sub-500-millisecond range that defines real-time WebRTC workflows. In Wowza Streaming Engine’s recent WebRTC benchmark, the network round trip alone accounted for 130 ms of a 258 ms glass-to-glass result. Any latency added at ingest creates downstream bottlenecks, because the origin server needs to wait for each segment to finish.

How Wowza Measured WebRTC Latency

Wowza engineers ran the WebRTC latency benchmark with the publisher and player on Windows 11 and Chrome over Wi-Fi in Uruguay, connected to Wowza Streaming Engine 4.12 on an AWS EC2 instance in the United States. The team screen-shared a running stopwatch from the publisher, played the stream back on the same machine, and recorded both windows at once. Glass-to-glass latency was calculated as the difference between the two visible clocks. The team took 20 paired readings per configuration, measured the network round trip with a ping to the server around each run, and subtracted the round trip to isolate the server-side latency.

A separate one-hour soak test with loss recovery on held at 340 ms glass-to-glass against a 158 ms round trip, so latency did not drift upward over a long session. This reflects one geography and one session per configuration with Wi-Fi at both ends. A wired connection would likely improve these results.

What Else Changed for Latency in 4.12

Wowza Streaming Engine 4.12 includes two more latency improvements:

• H.264 WebRTC ingest latency dropped by roughly 66 ms at 30 fps.
• Removed roughly 300 ms of latency when transcoding on NVIDIA GPUs.

Start a free 30-day trial of Wowza Streaming Engine to measure WebRTC latency on a specific network and workflow.

What Does Lower Latency Cost?

It costs more to deliver lower latency video streams at scale. Each protocol carries a different cost profile:

• HLS and DASH deliver cacheable segments that a CDN serves to any number of viewers from the edge, which keeps cost per viewer low at large scale, but at higher latency.
• LL-HLS and Low-Latency DASH split segments into partial segments and require frequent playlist updates, which increases requests to the CDN and origin and raises cost per viewer, while reducing latency compared to standard HLS and DASH.
• WebRTC holds a stateful connection between the server and every viewer, so server capacity scales with the number of concurrent viewers and video feeds are delivered in real time.

A broadcaster streaming a linear channel to a large public audience gains little from sub-second delivery and pays for it with every viewer. An operator steering a PTZ camera needs sub-second feedback for the workflow to function properly, and that audience stays small so costs are manageable. Many deployments serve both audiences from one source. Traffic management centers, for example, deliver WebRTC to operators and HLS to the public from the same traffic camera feed.

The Business Case for Sub-Second, Ultra-Low Latency

The push toward sub-second, ultra-low-latency streaming is a business imperative wherever a fraction of a second translates directly into revenue, safety, or engagement. Linear broadcasts tolerate up to 30 seconds of latency, but interactive, critical, and operational use cases require sub-second delivery.

Key Scenarios Where Delay is Costly

The core business benefit of sub-second streaming is eliminating the costs of delay: lost revenue, decreased productivity, or compromised safety.

Live Auctions, Real-Time Bidding, & Sports Betting

For platforms hosting live auctions of fine art, collectibles, or digital assets, sub-second streaming keeps bidding fair and timely for every remote participant. Any delay can mean a bidder misses the closing moment. This costs the auction house revenue and hurts the viewer experience. Immediate response also builds the urgency and excitement that drive bids. Sports betting platforms face a similar constraint and typically target 1 to 3 seconds of latency, because a delayed feed lets some bettors act on outcomes that others have not seen yet.

Remote Facility Surveillance & Operations

For monitoring critical infrastructure, manufacturing lines, or remote construction sites, latency directly affects response time and safety. Lower latency enables a prompt response to anomalies and security breaches, especially at remote facilities. In operational technology (OT) settings, where operators use live video to steer PTZ cameras or control machinery, near-instant feedback prevents errors and maintains precision. PTZ camera control, drone piloting, and industrial automation require streaming workflows that operate squarely in the under-200-millisecond latency tier.

Transportation & Traffic Cameras

Traffic management center operators use live camera video to adjust signal timing, dispatch emergency services, and divert traffic. A 10-second delay in spotting a sudden accident means a 10-second delay in dispatching help. Operators need sub-second video to act on what they see, while the public views the same cameras on 511 sites and travel apps where a few seconds of delay causes no harm. See how a state DOT cut camera management time from 50% to less than 1% without replacing a single camera.

How To Reduce Video Streaming Latency

Engineers can reduce latency in three ways. They can tune existing HTTP-based protocols, adopt protocols built for real-time performance, or adjust transport, encoding, and packaging settings across the workflow. In some cases, the right move means shifting from standard HLS or DASH to LL-HLS or WebRTC. Each choice involves trade-offs between compatibility, scale, and complexity.

HTTP-Based Streaming Innovations

Standard HTTP Live Streaming (HLS) and DASH are inherently high-latency due to their large segment sizes. However, industry innovators have developed extensions to make these protocols viable for low-latency delivery while retaining their massive scalability advantages.

Low-Latency HLS (LL-HLS) and Low-Latency DASH (LL-DASH) address the segment size problem directly. Apple folded LL-HLS into the main HLS specification in April 2020, and Low-Latency CMAF for DASH applies the same approach to MPEG-DASH. Both divide each segment into smaller partial segments, or chunks, that the server transfers as soon as they exist. Instead of waiting for a full 6-second segment, the player requests chunks as short as a few hundred milliseconds. This approach brings latency down to approximately 2 to 5 seconds, while keeping compatibility with existing CDNs and players. Wowza Streaming Engine generates LL-HLS streams through its CMAF packetizer.

Tuning standard HLS works in environments that don’t support the newer LL-HLS or LL-DASH specifications. This option manually reduces the segment size of standard HLS to 1 or 2 seconds. Tuning provides a quick latency win, but it introduces significant risks. The CDN has many more files to manage, which increases server costs and raises the risk of playback errors or stalling when network conditions are poor. HLS Latency Sucks, But Here’s How to Fix It walks through the Wowza Streaming Engine settings.

Ultra-Low Latency Standards

For mission-critical interactive applications where sub-second performance is mandatory, completely different protocols are required that bypass the limitations of segment-based HTTP streaming.

WebRTC (Web Real-Time Communication) is the leading sub-second protocol and delivers real-time video to any modern browser without plugins. It began as a protocol for two-way, peer-to-peer video conferencing, so it prioritizes instant delivery over large-scale distribution. WebRTC latency typically stays under 500 ms glass-to-glass, which makes WebRTC the standard for live video chat  and real-time surveillance or monitoring. The primary drawback is scale. HTTP-based protocols are stateless and easy to cache, while WebRTC typically runs over UDP and maintains a stateful connection for every viewer. A media server such as Wowza Streaming Engine solves this by accepting WebRTC ingest and repackaging the stream into HLS, LL-HLS, or DASH for larger audiences.

SRT (Secure Reliable Transport) reliably transports high-quality video over unreliable networks like the public internet. Teams typically use SRT for ingest or contribution, delivering the stream from the source to the origin server. SRT achieves latency of about 1 second by using fast retransmission to recover from packet loss without adding excessive buffering. Operators can tune the latency setting to trade speed against loss recovery.

Tune WebRTC Transport and Loss Recovery

Two Wowza Streaming Engine settings have the largest effect on WebRTC latency:

• UDP versus TCP transport. WebRTC over UDP delivers the lowest latency because it avoids TCP retransmission delays. TCP keeps WebRTC working on networks that block outbound UDP, such as corporate and campus networks, at the cost of added latency.
• NACK and RTX loss recovery. NACK requests retransmission of missing packets on the publish leg, and RTX retransmits lost packets to players. Leaving them off delivers the lowest latency on clean networks, while turning them on adds about 80 ms and stabilizes playback on lossy networks.

Optimizing Bandwidth for Latency vs. Reliability explains how to weigh speed against resiliency on constrained networks.

Tune Encoding, Transcoding, and Packaging

A keyframe interval, or Group of Pictures (GOP) size, of 1 to 2 seconds keeps HTTP latency low. Wowza Streaming Engine can’t create segments shorter than the GOP, so long keyframe intervals set the latency floor. Each transcode step also adds processing time. Passing renditions through where possible and using GPU acceleration both reduce that overhead. For hardware acceleration, Wowza Streaming Engine supports Intel Quick Sync Video, NETINT Quadra, and NVIDIA NVENC and NVDEC. Wowza’s LL-HLS guidance pairs a 2-second segment duration target with 500 ms video and audio chunks. For camera workflows, the RTSP protocol explainer covers how Wowza Streaming Engine ingests IP camera feeds for low-latency delivery.

Emerging Protocols

Media over QUIC (MoQ) is an open protocol under development. MoQ aims to combine sub-second latency with CDN-scale distribution. It uses a publish/subscribe model over QUIC, and relays forward media to subscribers the way a CDN fans out HLS. At NAB Show 2026, Wowza and Cloudflare demonstrated a Wowza Streaming Engine origin publishing CMAF over MoQ as a proof of concept. MoQ still has limited player and production relay network support, so it is not yet a full-fledged replacement for WebRTC for real-time delivery, or HLS for broad reach.

Mastering the Latency Trade-Off

The delivery protocol an architect chooses is one of the most critical decisions in a streaming workflow. The balancing act weighs latency against cost, scale, and complexity. From ingest through encoding, distribution, and final playback, every technical decision is a choice between speed and reliability, with low latency on one side, and high compatibility and stable playback on the other.

While protocols like standard HLS ensure massive global reach and highly stable viewing, they achieve this by intentionally introducing significant delay. On the other hand, cutting-edge protocols like WebRTC deliver the immediate, sub-second performance for near real-time interaction, but may not scale well on their own.

Therefore, the ultimate strategy for a successful live video infrastructure is supporting a wide array of protocols. The choice of protocol (such as WebRTC or LL-HLS) must align directly with the use case. If the goal is a non-interactive linear broadcast (like a TV channel), a low-cost, high-latency solution is sufficient. However, if interactivity is key, sub-second latency is non-negotiable. Taking advantage of both, leveraging WebRTC for ingest and HLS for delivery to public audiences, can yield significant benefits.

Identifying bottlenecks at every stage of the pipeline and matching each audience to the right protocol keeps latency within the range that is required. Wowza Streaming Engine experts offer demos of low-latency workflows tailored to specific applications, from real-time camera monitoring to large-scale live delivery. Get in touch today to schedule one.

Frequently Asked Questions About Video Latency

What is video latency?

Video latency is the delay between the moment a camera captures a frame and the moment that frame appears on a viewer’s screen. Engineers also call it streaming latency or glass-to-glass latency. It includes encoding, transcoding, packaging, network transit, CDN delivery, and player buffering, and it ranges from under 500 milliseconds with WebRTC to 30 seconds or more with standard HLS.

Does latency affect streaming quality?

Latency mainly affects how “real-time” a stream feels. High latency delays every event on screen, which disrupts live chat, bidding, betting, and remote camera control. Lower latency also shrinks the player buffer, so ultra-low latency streams have less protection against network disruption and can stall or drop resolution on unstable connections.

What causes streaming latency?

Streaming latency comes from every stage of the workflow. Encoding and transcoding add processing time, HTTP-based protocols wait for segments to finish, networks and CDNs add transit time, and players buffer several segments before playback starts. Segment length has the largest effect, and HTTP latency often equals about three times the segment duration.

What is a good latency for live streaming?

A good latency for live streaming depends on the use case. Linear broadcasts and large live events work well at 10 to 30 seconds with standard HLS. Interactive live events and sports betting typically target 1 to 5 seconds. Video conferencing, live auctions, and remote camera control need sub-second latency, typically under 500 milliseconds, which requires WebRTC.

How much latency does WebRTC add?

WebRTC typically delivers video in under 500 milliseconds glass-to-glass, compared with 2 to 5 seconds for LL-HLS. In Wowza’s benchmark, Wowza Streaming Engine 4.12 added roughly 130 ms in its default configuration and roughly 200 ms with packet loss recovery turned on. Total WebRTC latency is the server-side latency added to the network round-trip latency.

How do streaming platforms reduce latency?

Streaming platforms can reduce latency by switching to faster protocols such as LL-HLS or WebRTC, shortening segments and keyframe intervals to 1 to 2 seconds, and minimizing transcoding steps. For WebRTC, UDP transport with packet loss recovery turned off delivers the lowest latency on clean networks. Each reduction trades some resilience against network disruption for speed.