If you're distributing DASH format live media and want support for low latency, you can use Media Services Live (MSL), and set it as your origin in your AMD property.

📘

This method is only supported for use with DASH media

If you’re using HLS, you need to use a third-party origin.

How does it work?

When using DASH as your import format for a live stream in MSL, ​Akamai​ makes it possible to apply an “aggregating response” to requests for your content. In essence, this breaks your content up into smaller “chunks.” This helps to reduce latency and decrease the overall transfer time of live streams.

The player doesn’t have to wait until the complete segment is available. Each chunk is preceded by its size in bytes and the transmission ends when a "zero-length" chunk is received. This helps with these common latency issues in a streaming platform:

• An on-premises encoder might post a segment to an ingest server only once that encoder has completely generated the segment.

• A player might only use a segment once it fully downloads that segment. Plus, a player might only start playing a video after it downloads a certain number of segments.

• The AMD property that's used to distribute your live content might buffer a certain amount of data. This low latency workflow skips this buffering, saving that time.

Set up MSL and AMD for low latency DASH

This process uses a combination of Media Services Live and Property Manager for your AMD property in ​Akamai Control Center​.

1. Create your Media Services Live stream. Set the Input Format to either:

   • DASH
   • CMAF (HLS &DASH). Select this only if you'll be packaging your DASH input format media using CMAF containers. AMD automatically recognizes the CMAF container and identifies DASH-format media for use.

2. Configure an origin for your stream. Make note of your Primary Hostname.

3. Configure your AMD property to use an MSL origin. Here, you edit a rule in your AMD property to apply specific behaviors. But, apply these specific settings:

   • Origin Server. Set Origin Type to Media Services Live and input the Primary Hostname you noted as the MSL Origin.
   • Segmented Media Delivery Mode. Ensure that Enable ULL Streaming is set to "On."
   • Content Characteristics. Set Enable DASH to "Yes." Set Enable HLS, Enable HDS, and Enable Smooth to "No."

👍

If you'd like to deliver other media formats with this same property and still apply low latency for DASH, don't use the Default Rule. Set up a separate rule with unique match criteria, using all of the settings covered here to distribute DASH 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.

4. Include the appropriate live-ull element in a player request path to achieve low latency. Optimizations are automatically applied to a playback URL if the request includes the appropriate media-format path element:

   • /dash/live-ull/*
   • /cmaf/live-ull/* (You’d only use this if you have DASH media included in a CMAF container.)

5. Publish your DASH stream in Media Services Live.

Best practices for DASH

Implement these best practices to get the most out of low latency streaming.

DASH and MSL

• Ensure that you access a low latency stream using only /live-ull to achieve the best end-to-end latency.

• If you access a low latency optimized stream using both a low latency optimized player (using the /live-ull URL) and a regular player (using the /live URL), ensure that the regular player doesn't access a partial segment.

• With a regular player and DASH streams, the player is more conservative in fetching the newest segment, so that the newest segment is always fully available.

CMAF content-specific

Stable latency reduction with CMAF is only achieved if these things are in place:

• The content in the CMAF segment needs to be chunked-encoded.

• The encoder needs to adjust its manifest or playlist production to accommodate and signal the usage of chunked encoding and early availability of the data.

• The encoder needs to push content to the origin using HTTP 1.1 chunked encoding transfer.

• The CDN needs to propagate this content all the way to the client using HTTP chunked encoding transfer at each step in the distribution chain.

• The player needs to time the request for the segment accurately and request the segment as close as possible to, but not before, the time when the origin begins receiving the segment.

• The player needs to decode the bitstream as it's received and not wait for the end-of-segment. HTML5 players operating in a browser must use Fetch rather than XHR API because Fetch supports reading the response body while the data is still being downloaded.

• The player needs to be set up to estimate throughput. This is because standard segment-timing techniques will fail.

• The player needs to have buffer and adaptation logic to cope with very low buffers.

• The player needs to have a catch-up feature in case it falls behind the actual live stream. This can happen when there are fluctuations in throughput.