HLS and a third-party origin
If you're exclusively distributing HLS live media and want support for low latency, you need to configure a third-party origin and then apply it—and some more settings—in your AMD property.
How does it work?
Apple has updated the HLS specification to support low latency for HLS (LL-HLS). The update allows the segments at the live edge to be described as partial segments (“parts”). A properly enabled player can access the media data faster because it doesn’t have to wait for production of the entire segment. It can request one of these parts, instead.
Set up your AMD property
The LL-HLS specification and implementation details are evolving in real-time. What’s here represents current recommendations. This could change at any time.
Set up the appropriate rule and match criteria for requests that you want to add low latency support. In that rule, you need to set up specific behaviors. What’s covered here only describes the behaviors you need to enable LL-HLS support in an AMD property rule. See Define property configuration settings for full information on rule configuration.
Configure Origin Server
Since you're using your own unique origin to deliver live content, you'd select Your Origin and configure the applicable options.
You can't use NetStorage as your origin because this only applies to live media streams.
Configure Segmented Media Delivery Mode
Apply these settings in this behavior to support low latency:
- Set Mode to Live.
- Set Enable ULL Streaming to “On.”
See Segmented Media Delivery Mode and AMD for details on the remaining options.
Configure Content Characteristics
Apply these settings in this behavior to support low latency:
- Enable HLS. Set this to "Yes."
- Enable HDS. Set this to "No."
- Enable DASH. Set this to "No."
- Enable Smooth. Set this to "No."
See Content Characteristics and AMD for details on the remaining options.
If you'd like to deliver other media formats with this same property and still apply low latency for HLS, don't use the Default Rule. Set up a separate rule with unique match criteria, using all of the settings covered here to distribute HLS with low latency. Then, set up another separate rule with its own match criteria and different instances of these behaviors configured for the other media formats. Make sure Enable ULL Streaming is set to "Off" in that rule. You can't use the Default Rule, because it applies to all requests.
Configure Cache Key Query Parameters
An LL-HLS player asks for manifests explicitly using special _HLS
query parameters. So, you should include those query parameters in the cache key. The easiest way to catch them all is to add _HLS to the Parameters list, and then set Exact Match to “No.” This will catch any parameter that includes _HLS
.
Some packagers might require additional query parameters. For example, the Apple reference stream uses query parameters in segment requests. To ensure correct operation, these parameters need to be included in the parameter list.
Add HTTP/2
The LL-HLS specification requires HTTP/2. Add the HTTP/2 behavior to your AMD property. You’ll also need to serve content over HTTPS to support HTTP/2.
Configure Quick Retry
There are two ways that a manifest can describe the parts for LL-HLS:
-
DISCRETE mode. Each part can be addressed discreetly via a unique URL. This is the most common mode and all players support it. This is self-serviceable.
-
BYTERANGE mode. This lets you request HLS segment files at a byte-range offset. You’ll receive the data as it’s produced by the packager without having to request each individual byte-ranged part. This can reduce the number of requests from the client to the edge by 40%.
For DISCRETE Mode
Add the Quick Retry behavior to your rule and set it to “On.” This will help if a transfer appears to be struggling, by finding an alternative path.
For BYTERANGE Mode
Either remove the Quick Retry behavior from your rule or leave it in and disable it.
You should also enable support for RFC 8673.
The Quick Retry behavior is automatically included in the Default Rule for a new AMD property, and it’s set to “On.” If you’re using the Default Rule for this scenario, ensure it’s set to meet either DISCRETE or BYTERANGE modes.
Other recommended settings
Consider applying these additional settings to help with LL-HLS.
Tuning Read Timeout
The default read timeout with Enable ULL streaming set to “On” is 2 seconds at the edge and 1 second at the parent. The origin holds back requests for the duration of an individual part. So, this reduces the timeout window and can lead to false triggers. You can compensate for this by adding some extra margin to these values.
For example, assume you’re using 1 second parts. This could result in hold back times in the 950 - 980 millisecond range and result in occasional read timeouts. To avoid this, you can use a new millisecond resolution capability to add 500ms at the parent, like this:
<network:http.read>2s</network:http.read>
<match:request.type value="PARENT PEER_REQ">
<network:http.read>1500ms</network:http.read>
</match:request.type>
Work with your account representative to get this implemented with your AMD property.
The Allow-Timing-Origin header
For a web-based player, if you enable Timing-Allow-Origin headers, the player can access the Resource Timing API. This helps the player understand the hold back time (TTFB) and the actual download time, in order to make accurate bandwidth estimations.
-
Click Add Rule.
-
Select Blank Rule Template from the list.
-
Click Add Match.
-
Set the If parameters in the match to:
- Response Header
- Timing-Allow-Origin
- does not exist
-
Click Add Behavior.
-
In Search available behaviors, type "modify" and select Modify Outgoing Response Header from the list.
-
Click Insert Behavior.
-
Set Action to Modify and Select Header Name to Other…
-
In Custom Header Name, input "Timing-Allow-Origin".
-
Set New Header Value to “*” to serve as a wildcard for all values.
Understand Property Manager rule logic
Origin Server, Content Characteristics, and Segmented Media Delivery Mode are required behaviors that are automatically included and are required in the Default Rule. The Default Rule applies to all requests. If you add another rule to your AMD property and include these behaviors in that rule to support LL-HLS, a request that meets its match criteria will use that rule's behavior settings. However, if you add another rule and don't include these behaviors in it, requests that match that rule will use what you've set in the Default Rule for these behaviors.
Remember this logic when setting up your AMD rules for low latency support.
Additional resources
-
Enabling Low-Latency HLS. Apple developer documentation that offers a detailed explanation of this support.
-
Using LL-HLS with Byte-range addressing. This Akamai blog discusses how to use BYTERANGE mode to achieve interoperability in low latency streaming.
Updated over 1 year ago