Understanding Live Broadcast Delays

Overview

When broadcasting a live event, it is normal to see a delay between what happens in real time and what viewers see on screen.

This delay is a standard and necessary part of RTMP → HLS streaming workflows, and is required to ensure reliable, high-quality playback across all devices and network conditions.
 

Where the Delay Comes From

1. Encoding and Uploading

Your encoder (e.g. Webcastcloud Live Studio, OBS, Zoom RTMP Broadcast or StreamYard) captures your live video and sends it to our servers using RTMP.

Before delivery, the video is:

• Received and stabilised
• Processed and transcoded into multiple qualities (adaptive bitrate streaming)

This ensures smooth playback across different devices and internet speeds, but adds several seconds of delay.

2. HLS Segmenting

HLS (HTTP Live Streaming) delivers video in small segments, typically 3–6 seconds each.

The video player:

• Waits for multiple segments before starting playback
• Continues downloading segments during playback

This buffering is essential to:

• Prevent stuttering
• Handle network fluctuations
• Maintain a consistent viewing experience

3. Device and Player Buffering

Each viewer’s device adds its own buffer before playback begins.

This varies depending on:

• Device type (desktop, mobile, smart TV)
• Browser or app behaviour
• Network conditions

Additional buffering helps prevent interruptions but contributes to overall delay.

4. Network and CDN Delivery

Live streams are distributed globally via Content Delivery Networks (CDNs).  
A CDN (Content Delivery Network) is a globally distributed network of servers that delivers video content from the nearest location to each viewer. This improves load times, reduces buffering, and allows live streams to scale to large audiences.

Factors that can impact delivery time include:

• Viewer location
• Internet speed and stability
• CDN routing and caching

While CDNs improve scalability and reliability, they can introduce a small additional delay.
 

How Viewer Timing Affects Delay

Latency can vary based on when a viewer joins the broadcast.

• Viewers who start watching at the beginning experience the lowest latency.
• Viewers who join later start playback a few segments behind because their player must buffer initial data before starting.

This design ensures reliable playback but means that late joiners will always be a few seconds further behind live than early viewers.

Example:

• Viewer A joins at the start → approximately 10 seconds behind live
• Viewer B joins mid-broadcast → approximately 12–15 seconds behind live

Delay Differences Between Viewers

Even within the same event, viewers may see slightly different timings.
This is affected by:

• Network connection speed or stability
• Device type (desktop, mobile, smart TV)
• Time of joining
• Pauses, refreshes, or reconnections during playback

If a viewer pauses the live stream, this will increase their delay. When playback resumes, the player continues from where it was paused, rather than jumping back to “live”.

This means:

• The delay can increase by the length of the pause
• In some cases, additional buffering on resume may add a few extra seconds
• The player may retain a small buffer of the live stream, so viewers remain behind live until refreshed

Minor differences in viewing delay are normal and expected in HLS-based streaming.

Typical Delay Ranges

Delays outside these ranges can occur depending on encoder settings, network conditions, and the location of the encoder. Viewer-side factors such as internet stability, device type, and playback behaviour can also impact overall delay.

Factors That Can Increase Delay

The following can increase playback delay beyond typical ranges:

• Pausing and resuming the video player
• Poor or unstable internet connection
• High bitrate or non-optimised encoder settings
• Long segment durations
• Background apps or device performance issues
• Running both the encoder and playback on the same device or network can introduce additional delay due to shared CPU, memory, and bandwidth usage.

Tips to Minimise Delay

While some delay is unavoidable, you can help optimise performance by:

• Using a stable, high-speed internet connection
• Avoiding pausing the player during playback
• Keeping encoder settings aligned with recommended configurations
• Refreshing the player if delay appears to increase over time
• Using modern browsers (e.g. Chrome, Edge, Safari)

Key Points

• A broadcast delay is normal and expected in RTMP → HLS streaming
• Typical end-to-end delay is ~10–15 seconds in optimised environments
• Delay varies by device, connection, and viewer behaviour
• This delay ensures stable, scalable, and high-quality playback
• When coordinating presenters, moderators, or Q&A, allow for this delay in timing

Why does this differ from platforms like Zoom or GoToWebinar?

Some platforms (such as Zoom or GoToWebinar) may appear to have lower delay.

This is because they use fully managed, real-time delivery systems within their own platforms.

By comparison, RTMP → HLS streaming workflows are designed to:

• Optimised for large-scale broadcast audiences
• Deliver consistent playback across all devices and network conditions
• Scale reliably via global CDNs

These benefits come with a slightly higher, but more stable delay, which is standard across the industry.  
If using Zoom RTMP broadcast to a third-party live streaming server, similar delay ranges are expected due to the same RTMP → HLS workflow.