Configuration guidelines for live streaming

  Last updated August 09, 2018

The Fastly network can deliver live streams for any HTTP streaming technology, archived or recorded, on any public or private cloud storage service. When configuring VCL to deliver live streams, we recommend following these guidelines, which Customer Support can help you with.

Configure shielding

Configure shielding by designating a specific shield POP for your origin to ensure live streams remain highly available within the Fastly network. If your setup includes primary and alternate origins (e.g., for high profile live streams), be sure to select a shield POP, close to each origin, one for each origin you define.

Configure video manifest and segment caching TTLs

In live streams, video manifests are periodically refreshed when new segments become available, specially for HLS. We recommend setting manifest file TTLs to less than half of the video segment duration, typically 1-2 seconds for 5-second video segments. For long DVRs and live-to-VOD transitions, set segment TTLs longer on shields and shorter on edge POPs such that they are served from memory (that is, less than 3600s).

The following VCL sample may help you implement differnet TTLs for video manifest and segments. It can also be added to your service using VCL Snippets:

sub vcl_fetch {
#FASTLY fetch

  # Set 1s ttls for video manifest and 3600s ttls for segments of HTTP Streaming formats.
  # Microsoft Smooth Streaming format manifest and segments do not have file extensions.
  # Look for the keywords "Manifest" and "QualityLevel" to identify manifest and segment requests.
  if (req.url.ext ~ "m3u8|mpd" || req.url.path ~ "Manifest") {
    set beresp.ttl = 1s;
    return (deliver);
  else {
    if (req.url.ext ~ "m4s|mp4|ts|aac" || req.url.path ~ "QualityLevel") {
      set beresp.ttl = 3600s;
      return (deliver);

  return (deliver);

Optionally, identify video manifests and segments using the MIME type.

Configure lower TTLs for errors

By default, Fastly honors the Cache-Control header from the origin to set TTLs for cacheable objects. However, origins may not send Cache-Control headers for responses with non-200 or 206 HTTP status codes. As a result, Fastly will cache these responses with default TTLs, usually 3600s, to prevent large numbers of requests from hitting an origin simultaneously. For live streams, new video segments are added every few seconds. Typically, transcoders are configured to generate 5s segments and manifests are refreshed after each new segment is available. Any requests to unavailable segments or errors on manifests would cache the response, with default TTLs resulting in errors to every request for those objects until the cache TTLs expire, even though the same objects could have become available much earlier. Setting lower cache TTLs for these error responses help origins recover more quickly.

The following VCL sample may help you implement this or can also be added to your service using VCL Snippets:

sub vcl_fetch {
#FASTLY fetch

  # Set 1s ttl if origin response HTTP status code is anything other than 200 and 206
  if (!http_status_matches(beresp.status, "200,206")) {
    set beresp.ttl = 1s;
    return (deliver);

  return (deliver);

Configure Streaming Miss

Configure Streaming Miss to reduce the time clients (players) must wait to begin downloading streams when Fastly's edge servers must fetch content from your origin. Streaming Miss should be enabled for video or audio objects only (these are sometimes called "chunks" or "segments").

The following VCL sample may help you implement this. It can also be added to your service using VCL Snippets:

sub vcl_fetch {
#FASTLY fetch

  # Enable Streaming Miss only for video or audio objects.
  # Below conditions checks for video or audio file extensions commonly used in
  # HTTP Streaming formats.
  if (req.url.ext ~ "m4s|mp4|ts|aac") {
    set beresp.do_stream = true;

  return (deliver);

Configure automatic gzipping

Configure automatic gzipping for manifest files based on their file extension or content-type using the following table as a guide:

HTTP streaming format file extension content-type
Apple HLS m3u8 application/x-mpegurl, application/vnd.apple.mpegurl
MPEG-DASH mpd application/dash+xml
Adobe HDS f4m, bootstrap application/f4m (for manifest), application/octet-stream (for bootstrap)
Microsoft HSS N/A application/vnd.ms-sstr+xml

Configure a CORS header

Configure a CORS header on your service to play audio or video content on a different domain.

Enable TCP optimizations

Enable TCP tuning optimizations (e.g., CWND size) between cache servers and clients. For example, consider setting the CWND value higher, between 40-50. Enabling TCP optimizations allows clients to better estimate network bandwidth and thereby select the ideal rendition and bitrate for the best playback quality.

The following VCL sample may help you implement this. It can also be added to your service using VCL Snippets.:

sub vcl_deliver {
#FASTLY deliver

  # increase init cwnd
  if (client.requests == 1) {
    set client.socket.cwnd = 45;


Configure origin timeouts

Set appropriate origin timeouts to ensure new live video chunks and segments are fetched in a timely manner. Start by setting the First Byte (ms) and Between Bytes (ms) timeout values to less than half of the segment duration and then adjust the values accordingly to optimize them for your origin. For example, for a live stream configured with a 5s segment duration, you could start by setting both timeouts to 2000ms.

Consider setting up failover (fallback) origins

Consider configuring your VCL to allow your origins to failover from high-profile primary streams to alternate streams in case of encoder failures or other issues (e.g., high resource utilization).

Configure real-time log streaming

For troubleshooting and debugging any end-to-end live streaming latency issues (also known as "hand-waving latency" or "glass latency"), configure real-time log streaming and include TCP connection, caching, and different time-related metrics in vcl_log. For example:

These metrics can help you analyze throughput and may help you determine reasons a video player might switch quality levels during ABR playback.

Take advantage of surrogate key purging

All video segments and the manifest for a live stream can be purged using a single API call by using Fastly's surrogate key feature.

Manage live-to-VOD smoothly

Most encoders generate a separate video manifest when making the same live stream available for VOD. If your VOD manifest has the same URL as the live one, purge the live stream video manifest or wait for the caches to invalidate (as they will be set with low TTLs). If your setup archives the live stream as progressive mp4s, consider delivering them using Fastly's OTFP service.

Additional resources:

Back to Top