Streaming configuration guidelines

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 different TTLs for video manifest and segments. It can also be added to your service using VCL Snippets:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

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 ~ "aac|dash|m4s|mp4|ts" || 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 non-200 or 206 HTTP status code responses. As a result, Fastly will only cache few status code responses with default TTLs configured, usually 3600s, to prevent large numbers of requests from hitting the origin. Uncacheable status code responses can be enabled for caching by setting beresp.cacheable flag to true.

For live streams, new video segments are added every few seconds. Typically, live stream transcoders are configured to generate 5s segments and manifests are refreshed after each new segment is available. Frequently, video players can make requests to segments not yet available or requests can return errors like 500 or 503 status codes. In such cases, status code responses should be made cacheable and should only be cached with TTLs small enough to give sufficient time for origins to recover (around 1s).

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

1
2
3
4
5
6
7
8
9
10
11
12

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;
    set beresp.cacheable = true;
    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:

1
2
3
4
5
6
7
8
9
10
11
12

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 ~ "aac|dash|m4s|mp4|ts") {
    set beresp.do_stream = true;
  }

  return (deliver);
}

Configure automatic compression

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

Configure CORS

Configure a CORS header on your service to play audio or video content on a different domain. Clients can potentially send CORS pre-flight requests to determine if the main request is OK to send.

By default, OPTIONS requests will pass to origin. Instead of this, we can respond with a synthetic response from the CDN. We also have an example for handling OPTIONS specifically with a synthetic. If allowing OPTIONS requests to traverse to the origin, we recommend caching OPTIONS requests.

Configure methods

With a media origin, the requests are typically only for GET and HEAD methods, so it's worth blocking other requests that are not expected by the origin. By default, Fastly will pass on GET, HEAD, and FASTLYPURGE methods. We can block all other requests by using custom VCL to send a 405 error back to the client:

1
2
3
4
5
6
7
8
9

sub vcl_recv {
#FASTLY recv

  if (req.method != "HEAD" && req.method != "GET" && req.method != "FASTLYPURGE") {
    error 405; # This is a `return(pass);` by default
  }

return(lookup);
}

Enable the experimental BBR congestion algorithm

The BBR TCP congestion control algorithm is an optional, TCP-related configuration that can help improve a client's experience. Unlike the default CUBIC congestion control algorithm, which is packet-loss-based and latency-insensitive, BBR is designed to maximize bandwidth while controlling latency.

You can implement this algorithm by adding the following VCL to your service using VCL Snippets:

1
2
3
4
5
6
7
8
9
10

sub vcl_deliver {
#FASTLY deliver

  # set congestion algorithm for client requests
  if (!req.http.Fastly-FF && client.requests == 1) {
    set client.socket.congestion_algorithm = "bbr";
  }

  return(deliver);
}

Configure origin timeouts

Set appropriate origin timeouts to ensure new live stream segments are downloaded from origin in a timely manner. For example, for a live stream with 5s video segments, set the Origin Connect value to 1s and the First Byte and Between Bytes timeout values to 2s. Typically, these values should be configured such that Fastly can also retry another origin (if configured) before sending the appropriate response on client requests.

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 live streaming delivery issues, configure real-time log streaming and include TCP connection, caching, and different time-related metrics in vcl_log. For example, consider including:

• fastly_info.state (cache hits or misses)
• client.socket.tcpi_rtt (client round-trip time)
• time.to_first_byte (time from client request to the first byte being received)
• time.elapsed (time since the request started, which can be used to calculate response time or time-to-last-byte for both origin and clients)
• client.as.number and client.as.name (autonomous system number and name associated with client IP)
• client.socket.tcpi_delta_retrans (number of packets re-transmitted to the client)
• client.socket.tcpi_snd_mss (maximum segment size used to send responses to client)
• client.requests (number of requests on a connection so far)
• client.socket.nexthop (network path Fastly is sending the client response)
• req.restarts (number of request restarts typically indicates retry attempts)
• server.datacenter (the Fastly POP that served the request)
• resp.http.content-length and resp.body_bytes_written (actual bytes sent to client compared to what was expected to be sent)

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.